前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >揭秘可观测利器:腾讯云 APM 深度融合 OpenTelemetry 和 Prometheus,助力高效指标采集与处理

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

作者头像
腾讯云可观测平台
发布于 2025-02-11 06:15:30
发布于 2025-02-11 06:15:30
34600
代码可运行
举报
运行总次数:0
代码可运行

导语:文章主要介绍腾讯云应用性能监控(APM)服务端通过对数据的处理将 OpenTelemetry 指标转换成 Prometheus 指标,输出到腾讯云 Prometheus 监控服务中,做到让用户只需要进行简单的关联后,应用直接通过 OpenTelemetry API 上报指标,并提供多种可自定义的图表展示方式。

前言

腾讯云应用性能监控(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 类型的指标,可以使用如下的方式表达:

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

ExponentialHistogram

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

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
base = 2**(2**(-scale))

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

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

Scale

Base

表达式

10

1.00068

2**(1/1024)

9

1.00135

2**(1/512)

8

1.00271

2**(1/256)

7

1.00543

2**(1/128)

6

1.01089

2**(1/64)

5

1.02190

2**(1/32)

4

1.04427

2**(1/16)

3

1.09051

2**(1/8)

2

1.18921

2**(1/4)

1

1.41421

2**(1/2)

0

2

2**1

-1

4

2**2

-2

16

2**4

-3

256

2**8

-4

65536

2**16

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

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

scale=3 的例子如下:

index

下边界

表达式

-2

0.84090

2**(-2/8), 2**(-1/4)

-1

0.91700

2**(-1/8)

0

1

2**(0/8)

1

1.09051

2**(1/8)

2

1.18921

2**(2/8), 2**(1/4)

3

1.29684

2**(3/8)

4

1.41421

2**(4/8), 2**(2/4), 2**(1/2)

5

1.54221

2**(5/8)

6

1.68179

2**(6/8)

7

1.83401

2**(7/8)

Summary

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

Prometheus 指标模型

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

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
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 即可。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
<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 的成员变量。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
@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 的属性标签,用于标识这次请求来自哪一个方法。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
@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="

配置完成之后,检查图表能否正确的展示,并检查业务系统 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 融合的最终形态。腾讯云可观测团队也将与开源社区展开密切合作,确保旗下的可观测产品拥抱开源标准,并利用云计算的优势,为用户打造开放、易用、稳定、低成本的可观测平台

联系我们

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

关于腾讯云可观测平台

腾讯云可观测平台(Tencent Cloud Observability Platform,TCOP)基于指标、链路、日志、事件的全类型监控数据,结合强大的可视化和告警能力,为您提供一体化监控解决方案。满足您全链路、端到端的统一监控诉求,提高运维排障效率,为业务的健康和稳定保驾护航。功能模块有:

  • Prometheus 监控:开箱即用的 Prometheus 托管服务;
  • 应用性能监控 APM:支持无侵入式探针,零配置获得开箱即用的应用观测能力;
  • 云拨测 CAT:利用分布于全球的监测网络,提供模拟终端用户体验的拨测服务;
  • 前端性能监控 RUM:Web、小程序等大前端领域的页面质量和性能监测;
  • Grafana 可视化服务:提供免运维、免搭建的 Grafana 托管服务;
  • 云压测 PTS:模拟海量用户的真实业务场景,全方位验证系统可用性和稳定性;
  • ......等等
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2024-11-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯云可观测 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
开源监控系统 Prometheus 最佳实践
作者:jimmiehan(韩金明) , 腾讯PCG后台开发工程师, Prometheus/Thanos contributor Prometheus 是目前最流行的开源监控系统之一, 这里以我在基于 Prometheus 构建天机阁 2.0Metrics 子系统的实践谈一谈 Prometheus 的一些最佳实践, 最佳实践的理念是 Prometheus 系统简单稳定高效运行的关键。(注: 天机阁 2.0 是新一代云原生可观测性系统) 埋点思路 最好将原始指标暴露给 Prometheus, 而不是在应用
腾讯技术工程官方号
2021/11/17
1.8K0
Prometheus Metrics 设计的最佳实践和应用实例,看这篇够了!
作者 | 朱瑜坚 腾讯云后台开发工程师 Prometheus 是一个开源的监控解决方案,部署简单易使用,难点在于如何设计符合特定需求的 Metrics 去全面高效地反映系统实时状态,以助力故障问题的发现与定位。本文即基于最佳实践的 Metrics 设计方法,结合具体的场景实例——TKE 的网络组件 IPAMD 的内部监控,以个人实践经验谈一谈如何设计和实现适合的、能够更好反映系统实时状态的监控指标(Metrics)。该篇内容适于 Prometheus 或相关监控系统的初学者(可无任何基础了解),以及近期
腾讯云可观测平台
2020/06/05
2.8K0
第04期:Prometheus 数据采集(三)
爱可生上海研发中心成员,研发工程师,主要负责 DMP 平台监控告警功能的相关工作。
爱可生开源社区
2020/08/05
3.1K0
第04期:Prometheus 数据采集(三)
详细解读 Prometheus 的指标类型
原文链接:https://prometheus.io/docs/concepts/metric_types/
米开朗基杨
2019/08/29
2.5K0
从 Prometheus 到 OpenTelemetry: 指标监控的演进与实践
在上一篇:从 Dapper 到 OpenTelemetry:分布式追踪的演进之旅我们讲解了 Trace 的一些核心概念:
crossoverJie
2024/06/18
1.1K0
腾讯云某业务基于 DeepFlow 的可观测性实践
本文分享了腾讯云某业务基于 DeepFlow 的可观测性实践。面对复杂的业务服务(800+)和多样的编程语言,腾讯云某业务团队选择了 DeepFlow 作为跨语言、无侵入的可观测技术。与其他技术(如 Hubble 和 Pixie)相比,DeepFlow 在数据指标、协议支持和扩展能力等方面表现优异,成为最佳选择。引入 DeepFlow 后,腾讯云通过与现有系统的集成,实现了统一的服务性能监控和高效的故障排查能力,显著提升了运维效率,甚至能主动发现业务隐藏的 Bug,防范于未然。
DeepFlow
2024/06/05
7130
腾讯云某业务基于 DeepFlow 的可观测性实践
TiKV 源码解析系列文章(三)Prometheus(上)
Prometheus 支持四种指标:Counter、Gauge、Histogram、Summary。rust-prometheus 库目前还只实现了前三种。TiKV 大部分指标都是 Counter 和 Histogram,少部分是 Gauge。
PingCAP
2019/03/11
1.2K0
研究监控系统之prometheus
以前用过nagios和zabbix,nagios用起来太过原始,配置文件维护得很累,监控的图表也比较难看;zabbix的主要开发语言是C和PHP,要暴露一些自定义的监控指标较困难。网上一些云原生的项目都是用prometheus+grafana方案的,刚好花时间研究一下这个。
jeremyxu
2019/03/13
1.6K0
研究监控系统之prometheus
OpenTelemetry指标:概念、类型和插桩
探索 OpenTelemetry 指标:了解指标类型、插桩及其在性能监控中的作用。学习最佳实践以及如何开始使用 Checkly。
云云众生s
2024/08/02
5030
OpenTelemetry指标:概念、类型和插桩
OpenTelemetry - 云原生下可观测性的新标准
CNCF(Cloud Native Computing Foundation),中文为“云原生计算基金会”,CNCF是Linux基金会旗下的基金会,可以理解为一个非盈利组织。
全球技术精选
2021/01/21
1.2K0
OpenTelemetry - 云原生下可观测性的新标准
一文详解腾讯云可观测平台 APM 采样方案
前言:本文直击传统采样方案的痛点,着重介绍腾讯云 APM 新推出的采样策略优势:既能降低 APM 使用成本,又不会对用户的使用体验带来明显影响。
腾讯云可观测平台
2025/02/11
2180
一文详解腾讯云可观测平台 APM 采样方案
Prometheus 指标值不准:是 feature,还是 bug?
导语:笔者穷尽毕生绝学写就此文,通过剖析最典型的“怪现象”,解答 “Prometheus 指标值为何不准”这一灵魂拷问。
腾讯云可观测平台
2024/05/09
9840
Prometheus 指标值不准:是 feature,还是 bug?
如何基于标准化的OpenTelemetry构建APM探针能力
导语 | 本文推选自腾讯云开发者社区-【技思广益 · 腾讯技术人原创集】专栏。该专栏是腾讯云开发者社区为腾讯技术人与广泛开发者打造的分享交流窗口。栏目邀约腾讯技术人分享原创的技术积淀,与广泛开发者互启迪共成长。本文作者是腾讯前端高级开发工程师常敏。 云原生为传统监控带来挑战。云原生场景下,企业大规模地部署容器,应用节点呈指数级增长,故障可能发生在任意节点,无法感知与预测的因素越来越多。业界将“可观测性”能力划分为5个层级,其中告警(Alerting)与应用概览(Overview)属于传统监控的概念范畴。腾讯
腾讯云开发者
2022/09/08
9740
如何基于标准化的OpenTelemetry构建APM探针能力
运维监控之Prometheus入门简介篇
Prometheus(普罗米修斯)是一套开源的监控&报警&时间序列数据库的组合,它将所有信息都存储为时间序列数据;因此实现一种Profiling监控方式,实时分析系统运行的状态、执行时间、调用次数等,以找到系统的热点,为性能优化提供依据。
lyb-geek
2019/07/15
8.4K0
可观测迁移实战:从自建困境到高效运维的华丽转身
在教育行业数字化转型进程中,某教育头部客户的运维团队面临自建 SkyWalking 监控系统的严峻挑战。随着业务规模扩张,系统运维复杂度呈指数级增长,运维团队每月 20% 以上工作时间都消耗在监控系统自身故障处理且微服务架构下的故障排查效率极低 ,针对这一现状,该团队通过技术架构升级与优化,与腾讯云可观测平台产研团队共创,实现了从传统自建监控体系向腾讯云可观测平台的迁移,同时也为教育行业监控系统转型提供实践范例。
腾讯云可观测平台
2025/06/11
750
可观测迁移实战:从自建困境到高效运维的华丽转身
Prometheus Metrics 设计的最佳实践和应用实例,看这篇够了!
Prometheus 是一个开源的监控解决方案,部署简单易使用,难点在于如何设计符合特定需求的 Metrics 去全面高效地反映系统实时状态,以助力故障问题的发现与定位。本文即基于最佳实践的 Metrics 设计方法,结合具体的场景实例——TKE 的网络组件 IPAMD 的内部监控,以个人实践经验谈一谈如何设计和实现适合的、能够更好反映系统实时状态的监控指标(Metrics)。该篇内容适于 Prometheus 或相关监控系统的初学者(可无任何基础了解),以及近期有 Prometheus 监控方案搭建和维护需求的系统开发管理者。通过这篇文章,可以加深对 Prometheus Metrics 的理解,并能针对实际的监控场景提出更好的指标(Metrics)设计。
腾讯云原生
2020/05/22
3.8K0
OpenTelemetry 与 Prometheus - 架构和指标的差异
在不断发展的软件开发世界中,可观察性使软件工程师能够实时洞察复杂的系统。OpenTelemetry 和 Prometheus 是著名的云原生计算基金会 (CNCF) 毕业项目,但用于监控和调试应用程序的可观察性工具不同。
用户5166556
2024/01/10
1.9K0
OpenTelemetry 与 Prometheus - 架构和指标的差异
一文带你了解 Prometheus
作者:kevinkrcai,腾讯 IEG 后台开发工程师 Prometheus 是一个开源的完整监控解决方案,本文将从指标抓取到查询及可视化展示,以及最后的监控告警,对 Prometheus 做一个基本的认识。 1. 简介 Prometheus 是古希腊神话里泰坦族的一名神明,名字的意思是"先见之明",下图中是 Prometheus 被宙斯惩罚,饱受肝脏日食夜长之苦。 下面就是我们 CRUD Boy 所了解的 Prometheus,下面是其官网封面图引导语:From metrics to insight,
腾讯技术工程官方号
2022/05/10
1.5K0
一文带你了解 Prometheus
产品月报|Prometheus 支持跨账号采集 ,APM 支持对特定业务系统开启免费模式...
1.支持在容器集群详情页的 Prometheus 监控页面,一键安装集成中心中更多类型的组件监控,缩短用户使用路径。
腾讯云可观测平台
2025/02/11
960
产品月报|Prometheus 支持跨账号采集 ,APM 支持对特定业务系统开启免费模式...
如何基于标准化的OpenTelemetry构建APM探针能力
云原生为传统监控带来挑战。云原生场景下,企业大规模地部署容器,应用节点呈指数级增长,故障可能发生在任意节点,无法感知与预测的因素越来越多。业界将“可观测性”能力划分为5个层级,其中告警(Alerting)与应用概览(Overview)属于传统监控的概念范畴。腾讯云“应用性能观测”则补齐主动发现的能力。构建简单易用,高性能的全链路监控系统。如何做到简单易用,满足用户拿来即用的需求?构建标准化,完善的探针能力是关键。
拓荒牛儿
2022/05/13
3.7K6
如何基于标准化的OpenTelemetry构建APM探针能力
推荐阅读
相关推荐
开源监控系统 Prometheus 最佳实践
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验