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.
At a glance
What this is: Bindplane says OpenTelemetry’s 2026 roadmap is centring on easier governance through declarative configuration, structured logging, eBPF instrumentation, and richer semantic conventions.
Why it matters: This matters because observability teams need telemetry pipelines that are standardised enough to govern, but flexible enough to support scale, cost control, and safer data handling.
Context
OpenTelemetry is becoming a governance problem as much as a telemetry standard. As more teams adopt shared SDKs, collectors, and instrumentation patterns, the real challenge is no longer whether data can be captured, but whether it can be configured, filtered, and interpreted consistently across languages and environments.
The article points to a familiar operating gap in observability programmes: telemetry grows faster than the controls around it. Declarative configuration, structured logging, and semantic conventions all help reduce fragmentation, but they also raise expectations that governance can be expressed as code, policy, and lifecycle discipline rather than manual tuning.
Key questions
Q: How should teams control observability data volume without losing useful signal?
A: Teams should use filtering, sampling, and enrichment to reduce low-value telemetry before it reaches downstream platforms. The goal is to control cost and keep pipelines manageable while preserving the data needed for monitoring, troubleshooting, and analysis. A single control plane also helps maintain consistent agent configuration and health across large environments.
Q: Why do structured logs and semantic conventions matter for observability governance?
A: Because governance depends on consistent meaning. If logs and attributes are unstructured or interpreted differently by each service, teams cannot reliably filter noise, enforce policy, or correlate events across traces and metrics. Structured logging and semantic conventions make telemetry machine-readable enough for repeatable operational and security decisions.
Q: What are the main risks of expanding eBPF-based telemetry collection?
A: The main risks are broader capture scope, weaker data minimisation, and more telemetry that may be unnecessary or sensitive. eBPF can improve visibility, but it also shifts the collection boundary closer to the runtime, so teams need tighter approval, retention, and access rules before scaling it widely.
Q: What should observability teams do before standardising OpenTelemetry across large fleets?
A: They should establish configuration ownership, schema standards, and exception handling first. Standardisation without governance often produces configuration drift in a different form, especially when multiple languages, teams, and deployment models are involved. The goal is a repeatable control plane, not just more consistent tooling.
Technical breakdown
Declarative configuration and observability standardisation
Declarative configuration shifts observability setup from ad hoc per-service tuning to centrally described, repeatable policy. In practice, that means SDKs and instrumentation can be aligned across languages without each team inventing its own collection logic. The governance value is not just convenience. It reduces configuration drift, improves onboarding consistency, and makes change control more realistic in large estates. The risk is that declarative models can create a false sense of uniformity if teams do not also manage versioning, policy review, and environment-specific exceptions. A standard config layer only helps when the surrounding operating model is equally disciplined.
Practical implication: Treat declarative observability config as a governed control surface, not just a developer convenience.
Structured logging and semantic conventions as data quality controls
Structured logging matters because observability tools can only govern what they can reliably classify. Nested fields, typed attributes, and stable semantic conventions reduce the translation work that usually turns logs into inconsistent free text. That improves correlation across traces, metrics, and logs, and it also supports better filtering for noisy or sensitive telemetry. Semantic conventions are especially important because they define shared meaning across components. Without them, the same event can be represented differently by different services, which weakens analytics and policy enforcement. The maturity signal here is not volume, but whether telemetry is machine-readable enough to support repeatable governance decisions.
Practical implication: Standardise logging schemas and semantic conventions before expanding collection scope.
eBPF instrumentation changes the collection boundary
eBPF instrumentation pushes telemetry collection closer to the runtime and the kernel, which can reduce dependency on intrusive application-level code changes. That makes it attractive for broad fleet coverage, especially when teams want visibility without reworking every service. But moving the collection boundary lower also changes the governance model. It becomes easier to observe more systems with less application friction, which raises questions about data minimisation, permission scope, and what should be captured by default. In other words, eBPF simplifies acquisition of telemetry, but it does not remove the need to decide which signals are legitimate, necessary, and safe to retain.
Practical implication: Review kernel-level telemetry as a policy decision, not only an instrumentation choice.
Threat narrative
Attacker objective: The primary risk is not a classic intrusion chain but uncontrolled telemetry growth that degrades governance, raises cost, and increases the chance of oversharing sensitive operational data.
- Entry occurs through expanded telemetry collection paths, where default instrumentation or broad runtime hooks increase the amount of data entering the observability pipeline.
- Credential or trust abuse appears when teams rely on implicit collection permissions and loose configuration boundaries instead of tightly governed instrumentation scope.
- Impact is telemetry sprawl, higher cost, and weaker control over what data is exported, retained, or interpreted across the platform.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Observability governance is becoming a control plane problem. OpenTelemetry’s 2026 direction shows that configuration, logging structure, and semantic consistency are now governance primitives, not just engineering preferences. Once telemetry is standardized across fleets, the organisation needs explicit rules for ownership, change control, and policy enforcement. The practitioner conclusion is that observability programmes should be governed like any other production control surface.
Structured telemetry is the real prerequisite for safe automation. The article’s emphasis on nested structures, richer attributes, and semantic conventions points to a broader pattern: automation only works when signals are machine-readable and semantically stable. This matters for security teams as much as SRE teams, because ambiguous telemetry cannot support reliable filtering, alerting, or compliance review. The practitioner conclusion is to prioritise schema discipline before automation depth.
eBPF will expand visibility faster than most governance models can absorb. Kernel-level and runtime-level collection can reduce deployment friction, but it also widens the default observation boundary. That creates a governance gap if data minimisation, retention, and access scope are still being handled as afterthoughts. The practitioner conclusion is to treat runtime telemetry expansion as a policy decision, not merely an engineering upgrade.
Telemetry quality is now a cost, risk, and trust issue at the same time. The article makes clear that bad telemetry is not only noisy, but also expensive or risky when it includes over-collected or sensitive data. That is a familiar control failure in large observability estates, and it increasingly intersects with identity and access governance wherever telemetry includes user context, service identity, or delegated access paths. The practitioner conclusion is to align observability governance with identity and data controls, not isolate it from them.
What this signals
Observability governance will increasingly be judged by how well it controls telemetry quality, not just collection breadth. As OpenTelemetry matures, teams will need to prove that the data they ingest is structured, necessary, and aligned to policy rather than simply available for analysis. That shifts observability leadership toward data minimisation, schema discipline, and access governance as core operating duties.
Declarative configuration is a governance opportunity only if it is paired with lifecycle control. Centralised definitions can reduce fragmentation, but they also create a new dependency on version management, change approval, and environment-specific exceptions. The practical signal for readers is clear: standardisation helps only when policy can move at the same speed as instrumentation.
Structured telemetry creates a better bridge between observability and identity governance. Once logs, traces, and metrics carry stable attributes, teams can correlate service behaviour with identity context more reliably and spot misuse or over-collection sooner. That makes telemetry design part of broader security architecture, not a separate tooling conversation.
For practitioners
- Define telemetry collection policy before scaling instrumentation Set explicit rules for what may be collected, from where, and for which environments so that observability growth does not become ungoverned data growth.
- Standardise semantic conventions across teams and services Use one convention set for core event types, attribute names, and logging structure so that correlation and filtering work consistently across the stack.
- Review eBPF rollout through a data minimisation lens Approve kernel or runtime-level collection only where the signal value justifies the broader capture boundary and associated retention scope.
- Treat structured logging as a governance control Make typed fields, nested structures, and consistent schemas part of your observability baseline so that policy enforcement and analytics remain reliable.
Key takeaways
- OpenTelemetry’s 2026 roadmap points to governance becoming a first-class observability requirement, not an afterthought.
- Declarative configuration, structured logging, and semantic conventions all reduce fragmentation, but they also demand tighter policy control.
- The practical priority is to standardise telemetry in ways that improve trust, reduce noise, and limit unnecessary data capture.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-01 — Policies, Processes and Procedures | Observability governance here depends on formal policy and repeatable processes. |
| PR.DS-01 — Data-at-rest is protected | Telemetry retention and storage need explicit protection because logs may contain sensitive data. | |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Observability platforms often expose sensitive operational data that needs scoped access. | |
| Recommendation — Define telemetry collection and retention policy as a governed process, then enforce it across observability pipelines. Protect stored telemetry with access controls and retention limits that match its sensitivity and purpose. Restrict telemetry access by role and purpose so only authorised users can query sensitive observability data. | ||
| CIS Controls v8 | CIS-5 — Account Management | Telemetry platforms need disciplined account and access governance across many operators and services. |
| Recommendation — Review observability platform accounts regularly and remove access that no longer matches operational need. | ||
| MITRE ATT&CK | TA0009 — Collection | The article centres on how telemetry is collected, shaped, and exported into observability systems. |
| Recommendation — Map collection paths to TA0009 and reduce unnecessary telemetry capture before it reaches the pipeline. | ||
Key terms
- Declarative configuration: Declarative configuration describes the state a system should have, rather than the steps needed to build it. In practice, this makes reviews easier, supports repeatable deployments, and gives security and identity teams a stable reference point for drift detection and rollback.
- Semantic Convention: A semantic convention is a shared naming standard for telemetry fields so different teams and tools record the same kind of data in the same way. For agent observability, it prevents fragmented attribute naming, improves cross-team analysis, and reduces the cost of re-instrumentation later.
- Structured Logs: Structured logs are machine-readable records that keep the same field layout across components and actions. They make it easier to trace a security workflow from detection to response, correlate events with metrics or traces, and investigate failures. For automated response systems, structured logs are a core operational control.
- eBPF Instrumentation: A low-level instrumentation method that collects runtime data close to the kernel or system layer with limited application changes. It expands visibility, but it also changes the governance boundary for what gets observed and retained.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management in a way that supports broader security and observability programmes. It is designed for practitioners who need to connect identity control with operational discipline across modern infrastructure.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org