Generating Service Metrics with Mesh Telemetry

You will collect and analyze golden signals like latency, traffic, errors, and saturation directly from the service mesh proxy layer.

In this lesson, you will learn how to leverage your service mesh sidecar proxies to automatically generate and collect the "Four Golden Signals" of observability without modifying your application code.

The Power of the Sidecar Proxy

In a service mesh architecture, every request entering or leaving your pod passes through the sidecar proxy (like Envoy in Istio). Because this proxy acts as the literal gateway for your application's network traffic, it occupies the perfect vantage point to observe every transaction. By configuring Mesh Telemetry, you instruct these proxies to record metadata about every request, effectively offloading the burden of monitoring from your application to the infrastructure layer.

Observing the Golden Signals

Instead of writing custom metrics libraries in your code, the proxy automatically aggregates the following signals:

Latency: The time it takes for a service to respond to a request.
Traffic: The demand placed on your service (e.g., requests per second).
Errors: The rate of requests that fail (e.g., 5xx status codes).
Saturation: How "full" your service is, measured by concurrent connections.

Implementation Pattern

By defining a Telemetry resource in your cluster, you tell the mesh to start scraping and reporting these metrics to a backend like Prometheus. For example, a basic telemetry configuration might look like this:

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: mesh-default
  namespace: istio-system
spec:
  metrics:
  - providers:
    - name: prometheus
      reportInterval: 10s

Once this is applied, the mesh sidecars begin exporting metrics in a standardized format. You can then point your Grafana dashboards at the Prometheus data source to visualize your service health in real-time. Because this is handled by the proxy, you get consistent, cluster-wide observability even if your microservices are written in different languages or frameworks. You no longer need to rely on individual teams to correctly implement instrumentation; the mesh provides a uniform "source of truth" for performance across your entire ecosystem.

Key Takeaway: Mesh Telemetry shifts the responsibility of service monitoring from the application code to the infrastructure, ensuring consistent Golden Signal collection via the sidecar proxy layer.