Modern cloud-native architectures rely heavily on distributed tracing and metric collection systems like OpenTelemetry. While standard instrumentation provides deep insights into service logic via traces, logs, and custom metrics, there is a critical blind spot: the east-west traffic occurring between services within your mesh. Linkerd's proxy layer captures this network-level telemetry automatically once workloads are deployed to an environment like K3s or Kubernetes clusters.
Understanding Signal Overlap
The OpenTelemetry specification defines three primary signal types that form the backbone of modern observability stacks: traces, metrics, and logs. Traces follow a request across service boundaries to construct full call graphs essential for debugging latency issues in microservices architectures like Astronomy Shop demos or production Kubernetes clusters running Linkerd 2.19+. Metrics capture numeric measurements over time using counters, gauges, histograms, and summaries.
When you instrument an application with OpenTelemetry SDKs, the agent emits data based on code instrumentation points defined within your service logic. However, this approach requires rebuilding images or adding sidecar proxies to every workload manually.
- **Traces** provide end-to-end request flow visibility across distributed systems.
Metrics offer quantitative performance baselines for capacity planning and anomaly detection.
Logs capture structured events emitted by your application code at specific points in execution flows.
The mesh-derived metrics from Linkerd fill the gap left by standard OpenTelemetry pipelines, specifically capturing inbound and outbound request counts without requiring any changes to source code or image rebuilds.
Architectural Integration Strategies
To effectively combine these data sources into a single backend pipeline like VictoriaMetrics with Grafana dashboards requires careful configuration of the OpenTelemetry Collector. The collector acts as an aggregation layer that receives signals from both application-side SDK instrumentation and sidecar proxies running in your mesh environment.
When configuring Kubernetes, you typically deploy the OTel Collector DaemonSet to scrape metrics directly from Linkerd proxy endpoints exposed via Prometheus-style scraping ports.
The integration process involves mapping incoming requests captured by the proxy into standard metric formats compatible with existing dashboards. This ensures that every request entering your service mesh generates golden baseline data immediately available for analysis.
For engineers preparing for Kubernetes certifications, understanding how to wire these disparate sources together is essential.
The resulting dashboard view combines high-level application metrics with low-level network telemetry, giving you a complete picture of system health from the kernel up through business logic layers.
Operational Benefits and Use Cases
In production environments where teams manage complex microservices architectures using tools like K3s or standard Kubernetes distributions on edge nodes running Linux-based containers.
The ability to observe traffic patterns without code changes is particularly valuable during incident response scenarios. When a service experiences elevated latency, having access to both application-level traces and network-layer metrics allows engineers to distinguish between issues caused by backend processing delays versus saturation of the underlying mesh infrastructure.
This dual-source approach supports advanced troubleshooting workflows common in DevOps teams managing large-scale distributed systems.
The setup described here uses K3s v1.34.6 as a single-node reference environment, Linkerd 2.19+ for service discovery and traffic management functions within the mesh layer itself.
What This Means For You
By integrating these two distinct observability layers into your existing pipeline architecture, you gain immediate visibility into previously hidden network-level behaviors without disrupting ongoing development cycles or requiring extensive refactoring efforts across multiple services.
The combination of application-defined metrics and mesh-derived telemetry provides a holistic view necessary for maintaining high availability standards in cloud-native deployments. Engineers should ensure their monitoring stacks are configured to ingest both signal types simultaneously, leveraging the OTel Collector's ability to normalize diverse input formats into unified metric streams ready for visualization tools like Grafana.