Notifications
Clear all
Topic starter
18/08/2026 2:56 pm
TL;DR: OpenTelemetry’s 2026 roadmap points to declarative configuration, broader eBPF instrumentation, stabilized structured logging, and richer semantic conventions, according to Bindplane’s KubeCon recap. For practitioners, the real issue is not feature volume but whether telemetry governance can keep pace with faster onboarding, cleaner signals, and lower-risk collection.
NHIMG editorial — based on content published by Bindplane: OpenTelemetry updates and Observability Day highlights from KubeCon + CloudNativeCon North America 2025
By the numbers:
- Real-world traces are massive, with around 200 attributes on median spans and 40,000-plus on p99 spans.
- Typical traces range from 50 to 500 KB, while some outliers reach 20 MB or more.
- 95%, verting time series into tiny ASCII line charts reduced token count by about 95%, from 122,000 to 372.
Questions worth separating out
Q: How should teams govern OpenTelemetry configuration across many services?
A: Treat OpenTelemetry configuration as a policy-controlled production asset.
Q: Why can richer telemetry create security risk instead of just better visibility?
A: Richer telemetry increases the chance that secrets, identifiers, or privileged context are captured and propagated into multiple systems.
Q: What do security teams get wrong about observability in delivery pipelines?
A: They often stop at infrastructure telemetry and miss identity context.
Practitioner guidance
- Govern collector configuration as a production control Place OpenTelemetry SDK, collector, and pipeline configuration under change control, with approvals, rollback, and audit trails equal to other production policy updates.
- Minimise telemetry before export Apply filtering, schema enforcement, and redaction at the earliest practical stage so sensitive fields do not fan out across logs, traces, and downstream analytics.
- Separate runtime visibility from broad access Limit who can enable profiling, inspect high-cardinality traces, or export diagnostic payloads, especially where service context or privileged data may be present.
What's in the full article
Bindplane's full article covers the conference-level product and community detail this post intentionally leaves for the source:
- Community call footage and floor interviews from KubeCon that show how practitioners are discussing OpenTelemetry adoption in practice
- Session-by-session talk notes on AI trace analysis, profiling, and structured logging from the event agenda
- Bindplane's own recap of Fleets and Blueprints with OpAMP, including the operational workflow behind large collector management
- Conference atmosphere, booth interactions, and maintainer conversations that are useful for context but not for implementation planning
👉 Read Bindplane’s recap of OpenTelemetry updates and KubeCon observability sessions →
OpenTelemetry’s roadmap shift: what it means for observability teams?
Explore further
18/08/2026 3:38 pm
Telemetry governance is becoming part of identity governance. OpenTelemetry is no longer just an engineering standard for metrics and traces. Once telemetry pipelines carry richer runtime data, teams must govern who can configure, read, and export that data with the same seriousness they apply to privileged access elsewhere. That makes the control plane, not just the data plane, the security boundary.
A question worth separating out:
Q: How do identity and access controls apply to telemetry systems?
A: Telemetry systems have their own privileged users, service accounts, and pipeline permissions. Teams should assign explicit roles for collector administration, data access, and export controls, then review those rights periodically. This reduces the chance that a debug workflow becomes an open channel to sensitive production data.
👉 Read our full editorial: OpenTelemetry’s 2026 roadmap points to easier observability governance
