OpenTelemetry

OBI Network Metrics configuration options

Mon, 06 Apr 2026 03:41:58 -0700

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).

OBI global configuration properties

Mon, 30 Mar 2026 12:18:35 +0200

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.

代理

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 示例。

Migrating from OpenCensus

Thu, 19 Mar 2026 06:58:46 -0700

Migrating from OpenTracing

Thu, 19 Mar 2026 06:58:46 -0700

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.

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.

Run OBI as a Docker container

Thu, 19 Feb 2026 16:15:55 +0100

OBI can run a standalone Docker container that can instrument a process running in another container.

Find the latest image of OBI on Docker Hub with the following name:

otel/ebpf-instrument:main

The OBI container must be configured in following way:

run as a privileged container, or as a container with the SYS_ADMIN capability (but this last option might not work in some container environments)
Use the host PID namespace to allow accessing to the processes in other containers.

Image Signing and Verification

The OBI container image is signed using Cosign with ephemeral keys, authenticated via the OIDC (OpenID Connect) protocol in GitHub Actions. This ensures the authenticity and integrity of the container published by the OpenTelemetry project.

快速入门

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。

快速开始

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

安装

从 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 属性文件并从中加载配置值：

Deploy OBI in Kubernetes with Helm

Mon, 26 Jan 2026 02:42:14 -0800

说明

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
Providing secrets to the Helm configuration

Deploying OBI from helm

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

Measure traffic between Cloud availability zones

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

说明

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:

安装 Collector

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

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

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

Docker

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

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

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

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

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

docker run -v $(pwd)/config.yaml:/etc/otelcol-contrib/config.yaml ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector-contrib:0.149.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.149.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.149.0
 2>&1 | tee collector-output.txt # 可选择将输出保存，以便后续搜索

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

日志

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

日志是带有时间戳的文本记录，可以是结构化的（推荐）或非结构化的，且可附带元数据。在所有遥测信号中，日志具有最悠久的历史。大多数编程语言都内置了日志记录功能，或有知名且广泛使用的日志库。

OpenTelemetry 日志

OpenTelemetry 并未定义专用的 API 或 SDK 来创建日志。相反，OpenTelemetry 日志指的是你已有的日志，这些日志来自现有的日志框架或基础设施组件。OpenTelemetry SDK 和自动注入功能利用多个组件，自动将日志与链路关联。

OpenTelemetry 的日志支持旨在与你已有的日志完全兼容，提供了能力来为这些日志添加上下文，并提供统一的工具包，将来自不同来源的日志解析并转换为统一格式。

OpenTelemetry Collector 中的 OpenTelemetry 日志

OpenTelemetry Collector 提供了多个处理日志的工具：

多种接收器，可从特定的、已知的数据源解析日志。
filelogreceiver，可从任意文件读取日志，并支持多种日志格式解析或使用正则表达式。
类似 transformprocessor 的处理器，可解析嵌套数据、扁平化结构、添加/移除/更新值等。
多种导出器（exporters），可将日志数据导出为非 OpenTelemetry 格式。

采纳 OpenTelemetry 的第一步通常是部署 Collector 作为通用日志代理。

应用中的 OpenTelemetry 日志

在应用中，可以通过任意日志库或语言内置日志功能创建 OpenTelemetry 日志。当你启用自动注入或激活 SDK 后，OpenTelemetry 会自动将现有日志与活动的链路与 Span 关联起来，并将这些 ID 包裹到日志正文中。换句话说，OpenTelemetry 会自动关联你的日志与链路信息。

语言支持情况

日志信号在 OpenTelemetry 规范中是稳定的。各语言对 Logs API 和 SDK 的支持情况如下：

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.

规范状态概览

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一致。

从 OpenTracing 迁移

Thu, 24 Jul 2025 15:38:52 +0800

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 要求更高的语言版本。

OpenTelemetry

OBI Network Metrics configuration options

OBI global configuration properties

代理

示例

Migrating from OpenCensus

Migrating from OpenTracing

Configure OBI export modes

Configure and run OBI

Run OBI as a Docker container

Image Signing and Verification

快速入门

概述

快速开始

安装

声明式配置

配置代理

Deploy OBI in Kubernetes with Helm

Deploying OBI from helm

Measure traffic between Cloud availability zones

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

安装 Collector

Docker

Docker Compose

快速入门

前提条件

设置环境

生成并收集遥测数据

日志

OpenTelemetry 日志

OpenTelemetry Collector 中的 OpenTelemetry 日志

应用中的 OpenTelemetry 日志

语言支持情况

OBI network metrics quickstart

规范状态概览

组件生命周期

当前状态

链路追踪

指标

Baggage

日志

分析配置

Metrics

Meter Provider

Meter

Metric Exporter

Metric Instruments（测量仪器）

前置条件

签署 CNCF CLA

行为准则

社区指南

链路（Trace）

从 OpenTracing 迁移

语言版本支持

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