The Linkerd viz dashboard’s topology view doesn’t just draw a pretty picture; it’s actively calculating and rendering the actual real-time traffic flow and health of your service mesh, not just a static representation of your pods.
Let’s watch it in action. Imagine you’ve got a simple microservice setup: a frontend service talking to a backend API, and the backend API talking to a database.
Here’s a snippet of what the topology might look like:
(frontend) -- 99% success --> (backend-api) -- 98% success --> (database)
You’d see boxes for frontend, backend-api, and database. Lines connecting them represent traffic. The percentages are live success rates. If frontend suddenly starts failing to reach backend-api, that line would turn red, and the percentage would plummet.
The real magic isn’t in the drawing, but in how Linkerd collects and aggregates this information. Each Linkerd proxy (the little sidecar container running next to your application containers) is a telemetry gatherer. It observes every incoming and outgoing HTTP/gRPC request.
These proxies send their telemetry data (request counts, success/failure counts, latencies) back to the Linkerd controller’s Prometheus instance. The viz dashboard then queries this Prometheus database to build its view.
So, what are the key components you control and observe here?
- Services: The boxes in the diagram. These correspond to Kubernetes
Serviceobjects. Linkerd infers these from the target IP addresses of the requests observed by the proxies. - Pods: While not directly drawn as boxes, the traffic flowing between services is ultimately originating from and destined for specific pods running those services. When a service is scaled up or down, or a pod restarts, the topology view dynamically updates to reflect the current state.
- Linkerd Proxies: These are the unsung heroes. They are injected into your pods and are responsible for all inter-service communication. Their configuration (like their resource limits) can indirectly affect the accuracy and timeliness of the telemetry data.
- Success Rate & Latency: The metrics displayed on the lines. These are critical indicators of service health. A dip in success rate or a spike in latency on a particular link immediately flags a problem.
The topology view is powered by a combination of Kubernetes service discovery and the telemetry collected by the Linkerd proxies. When a proxy sees a request going to 10.0.1.5, it looks up which Kubernetes Service that IP belongs to (or if it’s a direct pod-to-pod communication). It then aggregates metrics for all requests directed to that service.
Consider the case where you have multiple pods backing a single Kubernetes Service. The Linkerd proxy doesn’t necessarily distinguish which specific pod on the other end received the request for the purpose of the service-level topology. It aggregates the metrics for the service as a whole. However, if you drill down into a specific service, you can see per-pod metrics, revealing if one particular pod is the source of errors.
The most surprising thing about the topology view is how it handles traffic that isn’t going through Linkerd. If you have a service that directly accesses a database outside the mesh, or a legacy service that hasn’t had the proxy injected, it will appear as an "unknown" or "external" entity on the edge of your topology. Linkerd is smart enough to show you what’s not being meshed, highlighting potential blind spots in your observability.
The next concept you’ll want to explore is how to integrate custom metrics into this view, allowing you to visualize business-level KPIs alongside network performance.