---
title: "Beyond linkerd-viz: Linkerd Metrics with OpenTelemetry"
url: https://daily.dev/posts/beyond-linkerd-viz-linkerd-metrics-with-opentelemetry-q9azhj4i4
source_url: https://linkerd.io/2025/09/09/linkerd-with-opentelemetry
type: article
source: "Linkerd"
published: 2026-08-23T12:23:35.698Z
updated: 2026-08-23T12:55:39.429Z
tags: ["kubernetes", "infrastructure", "observability", "opentelemetry", "service-mesh"]
reading_time: 9
upvotes: 0
comments: 0
language: en
---

> ## Documentation Index
> Fetch the complete documentation index at: https://daily.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Beyond linkerd-viz: Linkerd Metrics with OpenTelemetry

**[Linkerd](https://daily.dev/sources/linkerd)** · 9 min read · 0 upvotes · 0 comments

## Summary

Linkerd's linkerd-viz dashboard relies on a Prometheus instance not meant for production, pushing many teams to route observability data into third-party APMs via OpenTelemetry instead. This walkthrough shows how to bypass linkerd-viz entirely by deploying an otel-collector configured with a Prometheus receiver to scrape Linkerd control-plane and data-plane pods directly, then export metrics via OTLP into OpenObserve (or any APM of choice). It covers installing OpenObserve via Helm, injecting Linkerd sidecars into workloads, and the full RBAC, ConfigMap, and Deployment YAML needed to wire the collector pipeline together, plus a note on securing metrics access with Linkerd's Authorization Policies.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://linkerd.io/2025/09/09/linkerd-with-opentelemetry>

## Questions this post answers

### How do I scrape Linkerd proxy metrics directly with an OpenTelemetry collector instead of using linkerd-viz?

Configure an otel-collector deployment with a Prometheus receiver whose scrape_configs target pods labeled with the linkerd-proxy container and linkerd-admin port using Kubernetes service discovery, then relabel the linkerd_io_ prefixed pod labels into clean metric labels. Export the results with an OTLP exporter to your APM of choice, such as OpenObserve, without needing the linkerd-viz extension or its bundled Prometheus instance at all.

_Teams wiring service mesh telemetry into their own observability stack can track this kind of setup on daily.dev._

### Why is the Prometheus instance included with linkerd-viz not suitable for production use?

The Prometheus instance bundled with the linkerd-viz extension is explicitly not appropriate for production workloads, which is why many organizations instead centralize telemetry in APM platforms like Datadog, New Relic, or Coralogix. To achieve that centralization, teams commonly use OpenTelemetry to collect and export Linkerd's request/response error, latency, and traffic volume metrics to their chosen vendor.

_Anyone weighing linkerd-viz against a dedicated observability pipeline can follow this comparison on daily.dev._

## Similar posts on daily.dev

- [OTel and mesh-derived metrics: A 2026 reference](https://daily.dev/posts/otel-and-mesh-derived-metrics-a-2026-reference-vrkb9i0np) · CNCF · 0 upvotes · 0 comments
- [OpenTelemetry: OTel Collectors in Kubernetes and VictoriaMetrics Stack integration](https://daily.dev/posts/opentelemetry-otel-collectors-in-kubernetes-and-victoriametrics-stack-integration-rv0ruemf6) · ITNEXT · 3 upvotes · 0 comments
- [Inside Adobe's OpenTelemetry pipeline: simplicity at scale](https://daily.dev/posts/inside-adobe-s-opentelemetry-pipeline-simplicity-at-scale-xbmirj76w) · OpenTelemetry · 7 upvotes · 0 comments

---

Tags: [#kubernetes](https://daily.dev/tags/kubernetes), [#infrastructure](https://daily.dev/tags/infrastructure), [#observability](https://daily.dev/tags/observability), [#opentelemetry](https://daily.dev/tags/opentelemetry), [#service-mesh](https://daily.dev/tags/service-mesh)

[View this post on daily.dev](https://daily.dev/posts/beyond-linkerd-viz-linkerd-metrics-with-opentelemetry-q9azhj4i4)