OpenTelemetry

OBI global configuration properties

Tue, 10 Mar 2026 17:25:37 -0700

OBI can be configured via environment variables or via a YAML configuration file passed either with the -config command-line argument or the OTEL_EBPF_CONFIG_PATH environment variable. Environment variables have priority over the properties in the configuration file. For example, in the following command line, the OTEL_EBPF_LOG_LEVEL option overrides any log_level settings inside config.yaml:

Config argument:

OTEL_EBPF_LOG_LEVEL=debug obi -config /path/to/config.yaml

Config environment variable:

OTEL_EBPF_LOG_LEVEL=debug OTEL_EBPF_CONFIG_PATH=/path/to/config.yaml obi

Refer to the example YAML configuration file for a configuration file template.

Profiles

Tue, 10 Mar 2026 08:56:22 +0100

Status: Development

Nota

The profiles signal is still experimental and under active development. Breaking changes may be introduced in future versions.

A profile is a collection of samples and associated metadata that shows where applications consume resources during execution. A sample records values encountered in some program context (typically a stack trace), optionally augmented with auxiliary information like the trace ID corresponding to a higher-level request.

The moment of capturing a sample is known as a sample event and consists not only of the observation data point, but also the time at which it was captured.

Configure OBI export modes

Fri, 27 Feb 2026 08:18:31 -0800

In Direct mode OBI pushes metrics and traces directly to a remote endpoint using the OpenTelemetry protocol (OTLP).

OBI can also expose a Prometheus HTTP endpoint ready to scrape, for example in pull mode.

To use Direct mode requires configuration with authentication credentials. Set the OTLP endpoint authentication credentials with these environment variables:

OTEL_EXPORTER_OTLP_ENDPOINT
OTEL_EXPORTER_OTLP_HEADERS

To run in Direct mode using the Prometheus scrape endpoint, see the configuration documentation.

Configure and run OBI

This tutorial assumes OBI and OTel Collector are running natively on the same host, so there is no need to secure the traffic nor provide authentication in the OTel Collector OTLP receiver.

Quick start

Sat, 21 Feb 2026 17:26:02 -0500

The OpenTelemetry Collector receives traces, metrics, and logs, processes the telemetry, and exports it to a wide variety of observability backends using its components. For a conceptual overview of the Collector, see Collector.

You are going to learn to do the following in less than five minutes:

Set up and run the OpenTelemetry Collector.
Send telemetry and see it processed by the Collector.

Prerequisites

Make sure that your developer environment has the following. This page assumes that you’re using bash. Adapt configuration and commands as necessary for your preferred shell.

Getting started

Thu, 29 Jan 2026 05:41:57 -0500

Setup

Download opentelemetry-javaagent.jar from Releases of the opentelemetry-java-instrumentation repository and place the JAR in your preferred directory. The JAR file contains the agent and instrumentation libraries.

Add -javaagent:path/to/opentelemetry-javaagent.jar and other config to your JVM startup arguments and launch your app:

Directly on the startup command:

java -javaagent:path/to/opentelemetry-javaagent.jar -Dotel.service.name=your-service-name -jar myapp.jar

Via the JAVA_TOOL_OPTIONS and other environment variables:

export JAVA_TOOL_OPTIONS="-javaagent:path/to/opentelemetry-javaagent.jar"
export OTEL_SERVICE_NAME="your-service-name"
java -jar myapp.jar

Declarative configuration

Declarative configuration uses a YAML file instead of environment variables or system properties. This is useful when you have many configuration options to set, or if you want to use configuration options that are not available as environment variables or system properties.

Requisitos previos

Wed, 21 Jan 2026 23:15:16 +0100

Para contribuir a este repositorio, necesitas estar familiarizado con las siguientes tecnologías y herramientas:

git
GitHub
Markdown (CommonMark)
YAML

Para detalles técnicos sobre cómo se construye y prueba la documentación localmente, consulta Desarrollo.

Firma del CNCF CLA

Todos los colaboradores de OpenTelemetry deben firmar el Acuerdo de Licencia de Contribuidor (CLA) de la Linux Foundation.

Las solicitudes de código (pull requests) de colaboradores que no hayan firmado el CLA fallarán en las pruebas automatizadas. El nombre y correo electrónico que proporciones deben coincidir con los encontrados en git config, y los usados para el CLA de CNCF.

OBI Network Metrics configuration options

Sun, 18 Jan 2026 06:12:55 -0500

Network metrics are configured under the network property of the OBI Configuration YAML file or with a set of environment variables prefixed as OTEL_EBPF_NETWORK_.

Example YAML:

network:
 enable: true
 cidrs:
 - 10.10.0.0/24
 - 10.0.0.0/8
 - 10.30.0.0/16
attributes:
 kubernetes:
 enable: true
 select:
 obi_network_flow_bytes:
 include:
 - k8s.src.owner.name
 - k8s.src.namespace
 - k8s.dst.owner.name
 - k8s.dst.namespace
 - src.cidr
 - dst.cidr
otel_metrics_export:
 endpoint: http://localhost:4318

In addition to the network YAML section, OBI configuration requires an endpoint to export the network metrics (in the previous example, otel_metrics_export, but it also accepts a Prometheus endpoint).

Measure traffic between Cloud availability zones

Wed, 14 Jan 2026 07:44:34 -0500

Nota

This feature is currently only available in Kubernetes clusters.

Traffic between Cloud Availability Zones might incur additional costs. OBI is able to measure it either by adding src.zone and dst.zone attributes to regular network metrics, or by providing a separate obi.network.inter.zone.bytes (OTel) / obi_network_inter_zone_bytes_total (Prometheus) metric.

Add `src.zone` and `dst.zone` attributes to regular network metrics

Source and destination availability zone attributes are disabled by default in OBI. To enable it, explicitly add them to the list of included network attributes in the OBI YAML configuration:

Getting Started

Thu, 08 Jan 2026 22:37:28 +0530

This page will walk you through the fastest way to get started monitoring your Kubernetes cluster using OpenTelemetry. It will focus on collecting metrics and logs for Kubernetes clusters, nodes, pods, and containers, as well as enabling the cluster to support services emitting OTLP data.

If you’re looking to see OpenTelemetry in action with Kubernetes, the best place to start is the OpenTelemetry Demo. The demo is intended to illustrate the implementation of OpenTelemetry, but it is not intended to be an example of how to monitor Kubernetes itself. Once you finish with this walkthrough, it can be a fun experiment to install the demo and see how all the monitoring responds to an active workload.

Logs

Thu, 08 Jan 2026 12:52:37 -0300

Un log es un registro de texto con marca de tiempo, ya sea estructurado (recomendado) o no estructurado, con metadatos opcionales. De todas las señales de telemetría, los logs son la señal de telemetría con más historia. La mayoría de los lenguajes de programación tienen capacidades de logging integradas o librerías de logging muy conocidas y ampliamente usadas.

Logs de OpenTelemetry

OpenTelemetry no define una API o SDK a medida para crear logs. En cambio, los logs de OpenTelemetry son los logs existentes que ya tienes de un framework de logging o un componente de infraestructura. Los SDKs y la auto-instrumentación de OpenTelemetry utilizan varios componentes para correlacionar automáticamente los logs con las trazas.

OBI network metrics quickstart

Tue, 16 Dec 2025 14:16:09 +0100

OBI can generate network metrics in any environment (physical host, virtual host, or container). It’s recommended to use a Kubernetes environment, as OBI is able to decorate each metric with the metadata of the source and destination Kubernetes entities.

The instructions in this quickstart guide focus on deploying directly to Kubernetes with the kubectl command line utility. This tutorial describes how to deploy OBI in Kubernetes from scratch. To use Helm, consult the Deploy OBI in Kubernetes with Helm documentation.

Primeros pasos

Wed, 10 Dec 2025 04:41:59 -0600

Esta página te mostrará cómo empezar a utilizar la instrumentación automática de OpenTelemetry .NET.

Si estás buscando una forma de instrumentar manualmente tu aplicación, consulta esta guía.

Aprenderás cómo puedes instrumentar automáticamente una aplicación .NET sencilla, de tal manera que se emitan trazas, métricas y logs a la consola.

Requisitos previos

Asegúrate de tener lo siguiente instalado localmente:

.NET SDK 6+

Ejemplo de aplicación

El siguiente ejemplo utiliza una aplicación básica API mínima con ASP.NET Core. Si no utilizas ASP.NET Core, no te preocupes, puedes seguir utilizando la instrumentación automática de OpenTelemetry .NET.

Trazas

Fri, 31 Oct 2025 11:11:54 -0400

Las trazas nos dan una visión general de lo que ocurre cuando se hace una solicitud a una aplicación. Ya sea que tu aplicación sea un monolito con una sola base de datos o una sofisticada malla de servicios, las trazas son esenciales para entender la “ruta” completa que una solicitud toma en tu aplicación.

Exploremos esto con tres unidades de trabajo, representadas como Spans:

Note

Los siguientes ejemplos en JSON no representan un formato específico, y especialmente no representan OTLP/JSON, que es más verboso.

Ejecutar OBI como un proceso independiente

Thu, 09 Oct 2025 17:04:01 -0400

OBI puede ejecutarse como un proceso independiente del sistema operativo Linux con privilegios elevados que pueden inspeccionar otros procesos en ejecución.

Descargar e instalar

Puedes descargar el ejecutable de OBI desde la página de versiones de OBI.

Configurar OBI

Crea un archivo de configuración siguiendo la documentación de opciones de configuración.
Ejecuta OBI como un proceso con privilegios:

sudo ./obi --config=<path to config file>

Ejemplo de configuración

A continuación se muestra un ejemplo de archivo de configuración (obi-config.yml):

Implementar OBI en Kubernetes

Thu, 09 Oct 2025 17:04:01 -0400

Este documento explica cómo implementar OBI manualmente en Kubernetes, configurando todas las entidades necesarias por su cuenta.

Configuración de la decoración de metadatos de Kubernetes

OBI puede decorar sus trazas con las siguientes etiquetas de Kubernetes:

k8s.namespace.name
k8s.deployment.name
k8s.statefulset.name
k8s.replicaset.name
k8s.daemonset.name
k8s.node.name
k8s.pod.name
k8s.container.name
k8s.pod.uid
k8s.pod.start_time
k8s.cluster.name

Para habilitar la decoración de metadatos, debe hacer lo siguiente:

Ejecutar OBI como un contenedor Docker

Thu, 09 Oct 2025 17:04:01 -0400

OBI puedes ejecutar un contenedor Docker independiente que puede instrumentar un proceso que se ejecuta en otro contenedor.

Encuentra la última imagen de OBI en Docker Hub con el siguiente nombre:

ebpf-instrument:main

El contenedor OBI debe configurarse de la siguiente manera:

Ejecutarse como un contenedor privilegiado o como un contenedor con la capacidad SYS_ADMIN (pero esta última opción podría no funcionar en algunos entornos de contenedores).
Utilizar el espacio de nombres PID host para permitir el acceso a los procesos de otros contenedores.

Ejemplo de CLI de Docker

Para este ejemplo, se necesita un contenedor que ejecute un servicio HTTP/S o gRPC. Si no tiene uno, puedes utilizar este sencillo servicio de motor de blog escrito en Go:

Métricas

Tue, 16 Sep 2025 10:34:15 +0200

Una métrica es una medida de un servicio capturada en tiempo de ejecución. El momento de capturar una medida se conoce como evento de métrica, que consiste no solo en la medida en sí misma, sino también en el momento en que fue capturada y los metadatos asociados.

Las métricas de aplicación y de peticiones son indicadores importantes de disponibilidad y rendimiento. Las métricas personalizadas pueden proporcionar información sobre cómo los indicadores de disponibilidad impactan en la experiencia del usuario o en el negocio. Los datos recopilados se pueden usar para alertar de una interrupción del servicio o para activar decisiones de escalar automáticamente un deployment ante una alta demanda.

Baggage

Tue, 26 Aug 2025 09:45:14 +0200

En OpenTelemetry, el Baggage es información contextual que viaja con el contexto. El Baggage es un almacén de pares clave-valor, lo que significa que te permite propagar cualquier dato que desees junto con el contexto.

El Baggage te permite pasar datos a través de servicios y procesos, permitiendo que se puedan añadir a trazas, métricas o logs en esos servicios.

Ejemplo

El Baggage se usa a menudo en el trazado distribuido para propagar datos adicionales entre servicios.

Migrating from OpenCensus

Tue, 27 May 2025 05:58:16 -0400

Migrating from OpenTracing

Fri, 21 Mar 2025 16:06:24 -0400

Backward compatibility with OpenTracing has been a priority for the OpenTelemetry project from the start. To ease migration, OpenTelemetry supports the use of both the OpenTelemetry and OpenTracing APIs in the same codebase. This allows OpenTracing instrumentation to be recorded using OpenTelemetry SDKs.

To accomplish this, each OpenTelemetry SDK provides an OpenTracing shim, which acts as a bridge between the OpenTracing API and the OpenTelemetry SDK. Note that OpenTracing shims are disabled by default.

OpenTelemetry

OBI global configuration properties

Profiles

Configure OBI export modes

Configure and run OBI

Quick start

Prerequisites

Getting started

Setup

Declarative configuration

Requisitos previos

Firma del CNCF CLA

OBI Network Metrics configuration options

Measure traffic between Cloud availability zones

Add src.zone and dst.zone attributes to regular network metrics

Getting Started

Logs

Logs de OpenTelemetry

OBI network metrics quickstart

Primeros pasos

Requisitos previos

Ejemplo de aplicación

Trazas

Ejecutar OBI como un proceso independiente

Descargar e instalar

Configurar OBI

Ejemplo de configuración

Implementar OBI en Kubernetes

Configuración de la decoración de metadatos de Kubernetes

Ejecutar OBI como un contenedor Docker

Ejemplo de CLI de Docker

Métricas

Baggage

Ejemplo

Migrating from OpenCensus

Migrating from OpenTracing

Add `src.zone` and `dst.zone` attributes to regular network metrics