LabHub
学习 学习路径 课程

OTCA — OpenTelemetry 认证助理

OTLP 不是存储,是协议

在 LabHub 中继续学习

一句话总结

OpenTelemetry 标准化遥测数据的生成与发送方式,不负责存储或展示。OTLP 是传输协议,后端可选择 Tempo、Jaeger、ClickHouse 等。先明确这一边界,才能消除“安装 OpenTelemetry 就会出现仪表板吗”的误解。

概念图: 生成与发送方式 · 四种信号 · 哪里 · 从何时起、恶化多少

为什么需要它

过去各厂商的计量库不同,更换后端就意味着重新计量所有服务,因为代码中嵌入了特定厂商 SDK 调用。OpenTelemetry 切断了这种耦合:应用只与 OTel API 交互,发送目的地由 SDK 或 Collector 配置决定,因此更换后端从代码评审变成配置修改。

工作原理

四种信号分别回答不同问题。

信号 回答的问题 典型局限
Traces 请求在哪里耗时 看不到从何时开始、影响比例
Metrics 从何时起、恶化多少 无法还原单个请求
Logs 其中为何发生 服务间关联需自行连接
Profiles 哪些代码花费时间 最晚标准化的信号

追踪回答“哪里”,指标回答“何时与多少”,日志回答“为什么”。三者齐全才能完成调查。从追踪复制 trace ID 到日志中搜索,能否找到该请求日志,是确认计量是否连通的最低成本测试。

组件分三层。

OTLP 是层间流动的协议。它有两种传输方式,也是新手最常踩坑之处。

方式 默认端口 OTEL_EXPORTER_OTLP_PROTOCOL
gRPC 4317 grpc
HTTP/protobuf 4318 http/protobuf

端口与协议不匹配时连接直接失败,且错误只留在应用日志中。Collector 指标会一直为 0,很容易误诊为“Collector 不接收”。完全没有数据时,首先检查这组组合。

端点也有规则。OTEL_EXPORTER_OTLP_ENDPOINT 是所有信号共用的基础地址;使用 HTTP 时,SDK 会追加 /v1/traces 等路径。若各信号使用不同目的地,则用 OTEL_EXPORTER_OTLP_TRACES_ENDPOINT 等信号专用变量,此时必须写完整路径。

现场会遇到的情况

Collector 有两种发行版。Core 只包含核心组件,体积小;Contrib 包含大量社区组件,体积大。照搬文档或博客中的组件名后,Collector 常因“未知类型”退出,人们通常先怀疑配置拼写,实际更常见的原因是发行版不同。应先用 otelcol components 确认当前二进制包含的组件及稳定性等级。

Jaeger v2 内部基于 OpenTelemetry Collector 重构,原生接收 OTLP。Zipkin exporter 已进入弃用状态,新项目没有理由新增它。

实际接入计量时要决定什么

OpenTelemetry 概念很广,真正接入时常卡在从哪里开始。正确顺序如下。

先启用自动计量。 多数语言都有 agent 或库,无需改代码即可为 HTTP 服务端、客户端、DB 驱动等建立 span。仅此就能回答“哪个请求慢”,覆盖可观测性的八成。

再添加手工 span。 自动计量不知道业务逻辑。只为有意义的单元(订单验证、库存确认、结算计算)建立 span,不要每个函数都加。span 过多既难读又增加成本。

属性名称遵循约定。 使用 http.request.methoddb.systemservice.name 等标准名,工具才能自动生成界面。自定义名称只在自家仪表板有意义;内部属性应加前缀区分。

确认传播(propagation)。 跨服务追踪断裂最常见。要确认 traceparent 头能穿过代理、队列和批处理;消息队列常需手工注入、提取头部。

从一开始确定采样。 全量发送成本过高,随机减少又可能漏掉慢请求。答案是尾部采样:请求结束后保留慢请求或错误请求,但会占用 Collector 内存。起步可设为“错误和慢请求全部保留,其余 1%”。

在中间放置 Collector。 应用直发后端时,更换后端需重新部署所有服务。有 Collector 后,目的地变更、过滤和重试都集中在一处。

下一项检查要看什么

本模块没有实验。通过测验确认信号边界与 OTLP 约定后,下一模块会亲自编写 SDK 环境变量和资源属性,并通过 Kubernetes Downward API 注入实例标识。