Welcome to the October 2026 edition of the OpenTelemetry News!
This month, the Java agent gives you a way to test its upcoming 3.0 defaults before they land, OBI learns to stamp trace context onto logs without touching your applications, and the eBPF profiler ships thread context support across three languages. The Collector's 0.164.0 release brings Go security fixes alongside stabilized Prometheus defaults. The Governance Committee election has concluded, with results announced October 30.
Highlights
Preview the OpenTelemetry Java agent 3.0
The 2.32.0 release of the Java agent is the release candidate for 3.0, which is targeted for October 2026. Version 3.0 changes telemetry, configuration, and instrumentation defaults: database and code semantic conventions become stable defaults, messaging adopts newer conventions that are still experimental, and some instrumentations (Hibernate, Hystrix, and Twilio) are turned off by default. Expect renamed attributes, such as db.system values like mssql becoming microsoft.sql_server, code.namespace and code.function consolidating into code.function.name, and connection-pool duration metrics moving from milliseconds to seconds. Zipkin exporter support, deprecated in earlier releases, is now removed in preview mode; the recommended path is OTLP, which the agent has supported since 2.x, so existing Zipkin configurations should migrate before upgrading to 3.0.
To see how this affects your dashboards and alerts, the post recommends first comparing old and new telemetry with dual emission (OTEL_SEMCONV_STABILITY_OPT_IN=database/dup,code/dup and OTEL_SEMCONV_STABILITY_PREVIEW=messaging/dup), then testing the combined preview with OTEL_INSTRUMENTATION_COMMON_V3_PREVIEW=true. Some behavior may still change before the final release, so please open issues on the repository if you hit problems.
Zero-code trace-log correlation with OBI
OpenTelemetry eBPF Instrumentation (OBI) can now add trace_id and span_id to logs your services already write, with no SDK, logging-library configuration, or redeploy. OBI uses eBPF to see which request a thread is serving when it writes a log line, then annotates JSON, NDJSON, and plain text lines before they reach your container logging pipeline. The IDs match the ones on OBI's own spans.
The feature is opt-in and comes with constraints worth reading before you roll it out. It only covers logs written to stdout or stderr, only for lines written while OBI is tracing a request, and it requires CAP_SYS_ADMIN. Each enriched line replaces the original with a NUL-byte placeholder, which means the log shipper needs a filter that drops those records. The post recommends starting with a single low-risk service.
OpenTelemetry Profiling SIG update
The eBPF profiler has shipped thread context support for Java, Go, and PHP across a series of pull requests by Nicolas Savoire, merged October 14 through 20, laying the infrastructure for per-thread correlation with no in-band coupling between the profiler and the SDK. The same series removed the legacy APM integration it replaces, and added a design doc for Node.js thread context to extend the approach to more runtimes.
The work implements the context-sharing standards approved this year and mentioned in the July edition. Process context (OTEP 4719) shares resource attributes with external readers; thread context (OTEP 4947) shares thread-level information such as the active trace and span identifiers. Both were written for external readers like the eBPF profiler, which operate outside instrumented processes and previously could not see the context configured inside them. The ProcessContext message shipped in the protocol definitions, and opentelemetry-ebpf-instrumentation followed with the first implementation.
The final part of the series, which reads the thread context at unwind time, is in review, with Java's end-to-end validation pending. When it lands, a profile sample will link to the trace that was running when it was collected, using only published standards.
New Collector releases
This news edition covers the OpenTelemetry Collector releases 0.163.1, 0.163.2, and 0.164.0.
Security
Action required: release binaries are now built with Go 1.26.10, which includes the crypto/x509 security fixes released on 2026-10-19, and the updated CA bundle removes the distrusted eMudhra emSign roots, including emSign ECC Root CA - G3 (#1722). Container images now require Alpine ca-certificates 20261020-r0 or later, so refresh your base images if you build custom distributions. v0.163.2 carries the same Go and CA updates for the 0.163 line (#1723).
Breaking changes
Prometheus label sanitization stabilizes with new defaults (#52206): leading and consecutive underscores are now always preserved in label names in the prometheus and prometheus_remote_write exporters. The -pkg.translator.prometheus.PermissiveLabelSanitization feature gate is gone; disabling it now causes a startup error.
Several translators flip to current semantic conventions by default (#52096, #50909, #45293): the Azure logs and Zipkin translators now emit code.function.name, code.file.path, http.response.status_code, and otel.scope.name instead of their deprecated predecessors, and the goldendataset test helper generates current HTTP attributes, with each change revertible via the corresponding feature gates.
receiver/file_log checkpoints are now always written as protobuf; existing JSON checkpoints are still read and rewritten on the next save, per #43266 and #52037. On the project's benchmarks, saving a checkpoint is almost 5 times faster and the checkpoint itself is about 35% smaller. The mongodb.operation.latency.time metric becomes a monotonic cumulative sum, matching its semantics in the MongoDB profiler (#51909). receiver/kubelet_stats removes six deprecated resource attributes including aws.volume.id and fs.type (#40477). processor/drain rejects invalid configurations at startup instead of at first use (#51677), and the stable ottl.set.allowNil gate is removed (#48714).
New components
Three widely used Contrib components join the core distribution as stabilization priorities: the file_log receiver, resource_detection processor, and transform processor (#44130). Moving into the core distribution means these components will follow core's stability guarantees and ship in the core binary, making them a reliable foundation for production pipelines. The v1 core distro RFC proposes marking the core distro and all Phase 1 high-priority components as v1 by KubeCon Europe 2027.
extension/redis_fleet_tracker reports a collector fleet's live member count, so adaptive_tail_sampling can treat goal_throughput as a fleet-wide budget (#50577). processor/verify arrives as the verification counterpart to September's processor/signing, checking RFC 8785 canonical integrity attributes on log records (#51383). The gnmi receiver reads telemetry from network devices over gNMI (#50848), the nats receiver ingests traces, metrics, and logs from a NATS server (#50735), and the partitioning processor joins the Contrib distribution (#1727).
The OpenTelemetry Transformation Language (OTTL) reaches v1, meaning it is stable for traces, metrics, and logs with a compatibility promise for all of 1.x.
Deprecations
The Kafka receiver's built-in jaeger_proto, jaeger_json, and json log encodings are deprecated in favor of the dedicated encoding extensions, and partition_processing.max_buffered_batches is deprecated in favor of partition_processing.max_prefetch.batches (#39113, #52253). The transform processor's flatten_data option yields to flatten: {log: true} (#51766). Four components are now marked unmaintained and will eventually be removed from community distributions unless new maintainers step up: the logicmonitor, azuredataexplorer, and flinkmetrics exporters, and the riak receiver (#52152, #52055, #52051).
Component naming convention
The snake_case rename wave continued in v0.164.0:
| Type | Old name | New name | PR |
|---|---|---|---|
| Extension | googleclientauth | google_client_auth | #51696 |
Datadog-related updates
extension/datadog: A newNewFactoryWithOptionsconstructor lets a host embedding the Collector supply extra Agent-config options, for example to propagate an API key rotation into the extension's forwarder (#51877).
OpenTelemetry specification v1.62.0
The v1.62.0 release adds a Sampler.Shutdown operation and continues the Prometheus compatibility work from recent releases by stabilizing the transformation of Prometheus Unknown-typed and Info metrics (#5335, #5213, #5211).
The OTLP exporter timeout is now specified to bound the entire batch export, including all request attempts and waits between retries, with earlier caller deadlines taking precedence (#5347). Resource detectors become entity-aware unless OTEL_EXPERIMENTAL_ENTITIES_ENABLED is set (#5147), and declarative config now degrades gracefully when it encounters unrecognized resource detectors instead of failing startup (#5323).
Community news
2026 Governance Committee election
The 2026 Governance Committee election has concluded, with results announced October 30. Of 836 eligible contributors, 345 cast a ballot, a 41% participation rate in line with last year. Four seats were filled, each with a two-year term. Thank you to everyone who voted!
Applying the GenAI semantic conventions from scratch
Dragos Bilaniuc applied the GenAI semantic conventions to an open-source TypeScript support agent without an OTel SDK in the core, using a vendor-neutral OTLP exporter, and writes up the design decisions that followed: a span end state for crashes mid-span that surfaces as undetermined rather than error or missing, and boundary rules that keep instrumentation out of the agent's core. He raised his remaining questions, including mapping invoke_agent onto real agent behavior, in the GenAI SIG channel. Built something with OTel? Send it to otel-news@datadoghq.com and it may appear in a future edition.
KubeCon North America 2026
The OpenTelemetry project will be at KubeCon NA in Salt Lake City, November 9–12, 2026, with a Contribfest where you can work alongside project maintainers, and talks covering the ecosystem. Register if you can join.
OpenTelemetry Community Awards 2026
The project announced the 3rd annual OpenTelemetry Community Awards, recognizing contributions to the project through code, documentation, project management, outreach, content creation, adoption, and helping others in the community.
Datadog news
The OTLP Native Processing Pipeline is now generally available
Teams can now run a pure upstream OpenTelemetry Collector, with no Datadog-specific exporter or connector, and still get full Datadog logs, metrics, and APM. This removes the vendor-specific configuration layer previously required to get full functionality out of Datadog from OTel data.
See the OTLP section in this month's Datadog shipped announcement.
Get involved
Want to contribute to OpenTelemetry? Here are some ways to get started:
- Join a Special Interest Group (SIG).
- Contribute code to one of OpenTelemetry repositories.
- Share your OTel story with the community.
Resources
- Datadog OpenTelemetry Documentation
- OpenTelemetry Documentation
- Getting Started Guide
- CNCF OpenTelemetry Slack
Did we miss something? If you have news to share or want to contribute to the next edition, please reach out to us via otel-news@datadoghq.com.