OpenTelemetry

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

说明

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

说明

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

说明

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.

Deploy OBI in Kubernetes with Helm

Fri, 16 Oct 2026 12:20:11 +0000

说明

For more details about the diverse Helm configuration options, check out the OBI Helm chart documentation or browse the chart on Artifact Hub. For detailed configuration parameters, see the values.yaml file.

Contents:

Deploying OBI from helm
Configuring OBI
Configuring OBI metadata
Centralizing Kubernetes metadata with k8s-cache
Providing secrets to the Helm configuration

Deploying OBI from helm

First, you need to add the OpenTelemetry helm repository to Helm:

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.

从 OpenTracing 迁移

Thu, 04 Jun 2026 11:53:28 -0400

OpenTelemetry 项目自从诞生以来，OpenTracing 的向后兼容性就是优先事项之一。为了简化迁移过程，OpenTelemetry 支持在同一代码库中同时使用 OpenTelemetry 和 OpenTracing API。这样就可以使用 OpenTelemetry SDK 记录 OpenTracing 的插桩数据。

为实现这一点，每个 OpenTelemetry SDK 都提供了一个 OpenTracing Shim，它充当 OpenTracing API 和 OpenTelemetry SDK 之间的桥梁。请注意，OpenTracing Shim 默认是禁用的。

语言版本支持

在使用 OpenTracing Shim 之前，请检查你的编程语言和运行时组件版本，并在必要时进行更新。下表列出了 OpenTracing 和 OpenTelemetry API 的最低语言版本要求：

语言	OpenTracing API	OpenTelemetry API
Go	1.13	1.16
Java	7	8
Python	2.7	3.6
JavaScript	6	8.5
.NET	1.3	1.4
C++	11	11

请注意，OpenTelemetry API 和 SDK 通常比 OpenTracing 要求更高的语言版本。

快速开始

Thu, 04 Jun 2026 11:53:28 -0400

安装

从 opentelemetry-java-instrumentation 仓库的 Releases 下载 opentelemetry-javaagent.jar 并将 JAR 放在您偏好的目录中。 JAR 文件包含代理和插桩库。

添加 -javaagent:path/to/opentelemetry-javaagent.jar 和其他配置到你的 JVM 启动参数并启动您的应用程序：

直接在启动命令上：

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

通过 JAVA_TOOL_OPTIONS 和其他环境变量：

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

声明式配置

声明式配置使用 YAML 文件，而非环境变量或系统属性。当你需要设置许多配置选项，或者想要使用那些无法通过环境变量或系统属性来配置的选项时，这种方式会非常有用。

有关更多详细信息，请参阅声明式配置页面。

配置代理

代理高度可配置。

一种选择是通过 -D 标志传递配置属性。在本示例中，配置了服务名称和用于追踪的 Zipkin 导出器：

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

你也可以使用环境变量来配置代理：

OTEL_SERVICE_NAME=your-service-name \
OTEL_TRACES_EXPORTER=zipkin \
java -javaagent:path/to/opentelemetry-javaagent.jar \
 -jar myapp.jar

你也可以提供一个 Java 属性文件并从中加载配置值：

代理

Mon, 30 Mar 2026 18:14:49 +0800

代理 Collect 部署模式既包含采用 OpenTelemetry 协议（OTLP）并通过 OpenTelemetry SDK 插桩的各类应用，也包含使用 OTLP 导出器将遥测信号发送到与应用一起运行的 Collector 实例或与应用（例如边车或 DaemonSet）所在主机上的的其他 Collector。

每个客户端 SDK 或下游 Collector 都会配置一个 Collector 位置：

在应用中，SDK 被配置为将 OTLP 数据发送到 Collector。
Collector 被配置为将遥测数据发送到一个或多个后端。

示例

代理 Collector 部署模式的一个具体示例可能如下所示：你使用 OpenTelemetry Java SDK 手动为一个 Java 应用导出指标进行插桩。在应用的上下文中，你将 OTEL_METRICS_EXPORTER 设置为 otlp（这是默认值），并为 OTLP 导出器配置 Collector 的地址，例如（在 Bash 或 zsh shell 中）：

export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4318

在 collector.example.com:4318 提供服务的 Collector 将被配置为：

receivers:
 otlp: # 应用发送链路数据的 OTLP 接收器
 protocols:
 http:
 endpoint: 0.0.0.0:4318

processors:
 batch:

exporters:
 otlp/jaeger: # Jaeger 直接支持 OTLP
 endpoint: https://jaeger.example.com:4317

service:
 pipelines:
 traces/dev:
 receivers: [otlp]
 processors: [batch]
 exporters: [otlp/jaeger]

receivers:
 otlp: # 应用发送指标的 OTLP 接收器
 protocols:
 http:
 endpoint: 0.0.0.0:4318

processors:
 batch:

exporters:
 prometheusremotewrite: # PRW 导出器，用于将指标导入到后端
 endpoint: https://prw.example.com/v1/api/remote_write

service:
 pipelines:
 metrics/prod:
 receivers: [otlp]
 processors: [batch]
 exporters: [prometheusremotewrite]

receivers:
 otlp: # 应用发送日志的 OTLP 接收器
 protocols:
 http:
 endpoint: 0.0.0.0:4318

processors:
 batch:

exporters:
 file: # 文件导出器，用于将日志写入本地文件
 path: ./app42_example.log
 rotation:

service:
 pipelines:
 logs/dev:
 receivers: [otlp]
 processors: [batch]
 exporters: [file]

如果你想自己试一试，你可以查看端到端的 Java 或 Python 示例。

快速入门

Fri, 30 Jan 2026 17:29:44 +0800

本页面将引导你以最快的方式开始使用 OpenTelemetry 监控你的 Kubernetes 集群。它将专注于收集 Kubernetes 集群、节点、Pod 和容器的指标和日志，以及使集群支持发送 OTLP 数据的服务。

如果你想在 Kubernetes 中看到 OpenTelemetry 的实际应用，最好的起点是 OpenTelemetry 演示。该演示旨在说明 OpenTelemetry 的实现，但并非用于展示如何监控 Kubernetes 本身。完成本教程后，安装演示并查看所有监控如何响应活跃工作负载会是一个有趣的实验。

如果你想开始从 Prometheus 迁移到 OpenTelemetry，或者对使用 OpenTelemetry Collector 收集 Prometheus 指标感兴趣，请参阅 Prometheus 接收器。

概述

Kubernetes 通过多种不同方式暴露大量重要的遥测数据。它有许多不同对象的日志、事件、指标以及其工作负载生成的数据。

为了收集所有这些数据，我们将使用 OpenTelemetry Collector。 Collector 有许多不同的工具，可以高效地收集所有这些数据并以有意义的方式增强它。

为了收集所有数据，我们需要安装两个 Collector 实例，一个作为 Daemonset，另一个作为 Deployment。 Daemonset 安装的 Collector 将用于收集服务发出的遥测数据、日志以及节点、Pod 和容器的指标。 Deployment 安装的 Collector 将用于收集集群指标和事件。

我们将使用 OpenTelemetry Collector Helm Chart来安装 Collector，该 Chart 提供了一些配置选项，使 Collector 的配置更加容易。如果你不熟悉 Helm，请查看 Helm 项目网站。如果你对使用 Kubernetes Operator 感兴趣，请参阅 OpenTelemetry Operator，但本指南将重点介绍 Helm Chart。

安装 Collector

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

你可以在多种操作系统和多种架构上部署 OpenTelemetry Collector。以下说明展示了如何下载并安装 Collector 的最新稳定版本。

如果你还不熟悉 OpenTelemetry Collector 的部署模型、组件和相关代码库，请先查阅数据收集和部署方法页面。

Docker

以下命令会拉取一个 Docker 镜像，并在容器中运行 Collector。将 0.153.0 替换为你想要运行的 Collector 版本。

docker pull otel/opentelemetry-collector-contrib:0.153.0
docker run otel/opentelemetry-collector-contrib:0.153.0

docker pull ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector-contrib:0.153.0
docker run ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector-contrib:0.153.0

要从你的工作目录加载一个自定义配置文件，将该文件挂载为卷：

docker run -v $(pwd)/config.yaml:/etc/otelcol-contrib/config.yaml otel/opentelemetry-collector-contrib:0.153.0

docker run -v $(pwd)/config.yaml:/etc/otelcol-contrib/config.yaml ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector-contrib:0.153.0

Docker Compose

你可以像以下示例那样，将 OpenTelemetry Collector 添加到你现有的 docker-compose.yaml 文件中：

快速入门

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

OpenTelemetry Collector 是一个可执行文件，它能够接收链路、指标和日志，处理这些遥测数据，并通过其组件将其导出到多种可观测性后端。要了解 Collector 的概念性概览，请参见 Collector。

你将学习如何在不到五分钟的时间内完成以下操作：

设置并运行 OpenTelemetry Collector。
发送遥测数据并查看 Collector 对其进行处理。

前提条件

请确保你的开发环境具备以下条件。本文档假设你使用的是 bash，请根据你所偏好的 Shell 适配相关配置与命令。

Docker 或任何兼容的容器运行时。
Go 1.20 或更高版本
GOBIN 环境变量已设置；若未设置，请按如下方式进行初始化¹：
```
export GOBIN=${GOBIN:-$(go env GOPATH)/bin}
```

设置环境

拉取 OpenTelemetry Collector Contrib 的 Docker 镜像：
```
docker pull otel/opentelemetry-collector-contrib:0.153.0
```
安装 telemetrygen 工具：
```
go install github.com/open-telemetry/opentelemetry-collector-contrib/cmd/telemetrygen@latest
```
此工具可以模拟生成链路、指标和日志的客户端行为。

生成并收集遥测数据

启动 Collector，使其监听端口 4317（用于 OTLP gRPC）、4318（用于 OTLP HTTP）和 55679（用于 ZPages）：

docker run
 -p 127.0.0.1:4317:4317
 -p 127.0.0.1:4318:4318
 -p 127.0.0.1:55679:55679
 otel/opentelemetry-collector-contrib:0.153.0
 2>&1 | tee collector-output.txt # 可选择将输出保存，以便后续搜索

在另一个终端窗口中生成几个示例链路：

规范状态概览

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

OpenTelemetry 是基于各种信号逐一开发的。链路追踪、指标、Baggage 和日志都是一种信号。每个信号都构建在上下文传播机制之上，这是一种用于在分布式系统中关联数据的共享机制。

每个信号由四个核心组件组成：

API
SDK
OpenTelemetry 协议（OTLP）
Collector

信号还包括 contrib 组件，这是插件和插桩组成的生态体系。所有插桩遵循统一的语义约定，以确保在观察常见操作（如 HTTP 请求）时生成相同的数据。

如需了解信号和组件的信息，请参阅 OTel 规范的概览页面。

组件生命周期

组件遵循以下开发生命周期：

**草案（Draft）**组件仍在设计中，尚未纳入规范。
**实验性（Experimental）**组件已发布并可进行测试。
**稳定（Stable）**组件向后兼容，并享有长期支持。
**弃用（Deprecated）**组件仍然稳定，但未来可能被移除。

有关生命周期和长期支持的完整定义，参阅版本管理与稳定性。

当前状态

以下是目前各个信号的高层次状态报告。请注意，虽然 OpenTelemetry 各客户端遵循统一规范开发，但它们是独立开发的。

建议查看每个客户端在其 GitHub 仓库中 README 文件的当前状态说明。客户端对特性支持的具体情况可在规范兼容性表中查看。

注意，以下各部分中的 Collector 状态与协议状态一致。

链路追踪

规范
备注：
- 链路追踪规范现已完全稳定，并纳入长期支持范围。
- 链路追踪规范仍可扩展，但必须保持向后兼容。
- 一旦链路追踪实现完成，OpenTelemetry 客户端将进入 v1.0 版本。

指标

规范
备注：
- OpenTelemetry 各项指标正在积极开发中。
- 数据模型已稳定，并作为 OTLP 协议的一部分发布。
- Collector 中已提供对指标处理的实验性支持。
- Collector 正与 Prometheus 社区合作，开发对 Prometheus 的支持。

Baggage

规范
SDK： 稳定
协议： 不适用
备注：
- Baggage 现已完全稳定。
- Baggage 不是可观测性工具，而是一种在事务中附加任意键值对的系统，使下游服务可以访问这些值。因此，Baggage 没有 OTLP 或 Collector 组件。

日志

规范
备注：
- 日志数据模型已作为 OpenTelemetry 协议的一部分发布。
- 多种数据格式的日志处理已通过 Stanza 捐赠集成至 Collector。
- OpenTelemetry 的 Log Bridge API 允许开发日志附加器，用于将现有日志框架中的日志桥接到 OpenTelemetry 中。该 API 并不面向终端用户直接调用。目前正在开发多种编程语言的日志附加器。
- OpenTelemetry Log SDK 是 Log Bridge API 的标准实现。应用可以通过配置该 SDK 来指定日志的处理与导出方式（例如使用 OTLP 协议）。
- OpenTelemetry 的 Log Bridge API 还包含实验性支持，可用于生成符合事件语义约定的日志记录。

分析配置

规范

Metrics

Thu, 14 Aug 2025 10:14:16 -0300

一个 metric 是在运行时捕获的服务的测量值。捕获测量值的时刻称为 metric 事件，它不仅包括测量值本身，还包括捕获它的时间和相关的元数据。

应用和请求的 metrics 是可用性和性能的重要指标。自定义 metric 可以在‘可用性因素是如何影响到用户体验和业务’方面提供见解。收集的数据可以用于异常警告或触发调度决策，以在高要求时自动扩展部署。

要了解 OpenTelemetry 中的 metrics 是如何工作的，让我们看看在对代码进行观测时会涉及的一系列组件。

Meter Provider

Meter Provider（有时称为 MeterProvider）是 Meter 的提供者。在大多数应用程序中，Meter Provider 只初始化一次，其生命周期与应用程序的生命周期匹配。Meter Provider 的初始化还包括资源和导出器（Exporter）的初始化。它通常是使用 OpenTelemetry 进行观测的第一步。在某些语言 SDK 中，已经为您初始化了全局 Meter Provider。

Meter

Meter 创建 metric instruments，在运行时捕获有关服务的测量值。Meter 是由 Meter Provider 创建的。

Metric Exporter

Metric Exporter 将度量数据发送给消费者。这个消费者可以是开发期间用于调试的标准输出、OpenTelemetry Collector，或您选择的任何开源或供应商后端。

Metric Instruments（测量仪器）

在 OpenTelemetry 中，测量值是由 metric instruments 捕获的。Metric instruments 由以下部分定义：

名称
类型
单位（可选）
描述（可选）

名称、单位和描述由开发人员选择，或者通过语义约定为常见的如请求和进程指标定义。

仪器类型如下：

前置条件

Thu, 14 Aug 2025 10:14:16 -0300

要参与本仓库的贡献，你需要熟悉以下技术和工具：

git
GitHub
Markdown（CommonMark）
YAML

有关文档如何在本地构建和测试的技术细节，请参阅开发指南。

签署 CNCF CLA

所有 OpenTelemetry 贡献者必须签署 Linux 基金会的贡献者许可协议（CLA）。

尚未签署 CLA 的贡献者提交的 PR 会在自动测试中失败。你提供的姓名和电子邮件必须与 git config 中的内容一致，并且还必须与你用于签署 CNCF CLA 的信息一致。

行为准则

所有 OpenTelemetry 贡献者都必须遵守 CNCF 社区行为准则。

社区指南

有关 OpenTelemetry 社区的通用指南，包括角色和预期，请参阅 OpenTelemetry 新贡献者指南。

链路（Trace）

Thu, 14 Aug 2025 10:14:16 -0300

链路为我们提供了向应用发出请求时会发生什么的总览图。无论你的应用是具有单个数据库的单体应用还是复杂的服务网格，链路对于了解请求在应用中的完整“路径”至关重要。

让我们通过三个用 Span 表示的工作单元来探讨这个问题：

Note

以下 JSON 示例不表示特定格式，尤其是不表示 OTLP/JSON，因为 OTLP/JSON 更详细。

hello span:

{
 "name": "hello",
 "context": {
 "trace_id": "5b8aa5a2d2c872e8321cf37308d69df2",
 "span_id": "051581bf3cb55c13"
 },
 "parent_id": null,
 "start_time": "2022-04-29T18:52:58.114201Z",
 "end_time": "2022-04-29T18:52:58.114687Z",
 "attributes": {
 "http.route": "some_route1"
 },
 "events": [
 {
 "name": "Guten Tag!",
 "timestamp": "2022-04-29T18:52:58.114561Z",
 "attributes": {
 "event_attributes": 1
 }
 }
 ]
}

这是根 Span，表示整个操作的开始和结束。请注意，它有一个 trace_id 字段指示链路，但没有 parent_id。因此这是一个根 Span。

hello-greetings span:

{
 "name": "hello-greetings",
 "context": {
 "trace_id": "5b8aa5a2d2c872e8321cf37308d69df2",
 "span_id": "5fb397be34d26b51"
 },
 "parent_id": "051581bf3cb55c13",
 "start_time": "2022-04-29T18:52:58.114304Z",
 "end_time": "2022-04-29T22:52:58.114561Z",
 "attributes": {
 "http.route": "some_route2"
 },
 "events": [
 {
 "name": "hey there!",
 "timestamp": "2022-04-29T18:52:58.114561Z",
 "attributes": {
 "event_attributes": 1
 }
 },
 {
 "name": "bye now!",
 "timestamp": "2022-04-29T18:52:58.114585Z",
 "attributes": {
 "event_attributes": 1
 }
 }
 ]
}

此 Span 封装了特定任务，例如 hello-greetings，其父级 Span 是 hello Span。请注意，它的 trace_id 与根 Span 相同，这表明它们属于同一链路。此外，它的 parent_id 与 hello Span 的 span_id一致。

OpenTelemetry

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

Deploy OBI in Kubernetes with Helm

Deploying OBI from helm

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_*)

从 OpenTracing 迁移

语言版本支持

快速开始

安装

声明式配置

配置代理

代理

示例

快速入门

概述

安装 Collector

Docker

Docker Compose

快速入门

前提条件

设置环境

生成并收集遥测数据

规范状态概览

组件生命周期

当前状态

链路追踪

指标

Baggage

日志

分析配置

Metrics

Meter Provider

Meter

Metric Exporter

Metric Instruments（测量仪器）

前置条件

签署 CNCF CLA

行为准则

社区指南

链路（Trace）

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

`open_basedir`

Distro-specific options (`OTEL_PHP_*`)