最近把 Kafka 的監(jiān)控遷移到了 Prometheus, 順便思考了一下監(jiān)控系統(tǒng) Dashboard 的構(gòu)建原則. 記錄一下.
0x00 Kafka metrics 初探
Kafka 使用的是"民間標(biāo)準(zhǔn)"的 metrics library, 通過(guò)定制化的 reporter 在 server.properties 中配置 參見(jiàn) Kafka 關(guān)于 metrics 源碼. 默認(rèn)情況下, Kafka metrics 所有的 metric 都可以通過(guò) JMX 獲取.
如果想把 Kafka 中的 metrics 數(shù)據(jù)暴露出來(lái), 就有如下幾個(gè)選擇:
- 直接實(shí)現(xiàn)
kafka.metrics.KafkaMetricsReporter這個(gè) trait, 通過(guò)解析Metrics.defaultRegistry()里面所有的 metrics 暴露出來(lái). - 通過(guò) JMX, 獲取 metrics-core library 通過(guò) JMX 暴露的數(shù)據(jù)來(lái)讀取數(shù)據(jù). 讀取 JMX 又有兩種方式:
- 在 Kafka Broker 進(jìn)程內(nèi)部讀取 JMX 數(shù)據(jù), 這樣解析數(shù)據(jù)的邏輯就在 Kafka Broker 進(jìn)程內(nèi)部, 如果有任何調(diào)整, 需要重啟 Broker
- 在 Kafka Broker 外部, 作為一個(gè)獨(dú)立進(jìn)程, 通過(guò) JMX 的 RMI 接口讀取數(shù)據(jù). 這種方式的好處是有任何調(diào)整不需要重啟 Kafka Broker 進(jìn)程, 缺點(diǎn)是多維護(hù)了一個(gè)獨(dú)立的進(jìn)程
0x01 Prometheus + Kafka
回到 Prometheus, 我們來(lái)挨個(gè)評(píng)估一下上述的幾個(gè)方案:
實(shí)現(xiàn)一個(gè) reporter, 將數(shù)據(jù)推送給 Prometheus Pushgateway. 但實(shí)現(xiàn)太繁瑣, 而且要顧及到 Kafka 后續(xù) API 的升級(jí).
-
讀取 JMX 的數(shù)據(jù). Prometheus 官方的組件 jmx_exporter 把兩種實(shí)現(xiàn)都提供了:
-
jmx_prometheus_httpserver通過(guò)獨(dú)立進(jìn)程讀取 JMX 的數(shù)據(jù) -
jmx_prometheus_javaagent使用 Java Agent 方式, 盡量無(wú)侵入(僅需在 java 命令行中使用 -javaagent 參數(shù))的啟動(dòng) in-process library, 讀取 JMX 數(shù)據(jù).
-
不同于 metrics-core 設(shè)計(jì)的是, Prometheus 采用了 PULL 方式, 也就是說(shuō) Prometheus 主動(dòng)抓取 metrics 數(shù)據(jù), 而不是靠客戶(hù)端主動(dòng) PUSH 數(shù)據(jù), 因此 jmx_prometheus 都是通過(guò)暴露 HTTP 端口的方式暴露 metrics 數(shù)據(jù), 方便 Prometheus 抓取數(shù)據(jù).
考慮到 Kafka Broker 的 metrics 足夠穩(wěn)定(排除升級(jí)考慮), 并且對(duì) Prometheus 官方的 library 足夠有信心, 因此選擇了 jmx_prometheus_javaagent 方式, 重啟了一輪 Kafka Broker, 通過(guò) Prometheus 的 scraper 抓取了所有 Kafka Broker 的 metrics 數(shù)據(jù).
0x02 Monitoring Dashboard 構(gòu)建原則
有了 metrics 數(shù)據(jù), 就到了構(gòu)建 Dashboard 的階段了. 如何構(gòu)建一個(gè)"好用"監(jiān)控的 Dashboard? 簡(jiǎn)單的找?guī)讉€(gè) metrics 堆砌一下就完事兒了? NO, NO, NO, not that simple
總結(jié)了4個(gè)原則, 歡迎拍磚:
- 異角(jué)異面 (different dashboards for different roles)
- 唯一面板 (one and only one dashboard for a specific role)
- 依賴(lài)可達(dá) (all dependent systems' dashboard links are provided in the dashboards)
- 依圖告警 (all alert rules should have corresponding chart in the dashboard)
1. 異角異面
一個(gè)系統(tǒng)包含多種角色, 就 Kafka 集群來(lái)說(shuō),
- Kafka 的用戶(hù), 僅僅通過(guò) Kafka API 收發(fā)消息;
- Kafka Admin, 專(zhuān)注于 Kafka 集群的可用性;
- 系統(tǒng)運(yùn)維人員, 關(guān)注 IDC/硬件/網(wǎng)絡(luò)等更基礎(chǔ)的資源.
不同的角色, 關(guān)注的資源不同, 如下圖:
- Kafka 用戶(hù)僅僅關(guān)注自己的 Topic 是否可讀可寫(xiě), Consumer 是否有 Lag
- Kafka Admin 更關(guān)注 Kafka Broker 內(nèi)部的核心 metrics, 看集群資源利用情況(CPU/Memory/IO)和可用性等指標(biāo), 至于 Topic 級(jí)別的 metrics, 最多關(guān)注數(shù)據(jù)量比較大的 topic
- OPS 人員更關(guān)注 IDC 級(jí)別的網(wǎng)絡(luò)/硬件, 或者云服務(wù)提供商的可用性指標(biāo)
監(jiān)控系統(tǒng)應(yīng)該給不同角色提供不同的 Dashboard, 不能簡(jiǎn)單提供一個(gè)大到打不開(kāi)的 Dashboard 讓大家自己去找關(guān)注的指標(biāo)
2. 唯一面板
雖然不同角色關(guān)注點(diǎn)不同, 但關(guān)注的 metrics 確是有不少. 這里的核心原則就是為每個(gè)角色提供一個(gè)并且僅有一個(gè) Dashboad 作為入口, 不能說(shuō)為了看一些指標(biāo), 到處找 metric 在哪個(gè) Dashboard, 降低效率.
通過(guò)提煉核心的 metrics, 將這些 metrics 展現(xiàn)在一個(gè) Dashboard, 提高效率. 至于次要的 metrics 放在哪里, 參考下一條
3. 依賴(lài)可達(dá)
核心 metrics 放到一個(gè) Dashboard 中后, 有些看上去不是那么一針見(jiàn)血的 metrics 放在哪里?
External Link! 核心 Dashboard 中必須提供其他依賴(lài)的系統(tǒng)或者更多非核心的 Dashboard 的鏈接, 供用戶(hù)一鍵點(diǎn)擊打開(kāi), 注意, 是必須一個(gè)跳轉(zhuǎn)就可達(dá), 最大程度提高效率.
回到 Kafka Broker 的例子, Kafka Admin 除了看 Kafka Broker 的核心 metrics 外, 可以一鍵打開(kāi) Kafka Broker 使用的 Zookeeper 集群的 Dashboard, 或者 Kafka 節(jié)點(diǎn)的細(xì)節(jié)監(jiān)控信息的 Dashboard
4. 依圖告警
系統(tǒng)都會(huì)有一些監(jiān)控規(guī)則, 提供異常的告警功能. 但一個(gè)容易忽略的問(wèn)題是, 告警規(guī)則中使用的 metrics 是否在 Dashboard 中有對(duì)應(yīng)的圖表, 方便 on-call 人員收到告警信息后, 以最高效率的方式打開(kāi)對(duì)應(yīng)的異常 metrics 進(jìn)行問(wèn)題診斷. 更貼心的告警系統(tǒng), 應(yīng)該在告警信息中提供對(duì)應(yīng)的 Dashboard 的鏈接, 或者干脆直接把異常值時(shí)間附近的圖表信息發(fā)送到告警信息中(比如截個(gè)圖).
0x03 Kafka Broker Grafana Dashboard 構(gòu)建
貫徹上述的四點(diǎn)原則, 構(gòu)建一個(gè) Kafka Broker 的 Dashboard, 供 Kafka Admin 查看集群信息.
第一步, 提煉核心 metrics
- Kafka Broker 層面, 主要關(guān)注如下幾個(gè) metrics:
| metric name | description |
|---|---|
| ActiveControllerCount | 標(biāo)記哪個(gè) broker 節(jié)點(diǎn)是 controller |
| UncleanLeaderElectionPerSec | 爭(zhēng)議的 leader 選舉次數(shù) |
| PartitionCount | 每個(gè) broker 節(jié)點(diǎn)的 topic partition 的數(shù)量, 用于決定是否需要 rebalance |
| OfflinePartitionsCount | 下線的 partition 的數(shù)量, 一般 >0 就說(shuō)明集群有問(wèn)題 |
| UnderReplicatedPartitions | 復(fù)制中的 Partition 數(shù)量 |
| Bytes In bytes Per Topic Top 10 | 按照數(shù)據(jù)量計(jì)算前十個(gè)寫(xiě)入的 Topic |
| Bytes Out bytes Per Topic Top 10 | 按照數(shù)據(jù)量計(jì)算前十個(gè)讀取的 Topic |
| Message In Per Topic Top 10 | 按照消息量計(jì)算前十個(gè)讀取的 Topic |
- JVM 層面, 僅僅關(guān)注兩個(gè)指標(biāo), 細(xì)節(jié)通過(guò)鏈接到 JVM 詳細(xì) Dashboard.
| metric name | description |
|---|---|
| JVM Memory Usage | JVM Heap 占用的內(nèi)存 |
| Time Spend in GC | JVM GC 所占的時(shí)間比例, 定位是否有 GC 問(wèn)題 |
- 系統(tǒng)層面, 僅僅關(guān)注 CPU/IO/Network/Memory
| metric name | description |
|---|---|
| CPU Usage | 系統(tǒng) CPU 使用率 |
| Memory Usage | 系統(tǒng) Memory 使用率 |
| Disk Usage | 磁盤(pán)占用 |
| IO Utilization | IO 使用率, 看是否有磁盤(pán) IO 瓶頸 |
| Network In/Out | 網(wǎng)絡(luò)吞吐 |
第二步, 構(gòu)建 Dashboad
使用 Grafana 構(gòu)建 Dashboard. 建議構(gòu)建完成后, 通過(guò) JSON 文件導(dǎo)出備份.
第三步, 添加系統(tǒng)依賴(lài) Dashboard 鏈接
核心 Metrics 構(gòu)建完成后, 需要整理依賴(lài)系統(tǒng)的 Dashboard 鏈接并添加到 Dashboard 中. 建議如下幾個(gè):
- Kafka Broker Instance Dashboard: Kafka Broker 所在節(jié)點(diǎn)的詳細(xì)監(jiān)控信息
- Kafka Broker JVM Dashboard: JVM 其實(shí)有更多更細(xì)化的 metrics, 可以讓公司的 JVM 達(dá)人充分發(fā)揮專(zhuān)業(yè)特長(zhǎng), 構(gòu)建更細(xì)化的 JVM 監(jiān)控 Dashboard, 比如各種不同 Heap 的占用, 線程信息等.
- Zookeeper Dashboard: Kafka Broker 依賴(lài)的 Zookeeper 集群的 Dashboard
- Kafka Manager: 方便對(duì) Kafka 集群進(jìn)行調(diào)整
0x04 總結(jié)
通過(guò) Kafka Broker 的監(jiān)控這個(gè)事兒, 總結(jié)了幾個(gè)原則, 先在 Kafka Broker 上實(shí)踐了一下, 看后續(xù)是否需要進(jìn)一步修正, 爭(zhēng)取貫徹到各個(gè)系統(tǒng)的監(jiān)控 Dashboard 的構(gòu)建中.
-- EOF --
