📚 课程目录第1章课程导论

1. 课程导论：OpenTelemetry 指标重命名与标签合并的背景、重要性、适用场景

随着微服务架构与云原生技术的普及，一个业务系统往往由数十甚至上百个服务组成。每个服务可能使用不同的客户端库（Prometheus SDK、StatsD、Micrometer、OpenTelemetry SDK 等）来暴露指标数据。这种技术异构性导致了严重的 指标命名碎片化 问题：

命名风格不统一：同一业务含义的指标，在不同服务中可能叫 http_requests_total、request.count、http.server.requests。
标签（Label/Attribute）结构不一致：有的服务使用 method 标签，有的使用 http_method，有的使用 verb。
标签值格式混乱：状态码有的用 200，有的用 "200"，有的用 OK。
冗余标签膨胀：部分中间件自动注入大量无关标签，导致指标基数爆炸。

  核心痛点：后端监控系统（如 Prometheus、Grafana、Datadog）无法直接聚合这些异构指标，运维人员需要手动编写大量 PromQL 或查询转换逻辑，维护成本极高。

在 OpenTelemetry 生态中，指标重命名（Metric Renaming） 与 标签合并（Label Merging / Attribute Transformation） 是数据预处理阶段的关键能力。它们直接决定了可观测性数据的质量与可用性。其重要性体现在以下四个维度：

维度	说明	典型收益
数据一致性	将异构指标名称统一为标准命名，消除命名歧义	后端无需感知来源差异，直接使用统一名称查询
查询效率	合并冗余标签、精简标签数量，降低指标基数	Prometheus 存储压力下降 30%~60%
迁移兼容	从旧 SDK（如 Prometheus、StatsD）迁移到 OTel 时，保留原有指标名称	无需修改已有告警规则和仪表盘
治理标准化	通过统一规则强制团队遵守命名规范	降低跨团队协作的认知成本

实践建议：在引入 OpenTelemetry 的初期，就应制定指标命名与标签治理规范，并将重命名规则作为 Collector 配置的一部分进行版本管理。

并非所有场景都需要进行指标重命名。以下三类场景是 必须使用 重命名与标签合并的典型情况：

多技术栈统一接入：Java 服务使用 Micrometer、Go 服务使用 Prometheus SDK、Python 服务使用 OpenTelemetry SDK，三者上报的指标名称完全不同，必须通过 OTel Collector 的 transform 处理器统一命名。
遗留系统迁移：从 Prometheus 或 StatsD 迁移到 OpenTelemetry 时，为了不破坏已有的 Grafana 仪表盘和 Prometheus 告警规则，需要将 OTel 指标重命名为旧名称。
标签基数控制：某些中间件（如 Istio、Kong）会注入大量请求级标签（如 source_ip、user_agent），导致指标基数爆炸。需要通过标签合并或删除操作，只保留必要的标签。

下图展示了指标重命名与标签合并在整个 OpenTelemetry 数据管道中的位置与作用：

在 OpenTelemetry Collector 中，指标重命名与标签合并通常遵循以下处理步骤：

步骤	操作	示例（Prometheus 格式）
1	接收原始指标	`http_requests_total{method="GET",status="200",service="foo"}`
2	重命名指标名称	`http.server.requests{method="GET",status="200",service="foo"}`
3	合并/重命名标签	`http.server.requests{http_method="GET",http_status="200",service="foo"}`
4	删除冗余标签	`http.server.requests{http_method="GET",http_status="200"}`
5	输出标准化指标	发送到 Prometheus 后端存储

注意：标签合并操作可能导致指标基数增加（例如将两个高基数标签合并为一个），请务必在合并前评估基数变化。建议在测试环境中使用 otelcol 的 --metrics-level=detailed 参数观察指标基数变化。

指标重命名与标签合并是 OpenTelemetry 数据治理的核心手段。通过本课程，你将掌握：