Hi there 👋

一句话总结 本文介绍如何将 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....

0. 一句话总结 本文将介绍 opentelemetry collector 插件集合中的 spanmetrics connector 插件，主要描述它的基本功能和基本使用方式，并且进一步结合 demo 示例展示它的基本使用方法和其他的一些高阶使用方法。 将主要从以下几个问题出发 什么是 opentelemetry collector？ 什么是 connector 类型插件？ 什么是 spanmetrics connector 插件？ 如何使用 spanmetrics connector 插件？ 1. 什么是 opentelemetry collector？ Opentelemetry 是开源社区针对可观测领域相关技术制定的一套新的技术标准。它出现的目的是为了解决，用户在对自身业务进行可观测能力建设时，最常遇到的两个问题 多种多样的可观测数据类型：包括 metric，trace，log，profiling，exception，每种数据类型都有各自的特点，且难以联动 多种多样的可观测服务提供商：市面上存在多种可观测服务提供商（比如 datadog）或者开源解决方案（比如 prometheus），但是方案之间数据协议不一致，接入方式不一致，导致用户被服务商强绑定，迁移方案成本很高，并且服务商之间缺乏数据联动。 如上图所示，业务程序需要根据自己选择的可观测方案（比如 prometheus，jaeger），用对应的 SDK（prometheus metric sdk，jaeger trace sdk）进行数据埋点，并且需要部署方案对应的采集服务（jaeger agent），最终将数据持久化到对应的存储中（prometheus server, jaeger server）。想要切换解决方案（比如从 jaeger 切换为 zipkin），就需要切换完整的一套。 所以 Opentelemetry 提供了几个方面的能力来解决这些问题： 针对常见的可观测数据类型（metric，trace，log，profiling）提供了统一 API 定义：规范了各种数据的格式标准，联动方式 针对不同编程语言的提供了数据埋点的 SDK：golang，java，c++，python 等大部分常见语言都以覆盖，用户通过引入 SDK 即可生产标准的可观测数据 针对数据采集，处理，导出的需求，提供了一个强大工具 opentelemetry-collector：用户可以通过配置为 collector 内部编排多个从数据的处理流，每个流都包含数据的输入，处理，输出3个阶段。用户可以在其中根据自己的需求对数据进行非常灵活的二次加工，并且最终输出到希望输出的任何存储中。 最终在 Opentelemetry 的加持下，业务的可观测体系变成下面的样子...

什么是 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....

2022 KubeCon 北美站于十月在底特律召开。可观测性(observability)作为一个热门主题，有多达 7 个 talk。 最近 kubecon 官方也把所有 talk 的录像都放出了，所以在这篇文章主要就是记录了一下我对这几个 talk 录像的观后感，以及引发的思考。 Talk 1: Customer Centric Observability: How Intuit Reduced Time To Detect Customer Impact From 30+ Minutes To Under 3 Minutes. 直译：以客户为核心的可观测: Intuit 公司是如何将对客户体验有损情况的发现速度从30分钟+提速到3分钟 Intuit 公司是一家以财务软件为主的大型 SAAS 公司。并且根据讲者的介绍，所有 SAAS 子产品都是在 Intuit 的5大基础平台之上所构建出来的。 讲者所在的部门，就是5个基础平台之一，开发平台。他们的目标就是：让研发人员更快更稳的进行开发迭代。从他所提供的平台规模数据来看（百万核，2000+的微服务，900+团队，6000+开发人员，16000+命名空间），要达成这个目标是非常有挑战的。其中，可观测性建设就是挑战之一。 讲者总结了在优化前，他们的可观测能力建设的思路是 “以服务为中心进行监控” (system centric monitoring)，而这种思路也确实让他们遇到很多问题。 缺乏对客户影响面的理解 MTTD 超过 30min 难以定位根因 更高额的可观测成本 不能充分利用可观测数据的价值 所以他们重新思考，从用户体验出发，采取以用户为核心的新思路进行可观测性建设，从而能更加直观的判断对于用户体验的影响面。当然，并不是要把产品中用户每一个可能的动作都视作为核心用户动作，他们为核心用户动作也制定了自己的定义：只有真正会带来 “价值” 的动作才是核心用户动作。 以这个新的思想为基础，他们建设了一个 FCI(Failed Customer Interactions) 平台，专注于监测核心用户动作的可用性，整体架构如下 首先平台提供了一个基于 OpenTelemtry 的监控埋点库。所有 app 或者浏览器都通过这套埋点库进行 trace 数据埋点。当终端用户进行操作时，所有重点操作都会以 span 的形式上传到 FCI 平台，并且会通过两种方式进行二次处理。...