OpenTelemetry is the modern instrumentation standard. Kubernetes is the modern compute substrate. Both generate rich observability data — and both are frequently treated as afterthoughts in monitoring platform design, handled by bolt-on integrations rather than native asset models.
This post covers what it means to treat OTel and Kubernetes as genuine first-class sources, not just data streams that arrive and get stored, but structured asset types with their own hierarchy, their own navigable dashboards, and their own relationships to the synthetic and infrastructure data already in the platform.
Start Here: What the Videos Cover
▶ Video 39 — “OpenTelemetry as a First-Class Source: Traces, Metrics, Logs Together”
▶ Video 40 — “Kubernetes-Native Observability: Cluster, Namespace, Workload”
OpenTelemetry: Ingestion, Not Just Export
The most important conceptual shift in thinking about OTel as a monitoring source is the direction of data flow. Most observability platforms treat OpenTelemetry as something they export to — they send their data out to OTel-compatible backends. A platform that acts as an OTLP receiver inverts that: instrumented applications push spans, metrics, and logs directly to the monitoring platform over gRPC or HTTP. No separate collector pipeline. No additional hop.
The operational consequence is significant. When OTel data and synthetic data share the same ingestion path, they share timestamp references, asset context, and alert routing from the moment they arrive. Cross-signal queries — “what was the application doing during the synthetic alert at 14:22?” — are single queries against a unified dataset, not federated lookups across two systems.
The Three Signal Types
| Signal | What It Captures | Best Question It Answers |
|---|---|---|
| Traces | The complete path of one request — every service, every span, with timing | Which service, which operation, which database call caused the latency? |
| Metrics | Aggregated time-series — request rates, error rates, latency distributions | How is this service performing over time, and is the trend changing? |
| Logs | Structured event records with context attached | What decision did the application make, and with what inputs? |
Synthetic as the Envelope, OTel as the Content
The clearest way to understand the synthetic/OTel relationship: synthetic measures the envelope of a request — did it arrive, did it return, how long did it take end-to-end? OTel measures the content — what happened inside the application to produce that response. A synthetic check that detects a 503 tells you the request failed. The OTel trace for the same request shows a downstream database span at 8,400 milliseconds — 28 times its normal duration. One signal finds the problem. The other locates it.
High-cardinality trace data requires sampling policy at the ingestion layer, not only at the SDK. A high-traffic service generating millions of spans per hour at full resolution is expensive to store and query. The practical approach: tail-based sampling that captures 100% of error traces and a statistical sample of successful ones. This preserves diagnostic coverage for failures — where full resolution matters most — while controlling cost for the successful-request majority.
Kubernetes: The Monitoring Assumptions It Broke
Traditional infrastructure monitoring was built on stable, long-lived assets: a server with a fixed IP, a fixed hostname, a fixed set of processes. Kubernetes invalidates all three. Pods are ephemeral — they can be terminated and replaced in under a second. Names rotate with rolling deployments. IP addresses change on every restart. A monitoring platform that tracks individual pod instances will spend most of its time tracking churn rather than measuring performance.
The correct unit of identity in Kubernetes is the deployment, not the pod. A deployment is persistent; pods are its disposable instances. Monitoring at the deployment level means tracking aggregate replica health, restart rates across the deployment, HPA scaling decisions, and resource utilization relative to configured limits — not individual pod lifetimes that may be measured in seconds.
Three Tiers of K8s Observability
Comprehensive Kubernetes observability requires visibility at three distinct levels, each answering a different question:
| Tier | Key Metrics | What a Problem Here Means |
|---|---|---|
| Cluster (control plane) | etcd latency, API server request rate, scheduler queue depth, controller manager health | The orchestrator itself is degraded — every workload in the cluster is affected |
| Node | kubelet health, container CPU/memory (cAdvisor), disk pressure, memory pressure, node NotReady status | One machine is degraded — all pods on that node are affected |
| Workload | Deployment replica count vs desired, pod restart rate, HPA scaling events, container resource limits vs actual | A specific application is degraded — users of that service are affected |
Namespace as a First-Class Asset
The Kubernetes namespace is the primary isolation boundary — and the natural unit of monitoring for multi-team and multi-tenant clusters. Treating a namespace as a first-class asset means it gets its own health summary: aggregate pod health, resource consumption, active error rates, and current alerts, rolled up to the namespace level without requiring per-pod queries. For a platform team managing 15 application teams sharing a cluster, namespace-level observability is what makes operational handoffs legible.
About Parlon
Parlon is an infrastructure observability platform built for enterprise teams operating complex, hybrid environments. Parlon combines active synthetic validation, real-time telemetry normalization, and learning-based alerting into a single platform — shifting operations from firefighting to foresight. Learn more at parlon.io.