揭秘可观测利器：腾讯云 APM 深度融合 OpenTelemetry 和 Prometheus，助力高效指标采集与处理

前言

腾讯云应用性能监控（APM）作为腾讯云可观测平台（TCOP）旗下专注于应用性能管理的产品，基于链路、指标、日志等可观测数据，提供一站式应用性能管理能力，能够有效加速故障排查，定位架构瓶颈，为业务的健康和稳定保驾护航。

Prometheus 是一个功能强大、灵活且扩展性强的开源可观测平台，提供了多维数据模型、丰富的采集能力，以及强大的查询语言。作为 CNCF（Cloud Native Computing Foundation）旗下最重要的开源项目之一，Prometheus 在云原生时代被广泛使用，构建了繁荣的开源生态。特别是在指标（Metric）监控领域，Prometheus 已经成为了事实的标准。

与此同时，OpenTelemetry 也成为了可观测数据在检测、生成、收集和导出方面的最重要的技术标准，对于可观测领域的三大支柱数据——链路（Trace）、指标（Metric）、日志（Log）都提供了支持。

有没有办法把可观测领域的这 2 大标准完美的融合在一起？答案是肯定的。腾讯云应用性能监控（APM）提供了完整的技术方案：对于通过 OpenTelemetry 方案接入 APM 的应用，可以使用 OpenTelemetry API 上报自定义指标。APM 服务端负责将自定义指标同步到腾讯云 Prometheus 监控服务，帮助用户基于 Prometheus 生态挖掘数据价值。

其中最典型的使用场景就是通过 Grafana 服务对接 Prometheus 数据源，获得强大的数据展示能力。此外，用户还可以通过腾讯云可观测平台提供的 Dashboard 服务对接 Prometheus 数据源，并在 APM 控制台基于应用视角查看 Dashboard 中的自定义大盘。

OTel 指标输出到 Prometheus

由于 OpenTelemetry 和 Prometheus 属于不同的技术体系，OpenTelemetry API 上报自定义指标，不能直接输出到 Prometheus 中，需要进行处理和转换，常见的方式有如下几种：

1.应用引入 openTelemetry-exporter-prometheus 库，将 OpenTelemetry 指标直接以 Prometheus Exporter 形式进行暴露，再通过 Prometheus 进行拉取。

2.应用将 OpenTelemetry 指标上报到 OpenTelemetry Collector，由 Collector 将 OpenTelemetry 指标以 Prometheus Exporter 形式进行暴露，再通过 Prometheus 进行拉取。

3.应用将 OpenTelemetry 指标上报到 OpenTelemetry Collector，由 Collector 将 OpenTelemetry 指标转换为 Prometheus 指标，再通过 Remote Write 的方式写入到 Prometheus。

这几种方式的实用性都比较低：方式 1 需要引入特定的类库，在很多编程语言中都是缺失的，而且服务发现的配置工作也比较复杂。方式 2 和方式 3 需要自行搭建 OpenTelemetry Collector，部署和维护工作量比较大。

腾讯云应用性能监控（APM）引入了更便捷高效的集成方案，不需要自行搭建 OpenTelemetry Collector，也不需要复杂的配置项。在进行简单的关联后，应用直接通过 OpenTelemetry API 上报指标，即可输出到腾讯云 Prometheus 监控服务中。

腾讯云 Prometheus 监控服务（TencentCloud Managed Service for Prometheus，TMP）是基于开源 Prometheus 构建的高可用、全托管的服务，与腾讯云容器服务（TKE）高度集成，兼容开源生态丰富多样的应用组件，结合腾讯云可观测平台的告警功能和 Prometheus Alertmanager 能力，为用户提供免搭建的高效运维能力，减少开发及运维成本。

指标转换原理

OpenTelemetry 旨在构建与语言无关，支持多种编程框架以及多种可观测平台的统一标准，所以在通过 OpenTelemetry 方案上报指标数据的应用场景中，Prometheus 并不是唯一的指标存储平台选择。基于这个原因，OpenTelemetry 的指标模型和 Prometheus 的指标模型不完全相同，在编写上报数据的代码之前，需要先了解从 OpenTelemetry 指标到 Prometheus 指标的转换逻辑。

OpenTelemetry 指标模型

OpenTelemetry 指标模型的基本概念，关于 OpenTelemetry 协议数据模型的更多详细介绍，可自行参考 OpenTelemetry 官方文档。

OpenTelemetry 指标的数据结构如下图所示：

其中，指标由元数据和数据组成。元数据部分包括了指标名、描述和单位等信息；而数据部分支持多种数据类型，根据不同的数据类型，会带上相关的属性信息，并包含一系列带有时间戳和标签的数据点。

OpenTelemetry 指标支持的数据类型

Sum

Sum 表示一定时间间隔内所有测量值的总和。如果数据点是具备累加属性的，定义成 Sum 类型是更好的选择，例如 HTTP 请求数，网络流量等。如果测量值单调递增的，Sum 可以被标识为单调的（monotonic）。对于单调的 Sum，后一个测量值永远不会小于前一个测量值，HTTP 请求数就符合这样的特征。

在 OpenTelemetry 指标协议中，Sum 类型还支持两种不同的聚合时间性（Aggregation Temporality），用来区分数据是如何累加的，它们分别是：

增量（Delta）：指标流的时间窗口不会重叠，相当于在指标流中随着时间的推移记录每个间隔时间段的数据增量。

累积（Cumulative）：相当于在指标流中记录从“开始”以来的数据累积总和，“开始”通常意味着进程/应用程序的启动。

Gauge

Gauge 表示瞬时值，一般情况下，Gauge 类型的数据点是不具备累加属性的，例如当前的温度、汽车的时速等。

Histogram

表示通过聚合一定时间间隔内所有测量记录，以直方图的形式体现的数据类型。Histogram 包含通过聚合得到的 sum、count 字段，分别代表记录数以及测量值的总和。除此之外，还有可能包括表示最大值与最小值的 max、min 字段，以及一系列的数据桶（bucket）。每个数据桶会有明确的边界范围，以及落入到这个边界范围的记录数。Histogram 通过引入了聚合机制，显著降低了指标数据量，同时也能提升数据的可读性。

与 Sum 一样，Histogram 也定义了聚合时间性。上图表示增量（Delta）时间性，其中累积事件计数在报告后重置为零，并发生新的聚合。对于累积时间性，它会继续记录事件，且重置开始时间。

一个完整的 Histogram 类型的指标，可以使用如下的方式表达：

Resource labels:     -> host.name: STRING(127.0.0.1)     -> service.name: STRING(metric-service)     -> agent.version: STRING(opentelemetry-unknown)InstrumentationLibraryMetrics #0InstrumentationLibrary example.io/package/name Metric #0Descriptor:     -> Name: task.duration     -> Description: The duration of task execution.     -> Unit: s     -> DataType: DoubleHistogram     -> AggregationTemporality: AGGREGATION_TEMPORALITY_CUMULATIVEHistogramDataPoints #0StartTime: 1728375634434279000Timestamp: 1728375634434302000Count: 10Sum: 4.240000ExplicitBounds #0: 0.000000ExplicitBounds #1: 5.000000ExplicitBounds #2: 10.000000ExplicitBounds #3: 25.000000ExplicitBounds #4: 50.000000ExplicitBounds #5: 75.000000ExplicitBounds #6: 100.000000ExplicitBounds #7: 250.000000ExplicitBounds #8: 500.000000ExplicitBounds #9: 750.000000ExplicitBounds #10: 1000.000000ExplicitBounds #11: 2500.000000ExplicitBounds #12: 5000.000000ExplicitBounds #13: 7500.000000ExplicitBounds #14: 10000.000000Buckets #0, Count: 5Buckets #1, Count: 5Buckets #2, Count: 0Buckets #3, Count: 0Buckets #4, Count: 0Buckets #5, Count: 0Buckets #6, Count: 0Buckets #7, Count: 0Buckets #8, Count: 0Buckets #9, Count: 0Buckets #10, Count: 0Buckets #11, Count: 0Buckets #12, Count: 0Buckets #13, Count: 0Buckets #14, Count: 0Buckets #15, Count: 0

ExponentialHistogram

ExponentialHistogram 是 Histogram 的替代表达形式，和 Histogram 的唯一区别在于 ExponentialHistogram 使用指数作为桶的边界，适合以较小的相对误差传达高动态范围数据。ExponentialHistogram 引入了精度（Exponential Scale）和桶（Exponential Buckets）这两个重要的概念。

ExponentialHistogram 的精度由一个称为 Scale 的参数来表示，Scale 越大，精度越高。ExponentialHistogram 的桶边界位于 base 的整数幂，也称为"增长因子"，其中：

base = 2**(2**(-scale))

注意：以上公式中的符号  **  表示指数，即 2**x 读作"2 的 x 次方"，通常通过类似 math.Pow(2.0, x) 的表达式计算得出。

根据的 Scale 计算 base 如下所示：

ExponentialHistogram 的桶由 index (一个有符号的整数) 标识总体中大于 base**index 且小于等于 base**(index+1) 的值。

ExponentialHistogram 的正负范围是分开表示的。负值按其绝对值映射到负范围，使用与正范围相同的比例。所以请注意，在负值范围内，直方图桶使用下限边界。

scale=3 的例子如下：

Summary

Summary 通过分位数的形式表达数据，在最新的 OpenTelemetry 协议标准中，已经不推荐使用 Summary，所以尽可能不要使用这种数据点类型。

Prometheus 指标模型

Prometheus 指标数据流转的基本单位是时间序列（Time-Series）。每一条时间序列由指标名称（Metrics Name）以及一组标签（Labels）唯一标识，并记录在每一个时间戳（Timestamp）上产生的值（Value），如下图所示：

所有采集的监控数据均以指标(metric)的形式保存在内置的时间序列数据库当中(TSDB)。如下所示：

1. http_request_status{code='200',content_path='/api/path', environment='produment'} => [value1@timestamp1,value2@timestamp2...] 2. http_request_status{code='200',content_path='/api/path2', environment='produment'} => [value1@timestamp1,value2@timestamp2...]

Prometheus 包含如下几种指标模型，他们在定义上和 OpenTelemetry 的数据模型很类似，在本文中不再赘述。

• Counter

• Gauge

• Histogram

• Summary

模型映射

对于 OpenTelemetry 指标，将按照如下映射关系转换为 Prometheus 指标。

需要注意的是，Prometheus 的数据模型中，不能兼容增量聚合时间性（Delta Temporality），所以 APM 将直接丢弃使用 Delta 聚合时间性的 OpenTelemetry 指标。

在 OpenTelemetry 提供的探针以及 SDK 中，存在名为 OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE 的环境变量，或者名为 otel.exporter.otlp.metrics.temporality.preference 的系统参数，用于指定聚合时间性（Delta Temporality），其默认值为 cumulative 或 CUMULATIVE。在保持默认值的情况下，不会发生因为兼容性导致的丢弃问题。

对于不单调递增的 Sum，由于 Prometheus 的 Counter 指标必须保持单调递，因此不能直接保存为 Prometheus 的 Counter 指标。APM 会将其将转换为 Prometheus 的 Gauge 指标。

对于 ExponentialHistogram，APM 会将其转换为 Prometheus 的 Histogram 指标，当然，这种转换会丢失一些精度。

Sum 的指标转换

Sum 类型的 OpenTelemetry 指标在转换为 Prometheus 指标（单调递增的 Sum 将转换为 Counter，非单调递增的 Sum 将转换为 Gauge）的时候，会遵循如下的转换原则：

这是比较容易理解的，OpenTelemetry 指标中的指标名、标签对、时间戳等字段会被原样输出到 Prometheus 的数据样本中，每个 OpenTelemetry 数据点对应一个 Prometheus 数据样本（Sample）。

注意：由于两种数据模型并不是完全一致，在转换为 Prometheus 指标的过程中，OpenTelemetry 指标中的部分信息将被忽略，其中包括开始时间（StartTimeUnixNano）、单位（Unit）、范例（Exemplar）等。

Gauge 类型的指标转换

Gauge 类型的 OpenTelemetry 指标在数据结构上与 Sum 类型类似，转换方式与 Sum 类型没有区别，本文不再赘述。

Histogram 类型的指标转换

Histogram 类型的 OpenTelemetry 指标在转换为 Prometheus 指标的时候，会遵循如下的转换原则：

每个 Histogram 类型的 OpenTelemetry 数据点，会被转化为多个 Prometheus 数据样本（Sample），具体的个数取决于 Histogram 类型的 OpenTelemetry 数据点中带有多少个桶（Bucket）。和 Sum 类型一样，标签对和时间戳会被原样输出到 Prometheus 的数据样本中，但在指标名和指标值的处理上，会经过一系列的转换。

首先，APM 会生成一个名为指标名_sum 的 Prometheus 数据样本，取值为总和（sum）字段，代表所有原始记录的累加值总和。APM 还会生成一个名为 指标名_count 的 Prometheus 数据样本，取值为计数（count）字段，代表原始记录的总计数。

此外，每个来自 OpenTelemetry 的桶都会被转换成一个名为 指标名_bucket 的 Prometheus 数据样本，同时在此数据样本中添加一个标记为 le 的标签，表示该桶的边界。这些数据样本从低到高排列，每个点的值都是该数据样本 le 标签边界前所有桶的计数之和，从而转换成 Prometheus 中累加的 Histogram。之所以要这样转换，是因为在 Prometheus 的 Histogram 数据模型中，le 标签代表有多少条原始记录小于或等于一个特定的值，实际上就一定会包含前一个样本的计数。

最后，APM 会额外生成一个名为 指标名_bucket 的 Prometheus 数据样本，并添加值为 +Lnf 的 le 标签，其取值实际上就是计数（count）字段，代表原始记录的总计数。

因此，如果 1 个 Histogram 类型的 OpenTelemetry 数据点中带有 N 个桶（Bucket），将其转换为 Prometheus 指标后，会生成 N+3 条数据样本。

ExponentialHistogram 类型的指标转换

Prometheus 目前还没有支持 ExponentialHistogram，为了支持 ExponentialHistogram 类型的数据上报，APM 会先将 ExponentialHistogram 的桶边界转换成保留两位小数的 Histogram 桶边界，再进一步按照 Histogram 类型的指标转换规则进行处理。这样会丢失一些精度，所以不建议使用 ExponentialHistogram 类型上报数据。

Summary 类型的指标转换

Summary 类型的 OpenTelemetry 指标在转换为 Prometheus 指标的时候，会遵循如下的转换原则：

Summary 类型的转换规则和 Histogram 类似，如果 1 个 Summary 类型的 OpenTelemetry 数据点中带有 N 个分位数，将其转换为 Prometheus 指标后，会生成 N+2 条数据样本。由于在最近的 OpenTelemetry 协议标准中，已经不推荐使用 Summary，所以尽可能不要使用 Summary 类型上报数据。

实战环节

关联 Prometheus 实例

在应用上报自定义指标之前，需要先建立 APM 业务系统和 Prometheus 实例之间的关联，并配置需要从 APM 服务端同步到 Prometheus 实例的指标。

1.登录 APM 控制台，请前往系统配置 > Prometheus 集成。

2.在 关联配置 中，开启 Prometheus 关联，并选择当前业务系统中任何一个 Prometheus 实例。每个 APM 业务系统只能关联同地域的最多一个 Prometheus 实例。在当前账号第一次做关联操作的时候，需要授予 APM 访问 Prometheus 资源的权限，根据控制台的提示完成服务授权即可，系统会在访问管理（CAM）自动创建名为 APM_QCSLinkedRoleInPromInstance 的角色。

3.单击 新增指标同步规则，指定需要同步到 Prometheus 实例的指标。

对于每一条同步规则，您可以基于精确匹配、前缀匹配以及后缀匹配这三种匹配方式来匹配指标名，也可以指定该规则的生效范围（可以是该业务系统的全部应用，或某一个具体的应用）。当 APM 服务端收到应用上报的自定义指标后，满足同步规则的指标将被写入到被关联的 Prometheus 实例中，不满足同步规则的指标将被丢弃。

除了上报时填入的自定义标签外，APM 还额外增加了 apm_instance 和 apm_service_name 两个标签，分别代表 APM 业务系统 ID 以及应用名，这样每一条 Prometheus 指标样本都能关联到唯一的 APM 应用。

通过 OpenTelemetry API 上报指标

了解从 OpenTelemetry 指标到 Prometheus 指标的转换逻辑，可以帮助我们更好地理解两种数据模型，更合理地设计指标结构。但在代码编写实战环节，OpenTelemetry API 通过一系列的封装，屏蔽了 OpenTelemetry 指标模型的底层细节，让开发者可以轻松上手完成指标上报。

同步 API 与异步 API

OpenTelemetry 提供了同步和异步 2 种 API 编码模型，开发者可以根据实际情况使用其中的一种：

同步方式（Synchronous Instruments）：这是一种比较直观的编码方式，当有新的测量数据时，直接通过代码调用 API 输入数据即可。测量系统的 QPS 是同步方式的典型使用场景，每收到一条请求的时候，都主动调用 API 将请求数加 1。

异步方式（Asynchronous Instruments）：异步方式需要先注册一个回调方法/函数，用于读取测量数据。在系统有收集数据需要的时候（通常情况下取决于客户端 SDK 往 APM 服务端上报数据的频率），会运行回调方法获取测量数据。测量 CPU 温度是异步方式的典型使用场景，开发者并不需要考虑何时调用 API 输入 CPU 温度数据，而是提供一个读取 CPU 温度的方法/函数，作为回调方法/函数提供给异步 API。

重要对象

在编写代码的时候，需要使用到如下几个对象：

MeterProvider：MeterProvider 是使用 OpenTelemetry 指标 API 的唯一入口。通常情况下，在一个应用中只需要初始化一次。

Meter：Meter 由 MeterProvider 创建而成，用来创建 Instrument 对象。

Instrument：Instrument 对象用来输入测量数据。针对不同的指标类型以及不同编码模型（同步/异步），OpenTelemetry API 提供了一系列 Instrument 实现，包括 Counter、Asynchronous Counter、Histogram、Gauge、Asynchronous Gauge、UpDownCounter 等。这些对象的使用都比较简单，通过查阅相关的 OpenTelemetry API 文档，就能够轻松掌握。

代码编写示例

我们以 Java 项目为例，演示如何通过 OpenTelemetry API 上报接收到的 HTTP 请求数量。

1.构建 Spring Boot 项目，并提供相关的 HTTP 服务接口。此步骤请参考 Spring Boot 官方文档，本文不再赘述。也可以将 Spring Boot 替换为任意一种 Java 系的 HTTP Server。

2.在项目中引入必要的依赖。参考如下 Maven 配置，引入 opentelemetry-api 即可。

<dependency>    <groupId>io.opentelemetry</groupId>    <artifactId>opentelemetry-api</artifactId>    <version>1.35.0</version></dependency>

3.创建 Instrument 对象。在这个示例中，需要上报 HTTP 请求数量，很明显我们需要用到 Sum 类型的指标。每当应用接收到一次 HTTP 请求后，需要将请求数 +1，所以使用同步 API 是比较合理的。通过查阅 OpenTelemetry API 文档，我们可以确认需要使用到的 Instrument 对象是 Counter。

由于请求量通过整数来表达，在 Counter 的两种实现中，需要用到的是 LongCounter。通过如下代码，我们可以非常简单的创建一个用于上报 HTTP 请求数量的 LongCounter 对象。这个对象仅需要创建一次即可，其对应的指标名为 http_request_total，因为我们将其作为 RestController 的成员变量。

@RestController@RequestMapping("/metric")public class MetricController {    // 把LongCounter作为成员变量    private LongCounter httpRequestCounter;    @PostConstruct    public void init() {        String scope = this.getClass().getName();        // 获取OpenTelemetry对象        OpenTelemetry openTelemetry = GlobalOpenTelemetry.get();        // 获取Meter对象。关于Scope的定义，请参考OpenTelemetry官方文档，一般情况下，可以使用class全名        Meter meter = openTelemetry.getMeter(scope);        // 创建LongCounter对象。在项目中创建1次即可        httpRequestCounter = meter.counterBuilder("http_request_total").setDescription("Counts HTTP request").build();    }}

4.计数。参考如下代码片段，每次收到 HTTP 请求的时候，将请求数 +1 即可。在本示例中，还加入了 Key 为 method 的属性标签，用于标识这次请求来自哪一个方法。

@RestController@RequestMapping("/metric")public class MetricController {    // 定义一个Key为method的属性标签    private static final AttributeKey<String> METHOD_KEY = stringKey("method");    /*    上个步骤中的初始化逻辑    */    @RequestMapping("/order")    public String order() {        // order请求数+1        httpRequestCounter.add(1, Attributes.of(METHOD_KEY, "order"));        return "order + 1";    }    @RequestMapping("/pay")    public String pay() {        // pay请求数+1        httpRequestCounter.add(1, Attributes.of(METHOD_KEY, "pay"));        return "pay + 1";    }}

通过简单几个步骤，就完成了代码的编写。需要注意的是，并不是每次调用 LongCounter.add() 方法就会生成一条新的指标，OpenTelemetry API 会对数据进行聚合后再进行上报，所以写入到 Prometheus 的真实的指标数量取决于如下两个方面：

1. 标签的基数。在本示例中，只有一个 Key 为 method 的标签，那么方法的数量就决定了每次上报的指标数量。在真实场景中，可能不止一个标签，这些标签的基数共同决定了每次上报的指标数量。

2. 上报频率。可以通过 otel.metric.export.interval 系统参数设置上报频率，默认为 60 秒，一般情况下保持默认即可。

注意：如果您使用腾讯云增强版 OpenTelemetry Java 探针，请确保探针版本不低于 2.3-20241031，否则会导致上报失败。

通过 Grafana 查阅指标

上报完成后，前往关联的 Prometheus 实例，通过其关联的 Grafana 服务查询 http_request_total 指标，就能查阅到上报的数据。接下来，可以基于 PromQL 语句实现复杂的查询，并通过 Grafana 自定丰富的图表。

如果这个时候没有查到 http_request_total 指标，请确保在关联 Prometheus 实例的时候，针对此指标名配置了同步规则。对于不能匹配同步规则的指标，APM 服务端会进行丢弃处理。

由于 APM 在进行指标转换的时候，额外增加了 apm_instance 和 apm_service_name 两个标签，分别代表 APM 业务系统 ID 以及应用名，这样就可以基于这两个标签创建业务系统和应用过滤条件。

可观测平台 Dashboard 关联展示

完成 APM-Prometheus 数据集成后，除了可以通过 Grafana 进行自定义图表展示以外，也可以通过可观测平台 Dashboard 进行自定义图表展示，并支持将展示结果嵌入到 APM 控制台的应用详情页中。可观测平台 Dashboard 是腾讯云针对云产品指标监控数据提供的具备可视化和分析功能的智能仪表盘。

创建以 Prometheus 为数据源的 Dashboard

1.创建一个 Dashboard。

2.单击 Dashboard 上方的 按钮，在弹出的下拉框中选择 模板变量。

3.单击 初始化 Prometheus 预设变量，系统将自动生成地域和 Prometheus 实例两个模板变量。

4.单击 Dashboard 右上方的 保存 后，就得到了一个以 Prometheus 为数据源的 Dashboard。通过下拉框选择具体和地域和 Prometheus 实例，可以从任何一个腾讯云 Prometheus 监控服务的实例中获取指标数据。

APM 控制台关联展示 Dashboard

在 Prometheus 指标以及 Dashboard 的使用过程中，存在这样一种非常普遍的场景：

• 对于配置好的 Dashboard，从 APM 应用的维度过滤指标数据，并展示图表。

• 将展示结果嵌入到 APM 控制台的应用详情中。

• 同一个 APM 业务系统中的多个应用，都共享同一个 Dashboard，不需要重复配置。

对于这种使用场景，可以通过 APM-Dashboard 关联轻松实现。

注意：

在执行如下步骤前，需要先确保如下前置操作已经完成：

• 完成 APM-Prometheus 关联。

• 通过 OpenTelemetry API 往 Prometheus 实例写入指标数据。

• 创建以 Prometheus 为数据源的 Dashboard。

• 在 Dashboard 的过滤选项中指定 Prometheus 实例。

配置应用与 Dashboard 的关联

前往 APM 控制台 > 系统配置 > 业务系统配置，在 Dashboard 关联栏目中，关联已经创建好的 Dashboard，需要确保该 Dashboard 使用 Prometheus 数据源。在业务系统中关联 Dashboard，相当于该业务系统的所有应用都完成了关联，您也可以在系统配置 > 应用配置中，针对指定的应用覆盖业务系统级别的配置。

配置必要的模板变量

为了实现 Dashboard 能够基于特定的应用过滤指标，需要为 Dashboard 增加必要的应用过滤选项，包括业务系统和应用两个模板变量。回顾前面的章节，在完成了 APM-Prometheus 关联后，通过 OpenTelemetry API 写入的指标都额外增加了 apm_instance 和 apm_service_name 两个标签，分别代表 APM 业务系统 ID 以及应用名。通过这两个标签就能非常方便的为 Dashboard 增加必要的模板变量。

前往 Dashboard，进入 Dashboard 设置 > 模板变量，参考下图的配置项，就可以增加业务系统 ID 模板变量。请确保将变量名设置为 apm_instance，变量类型设置为查询(label_values)，查询条件中包含唯一的标签 apm_instance：

接下来，参考下图的配置项，就可以增加应用名称模板变量。请确保将变量名设置为 apm_service_name，变量类型设置为查询(label_values)，查询条件中包含唯一的标签 apm_service_name。

完成了所有设置以后，再次检查 Dashboard 中是否包含如下 4 个必要的模板变量。

在图表的 PromQL 语句中，增加业务系统 ID 和应用名称过滤条件。

在如下 HTTP 请求数图表中，PromQL 语句为 sum by(method) (irate(http_request_total{apm_instance="$apm_instance",apm_service_name="$apm_service_name"}[5m]))，这样就能够基于业务系统 ID 和应用名称过滤数据。

配置完成之后，检查图表能否正确的展示，并检查业务系统 ID 和应用名称这 2 个过滤条件是否能正常工作。

在应用详情中查看内嵌的 Dashboard。

前往 APM 控制台 > 应用列表，选择关联了 Dashboard 的应用后，就能看到 Dashboard 标签页，在此此标签页中， 将以内嵌的方式展示 Dashboard。由于 Prometheus 地域、Prometheus 实例、业务系统 ID、应用名称这 4 个必要的模板变量都已经自动指定，所以在内嵌的视图中，这 4 个过滤条件是隐藏的。如果多个应用关联了同一个 Dashboard，通过切换不同应用，就能够方便的查看每个应用的 HTTP 请求数情况。

至此，就已经完成了 APM 与 Dashboard 关联的全部步骤。

注意：对于没有使用 Prometheus 数据源的 Dashboard，同样可以实现 APM 与 Dashboard 关联，通过内嵌的方式在应用详情中展现 Dashboard 图表。虽然系统无法自动填入应用相关的过滤条件，但在特定的场景中，这样的用法也能很好的结合 APM 以及 Dashboard 的能力，为用户带来更便捷的使用。

结语

在融合 OpenTelemetry 和 Prometheus 这两套可观测标准的过程中，腾讯云应用性能监控（APM）发挥了重要的桥梁作用。基于本文的概念阐述以及实战指引，开发者可以快速上手，基于 OpenTelemetry API 灵活构建自定义业务指标，并利用腾讯云 Prometheus 服务以及可观测平台 Dashboard 充分发掘指标数据的价值。

OpenTelemetry 标准和 Prometheus 标准还在快速演进发展中，本文中呈现的协议转换以及集成方式，并不一定代表着 OpenTelemetry 与 Prometheus 融合的最终形态。腾讯云可观测团队也将与开源社区展开密切合作，确保旗下的可观测产品拥抱开源标准，并利用云计算的优势，为用户打造开放、易用、稳定、低成本的可观测平台。

联系我们

如有任何疑问，欢迎加入官方技术交流群