Linkerd runs an invisible proxy alongside every meshed service, so without mesh-level observability you can see what your services do but not how they talk to each other.
This integration uses the OpenTelemetry Collector's Prometheus receiver to scrape Linkerd's proxy and control plane metrics automatically, with no code changes and no per-service instrumentation. You get request rate, latency, and mTLS status for every meshed workload out of the box, and you can optionally add distributed traces that stitch mesh-level spans into the same waterfall as your application's APM traces.
Key benefits
- Mesh-level golden signals: See request rate, latency (p50/p95/p99), success rate, and TCP connections for every meshed workload, collected automatically without changing any application code.
- mTLS and security visibility: Track certificate expiry, rotation rate, and authorization allow/deny counts in one place.
- Control plane health: Monitor queue depth, live endpoint counts, certificate issuance rate, and proxy-injector activity for the Linkerd control plane itself.
- APM relationship visibility: When you enable distributed tracing (Linkerd 2.19+), Linkerd synthesizes proxy spans into the same entity as your APM services, so you don't need a separate tracing backend.
- Zero code changes: Every meshed pod's proxy sidecar exposes metrics on
:4191, and the OTel Collector scrapes them automatically.
Use case
If you're a platform or SRE team running Kubernetes-native microservices, mesh-level visibility helps you pinpoint the upstream service causing a latency spike, catch mTLS certificates before they expire, understand retry storms, and correlate control-plane load with application performance. You get all of this from a single New Relic entity.
Capabilities
- Metrics: request rate, latency (p50/p95/p99), success rate, and TCP connection stats for every meshed workload, plus mTLS certificate expiry and control-plane health, collected automatically with zero code changes
- Traces (optional, Linkerd 2.19+): Linkerd proxy spans synthesized into the same waterfall as your APM traces, so mesh-level latency and application-level spans show up together
- Logs:
linkerd-proxysidecar container logs attached to the same entity as the metrics and traces - Entities: a Linkerd entity per meshed workload, correlated with the underlying Kubernetes deployment
Choose your install path
- NRDOT with Helm (recommended): New Relic supported OpenTelemetry Collector distribution, installed the same way most Kubernetes users already manage Helm releases
- NRDOT with manifest: the same NRDOT collector, for clusters that manage config through raw Kubernetes manifests instead of Helm
- OTel Collector Contrib with Helm: the community OpenTelemetry Collector, if you're already standardized on it instead of NRDOT
- OTel Collector Contrib with manifest: the same community collector, manifest-based install
Installation at a glance
- Check compatibility and gather prerequisites
- Install the collector and configure it to scrape Linkerd
- Apply the minimum configuration
- Find and use the data in New Relic