OpenTelemetry

OBI Network Metrics configuration options

Wed, 21 Oct 2026 23:50:30 +0000

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:

metrics:
 features: [network]
network:
 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).

OBI Config v2 reference

Wed, 21 Oct 2026 23:50:30 +0000

Config v2 is available in OBI v0.11.0 and later. It uses the OpenTelemetry declarative configuration structure. Common settings such as resources, sampling, and exporters remain at the root of the document, while OBI-specific settings are grouped under extensions.obi.

If you already have a Config v1 file, use the Config v1 to v2 migration guide instead of rewriting it by hand.

Choose a configuration structure

How you structure the configuration depends on how you run OBI:

OBI global configuration properties

Wed, 21 Oct 2026 23:50:30 +0000

Nota

This page uses Config v1 field names, examples, and environment variables. For Config v2, see the Config v2 reference. To convert an existing file, use the migration guide.

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:

OBI network metrics quickstart

Wed, 21 Oct 2026 23:50:30 +0000

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.

Measure traffic between Cloud availability zones

Wed, 21 Oct 2026 23:50:30 +0000

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:

Configure OBI export modes

Wed, 21 Oct 2026 23:50:30 +0000

Nota

This page uses Config v1 field names and examples. For Config v2, see the Config v2 reference. To convert an existing file, use the migration guide.

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.

For Direct mode, set the OTLP endpoint with OTEL_EXPORTER_OTLP_ENDPOINT. If the endpoint requires authentication, also set OTEL_EXPORTER_OTLP_HEADERS with the credentials.

Implementar OBI en Kubernetes con Helm

Thu, 15 Oct 2026 14:09:40 -0400

Nota

Para obtener más detalles sobre las diversas opciones de configuración de Helm, consulta el documentoOpciones del gráfico Helm de OBI.

Contenido:

Implementación de OBI desde Helm {#deploying-obi-from-helm}
Configuración de OBI {#configuring-obi}
Configuración de los metadatos de OBI {#configuring-obi-metadata}
Proporcionar secretos a la configuración de Helm {#providing-secrets-to-helm-configuration}

Implementación de OBI desde Helm

En primer lugar, debes agregar el repositorio de OpenTelemetry Helm a Helm:

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts

El siguiente comando implementa un DaemonSet de OBI con una configuración predeterminada en el namespace obi:

Quick start

Thu, 27 Aug 2026 05:31:10 +0000

The OpenTelemetry Collector receives telemetry such as traces, metrics, and logs, processes it, and forwards it to one or more observability backends through its component pipeline.

Nota

This quick start demo creates a basic local setup. The goal is to show you how the Collector works, not to set up a production-ready environment.

In this guide, you will:

Start a local instance of the OpenTelemetry Collector
Generate trace data and send it to the Collector
Check that the Collector receives and processes the data

By the end, you will have a simple pipeline running on your machine and a clearer idea of how the Collector fits into an observability stack. If you want more context before getting started, see the Collector overview.

Supported Technologies

Tue, 18 Aug 2026 21:29:20 +0000

OpenTelemetry PHP Distro is a distribution of OpenTelemetry PHP. It inherits OpenTelemetry compatibility and extends runtime features with native components.

Auto-instrumentation scope

Auto-instrumentation captures telemetry for supported frameworks and libraries, but it does not instrument:

Proprietary or custom framework internals
Closed-source components without instrumentation hooks
Application-specific business logic

For unsupported areas, use manual OpenTelemetry instrumentation.

PHP versions

Supported PHP versions: 8.1 to 8.5.

Supported SAPIs

php-cli
php-fpm
php-cgi/fcgi
mod_php (prefork)

Supported operating systems

Linux
- Architectures: x86_64, arm64
- glibc-based systems: deb, rpm
- musl-based systems (Alpine): apk

Instrumented frameworks

Laravel 6.x to 13.x
Slim 4.x

Instrumented libraries

cURL
HTTP async (php-http/httplug)
MySQLi
PDO
PostgreSQL
PSR-18 HTTP Client (psr/http-client)

Included auto-instrumentation packages

Name	Included from distro version	Package
`curl`	1.0	open-telemetry/opentelemetry-auto-curl
`http-async-client`	1.0	open-telemetry/opentelemetry-auto-http-async
`laravel`	1.0	open-telemetry/opentelemetry-auto-laravel
`mysqli`	1.0	open-telemetry/opentelemetry-auto-mysqli
`pdo`	1.0	open-telemetry/opentelemetry-auto-pdo
`postgresql`	1.2	open-telemetry/opentelemetry-auto-postgresql
`psr18`	0.5	open-telemetry/opentelemetry-auto-psr18
`slim`	1.0	open-telemetry/opentelemetry-auto-slim

Included metrics packages

Included from distro version	Package	Emitted metrics
0.6.0	open-telemetry/opentelemetry-metrics-runtime	PHP memory usage, GC cycles, peak memory

Additional runtime features

Automatic root span creation
Root span URL grouping
Inferred spans
Attribute-based instrumentation (#[WithSpan], #[SpanAttribute])
Background telemetry sending
PHP runtime metrics (memory, GC — exported automatically via the native async transport)

Background sending (non-blocking export) works with OTLP http/protobuf (default). If the exporter or protocol is changed to an unsupported transport (for example gRPC), export becomes synchronous.

Limitations

Tue, 18 Aug 2026 21:29:20 +0000

This page describes known limitations and constraints of OpenTelemetry PHP Distro.

Running with another PHP telemetry agent

Do not run OpenTelemetry PHP Distro together with another PHP APM or OpenTelemetry agent in the same process. Running both can cause conflicts, duplicate instrumentation, and unstable behavior.

`open_basedir`

If open_basedir is enabled in php.ini, the distro installation path must be included in allowed paths, otherwise the agent may fail to load.

Set Up OpenTelemetry PHP Distro

Tue, 18 Aug 2026 21:29:20 +0000

Learn how to instrument your PHP application with OpenTelemetry PHP Distro and send telemetry data to an OTLP-compatible backend.

Prerequisites

Have a destination for telemetry data (OTLP endpoint).
Use a supported Linux distribution and PHP version.
Do not run another PHP APM or OpenTelemetry agent in the same process.

For supported operating systems and PHP versions, see Supported technologies.

Limitations

Known runtime and compatibility limitations are described in Limitations.

Configuration

Tue, 18 Aug 2026 21:29:20 +0000

OpenTelemetry PHP Distro supports standard OpenTelemetry SDK configuration and distro-specific options.

Configuration method

Configure via environment variables available to PHP processes:

OTEL_* for OpenTelemetry standard options
OTEL_PHP_* for distro-specific options

Example:

export OTEL_EXPORTER_OTLP_ENDPOINT="https://your-endpoint:443/"
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <token>"
export OTEL_PHP_LOG_LEVEL_STDERR="INFO"

OpenTelemetry options

The distro supports standard OpenTelemetry PHP SDK options.

Option	Default	Accepted values	Description
`OTEL_EXPORTER_OTLP_ENDPOINT`	`http://localhost:4318`	URL	OTLP endpoint URL
`OTEL_EXPORTER_OTLP_HEADERS`	(empty)	`key=value,key2=value2`	OTLP request headers
`OTEL_EXPORTER_OTLP_INSECURE`	`false`	`true` or `false`	Disable TLS verification (testing only)
`OTEL_EXPORTER_OTLP_CERTIFICATE`	(empty)	Filesystem path (PEM)	CA certificate path for OTLP TLS
`OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE`	(empty)	Filesystem path (PEM)	Client certificate for OTLP mTLS
`OTEL_EXPORTER_OTLP_CLIENT_KEY`	(empty)	Filesystem path (PEM)	Client key for OTLP mTLS
`OTEL_EXPORTER_OTLP_CLIENT_KEYPASS`	(empty)	String	Passphrase for encrypted OTLP client key
`OTEL_SERVICE_NAME`	`unknown_service`	String	Value of `service.name` resource attribute
`OTEL_RESOURCE_ATTRIBUTES`	(empty)	`key=value,key2=value2`	Resource attributes
`OTEL_TRACES_SAMPLER`	`parentbased_always_on`	Sampler name	Trace sampler
`OTEL_TRACES_SAMPLER_ARG`	(empty)	String/number	Sampler argument
`OTEL_LOG_LEVEL`	`info`	`error`, `warn`, `info`, `debug`	SDK internal log level

Distro-specific options (`OTEL_PHP_*`)

All OTEL_PHP_* options can be set as environment variables or in php.ini.

Métricas

Fri, 03 Jul 2026 11:11:16 -0400

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.

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.

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.

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.

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:

OpenTelemetry

OBI Network Metrics configuration options

OBI Config v2 reference

Choose a configuration structure

OBI global configuration properties

OBI network metrics quickstart

Measure traffic between Cloud availability zones

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

Configure OBI export modes

Implementar OBI en Kubernetes con Helm

Implementación de OBI desde Helm

Quick start

Supported Technologies

Auto-instrumentation scope

PHP versions

Supported SAPIs

Supported operating systems

Instrumented frameworks

Instrumented libraries

Included auto-instrumentation packages

Included metrics packages

Additional runtime features

Limitations

Running with another PHP telemetry agent

open_basedir

Set Up OpenTelemetry PHP Distro

Prerequisites

Limitations

Configuration

Configuration method

OpenTelemetry options

Distro-specific options (OTEL_PHP_*)

Métricas

Getting started

Setup

Declarative configuration

Requisitos previos

Firma del CNCF CLA

Getting Started

Logs

Logs de OpenTelemetry

Trazas

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

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

`open_basedir`

Distro-specific options (`OTEL_PHP_*`)