AutoMQ 可观测性实践：如何使用 OpenTelemetry 监控 Kafka 和底层流存储

前言

我们在之前的文章里介绍了 AutoMQ 如何与 Prometheus、观测云[1]、夜莺监控[2]等后端进行集成并实现对 AutoMQ 的监控，本文将进一步介绍 AutoMQ 的可观测性架构，以及 AutoMQ 如何实现多云可观测性。

可观测架构

Apache Kafka 的 Server 侧主要依赖 YammerMetrics[3] 这一第三方 Library 实现了指标的定义和采集，并通过将指标注册到 MBeans Server 的方式对外暴露观测接口，在实际集成过程中，还需要结合诸如 jmx_exporter[4] 之类的第三方 agent 来完成与可观测后端的集成。而 AutoMQ 作为一款面向云重新设计的流处理平台，自然需要更加原生化的可观测方式，而 OpenTelemetry[5]（下简称 OTel） 作为当前云原生应用可观测性框架的事实标准，自然成为了 AutoMQ 的首选。AutoMQ 的整体可观测架构如下图所示，本节将分采集、导出、可观测后端、可视化前端四个部分进行介绍。

采集

在采集侧，AutoMQ 保留了 Apache Kafka 的原生指标采集链路，并通过 OTel 社区的 JMXMetrics Library 完成从 JMX 到 OTLP 格式的指标转换。对于 AutoMQ 自身新增的指标，则全部使用了 OTel SDK 进行采集。

导出

基于 Apache Kafka MetricsReporter 接口：

• JmxReporter：即上文提到的 Apache Kafka 的原生指标导出方式，通过 YammerMetrics Library 将指标以 JMX 形式导出

• AutoBalancerMetricsReporter：AutoMQ 实现的内部指标采集器，主要用于采集节点和分区维度的负载相关指标并写入内部 Topic

基于 OTLP SDK：

• PrometheusMetricsExporter：基于 OTel SDK 的 PrometheusHttpServer 实现，AutoMQ 自身作为 HTTP Server 对外暴露端口，以被动拉取的方式提供 Prometheus 格式的指标

• OpsMetricsExporter：AutoMQ 实现的基于对象存储的指标上报组件，可定时将采集到的指标进行序列化后上传至指定的对象存储 Bucket 中，以实现便捷的跨云跨账号的指标共享和分析

• OTLPMetricsExporter：基于 OTel SDK 的 OtlpHttpMetricExporter 及 OtlpGrpcMetricExporter 实现，支持以 Grpc 或 HTTP 协议主动对外推送 OTLP 格式的指标

• RemoteWriteExporter：AutoMQ 商业版提供的上报组件，支持直接以 Prometheus Remote Write 协议直写支持对应协议的后端存储，无需额外组件部署即能实现对绝大多数兼容 Prometheus 格式的后端的集成

可观测后端

基于上述导出方式，AutoMQ 支持以下多种后端服务的集成：

• Prometheus:

  • Pull-based：可通过静态配置，或通过自建 HTTP 服务发现、kubernetes_sd 等方式配置 Prometheus Server 对 AutoMQ 进行指标拉取

  • Push-based:

    • 可通过自建 Vector 服务，监听并解析 OpsMetricsExporter 上传至对象存储的指标文件，并配置 Vector Prometheus Remote Write Sink 将指标写入 Prometheus Server

    • 可通过 OTLPMetricsExporter 向支持 OTLP receiver 的 Prometheus Server 直接以 OTLP 协议写入指标

    • 在 AutoMQ 商业版中，还可以通过控制台集成 Prometheus Server，通过 RemoteWriteExporter 直接写入指标

• Datadog[6]：

  • Prometheus：Datadog agent 可在 OpenMetrics 配置中将 openmetrics_endpoint 配置为 AutoMQ 暴露的 Prometheus HTTP Server endpoint，即可实现对 Prometheus 格式的指标采集

  • OTLP：Datadog agent 也可以在 otlp_config 中配置开启 OTel receiver，并将 AutoMQ 的 OTLP endpoint 配置为 Datadog agent OTel receiver 相应的 endpoint，实现 OTLP 格式的指标导出

• Datakit[7]：作为观测云的主要观测组件，Datakit 可以 agent 模式部署在 AutoMQ 节点，并通过配置 Prometheus 采集器进行指标拉取并上报至观测云 DataWay

• 其他支持 Prometheus 协议的后端：如 GreptimeDB、VictoriaMetrics、Thanos 等，均可使用类似 Prometheus 的方式进行集成

可视化前端

AutoMQ 提供了基于 Prometheus 格式，且适配 Grafana、观测云、夜莺监控的仪表盘模板，在前面的文章中已经介绍过，本文不再赘述

配置方式

AutoMQ 1.2.x 及以上版本提供了统一的 URI 格式的监控导出配置，格式如下：

# <exporter_uri> 为不同 exporter 类型的 uri 表示，可配置多个 exporter 来同时支持多种导出方式
s3.telemetry.metrics.exporter.uri=<exporter_uri1>,<exporter_uri2>,<exporter_uri3>

不同 exporter_uri 根据协议配置方式如下：

• Prometheus HTTP Server:

# hostname: HTTP Server 的 IP 或域名
# port：HTTP Server 的端口号
prometheus://?host=$hostname&port=$port

• OTLP:

# endpoint: OTLP 后端服务的访问地址
# protocol: 使用 grpc 协议或 http 协议
otlp://?endpoint=$endpoint&protocol=$protocol

• S3:

# AutoMQ 的对象存储上报方式默认开启，仅需配置对象存储的 bucket 即可，详细配置方式请参考 https://github.com/AutoMQ/automq/blob/main/core/src/main/java/kafka/automq/AutoMQConfig.java#L58
s3.ops.buckets=0@s3://$bucket?region=$region

AutoMQ 的指标采集优化实践

Histogram 类型指标窗口优化

Histogram 类型指标主要用于记录数据的统计学指标，如 avg、p50、p99 等，在 AutoMQ 中广泛用于衡量各类延迟、请求大小、排队时间等。

在 Apache Kafka 的原生指标中，Histogram 均通过 Cumulative 方式进行统计，也即采集的是程序启动以来的统计值。其中 p50，p99 等分位数通过一个定长（1024）的跳表，基于记录的数据点的时间戳计算出指数级衰减（Exponentially Decay）权重并进行数据点的驱逐，从而实现近一段时间内的分位数的效果。而 avg 则直接对外暴露启动以来的平均值，这在实际线上环境参考意义并不大，因此 AutoMQ 通过继承 MetricsReporter 实现了一个 DeltaHistogram 的转换，将 Apache Kafka 的部分原生 Histogram 的 avg 指标转换为固定时间窗口内的平均值，使得这部分指标能够更好的反应集群不同时间点的状态。

对于 AutoMQ 增加的 Histogram 类型指标，我们直接采取了 Delta 方式进行统计，即在每个上报时间窗口独立进行 avg、p50、p99 等指标的统计。

指标数据量优化

在 AutoMQ 早期进行指标 benchmark 时，我们发现 OTel 的 Histogram 类型指标，一个 OTel Histogram 对应产生三种 Metric Name：$name_bucket， $name_sum， $name_count。其中 $name_bucket 附加了一个 Label “le” 用于对记录的数据点进行分桶，在前端展示时可通过对 le 进行分位数计算来得到不同分位的统计值。这也就使得分位数的精度取决于桶切割的粒度，对于一些数据跨度范围较大的指标而言，则需要划分更多的桶，从而导致指标数据量迅速膨胀。为解决这一问题，AutoMQ 选择了在本地进行 Histogram 的 Delta 记录时直接计算出相应的分位数，从而将与 OTel Histogram 转换成了固定大小的 Gauge 类型指标，相对直接使用 OTel Histogram 数据量减少了近 80%。

AutoMQ 多云可观测性的集成实践

作为独立的流处理平台供应商，AutoMQ 商业版对业界主流云厂商的全托管监控方案均提供了相应的集成方式，通过 AutoMQ 控制台添加 Remote Write 集成，根据不同云厂商选择鉴权方式即可：

• 阿里云可观测监控 Prometheus 版：使用 Basic Auth 鉴权方式，并填入阿里云对应具备 ARMS 写入权限的 RAM 用户 AK/SK 信息

• 腾讯云 Prometheus 监控 / 华为云 Prometheus：使用 Bear Token 鉴权方式，并填入相应产品控制台获取的 token

• Amazon Managed Service for Prometheus：使用 AWS SigV4 鉴权方式，根据控制台提示，为对应角色授予 AWS Prometheus 写入权限

• （Comming Soon） 百度云 CProm：使用 Bear Token 鉴权方式，并填入 CProm 控制台生成的 token 及 CProm 实例 Id

• （Comming Soon） Azure Monitor Managed Service for Prometheus：使用 AzureAD 鉴权方式，根据 Azure 文档完成 User-Assigned Managed Identity 授权，并填入 ClientId

总结

本文从各个方面对 AutoMQ 的可观测架构及集成进行了介绍，并结合 AutoMQ 的实际案例探讨了指标的具体优化实践。最后，本文还介绍了 AutoMQ 商业版在多云环境下实现可观测性的集成实践，未来 AutoMQ 还会继续完善可观测性架构的可扩展性，提供更多可观测系统的集成方式。

参考链接

[1] 如何使用观测云监测 AutoMQ 集群状态：https://www.automq.com/zh/blog/monitor-automq-cluster-using-guance-cloud

[2] AutoMQ 开源可观测性方案：夜莺 Flashcat：https://www.automq.com/zh/blog/automq-open-source-observability-solution-nightingale-flashcat#部署夜莺监控

[3] Metrics Core Library: https://mvnrepository.com/artifact/com.yammer.metrics/metrics-core/2.2.0

[4] jmx_exporter: https://github.com/prometheus/jmx_exporter

[5] What is OpenTelemetry: https://opentelemetry.io/docs/what-is-opentelemetry/

[6] Datadog：https://docs.datadoghq.com/getting_started/

[7] Datakit: https://docs.guance.com/datakit/