opentelemetry-collector

一句话总结 本文介绍如何将 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 的加持下，业务的可观测体系变成下面的样子...