什么是 OpenTelemetry 指标？

与  OpenTelemetry 日志 和追踪一样，OTel 指标提供标准化的遥测信号。这些信号采用通用且语言无关的数据模型和传输协议（即 OpenTelemetry 协议 (OTLP)），能够从不同来源、系统和格式中摄取数据，并将其发送至 可观测性 后端。 

OTel 指标依赖 OpenTelemetry 插桩来收集时间序列数据——例如  CPU  和内存使用率、吞吐量、错误率、请求计数和响应时间——这些数据来自运行中的应用程序和 基础设施 组件。开发人员对代码进行插桩以记录必要指标后，OTel 允许将这些指标聚合并导出到任意（或每一个）后端可观测性工具，用于存储、查询和可视化，且无需更改插桩。

指标通常是揭示系统问题的首个遥测信号。在 OTel 框架中，指标与日志（离散系统事件的不可变记录）和追踪（数据请求的端到端旅程）集成，这些日志和追踪依赖相同的概念和 元数据。

这种机制使开发人员和 站点可靠性工程师 (SRE)  能够将指标用作高级预警系统。他们可以在一个连贯的视图中跟踪故障的完整路径（包括故障组件与之交互的每个服务的指标），并快速转向追踪和日志进行 根本原因分析。

实际上，这意味着 IT 团队只需几次点击，就能从“此 端点 速度慢”跳转到“这些特定请求和依赖项就是问题所在”。

此外，OTel 的标准化协议有助于跨可观测性供应商实现自动化信号关联，使企业能够灵活地随时切换可观测性工具，或同时使用多个工具。

OpenTelemetry 指标是 OpenTelemetry 的基础组件。OpenTelemetry 是一个 开源 可观测性框架，包含一 系列软件开发工具包 (SDK)、供应商中立的 应用程序编程接口 (API)  以及用于应用程序、系统和设备插桩的其他工具。

过去，插桩代码差异很大，且没有一家商业供应商能提供从网络上每个应用程序和服务收集数据的工具。这种功能缺口使得团队难以（而且常常不可能）从不同编程语言、格式和运行时环境中收集数据。

传统的可观测性方法还使得更换后端基础设施和组件成为一个耗时费力的过程。

假设一个开发团队想要更换后端工具，他们将不得不完全重新插桩代码，并配置新的智能体（执行 自动化 构建和发布任务的软件组件），以将遥测数据发送到新服务器。 碎片化的方法造成了数据孤岛和混乱，使得有效解决性能问题变得困难。

OpenTelemetry 代表了可观测性工具的重大进步， 因为它标准化了遥测数据的收集、分析和传输至后端平台的方式。 它提供了一种基于社区驱动标准的 开源 解决方案，用于收集有关系统行为和安全性的数据，帮助团队简化分布式生态系统中的 监控和可观测性 。

OpenTelemetry 指标依赖一组相关组件，这些组件共同定义了指标如何产生、描述并传输至可观测性后端。它们包括：

测量器是代码用来记录指标值的工具。它们以两种方式记录值：同步（在代码运行时，直接在执行路径中）和异步（每当 SDK 从代码请求值时）。

由于同步测量器与操作内联运行，它们能够捕获当前的追踪上下文及相关事件属性，使其收集的指标更容易与日志和追踪关联。

异步测量器通过基于拉取的回调函数更新，SDK 会按预设的收集间隔调用这些函数。这些测量器对于定期采样而非每次用户请求都采样的值（例如 CPU 使用率或内存）非常有用。 

OTel 插桩位于应用程序逻辑和指标管道之间，将诸如“HTTP 请求完成”之类的事件转换为结构化的测量数据，供 SDK 聚合和导出。每种类型的指标测量器都针对特定的测量模式进行了优化，并具有相关的聚合策略，描述了 SDK 应如何将单个测量结果合并为导出的指标。

常见的测量器类型有：

• 计数器 是同步测量器，记录随时间递增的增量（例如请求总数或进程启动以来发送的总字节数）。计数器也是单调的，因此每次记录新测量值时，它们会将其添加到现有值上，而不是替换现有值。

• 升降计数器是同步测量器，记录可随时间增加或减少的值（例如活跃用户数或队列大小）。与标准计数器不同，升降计数器是非单调的，因此它们通过替换现有值来向上或向下调整总数。

• 异步计数器和异步升降计数器与其同步对应物类似，但它们每次导出时记录一次值，而不是在代码执行期间收集。

• 仪表是同步测量器，记录在每次数据推送时可任意增加或减少的值，代表从代码收集的那一刻的值。除同步仪表外，指标收集还需要可观测仪表，它们是异步测量器，在指标后端收集数据时拉取当前值。
  
  仪表捕获值快照的方式与相机拍摄目标快照的方式大致相同。并且由于仪表是非累积的，它们通常应用于不可加总的值，即求和没有意义的值（例如内存使用量或温度）。  

• 直方图是同步测量器，用于捕获有多少测量值落入不同的值范围，而不是跟踪单个数字（如总数或当前值）。它们将值放入“桶”中，使 IT 团队能够计算百分位数，并了解请求时长、 延迟 及有效载荷大小等指标的值分布。

OTel 定义了一套标准化的指标数据模型和时间序列，可将单个指标事件转换为清晰、可查询、基于时间的数字序列，供 IT 团队在可观测性平台中存储和分析。

OpenTelemetry 通过三个相关模型来描述指标：事件模型（来自测量器的原始测量值）、OTLP 流模型（这些测量值如何打包和发送）以及时间序列模型（后端如何存储它们）。

在实践中，应用程序代码使用事件模型记录事件，SDK/收集器将其转换为 OTLP 流，后端平台将其存储为时间序列，例如“服务 X 在特定时间段内每秒返回状态码 200 的请求数”。

语义约定（也称为命名约定）为常见指标定义了标准化的名称、单位和属性键，以便不同服务和库产生一致的遥测数据。例如，约定规定了诸如 “http.server.duration” 这样的名称用于 HTTP 服务器请求延迟，并建议使用秒或毫秒作为持续时间的单位。

使用 OTel 的语义约定，团队可以将指标接入期望特定模式的预构建仪表板和告警系统，从而减少他们花费在自定义配置工作上的时间。这也让跨团队协作更加容易，因为每个人在 微服务之间都使用相同的“指标语言”。

此外，上下文传播功能可以通过跨服务边界携带共享上下文（例如追踪或跨度标识符），将指标与相关追踪（通过使用示例）以及日志关联起来。

例如，OTel 传播器可以从请求处理程序中提取传入的上下文，用它启动一个追踪跨度，并使用相同的上下文记录延迟指标和写入日志条目。这样，指标数据点和日志行都会标记上当前的追踪信息。

当应用程序代码发起下游调用时，传播器将相同的上下文注入到传出请求中。代码提取该上下文，启动自己的子跨度，并将该上下文用于自身的指标和日志，从而使两个服务的所有内容都与同一个端到端追踪关联在一起。

属性（也称为标签、标记或维度）是附加到单个测量或聚合数据点上的键值对。它们与指标名称、聚合类型和单位一起，完全或部分地定义了一个时间序列。如果没有属性，一个指标的所有测量值将合并为一个无差别的序列。

添加属性（例如服务名称、端点、HTTP 状态码、区域或租户 ID）可将简单指标转变为多维的、专门的指标流，团队可以在可观测性工具中对其进行切片和切块分析。团队可以获得按他们选择的任何维度过滤或分组的高分辨率视图。

良好的属性设计还能在细节与指标基数（一个属性可以取的不同值的数量）之间取得平衡，这样团队可以避免标签爆炸，同时仍能运行有用的查询。

测量是由测量器在特定时间点获取的单个事件级读数，通常附带属性。例如，当一个 HTTP 请求完成时，你可能会记录一个 120 毫秒的延迟，并附带诸如 route=”/login” 和 status_code=200 这样的属性，分别代表路由和状态码。

每次单独的记录都是一个独立的测量，描述了该次操作期间发生的情况。

测量值会短暂存储在 SDK 内部，然后 SDK 将原始测量值转换为更大指标流中的数据点。聚合的数据点不会显示每个单独的请求，而是可能显示“对于路由  /login  且状态码为 200，在 10:00:00 到 10:00:10 期间，共有 500 个请求，总持续时间为 25 秒。”正是这些数据点最终被导出并存储在可观测性后端。

OpenTelemetry 指标 API 是应用程序代码为生成指标而调用的一组接口。它设计为与供应商无关，将插桩与具体的 SDK 实现解耦。IT 团队可以一次性编写插桩（使用标准 API），然后无需采取额外步骤即可更换 SDK、导出器和后端。

OTel 指标 API 的结构由三个核心接口构成：计量器提供者、计量器和指标测量器。

计量器提供者 是 API 的入口点，负责创建计量器实例。它们决定使用哪些指标读取器和导出器、应用哪些视图和聚合，以及收集和导出数据的频率。计量器提供者通常在应用程序启动时加载一次（通常作为全局提供者），以便所有计量器和测量器共享一致的资源定义和导出管道。

计量器 是应用程序代码用来创建计数器、直方图和仪表的对象。每个计量器通常以库或服务命名（例如 “bank.payment”），以便来自该代码的指标能够被一致地分组和标识。

计量器本身不存储数据；相反，它们充当测量器的工厂，并将记录的测量值传递给底层 SDK 进行聚合和导出。由于计量器是从计量器提供者获取的，它们始终使用提供者定义的配置、视图和导出器运行。

然后，测量器 提供指令，使代码能够报告带有属性的测量值。

OpenTelemetry SDK 是 OpenTelemetry API 的具体实现，它将 API 调用转换为实际的遥测数据点。它提供了一个特定于语言的库（例如 Java™ 或 Python），用于收集、聚合和准备指标数据以供导出。

SDK 管理插桩生命周期，处理测量值的内存存储，运行异步测量器的回调，应用已配置的聚合和视图，并控制指标收集间隔（通常为 10–60 秒）。

在 SDK 内部，处理器应用聚合和其他逻辑，包括过滤、速率限制或在发送之前转换指标流。

导出器将处理后的指标数据点转换为后端特定格式，并使用支持的协议（例如 OTLP）将其发送到外部后端或可观测性平台。

团队可能会选择在 SDK 中将多个导出器链接在一起，以在需要高可用性和冗余的环境中支持多后端。在这些情况下，OpenTelemetry 收集器充当智能代理，可以同时向多个后端发送指标，重试导出尝试或大规模进行身份验证。 

聚合定义了如何将原始的单个测量值在数学上组合为汇总统计数据，后端将其作为时间序列数据点进行存储和查询。原始数据由 SDK 的聚合器按每个收集间隔聚合成每个唯一时间序列的单个数据点。

常见的聚合模式包括：

• 求和 (Sum)，将累积量（例如传输的字节数）的所有值相加。

• 最新值 (LastValue)， 仅保留最新的测量值，丢弃较早的值。

• 直方图聚合， 将值分组到桶中，以便团队计算百分位数并检测异常值。

• 丢弃 (Drop)，丢弃所有值以防止高基数数据（具有大量唯一值的数据）。

聚合还携带时间性元数据，它告诉后端如何解释随时间变化的指标值。两种主要类型是：

• 累积值反映自进程启动以来的总量。这些值仅在进程重启时重置，后端通过计算数据点之间的差值来得出速率。

• 增量值反映自上次数据收集以来的变化。后端可以直接对增量求和来确定速率。

SDK 会根据测量器类型自动应用正确的聚合。它们还使 IT 团队能够从简单的总数切换到丰富的直方图或其他算法，而无需更改插桩。

指标展示趋势并发送警报，追踪揭示请求的路径，日志提供丰富的事件级上下文。将指标与追踪和日志关联起来，连接了三大可观测性信号（称为“可观测性的支柱”），使团队能够获得系统行为的分层视图。

例如，指标可以显示聚合趋势，如“错误率在下午 2:15 飙升”，但它们无法揭示哪些请求失败或为何失败。追踪可以揭示跨服务的有问题的单个请求路径，但如果没有指标，它们无法帮助团队判断一个坏请求是异常值还是系统性问题。日志提供详细的错误消息和事件，但如果没有上下文，它们只是噪音。

将所有三个信号关联起来，使 IT 团队能够在几秒钟内从高级指标趋势无缝转移到受影响的追踪和相关日志。

OTel 指标与传统指标有着根本区别。传统指标通常指传统的监控方法，侧重于针对资源使用情况的简单、预定义计数器。这些指标强调主机级或特定于应用程序的测量。 

相比之下，OpenTelemetry 指标是统一的、供应商中立的可观测性框架的一部分，该框架为分布式 IT 环境的追踪、日志和指标标准化了数据收集。它们通过提供更灵活的数据模型和插桩，在传统指标的基础上进行了改进，包括用于双向变化的升降计数器和支持指数分桶的直方图。它们还提供显式的属性、单位和时间戳来丰富指标。

OTel 指标在设计、收集方法以及对现代系统的适用性方面也不同于传统指标。

传统指标采用僵化的全栈模型，将收集、存储和查询紧密耦合，通常仅使用来自基本计数器、仪表、摘要和带有显式分桶（需要手动分桶）的直方图的累积值。

OpenTelemetry 指标采用模块化的三层设计——包含 API、SDK 和协议——将信号生成与处理和导出分离。这种配置使 OTel 指标能够支持高级功能，例如增量时间性、整数值、直方图上的最小和最大元数据，以及用于动态缩放的指数直方图。

传统方法依赖从暴露的 API 端点进行基于拉取的数据抓取，主要针对孤立的指标。它们使用手动插桩，并且对追踪或日志的支持有限，这导致了零散的遥测和可观测性管道。

OpenTelemetry 使用 OTLP（一种二进制协议）进行基于推送的数据收集，能够通过自动和手动插桩统一收集追踪、指标和日志。OTel 还提供了一个收集器来促进数据转换、批处理以及路由至后端工具，这有助于 IT 团队解决应用程序存储方面的问题。

传统遥测数据适用于简单的单体架构。然而，由于追踪能力差、供应商锁定问题以及孤立的信号（这些信号掩盖依赖关系且无法揭示级联故障），它在微服务环境中表现不佳。

OpenTelemetry 在 云原生、分布式环境中表现出色，因为它提供了相关的、供应商中立的遥测数据，可实现对跨服务请求流、延迟瓶颈和资源诊断的端到端可见性。OTel 还支持采样和混合工具集成，这有助于遥测和插桩随 IT 环境一同扩展。 

OpenTelemetry 指标提供标准化的、定量的测量，有助于改进现代架构中的可观测性。它们提供对系统性能的详细洞察，使开发人员和工程师能够实施主动的问题解决和优化策略。

其他优势包括：