What are some of the limitations of Jaeger ?

 Limitations of using Jaeger as a distributed tracing tool

Jaeger is a preferred choice when it comes to distributed tracing. But engineering teams need more than traces to resolve issues quickly. They need access to both metrics and traces. Metrics such as response times, error rates, request rates, and CPU usage are equally important to understand application performance.

A few key challenges of using Jaeger as a distributed tracing tool are as follows:

Only provides trace data. You will have to use another tool for metrics and logs management.

Databases supported by Jaeger need active maintenance.

Jaeger's web UI is limited with basic visualizations.

Implementing distributed tracing in Jaeger - Sample App

Sample HotRod application

The sample HotRod application is a demo ride-sharing application. It shows four locations and by clicking on a location you call a ride to that location.

The sample HotRod application is a demo ride-sharing application. It shows four locations, and by clicking on a location, you call a ride to that location.

Steps to get started with Jaeger distributed tracing

In order to see how Jaeger is used for distributed tracing, let's run the demo application HotRod and see its traces using Jaeger.

Steps to run HotRod application with Jaeger:

The recommended way to run Jaeger is with a Docker image. If you don't have docker installed, install it from the official Docker website.

The HotRod application is implemented in Go, so you need to install Go.

Run Jaeger backend as an all-in-one Docker image with the following command:

docker run -d -p6831:6831/udp -p16686:16686 jaegertracing/all-in-one:latest

Once the container starts, you will be able to access Jaeger's UI at http://localhost:16686/search

Clone Jaeger's GitHub repo in local and change directory

git clone https://github.com/jaegertracing/jaeger.git

cd jaeger

Run the sample HotRod application

go run ./examples/hotrod/main.go all

You will be able to access the app UI at http://127.0.0.1:8080/

To see traces on Jaeger, we need to generate some load. Click on different locations a number of times. When you access the Jaeger UI now, you can find the list of services along with its trace captured on Jaeger.

Jaeger also creates a dependency diagram by tracing how requests flow and shows it in the dashboard. From the dependency diagram, we can see that the HotRod application has four microservices and two databases.

What is instrumentation? and how does it work in Jaegar ?

Instrumentation is the process of generating telemetry data(logs, metrics, and traces) from your application code. It is essentially writing code that enables your application code to emit telemetry data, which can be used later to investigate issues.

Most distributed tracing tools offer clients libraries, agents, and SDKs to instrument application code. Jaeger's client libraries for instrumentation are based on OpenTracing APIs.

OpenTracing was an open-source project aimed at providing vendor-neutral APIs and instrumentation for distributed tracing. It later got merged into OpenTelemetry. Jaeger has official client libraries in the following languages:

Go

Java

Node.js

Python

C++

C#

When a service is instrumented, it generates spans for incoming transactions and attaches trace context to outgoing transactions.

What is Jaeger UI ?

 Jaeger UI is the official, React-based web interface for Jaeger, a popular open-source distributed tracing platform. It serves as a visual dashboard for developers and engineers to monitor, analyze, and troubleshoot microservices and complex software architectures.Key Features of Jaeger UITrace Visualization: It allows you to see the entire lifecycle of a single user request as it travels across various microservices, databases, and internal function calls.Timeline and Flame Graph Views: Traces are displayed in easy-to-read timelines or flame graphs, breaking down exactly how much time each service spends processing a request.Root Cause Analysis: It helps pinpoint the exact service where a delay occurs or an error is thrown.Service Dependency Graph: It automatically generates a visual map illustrating how different microservices communicate and depend on each other.Trace Filtering: You can search for traces using exact criteria such as operation name, time elapsed (latency), tags, or log errors.How it Works Under the HoodYour application microservices are instrumented with tracing libraries (like OpenTelemetry).As a request travels through your system, the execution path is collected and stored.The Jaeger Query service reads this stored trace data and powers the UI, turning the backend JSON data into interactive charts.For a visual walkthrough of how to use Jaeger UI to trace errors and debug latency in a real-world application:

What is MCP

MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems.

Using MCP, AI applications like Claude or ChatGPT can connect to data sources (e.g. local files, databases), tools (e.g. search engines, calculators) and workflows (e.g. specialized prompts)—enabling them to access key information and perform tasks.

Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.

What can MCP enable?

Agents can access your Google Calendar and Notion, acting as a more personalized AI assistant.

Claude Code can generate an entire web app using a Figma design.

Enterprise chatbots can connect to multiple databases across an organization, empowering users to analyze data using chat.

AI models can create 3D designs on Blender and print them out using a 3D printer.

​

Why does MCP matter?

Depending on where you sit in the ecosystem, MCP can have a range of benefits.

Developers: MCP reduces development time and complexity when building, or integrating with, an AI application or agent.

AI applications or agents: MCP provides access to an ecosystem of data sources, tools and apps which will enhance capabilities and improve the end-user experience.

End-users: MCP results in more capable AI applications or agents which can access your data and take actions on your behalf when necessary.

The Model Context Protocol includes the following projects:

MCP Specification: A specification of MCP that outlines the implementation requirements for clients and servers.

MCP SDKs: SDKs for different programming languages that implement MCP.

MCP Development Tools: Tools for developing MCP servers and clients, including the MCP Inspector

MCP Reference Server Implementations: Reference implementations of MCP servers.

MCP follows a client-server architecture where an MCP host — an AI application like Claude Code or Claude Desktop — establishes connections to one or more MCP servers. The MCP host accomplishes this by creating one MCP client for each MCP server. Each MCP client maintains a dedicated connection with its corresponding MCP server.

Local MCP servers that use the STDIO transport typically serve a single MCP client, whereas remote MCP servers that use the Streamable HTTP transport will typically serve many MCP clients.

The key participants in the MCP architecture are:

MCP Host: The AI application that coordinates and manages one or multiple MCP clients

MCP Client: A component that maintains a connection to an MCP server and obtains context from an MCP server for the MCP host to use

MCP Server: A program that provides context to MCP clients

For example: Visual Studio Code acts as an MCP host. When Visual Studio Code establishes a connection to an MCP server, such as the Sentry MCP server, the Visual Studio Code runtime instantiates an MCP client object that maintains the connection to the Sentry MCP server. When Visual Studio Code subsequently connects to another MCP server, such as the local filesystem server, the Visual Studio Code runtime instantiates an additional MCP client object to maintain this connectio

Note that MCP server refers to the program that serves context data, regardless of where it runs. MCP servers can execute locally or remotely. For example, when Claude Desktop launches the filesystem server, the server runs locally on the same machine because it uses the STDIO transport. This is commonly referred to as a “local” MCP server. The official Sentry MCP server runs on the Sentry platform, and uses the Streamable HTTP transport. This is commonly referred to as a “remote” MCP server.

What is LiteLLM?

 

LiteLLM is an open-source AI gateway and Python SDK that allows you to call over 100 Large Language Model (LLM) APIs using a single, unified interface. It translates your requests into the specific formats required by various providers like OpenAI, Anthropic, Google Gemini, Azure, and AWS Bedrock.Key FeaturesDrop-in OpenAI Compatibility: You can swap LLM providers without rewriting your code; any model can be treated as if it were a standard OpenAI object.Spend Tracking: Accurately track API costs by key, user, team, or organization.Model Fallbacks: Set up rules so that if a primary model fails or is rate-limited, your application automatically routes requests to a backup model.Enterprise Security: Provides features like virtual API keys, rate-limiting, edge-level guardrails, and access control.Observability: Easily log your inputs and outputs to tools like Langfuse, Helicone, Lunary, and MLflow.How You Can Use ItPython SDK: Integrate it directly into your Python codebase for seamless, local script-based multi-model support.Proxy Server (AI Gateway): Deploy it as a standalone server to create a centralized API gateway for your entire organization, making it easy to manage users and budgets.For a quick beginner introduction to how LiteLLM standardizes the code for various models and providers:

OpenTelemetry Tracing

 OpenTelemetry (OTel) tracing is an open-source, vendor-neutral standard for monitoring requests as they flow through complex software systems. It tracks the exact path of a transaction, breaking down what happened, how long each step took, and whether the operation succeeded or failed.Core ConceptsTraces: A Trace represents the entire lifecycle of a single request or transaction from start to finish.Spans: The building blocks of a trace. Every individual operation, function call, or service request within a trace is captured as a Span. Spans contain metadata like start/end times, attributes (key-value pairs), and error statuses.Trace Context Propagation: This is the magic of distributed tracing. It passes a unique identifier (Trace ID) between different services and processes, ensuring that spans generated in separate microservices, databases, or servers are linked into one cohesive story.Why is it important?Modern applications, such as microservices, involve multiple networked components. When a problem or slowdown occurs, pinpointing the root cause is difficult. OTel tracing visualizes the end-to-end request path as a "waterfall diagram," making it easy to identify bottlenecks, diagnose latency, and track down errors.The OpenTelemetry AdvantageNo Vendor Lock-in: You instrument your code once using the OTel API and SDK. You can then send this data to any backend you prefer (e.g., Jaeger, Prometheus, Datadog) without having to rewrite your application code.Automatic Instrumentation: OTel offers libraries and agents that can automatically trace standard web requests, database queries, and framework calls without requiring you to manually write tracing code