prometheus

一句话总结 本文介绍如何将 OpenTelemetry Metric 数据导入 Prometheus 中，并且通过可运行的 demo 样例介绍几种常见的使用模式。 什么是 OpenTelemetry Metric 数据？ OpenTelemetry 协议中目前包含 3 类可观测数据 —— Trace，Metric，Log。其中 Metric 类型的数据通常用于衡量系统在一段时间内表现的统计值，比如请求成功率；或者系统表现的瞬时值，比如 CPU 利用率。 Prometheus 作为云原生领域 Metric 技术的事实标准，显然也是最适合作为 OpenTelemery Metric 数据的后端存储方案。但是 Prometheus 原生的 Metric 数据协议同 OpenTelemetry Metric 数据协议还是有诸多不一致的地方，如何才能将 OpenTelemetry Metric 数据写入 Prometheus 中呢？ 如何生产 OpenTelemetry Metric 数据？ OpenTelemetry 提供了有关 OpenTelemetry Metric 的 API，以及基于这套协议，针对各种编程语言实现的 SDK。基于官方提供的 SDK，我们就可以生产 OpenTelemetry Metric 数据了。 参考如下代码，是通过 golang 实现的输出一个最简单的 Counter 类型指标的程序 https://github.com/fatsheep9146/awesome-observability/blob/main/services/otel-metric-producer/main.go package main ... var mode string func init() { flag....

什么是 exemplar 在可观测领域，通常把一个系统为了完成某个功能，所发起的相关动作称之为事件。比如，对于「电商网站」系统的「访问产品详情页」的功能，背后的实现包括了鉴权，访问缓存，访问数据库等等事件。 为了能够更好的对系统进行监控，可观测领域沉淀出三种经典的可观测数据类型，并且把他们叫做可观测领域的三根支柱（pillar） log: 用于记录完成某个动作的详细内容。 trace: 用于记录完成某个功能的所有动作，以及每个动作的基础信息，比如耗时，是否成功等等。 metric: 用于统计所有同类动作的整体表现，比如平均耗时 但是在工作中我们经常遇到的一个场景是：当系统的某个核心 metric 发生了抖动时，我们仅仅通过 metric 上的信息，是很难确认到底是哪些具体的请求导致了这种波动，所以就需要再通过 trace 系统去大海捞针，捞出那些异常的请求再进行分析，整体是非常低效的。 所以为了解决这个问题，exemplar 技术诞生了。它为 metric 和 trace 之间建立起了一座桥梁，使用户在遇到上面的问题时，可以直接一键跳转到导致 metric 波动的具体请求的 trace 详情中，大幅提升排障的速度和精度。这项技术也是由 Google 发起，并且也其公司得到了广泛使用。详细介绍可以看这篇视频。 exemplar 的定义 因为 exemplar 是 metric 和 trace 之间的桥梁，所以为了达成这个效果，需要再 metric 数据上附带可以推导相关 trace 的信息，最常用的信息就是具体的 trace id。 从 OpenMetric 官方文档给出的示例就有最直观的体现 # TYPE foo histogram foo_bucket{le="0.01"} 0 foo_bucket{le="0.1"} 8 # {} 0.054 foo_bucket{le="1"} 11 # {trace_id="KOO5S4vxi0o"} 0.67 foo_bucket{le="10"} 17 # {trace_id="oHg5SJYRHA0"} 9.8 1520879607....