OpenTelemetry 指标详解：Instruments、聚合与导出
OpenTelemetry Metrics 通过 Counter、UpDownCounter、Histogram、Observable Gauge 四种仪器采集指标，经聚合后由 Reader 导出。本文讲清仪器选型、聚合方式、View 定制与导出到观测云的配置方法。
OpenTelemetry Metrics 是 OTel 的指标信号体系：应用通过四种仪器（Counter、UpDownCounter、Histogram、Observable Gauge）记录测量值，SDK 按聚合规则汇总成数据点，再由 Reader 周期导出——与链路追踪的「单请求视角」不同，指标提供「全局水位视角」，是告警与容量规划的骨干数据。
核心要点速览
- 计数用 Counter（只增），变化量用 UpDownCounter（可增可减），分布用 Histogram，瞬时值用 Observable Gauge；
- Histogram 默认聚合为显式边界桶，新版本支持指数桶（Exponential Histogram）兼顾精度与体积；
- View 可定制聚合方式与保留属性，是控制指标基数的关键手段；
- 导出到观测云：OTLP 推送或 Prometheus 拉取，两条路都支持。
四种仪器怎么选？
| 仪器 | 语义 | 典型场景 |
|---|---|---|
| Counter | 单调递增 | 请求总数、错误总数、字节数 |
| UpDownCounter | 可增可减 | 当前连接数、队列深度、进行中任务 |
| Histogram | 分布统计 | 请求延迟、响应体大小 |
| Observable Gauge | 回调读取瞬时值 | CPU 使用率、内存占用、温度 |
选错仪器的典型症状：用 Gauge 记录累计值导致重启归零、用 Counter 记录瞬时值导致数据无意义。
聚合与数据点类型
SDK 把原始测量值聚合成数据点：Sum（Counter/UpDownCounter）、Gauge、Histogram（桶计数）、Exponential Histogram。聚合发生在 SDK 内，网络上传输的是聚合后的紧凑数据——这是 OTel 指标高效的原因。
View：定制与基数控制
View 允许对仪器做二次定制：改聚合方式（如把 Histogram 降为 Sum 省成本）、裁剪属性（丢弃高基数标签）、重命名指标。控制指标基数最有效的位置就是 View——在数据离开 SDK 前把 user_id 之类的危险属性裁掉（基数纪律见《高基数问题》）。
导出：推还是拉？
- OTLP 推送：周期性把指标推到 Collector 或 DataKit，适合服务实例动态伸缩的云原生环境；
- Prometheus 拉取：暴露
/metrics端点由 Prometheus 生态抓取，适合存量 Prom 体系。
观测云落地
- OTLP 路线：SDK 配置
OTEL_METRICS_EXPORTER=otlp，数据经 OTLP 进入观测云指标模块，用 DQL 查询、仪表板展示、监控器告警； - Prometheus 路线：暴露端点后由 DataKit 的 prom 采集器抓取（支持 K8s 自动发现），平滑融入观测云；
- 告警闭环：指标接入后，监控器即可按服务/接口维度配置阈值、突变与无数据告警，通知到钉钉/企微/飞书。
常见问题（FAQ）
Q：OTel 指标和 Prometheus 指标能互转吗？ 可以， Collector 与 DataKit 都支持格式转换；两者数据模型的差异与迁移要点见《OpenTelemetry 指标 vs Prometheus 指标》。
Q：Histogram 桶边界怎么设？ 默认边界覆盖常见 Web 延迟量级；业务特殊（如 AI 推理秒级到分钟级）时通过 View 自定义边界，或改用指数桶。
Q：指标采样间隔设多少合适？ 默认 60s 适用于多数场景；高频波动指标可降到 15-30s，但注意成本线性上升。
Q：SDK 侧聚合和平台侧聚合冲突吗？ 不冲突且互补：SDK 聚合控制传输体积，平台侧查询时按维度二次聚合。OTel 的 Sum 数据点带时间起点信息，平台能正确计算速率。
