OTel News

July 2026

July 2026

Curated by:

Welcome to the July 2026 edition of the OpenTelemetry News!

Zero-code instrumentation took two big steps forward this month: OpenTelemetry Go Compile-Time Instrumentation reached v1, and a new opentelemetry system package brings one-command auto-instrumentation setup to Linux hosts. The OpenTelemetry Demo also shipped its 3.0 release, adding a fully instrumented agentic AI stack with continuous profiling support and paying down years of dependency debt. Profiling SIG work also progressed, with OTEP-4947 merging to lay the groundwork for correlating traces and profiles by process and thread context. On the Collector side, releases 0.156.0 and 0.157.0 add a wave of lambda-based OTTL converters and introduce the dynamic_sampling processor. Specification v1.59.0 adds a Profiles data model and moves environment variable context propagation to release candidate, while semantic conventions v1.43.0 promotes CI/CD, VCS, and process conventions to release candidate.

Highlights

OpenTelemetry Go Compile-Time Instrumentation reaches v1

The Go Compile-Time Instrumentation project shipped its first stable release. Go compiles to a single static binary, which has long made automatic instrumentation harder than in interpreted languages. This project hooks into the standard Go toolchain during the build, through its -toolexec mechanism, and injects OpenTelemetry instrumentation into your code, its dependencies, and the standard library as they compile, with no separate agent and nothing to attach at runtime. It's exciting to see this cross-company collaboration pay off: The project traces back to a 2025 announcement where Alibaba and Datadog chose to join forces on a single SIG instead of maintaining competing solutions.

The change to your build is a single line: run otelc go build where you used to run go build. v1 ships semantic-convention-compliant instrumentation for net/http, database/sql, gRPC, Redis, and Go runtime metrics, with more added regularly through the SIG's rule-based instrumentation format. Go developers now have three complementary options for telemetry: this compile-time approach (best when you can rebuild and want zero runtime overhead), OpenTelemetry eBPF Instrumentation (best when you can't rebuild the binary), and manual instrumentation with the Go API. See the project repository and its getting-started guide to try it.

One-command OpenTelemetry setup lands for Linux hosts

The Packaging SIG shipped native OS packages that let you install OpenTelemetry auto-instrumentation with apt install opentelemetry or yum install opentelemetry. The package installs the OpenTelemetry Injector alongside the SDKs and auto-instrumentation packages for Java, .NET, Node.js, Python, and Ruby. The Injector hooks into process startup on the host and activates the matching auto-instrumentation, with no application code changes or deployment script changes required.

By default, the auto-instrumentation sends OTLP to localhost:4317 (gRPC) and localhost:4318 (HTTP). From there you can point the SDKs directly at a backend via /etc/opentelemetry/injector/default_env.conf, or run a Collector on the host to forward telemetry onward. Languages without SDK-based auto-instrumentation, such as Go, Rust, and C++, are expected to get coverage through a future integration with OpenTelemetry eBPF Instrumentation (OBI).

OpenTelemetry Demo 3.0 ships an agentic AI stack and profiling support

The OpenTelemetry Demo 3.0 release adds three new services that form a complete, observable AI stack: an agent, a MCP server exposing the Demo's capabilities as tools, and a chatbot UI. Every tool call, LLM interaction, and reasoning step is traced end to end, from chatbot to agent, agent to MCP, and MCP to the rest of the microservices.

The release also adds continuous profiling support so you can see the OpenTelemetry eBPF Profiler in action. And that's a perfect hook for our next highlight.

Enhancement proposal adds process and thread context support to the OpenTelemetry Profiler

Profiling SIG efforts to add process and thread context support to the profiler have progressed nicely over the last four months, with OTEP-4947 being merged to the specification repository in July. These efforts provide the foundation to bring request context and correlation to the OpenTelemetry eBPF Profiler by providing a mechanism for OpenTelemetry SDKs to share this context with the profiler. When this is all in place users will be able to view the relationships between request traces and profiles, unlocking use cases such as viewing flamegraphs for particular endpoints, or jumping from a profile to the trace that was running when the profile was captured.

The team is now looking at adding support to the OpenTelemetry SDKs!

New Collector releases

This news edition covers the OpenTelemetry Collector releases 0.156.0 and 0.157.0.

Breaking changes

  • processor/filter, processor/transform, and connector/routing now default to error_mode: ignore: All three components promote their defaultErrorModeIgnore feature gates to beta or stable this release, so malformed OTTL statements are skipped by default instead of aborting the pipeline. If you depend on the old fail-fast behavior, set error_mode: propagate explicitly in your configuration; the gates for processor/filter and processor/transform will be removed entirely in v0.159.0 (#47232, #47231, #48418).

  • receiver/host_metrics aggregates CPU metrics by default: system.cpu.time and system.cpu.utilization no longer include the cpu attribute by default, aggregating across logical CPUs instead of emitting one series per core. system.cpu.logical.count is now enabled by default too. If your dashboards depend on per-core data, re-add the cpu attribute to those metrics in your scraper config (#49161, #49325).

  • receiver/oracledb query plan collection now requires broader privileges: SQL query plan details are now retrieved from V$SQL_PLAN_STATISTICS_ALL instead of V$SQL_PLAN to capture additional runtime execution statistics. Deployments that only grant access to V$SQL_PLAN may see query plan collection failures until the corresponding privilege is granted (#49329).

New components

  • processor/dynamic_sampling: Adaptive trace sampling with W3C TraceState rate encoding (#48898). A follow-up in 0.157.0 makes the processor honor an incoming ot=th sampling threshold and ot=rv randomness value when deciding and emitting, so downstream metric consumers can reconstruct the correct adjusted count for the original population (#49311).

Component naming convention

The snake_case rename wave continued across v0.156.0 and v0.157.0. Deprecated aliases are maintained so existing configurations keep working, but plan to update your component names to ensure compatibility with future releases.

Type Old name New name PR
Receiver awscloudwatch aws_cloudwatch #49286
Processor cumulativetodelta cumulative_to_delta #49487
Processor spanpruning span_pruning #47673
Processor awsecsattributes aws_ecs_attributes #49617

OTTL & processing improvements

0.157.0 adds lambda expressions to OTTL: small anonymous functions defined inline, passed directly to generic higher-order converters instead of requiring a bespoke function for every transformation. Eight new converters ship built on this capability: Filter, MapEach, MapKeys, All and Any, Find, Reduce, IsEmpty, and When. For a walkthrough with practical examples, see Lambda-powered functions land in OTTL.

  • connector/routing gains OTTL context inference, letting you write routing conditions with explicit context-qualified paths like resource.attributes["env"] instead of relying on implicit resolution; unqualified paths still default to the resource context for backward compatibility (#38080). The connector's legacy request context and request["key"] condition syntax are deprecated in favor of otelcol.client.metadata and otelcol.grpc.metadata OTTL paths, which work across all signal contexts (#44762).
  • processor/transform gains exemplar context support, letting metric_statements read and modify exemplar fields on metric datapoints (#49022).
  • processor/transform adds a ParseCEF function for parsing Common Event Format security event data (#48351).
  • processor/drain adds positional parameter extraction, writing the values matched at <*> positions in a template as a string slice attribute (#48914).
  • processor/lookup adds a csv lookup source with headered or headerless files, scalar or whole-row values, and an optional reload_interval to periodically re-read the file without restarting the Collector; the same reload capability is now available for the yaml lookup source (#41816).
  • exporter/datadog:
    • Fargate workloads now emit a dedicated otel.datadog_exporter.metrics.running.fargate{task_arn} metric instead of sharing otel.datadog_exporter.metrics.running with host-based workloads (#49042).
    • New alpha UseSyncForwarder feature gate replaces the async default forwarder for metrics with a synchronous one, so Datadog intake errors propagate to OTel's exporterhelper retry and queue layer instead of being silently swallowed (#49571).
    • The metric sketches payload is now gzip-compressed in the legacy metric API client, reducing egress for distribution and histogram metrics (#49313).
    • Fixed CPU core count fields missing from host metadata payloads for remote hosts in OTel gateway topologies (#49320).
  • extension/datadog: Skip the cloud metadata source provider probe when a hostname is already set in config, avoiding spurious GCP metadata server requests on non-GCP hosts (#49241).

OpenTelemetry specification v1.59.0

The v1.59.0 release adds a formal data model for the Profiles signal and advances environment variable context propagation to release candidate.

  • A Profiles data model is now part of the specification's data model appendix, giving implementers a normative reference for the fourth signal alongside traces, metrics, and logs.
  • "Environment Variables as Context Propagation Carriers" is marked release candidate (#5142), with accompanying clarifications that its operational guidance is non-normative and should be documented per language implementation (#5165, #5166, #5179).
  • An OTEP introducing Policies into the specification was merged (#4738), alongside an OTEP proposing a central OpenTelemetry benchmarks repository (#5118).
  • The logs data model appendix gains an ETW (Event Tracing for Windows) example mapping, including the ETW level to SeverityNumber mapping (#5159).

Semantic conventions v1.43.0

The v1.43.0 release promotes several convention groups to release candidate and adds a new Azure attribute.

  • CI/CD span, metric, log, attribute, and entity conventions are promoted to release candidate (#3674, #3675, #3677), alongside VCS conventions (#3676) and process metrics and entity (#3041).
  • A new azure.resource_group.name attribute captures the Azure resource group a resource belongs to, and the docs now clarify that cloud.account.id maps to the Azure subscription ID (#3697, #3708).
  • Oracle Database's db.query.text guidance is aligned with other SQL database conventions: Parameterized query text is now recommended to be collected by default, while query parameter values remain opt-in (#3790).
  • disk.io.direction, network.io.direction, and system.paging.fault.type attributes are promoted to release candidate (#3796).

Datadog news

Get involved

Want to contribute to OpenTelemetry? Here are some ways to get started:

Resources

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.