最近把 Kafka 的监控迁移到了 Prometheus, 顺便思考了一下监控系统 Dashboard 的构建原则. 记录一下.
0x00 Kafka metrics 初探
Kafka 使用的是"民间标准"的 metrics library, 通过定制化的 reporter 在 server.properties 中配置 参见 Kafka 关于 metrics 源码. 默认情况下, Kafka metrics 所有的 metric 都可以通过 JMX 获取.
如果想把 Kafka 中的 metrics 数据暴露出来, 就有如下几个选择:
- 直接实现
kafka.metrics.KafkaMetricsReporter这个 trait, 通过解析Metrics.defaultRegistry()里面所有的 metrics 暴露出来. - 通过 JMX, 获取 metrics-core library 通过 JMX 暴露的数据来读取数据. 读取 JMX 又有两种方式:
- 在 Kafka Broker 进程内部读取 JMX 数据, 这样解析数据的逻辑就在 Kafka Broker 进程内部, 如果有任何调整, 需要重启 Broker
- 在 Kafka Broker 外部, 作为一个独立进程, 通过 JMX 的 RMI 接口读取数据. 这种方式的好处是有任何调整不需要重启 Kafka Broker 进程, 缺点是多维护了一个独立的进程
0x01 Prometheus + Kafka
回到 Prometheus, 我们来挨个评估一下上述的几个方案:
实现一个 reporter, 将数据推送给 Prometheus Pushgateway. 但实现太繁琐, 而且要顾及到 Kafka 后续 API 的升级.
-
读取 JMX 的数据. Prometheus 官方的组件 jmx_exporter 把两种实现都提供了:
-
jmx_prometheus_httpserver通过独立进程读取 JMX 的数据 -
jmx_prometheus_javaagent使用 Java Agent 方式, 尽量无侵入(仅需在 java 命令行中使用 -javaagent 参数)的启动 in-process library, 读取 JMX 数据.
-
不同于 metrics-core 设计的是, Prometheus 采用了 PULL 方式, 也就是说 Prometheus 主动抓取 metrics 数据, 而不是靠客户端主动 PUSH 数据, 因此 jmx_prometheus 都是通过暴露 HTTP 端口的方式暴露 metrics 数据, 方便 Prometheus 抓取数据.
考虑到 Kafka Broker 的 metrics 足够稳定(排除升级考虑), 并且对 Prometheus 官方的 library 足够有信心, 因此选择了 jmx_prometheus_javaagent 方式, 重启了一轮 Kafka Broker, 通过 Prometheus 的 scraper 抓取了所有 Kafka Broker 的 metrics 数据.
0x02 Monitoring Dashboard 构建原则
有了 metrics 数据, 就到了构建 Dashboard 的阶段了. 如何构建一个"好用"监控的 Dashboard? 简单的找几个 metrics 堆砌一下就完事儿了? NO, NO, NO, not that simple
总结了4个原则, 欢迎拍砖:
- 异角(jué)异面 (different dashboards for different roles)
- 唯一面板 (one and only one dashboard for a specific role)
- 依赖可达 (all dependent systems' dashboard links are provided in the dashboards)
- 依图告警 (all alert rules should have corresponding chart in the dashboard)
1. 异角异面
一个系统包含多种角色, 就 Kafka 集群来说,
- Kafka 的用户, 仅仅通过 Kafka API 收发消息;
- Kafka Admin, 专注于 Kafka 集群的可用性;
- 系统运维人员, 关注 IDC/硬件/网络等更基础的资源.
不同的角色, 关注的资源不同, 如下图:
- Kafka 用户仅仅关注自己的 Topic 是否可读可写, Consumer 是否有 Lag
- Kafka Admin 更关注 Kafka Broker 内部的核心 metrics, 看集群资源利用情况(CPU/Memory/IO)和可用性等指标, 至于 Topic 级别的 metrics, 最多关注数据量比较大的 topic
- OPS 人员更关注 IDC 级别的网络/硬件, 或者云服务提供商的可用性指标
监控系统应该给不同角色提供不同的 Dashboard, 不能简单提供一个大到打不开的 Dashboard 让大家自己去找关注的指标
2. 唯一面板
虽然不同角色关注点不同, 但关注的 metrics 确是有不少. 这里的核心原则就是为每个角色提供一个并且仅有一个 Dashboad 作为入口, 不能说为了看一些指标, 到处找 metric 在哪个 Dashboard, 降低效率.
通过提炼核心的 metrics, 将这些 metrics 展现在一个 Dashboard, 提高效率. 至于次要的 metrics 放在哪里, 参考下一条
3. 依赖可达
核心 metrics 放到一个 Dashboard 中后, 有些看上去不是那么一针见血的 metrics 放在哪里?
External Link! 核心 Dashboard 中必须提供其他依赖的系统或者更多非核心的 Dashboard 的链接, 供用户一键点击打开, 注意, 是必须一个跳转就可达, 最大程度提高效率.
回到 Kafka Broker 的例子, Kafka Admin 除了看 Kafka Broker 的核心 metrics 外, 可以一键打开 Kafka Broker 使用的 Zookeeper 集群的 Dashboard, 或者 Kafka 节点的细节监控信息的 Dashboard
4. 依图告警
系统都会有一些监控规则, 提供异常的告警功能. 但一个容易忽略的问题是, 告警规则中使用的 metrics 是否在 Dashboard 中有对应的图表, 方便 on-call 人员收到告警信息后, 以最高效率的方式打开对应的异常 metrics 进行问题诊断. 更贴心的告警系统, 应该在告警信息中提供对应的 Dashboard 的链接, 或者干脆直接把异常值时间附近的图表信息发送到告警信息中(比如截个图).
0x03 Kafka Broker Grafana Dashboard 构建
贯彻上述的四点原则, 构建一个 Kafka Broker 的 Dashboard, 供 Kafka Admin 查看集群信息.
第一步, 提炼核心 metrics
- Kafka Broker 层面, 主要关注如下几个 metrics:
| metric name | description |
|---|---|
| ActiveControllerCount | 标记哪个 broker 节点是 controller |
| UncleanLeaderElectionPerSec | 争议的 leader 选举次数 |
| PartitionCount | 每个 broker 节点的 topic partition 的数量, 用于决定是否需要 rebalance |
| OfflinePartitionsCount | 下线的 partition 的数量, 一般 >0 就说明集群有问题 |
| UnderReplicatedPartitions | 复制中的 Partition 数量 |
| Bytes In bytes Per Topic Top 10 | 按照数据量计算前十个写入的 Topic |
| Bytes Out bytes Per Topic Top 10 | 按照数据量计算前十个读取的 Topic |
| Message In Per Topic Top 10 | 按照消息量计算前十个读取的 Topic |
- JVM 层面, 仅仅关注两个指标, 细节通过链接到 JVM 详细 Dashboard.
| metric name | description |
|---|---|
| JVM Memory Usage | JVM Heap 占用的内存 |
| Time Spend in GC | JVM GC 所占的时间比例, 定位是否有 GC 问题 |
- 系统层面, 仅仅关注 CPU/IO/Network/Memory
| metric name | description |
|---|---|
| CPU Usage | 系统 CPU 使用率 |
| Memory Usage | 系统 Memory 使用率 |
| Disk Usage | 磁盘占用 |
| IO Utilization | IO 使用率, 看是否有磁盘 IO 瓶颈 |
| Network In/Out | 网络吞吐 |
第二步, 构建 Dashboad
使用 Grafana 构建 Dashboard. 建议构建完成后, 通过 JSON 文件导出备份.
第三步, 添加系统依赖 Dashboard 链接
核心 Metrics 构建完成后, 需要整理依赖系统的 Dashboard 链接并添加到 Dashboard 中. 建议如下几个:
- Kafka Broker Instance Dashboard: Kafka Broker 所在节点的详细监控信息
- Kafka Broker JVM Dashboard: JVM 其实有更多更细化的 metrics, 可以让公司的 JVM 达人充分发挥专业特长, 构建更细化的 JVM 监控 Dashboard, 比如各种不同 Heap 的占用, 线程信息等.
- Zookeeper Dashboard: Kafka Broker 依赖的 Zookeeper 集群的 Dashboard
- Kafka Manager: 方便对 Kafka 集群进行调整
0x04 总结
通过 Kafka Broker 的监控这个事儿, 总结了几个原则, 先在 Kafka Broker 上实践了一下, 看后续是否需要进一步修正, 争取贯彻到各个系统的监控 Dashboard 的构建中.
-- EOF --
