Skip to content
OpenTelemetry 接入文档

OpenTelemetry 多语言接入指南

OpenTelemetry 多语言接入指南

统一的可观测性平台

使用 OpenTelemetry 标准协议，为您的应用程序提供全面的追踪、指标和日志收集能力。支持 Go、Python、Java、JavaScript、.NET、PHP、Rust、C++ 等主流语言。

为什么选择 OpenTelemetry？

🚀 零代码接入

无需修改代码，通过自动化工具即可快速接入，大幅降低接入成本和维护负担。

🌐 多语言支持

支持 Go、Python、Java、JavaScript、.NET、PHP、Rust、C++ 等主流编程语言，满足异构技术栈的监控需求。

📊 全链路追踪

自动捕获分布式系统中的请求调用链，快速定位性能瓶颈和故障根因。

🔧 灵活配置

提供丰富的配置选项和环境变量，支持自定义采样策略、资源属性等高级功能。

📈 标准协议

基于 OpenTelemetry 标准协议，避免厂商锁定，轻松切换不同的可观测性后端。

🎯 生产就绪

经过大规模生产环境验证，性能优异，资源占用低，可靠性高。

OpenTelemetry vs Apache SkyWalking

OpenTelemetry 和 Apache SkyWalking 都是优秀的 APM 解决方案。以下对比帮助您根据实际需求做出选择：

对比维度OpenTelemetryApache SkyWalking
定位🎯 开放标准 + SDK/API🛠️ 完整 APM 解决方案
标准化✅ CNCF 标准，厂商中立⚠️ 专有协议，部分支持 OTel
语言支持✅ 11+ 语言原生支持⚠️ Java 最佳，其他语言支持有限
数据模型✅ 统一的信号模型（Traces/Metrics/Logs）⚠️ 主要聚焦 Traces
自动埋点✅ 9 种语言零代码接入✅ Java 零代码接入（Agent 成熟）
社区生态✅ 最活跃的可观测性项目⚠️ 主要是中国社区
后端依赖✅ 无绑定，支持任意后端⚠️ 需要 SkyWalking OAP 后端
数据导出✅ OTLP 标准协议⚠️ 专有协议为主
灵活性✅ 高度可定制和扩展⚠️ 相对封闭的生态
学习曲线⚠️ 概念较多，需要学习标准✅ 开箱即用，上手简单
UI 和可视化⚠️ 需要第三方（Jaeger/Grafana/Uptrace）✅ 内置完整 UI，功能丰富
部署复杂度✅ 轻量级，只需 SDK + Collector⚠️ 需要部署 OAP + 存储 + UI
性能开销✅ 极低（SDK 级别）⚠️ Agent 开销稍高
厂商支持✅ 所有主流厂商支持⚠️ 厂商支持有限
数据所有权✅ 完全掌控，可切换后端⚠️ 依赖 SkyWalking 后端

📊 选择建议

选择 OpenTelemetry，如果您：

  • ✅ 需要厂商中立的解决方案，避免锁定
  • ✅ 使用多种编程语言（Go、Python、Java、.NET、Rust 等）
  • ✅ 希望灵活切换不同的 APM 后端（Jaeger、Zipkin、Grafana、Uptrace、Datadog 等）
  • ✅ 关注行业标准和长期演进（CNCF 项目）
  • ✅ 需要统一的 Traces、Metrics、Logs 数据模型
  • ✅ 希望与云原生生态深度集成（Kubernetes、Prometheus、Grafana）

选择 SkyWalking，如果您：

  • ✅ 主要使用 Java 技术栈
  • ✅ 需要开箱即用的完整 APM 方案（不想自己组合后端）
  • ✅ 喜欢 SkyWalking 的内置 UI 和可视化能力
  • ✅ 团队更熟悉中文文档和社区
  • ✅ 不需要切换到其他 APM 后端

💡 最佳实践：混合使用

您也可以将两者结合使用：

  • 使用 OpenTelemetry SDK 进行数据采集（享受标准化和灵活性）
  • 导出到 SkyWalking OAP（通过 SkyWalking 的 OTel Receiver，享受其 UI）
  • 同时导出到其他后端（如 Uptrace、Grafana），实现多后端对比和备份
# OpenTelemetry SDK 可以同时导出到多个后端
OTEL_EXPORTER_OTLP_ENDPOINT=http://skywalking-oap:11800,http://uptrace:4317

这种方式让您既能享受 OpenTelemetry 的标准化，又能利用 SkyWalking 的 UI 能力。

快速开始

选择您使用的编程语言，开始接入 OpenTelemetry：

Go 语言

支持零代码接入和 SDK 手动接入

查看文档 →

Python

使用 opentelemetry-instrument 一键启动

查看文档 →

Java

通过 Java Agent 实现零侵入

查看文档 →

JavaScript

Node.js 和浏览器端全覆盖

查看文档 →

.NET

ASP.NET Core 自动化监控

查看文档 →

PHP

Laravel 和 Symfony 自动化监控

查看文档 →

Rust

Rust 自动化监控

查看文档 →

C++

C++ 自动化监控

查看文档 →

主要特性

三大信号支持

  • Traces（追踪）：分布式追踪，记录请求在系统中的完整调用链路
  • Metrics（指标）：性能指标采集，包括请求量、响应时间、错误率等
  • Logs（日志）：结构化日志收集，与 Trace 自动关联

丰富的框架支持

自动支持主流框架和库：

  • Web 框架：Gin、Echo、Flask、Django、Spring Boot、Express、Koa、ASP.NET Core
  • 数据库：MySQL、PostgreSQL、MongoDB、Redis、Elasticsearch
  • 消息队列：Kafka、RabbitMQ、RocketMQ
  • RPC 框架：gRPC、Dubbo、Thrift
  • HTTP 客户端：标准库、第三方客户端

灵活的部署方式

  • 零代码接入：通过 Agent 或自动化工具，无需修改代码
  • SDK 接入：手动集成 SDK，获得更细粒度的控制
  • 混合模式：结合自动化和手动埋点，满足复杂场景

核心概念

了解 OpenTelemetry 的核心概念，帮助您更好地使用：

  • Span：表示一次操作，包含时间戳、属性、事件等信息
  • Trace：由多个 Span 组成的完整调用链
  • Context Propagation：在分布式系统中传递追踪上下文
  • Resource：描述生成遥测数据的实体，如服务名称、版本等
  • Instrumentation：代码埋点和数据采集的过程

了解更多核心概念 →

环境变量配置

OpenTelemetry 支持通过环境变量进行配置，以下是常用配置：

# 服务基本信息
OTEL_SERVICE_NAME=your-service-name
OTEL_RESOURCE_ATTRIBUTES=service.version=1.0.0,deployment.environment=production


# OTLP 导出器配置
OTEL_EXPORTER_OTLP_ENDPOINT=https://your-apm-platform.com
OTEL_EXPORTER_OTLP_HEADERS=uptrace-dsn=<your-dsn>
OTEL_EXPORTER_OTLP_PROTOCOL=grpc


# Trace 配置
OTEL_TRACES_EXPORTER=otlp
OTEL_TRACES_SAMPLER=parentbased_traceidratio
OTEL_TRACES_SAMPLER_ARG=0.1


# Metrics 配置
OTEL_METRICS_EXPORTER=otlp
OTEL_METRIC_EXPORT_INTERVAL=60000


# Logs 配置
OTEL_LOGS_EXPORTER=otlp

查看完整环境变量列表 →

获取 DSN

DSN（Data Source Name）是连接 APM 平台的凭证，请联系平台管理员获取或在平台控制台中生成。

DSN 配置指南 →

高级特性

探索更多高级功能，充分发挥 OpenTelemetry 的能力：

准备好开始了吗？

选择您的编程语言，5 分钟内完成接入

开始接入 →