1 of 21

Steve Flanders

​

OTel 2025: The Latest Milestones and What’s Next

2 of 21

Steve Flanders

Engineering Leader, Splunk

https://sflanders.net

Founding member of OpenCensus and OpenTelemetry projects

15+ years of monitoring and observability experience

    • OpenTelemetry + Metrics�at Splunk (acquired by Cisco)
    • OpenCensus + Traces (APM)�at Omnition (acquired by Splunk)
    • Logs at VMware

Author of the book: Mastering OpenTelemetry and Observability!

3 of 21

What is OpenTelemetry?

DATA COLLECTION

Single binary multiple form factors�to receive, process, and export data

SPECIFICATION

API (conventions + definition), SDK (API + configuration), and�Data (data formats, protocols, and semantic conventions)

INSTRUMENTATION LIBRARIES

Single library per language

OpenTelemetry is an Observability framework and toolkit designed to create and manage telemetry data such as traces, metrics, and logs. OpenTelemetry is vendor- and tool-agnostic, meaning that it can be used with a broad variety of Observability platforms, including open source tools like Jaeger and Prometheus, as well as commercial offerings. - https://opentelemetry.io/docs/what-is-opentelemetry/

4 of 21

Latest Milestones

  • OTel Demo 2.0: https://opentelemetry.io/blog/2025/otel-demo-2/
    • Added Flagd UI, exemplars, React Native app, and Span links for messaging spans
    • Replaced Redis with Valkey (CNCF project)
    • Rewrote Accounting in .NET to demonstrate auto-instrumentation

5 of 21

Latest Milestones

  • OTel Demo 2.0: https://opentelemetry.io/blog/2025/otel-demo-2/
    • Added Flagd UI, exemplars, React Native app, and Span links for messaging spans
    • Replaced Redis with Valkey (CNCF project)
    • Rewrote Accounting in .NET to demonstrate auto-instrumentation
  • OTel Weaver: https://opentelemetry.io/blog/2025/otel-weaver/
    • Define and version your semantic conventions
    • Policy-based validation
    • Live instrumentation checks
    • Code and docs generation
    • Diff and evolution

6 of 21

Semantic conventions normalize data.

HTTP: http.method, http.status_code

Database: db.instance, db.statement

Messaging: messaging.system

FaaS: faas.trigger

​

​

Resources capture environment metadata.

Application: Service, Telemetry

Compute Unit: Container, FaaS, Process

Compute Instance: Host

Environment: OS, Cloud, Deployment

​

Application

​

​

Database

Otel Library

https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/trace/semantic_conventions/README.md�https://github.com/open-telemetry/opentelemetry-specification/tree/master/specification/resource/semantic_conventions

Specification = Data Portability

7 of 21

OTel Weaver

# Checking the Official OTel Registry

weaver registry check -r registry-path

​

# Generating Markdown documentation

weaver registry update-markdown -r registry-path --target=markdown

​

# Generating code for instrumentation helpers

weaver registry generate -r registry-path -t templates-root-dir go

​

# Tracking changes and schema evolution

weaver registry diff -r current-version-registry-path --baseline-registry previous-version-registry-path

​

# Live instrumentation checks and coverage

weaver registry live-check --registry registry-path

​

# Simulating telemetry

weaver registry emit --registry registry-path --endpoint http://localhost:4317

​

Learn more: https://www.youtube.com/watch?v=BJt6LyJEYD0

8 of 21

Semantic Conventions

Latest Milestones

​

  • HTTP has been stable
  • Databases stable!
  • Exceptions stable!

​

What’s Next?

​

​

​

9 of 21

Latest Milestones

  • OTel Demo 2.0: https://opentelemetry.io/blog/2025/otel-demo-2/
    • Added Flagd UI, exemplars, React Native app, and Span links for messaging spans
    • Replaced Redis with Valkey (CNCF project)
    • Rewrote Accounting in .NET to demonstrate auto-instrumentation
  • OTel Weaver: https://opentelemetry.io/blog/2025/otel-weaver/
    • Define and version your semantic conventions
    • Policy-based validation
    • Live instrumentation checks
    • Code and docs generation
    • Diff and evolution
  • OTel injector donation: https://opentelemetry.io/blog/2025/otel-injector/

10 of 21

OTel Injector

# Supported languages today: Java, Node.JS, .NET

​

# System wide

echo /usr/lib/opentelemetry/libotelinject.so >> /etc/ld.so.preload

​

# Systemd services only

mkdir -p /usr/lib/systemd/system.conf.d/ && cp /usr/lib/opentelemetry/examples/systemd/00-otelinject-instrumentation.conf /usr/lib/systemd/system.conf.d/

11 of 21

Latest Milestones

12 of 21

OTelCol Extension Layer

receivers:

telemetryapi:

​

exporters:

otlphttp/external:

endpoint: 'external-collector:4318'

​

processors:

batch:

decouple:

​

service:

pipelines:

traces:

receivers: [telemetryapi]

processors: [batch, decouple]

exporters: [otlphttp/external]

logs:

receivers: [telemetryapi]

processors: [batch, decouple]

exporters: [otlphttp/external]

13 of 21

Latest Milestones

14 of 21

OTTL (Collector DSL)

OTel Transform Language (OTTL) is a domain-specific language (DSL) to define primarily processor configurations in the Collector. It’s an alternative to YAML and provides more flexibility.

Before

​

attributes:

include:

attributes:

- key: http.method

value: "POST"

actions:

- key: http.status_code

action: insert

value: 200

After

​

transform:

error_mode: ignore

metric_statements:

- context: metric

statements:

- set(attributes["http.status_code"], 200) where attributes["http.method"] == "POST"

15 of 21

OTTL now with context inference

Before

​

metric_statements:

- context: resource

statements:

- keep_keys(attributes, ["host.name"])

- context: metric

statements:

- set(description, "Sum") where type == "Sum"

- convert_sum_to_gauge() where name == "system.processes.count"

- context: datapoint

statements:

- limit(attributes, 100, ["host.name"])

After

​

metric_statements:

- keep_keys(resource.attributes, ["host.name"])

- set(metric.description, "Sum") where metric.type == "Sum"

- convert_sum_to_gauge() where metric.name == "system.processes.count"

- limit(datapoint.attributes, 100, ["host.name"])

16 of 21

Latest Milestones

17 of 21

OTel Protocol + Apache Arrow

Phase 1: Traffic reduction (done)

​

​

​

​

​

​

​

​

​

​

​

​

​

​

Phase 2: End-to-end OTAP pipeline

​

  1. Extend OTel client SDKs to natively support the OTel Protocol with Apache Arrow Protocol
  2. Extend the OTel Collector with direct support for OTel Protocol with Apache Arrow pipelines
  3. Extend OTel data model with native support for multi-variate metrics
  4. Output OTel data to the Parquet file format, part of the Apache Arrow ecosystem

18 of 21

Latest Milestones

19 of 21

GoLang Auto-Instrumentation

  • eBPF-based instrumentation: Use a separate binary that analyzes your Go process and attaches eBPF programs to hooks in your application — see opentelemetry-go-instrumentation
  • Compile-time instrumentation: Leverages the standard Go toolchain’s -toolexec mechanism to re-write Go source code before it is passed to the Go compiler, adding instrumentation in all relevant places — see opentelemetry-go-compile-instrumentation

​

https://opentelemetry.io/blog/2025/go-compile-time-instrumentation/

​

20 of 21

What’s Next?

Roadmap (https://opentelemetry.io/community/roadmap/)

  • P0: Continued Investment OpenTelemetry Artifacts
    • KTLO, performance, scale, and reliability
    • Collector stability
    • Stabilizing the logging signal events API and conventions
  • P1: Further Stabilizing Semantic Conventions
  • P2: Advancing OpenTelemetry
    • OpenTelemetry Demo
    • Additional signals (Profiling)
    • OpenTelemetry Control Plane (OpAMP)
    • Client instrumentation (RUM)

�OTel is on the path to CNCF graduation! Be sure to show your support by commenting on the ticket and consider adding your company to the Adopters page.

21 of 21

Thank You!

See you at the OTel table

in the Solutions Showcase!