During the last Kubecon in London, we heard a lot of people and projects gravitating around OpenTelemetry. We’ll explain what is it and explain what are the next steps for this product.

OpenTelemetry (OTel) is a suite of tools, APIs, and SDKs designed to collect, process, and export telemetry data such as traces, metrics, and logs to improve observability in modern distributed systems.

Initially focused on traces and metrics, OpenTelemetry is now evolving into a unified standard for observing the complete behavior of applications. It provides a standardized protocol, OTLP (OpenTelemetry Protocol), which is increasingly replacing traditional formats like Jaeger or Prometheus.

(image taken from Grafana website)

What is the difference with tools like Prometheus ?

While OpenTelemetry and Prometheus are both related to observability, they all have different roles:

• OpenTelemetry is a framework for collecting telemetry data (traces, metrics, logs, profiling). It focuses on instrumentation and exporting data. It does not store or visualize data itself.

• Prometheus scrapes metrics data from targets, stores them locally, and allows for querying and alerting. So, OpenTelemetry can export metrics to Prometheus. As I thought that they were competitors, they’re in fact complementary

Why should you adopt OpenTelemetry?

• Unified signals (traces, logs, metrics, and now profiling, for example CPU or RAM usage over time for analysis): ability to collect and process different types of data in a standardized way

• Multi-cloud interoperability: Large organizations typically use more than one observability platform. Instrumenting for each vendor separately leads to complexity, redundancy, and performance issues (like double tracing). OpenTelemetry enables you to instrument your code once and export the data to multiple observability backends with minimal overhead.

• Widespread adoption by cloud providers: AWS, Azure, and GCP integrate OpenTelemetry natively

How could you try it ?

Basically, you have to use the SDKs available here : https://opentelemetry.io/docs/languages/

When you have your application ready, here’s an example in a K8s cluster (with sidecar to collect the data).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-with-otel
  labels:
    app: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: my-org/my-app:latest
          ports:
            - containerPort: 8080
          env:
            - name: OTEL_EXPORTER_OTLP_ENDPOINT
              value: "http://localhost:4317"
            - name: OTEL_RESOURCE_ATTRIBUTES
              value: "service.name=my-app"
            - name: OTEL_TRACES_SAMPLER
              value: "always_on"

        - name: otel-collector
          image: otel/opentelemetry-collector:latest
          args: ["--config=/etc/otel-collector-config.yaml"]
          ports:
            - containerPort: 4317 # OTLP gRPC
            - containerPort: 4318 # OTLP HTTP (optional)
          volumeMounts:
            - name: otel-config
              mountPath: /etc/otel-collector-config.yaml
              subPath: otel-collector-config.yaml

      volumes:
        - name: otel-config
          configMap:
            name: otel-collector-config

What is the future of this solution ? Here’s what the KubeCon Europe taught us…

Current situation

• OpenTelemetry is the second most contributed project in the CNCF, after Kubernetes (over 7000 contributions per week!)

• Many CNCF projects are actively adopting OpenTelemetry

• Increasing integration into open source libraries and frameworks

New features and development directions

• Profiling support in OTLP (v1.30.0) Profiling has been added as a first-class signal in OpenTelemetry, alongside traces, metrics, and logs. This allows low-overhead CPU profiling to be collected and exported via OTLP, enabling developers to correlate performance bottlenecks with application behavior more easily.

• Standardized Logs API in progress Although OpenTelemetry was initially not designed to include logs, community demand has pushed the project to develop a vendor-neutral Logs API. The aim is to unify logs with traces and metrics so they can all be processed in a single telemetry pipeline.

• OTLP/HTTP as the emerging standard format The OpenTelemetry Protocol (OTLP) over HTTP is becoming the preferred transport format for telemetry. It is designed to replace older, tool-specific formats such as Jaeger’s native format and Prometheus exporters, providing a more consistent and interoperable standard across observability platforms.

• Expanded and stabilized semantic conventions OpenTelemetry continues to refine and expand its semantic conventions. Those conventions are used by the developpers to standardize the information sent to Opentelemetry. This includes stabilizing attributes like code.*, database-related tags, and introducing conventions for Kubernetes resources, messaging systems, RPC communication, and profiling events. These conventions help ensure consistent labeling and correlation across all telemetry signals. Examples :

Conclusion

OpenTelemetry continues to grow as a key pillar of cloud-native observability. With profiling support, the upcoming logs API, adoption of the OTLP/HTTP protocol, and deeper integration into clouds and frameworks, OpenTelemetry is on track to become the unified standard for cross-platform telemetry.

The community is highly active, with many contributors, and the tools are evolving to make adoption easier and more valuable in production environments.

Further resources:

• https://opentelemetry.io/

• https://bindplane.com/blog/opentelemetry-in-production-a-primer/

• https://bindplane.com/blog/kubecon-europe-2025-opentelemetry-recap-from-london