How do I view service mesh distributed traces?

Both Istio and Linkerd integrate with distributed tracing backends. Istio can send traces to Jaeger, Zipkin, or any OTLP-compatible backend by configuring a MeshConfig extensionProvider. Linkerd supports trace context propagation. To get end-to-end traces, your applications need to propagate B3 or W3C trace context headers when making outbound requests.

Service Mesh Monitoring: Complete Guide to Istio, Linkerd & Consul Connect in 2026

Q: What metrics does Istio expose by default?

Istio exposes a rich set of metrics via its Envoy sidecar proxies: request count (istio_requests_total), request duration (istio_request_duration_milliseconds), request bytes (istio_request_bytes), response bytes (istio_response_bytes), and TCP bytes (istio_tcp_sent_bytes_total / istio_tcp_received_bytes_total). All metrics include labels for source and destination workload, namespace, service, and response code.

Q: How does Linkerd monitoring differ from Istio?

Linkerd uses a Rust-based micro-proxy (linkerd2-proxy) rather than Envoy. It exposes golden signal metrics (success rate, requests per second, latency percentiles) automatically with no configuration. Linkerd's metrics are simpler than Istio's Envoy metrics but sufficient for most observability needs. Linkerd also includes a built-in dashboard via the linkerd viz extension.

Q: Do I still need application-level metrics if I have a service mesh?

Yes — service mesh metrics cover the network layer (request counts, latency at the proxy level, mTLS status). They don't capture business metrics (e.g., orders processed, user sign-ups) or application-internal metrics (queue depth, cache hit rate, database query time). A complete observability strategy uses both mesh-level metrics and application-level instrumentation.

Feature	Istio	Linkerd	Consul Connect
Built-in Golden Signals	✅	✅	✅
Built-in Dashboard	Kiali	linkerd viz	Consul UI
Distributed Tracing	✅ OTLP/Jaeger	✅ B3 propagation	✅ via Envoy
mTLS Observability	✅	✅	✅
Prometheus Integration	Built-in	linkerd viz install	Consul metrics
Proxy Type	Envoy	linkerd2-proxy (Rust)	Envoy

A service mesh abstracts network communication between microservices — but it also creates a rich observability layer. Istio, Linkerd, and Consul Connect all expose metrics, traces, and connection security status automatically, without requiring changes to your application code. This guide covers how to use that data effectively to monitor production systems.

What Service Meshes Monitor by Default

Every major service mesh injects a sidecar proxy alongside your application containers. That proxy observes all incoming and outgoing traffic and reports:

Request volume: Requests per second (RPS) per service-to-service edge.
Success rate: Percentage of requests returning 2xx vs. 4xx/5xx — the most important signal.
Latency percentiles: P50, P90, P99, P999 per service.
mTLS status: Whether connections are mutually authenticated (security posture visibility).
Retries and timeouts: How often the mesh is retrying or timing out requests (circuit breaker activity).

This is essentially the Four Golden Signals — latency, traffic, errors, and saturation — applied at every service boundary automatically.

Istio Monitoring

Key Istio Metrics

Istio's Envoy sidecars expose metrics at /stats/prometheus. The most important standard metrics:

istio_requests_total

Labels: source_workload, destination_service, response_code

Total request count by source, destination, and status code

istio_request_duration_milliseconds

Labels: source_workload, destination_service, response_code

Histogram of request latencies

istio_request_bytes

Labels: source_workload, destination_service

Request payload sizes (histogram)

istio_tcp_connections_opened_total

Labels: source_workload, destination_workload

TCP connection count for L4 traffic

Essential Istio PromQL Queries

# Success rate per destination service (last 1 minute)
sum(rate(istio_requests_total{destination_service_name="payments", response_code!~"5.*"}[1m]))
/
sum(rate(istio_requests_total{destination_service_name="payments"}[1m]))

# P99 latency for a specific service
histogram_quantile(0.99,
  sum(rate(istio_request_duration_milliseconds_bucket{
    destination_service_name="payments"
  }[5m])) by (le)
)

# Request rate per service (RPS)
sum(rate(istio_requests_total{destination_service_namespace="production"}[1m]))
  by (destination_service_name)

Kiali: Istio's Service Graph Dashboard

Kiali is the canonical Istio observability UI. It visualizes the service topology as a graph where edge thickness indicates traffic volume and edge color indicates success rate (green = healthy, red = high error rate). Install Kiali alongside Istio and connect it to your Prometheus instance for real-time service graph data.

📡 Monitor your services uptime every 30 seconds — get alerted in under a minute

Trusted by 100,000+ websites · Free tier available

Start Free →

Linkerd Monitoring

Linkerd's Golden Signals Dashboard

Linkerd's linkerd viz extension installs a Prometheus instance and a pre-built Grafana dashboard. The CLI also provides a real-time golden signals view:

# Real-time golden signals for all deployments
linkerd viz stat deployments -n production

# Per-route metrics for a specific service
linkerd viz routes svc/payments -n production

# Live tail of requests to a specific pod
linkerd viz tap deployment/payments -n production --to svc/database

Key Linkerd Prometheus Metrics

response_total

Total responses by classification (success/failure/l5d-proxy-error)

response_latency_ms

Latency histogram with source and destination labels

tcp_open_connections

Current open TCP connections (saturation signal)

route_response_total

Per-HTTP-route request counts (with ServiceProfile routes configured)

Consul Connect Monitoring

Consul Connect uses Envoy sidecars (same as Istio) and exposes metrics via the Consul agent. Consul's metrics cover both the service mesh layer and the service registry:

# Consul agent metrics endpoint (statsd format by default)
# Enable Prometheus metrics in consul agent config:
{
  "telemetry": {
    "prometheus_retention_time": "60s",
    "disable_hostname": true
  }
}

# Key metrics to watch:
# consul.health.service.passing   — services with passing health checks
# consul.health.service.warning   — services with warning health checks
# consul.health.service.critical  — services with critical health checks (alert on this)
# consul.rpc.request              — RPC request rate to Consul servers

Distributed Tracing in Service Meshes

Service mesh proxies can participate in distributed tracing but require application cooperation for end-to-end traces:

Critical: Header Propagation Required

Service mesh proxies inject trace headers (B3 or W3C) into incoming requests. For traces to be connected across services, your application code must extract these headers from incoming requests and inject them into all outgoing requests. Failing to propagate headers creates disconnected trace fragments.

Istio Distributed Tracing Configuration

# MeshConfig: configure Jaeger as the tracing backend
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    defaultConfig:
      tracing:
        sampling: 10.0  # 10% sampling rate
    extensionProviders:
    - name: jaeger
      opentelemetry:
        port: 4317
        service: jaeger-collector.monitoring.svc.cluster.local

Production Alerting Rules for Service Meshes

# Prometheus alert rules for Istio
groups:
- name: service-mesh
  rules:
  - alert: HighErrorRate
    expr: |
      sum(rate(istio_requests_total{response_code=~"5.*"}[5m]))
      /
      sum(rate(istio_requests_total[5m])) > 0.05
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Error rate > 5% in service mesh"

  - alert: HighP99Latency
    expr: |
      histogram_quantile(0.99,
        sum(rate(istio_request_duration_milliseconds_bucket[5m])) by (le, destination_service_name)
      ) > 1000
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "P99 latency > 1s for {{ $labels.destination_service_name }}"

  - alert: ServiceMTLSNotMutual
    expr: |
      sum(istio_requests_total{connection_security_policy!="mutual_tls"}) > 0
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "Traffic detected without mTLS"

📡

Recommended

Monitor the external endpoints your service mesh exposes

Better Stack monitors your ingress gateway URLs and external API health endpoints with 30-second check intervals. Complete the observability picture beyond the mesh.

Try Better Stack Free →

Service Mesh vs. Application-Level Monitoring

A common misconception is that a service mesh replaces application-level instrumentation. It doesn't — the two are complementary:

Service mesh monitors

Network-level latency (at proxy)
HTTP status codes at L7
mTLS and security policy compliance
TCP connections and bytes
Service-to-service topology

Application instrumentation monitors

Business metrics (orders/sec, checkout value)
Database query time (within the pod)
Cache hit/miss rates
Queue depth and consumer lag
Custom error types beyond HTTP status codes

Frequently Asked Questions

What metrics does Istio expose by default?

Istio exposes request count (istio_requests_total), request duration histogram (istio_request_duration_milliseconds), byte sizes (istio_request_bytes, istio_response_bytes), and TCP metrics. All include source/destination workload and namespace labels plus HTTP response code.

How does Linkerd monitoring differ from Istio?

Linkerd uses a lightweight Rust-based proxy and exposes simpler golden signal metrics (success rate, RPS, latency) with no configuration. Istio's Envoy sidecar provides more granular metrics but requires more resources. Linkerd's built-in linkerd viz dashboard provides immediate golden signal visibility; Istio's equivalent is Kiali.

Do I still need application-level metrics if I have a service mesh?

Yes — the mesh monitors network-layer metrics at the proxy. Business metrics (order volume, user sign-ups), internal latency (database query time, cache performance), and custom application errors are invisible to the mesh and require application-level instrumentation.

How do I get end-to-end distributed traces across a service mesh?

Configure your mesh to send traces to a backend (Jaeger, Tempo, Honeycomb). Critically, your application code must propagate B3 or W3C TraceContext headers from incoming requests to all outgoing requests. Without this propagation, traces from different services appear as disconnected fragments.