當(dāng)通過 Kafka 構(gòu)建的系統(tǒng)需要提供特定的可靠性，我們對(duì) Kafka 做了相應(yīng)配置，對(duì)生產(chǎn)者和消費(fèi)者的應(yīng)用做了必要的處理之后，如何驗(yàn)證整個(gè)系統(tǒng)確實(shí)實(shí)現(xiàn)了期望的可靠性呢?本文介紹。

[[284091]]

內(nèi)容提要：

• 概述
• 驗(yàn)證配置
• 驗(yàn)證應(yīng)用
• 線上監(jiān)控

1. 概述

仍然是那句話，可靠性不是一個(gè)可以輕易獲得的東西，驗(yàn)證的方法也不簡單，分為三個(gè)階段：

• 在沒有生產(chǎn)者和消費(fèi)者參與的情況下，對(duì) Kafka 的配置進(jìn)行驗(yàn)證，確認(rèn) Kafka 的表現(xiàn)與預(yù)期一致;
• 加入生產(chǎn)者和消費(fèi)者的應(yīng)用，確認(rèn)生產(chǎn)者和消費(fèi)者的表現(xiàn)和預(yù)期一致;
• 應(yīng)用上線后，對(duì)應(yīng)用和 Kafka 的指標(biāo)、日志等進(jìn)行監(jiān)控，發(fā)現(xiàn)與可靠性有關(guān)的問題，進(jìn)行修復(fù)。

2. 驗(yàn)證配置

驗(yàn)證：其實(shí)就是測試，實(shí)際效果和預(yù)期效果是否一致，因此在驗(yàn)證前必須確認(rèn)期望看到的結(jié)果，如果這一步有誤差，驗(yàn)證可能很難成功。

驗(yàn)證配置不是指用肉眼去確認(rèn)配置文件是否正確，而是使用 Kafka 提供的工具，Kafka 在 org.apacha.kafka.tools 包下有兩個(gè)類：VerifiableProducer 和 VerifiableConsumer，這兩個(gè)類既可以通過命令行運(yùn)行，也可以在各種測試框架中使用。

VerifiableProducer 可以按照我們指定的參數(shù)來發(fā)送一定數(shù)量的消息，消息內(nèi)容為從 1 開始遞增的數(shù)字，參數(shù)包括 acks，重試次數(shù)和發(fā)送速率等等，運(yùn)行時(shí)會(huì)打印每條消息發(fā)送成功或失敗。VerifiableConsumer 消費(fèi) VerifiableProducer 生產(chǎn)的消息，按照消費(fèi)順序打印消息內(nèi)容，并且打印提交 offset 和分區(qū)重分配的消息。

下面來實(shí)戰(zhàn)一下，先看下這兩個(gè)命令行工具都有哪些參數(shù)：

因?yàn)槲乙彩堑谝淮问褂?，所以我就隨便選幾個(gè)參數(shù)設(shè)置一下：

使用 VerifiableProducer 發(fā)送數(shù)據(jù)：

然后用 VerifiableConsumer 接收收據(jù)：

因?yàn)閷?max-messages 設(shè)置為 10，而 topic 中只有 5 條消息，所以沒有退出。

以上只是演示，因?yàn)?broker 只有一臺(tái)，而且非常穩(wěn)定，實(shí)際測試時(shí)需要構(gòu)建更復(fù)雜的場景：

• leader 選舉，關(guān)掉 leader 所在的 broker，producer 和 consumer 需要多長時(shí)間恢復(fù)?
• controller 選舉，重啟 controller，整個(gè)系統(tǒng)需要多長時(shí)間恢復(fù)?
• 滾動(dòng)重啟，一臺(tái)一臺(tái)的重啟 broker，能否做到一條消息都不丟失?
• 臟 leader 選舉，當(dāng)發(fā)生了臟 leader 選舉時(shí)，producer 和 consumer 會(huì)發(fā)生什么，能否接受后果?

根據(jù)實(shí)際的需要去構(gòu)建測試場景，當(dāng)測試都通過之后可以進(jìn)入下一步。

3. 驗(yàn)證應(yīng)用

其實(shí)這一步的驗(yàn)證方法和上一步非常類似，唯一的區(qū)別是：生產(chǎn)者和消費(fèi)者替換成了自己開發(fā)的應(yīng)用代碼，保持 Kafka 的配置不變，啟動(dòng)應(yīng)用中的生產(chǎn)和消費(fèi)者，在構(gòu)建的場景中測試，比如：

• 生產(chǎn)者和消費(fèi)者與 Kafka 集群斷開網(wǎng)絡(luò)
• 發(fā)生了 leader 選舉
• broker 進(jìn)行滾動(dòng)重啟
• 消費(fèi)者進(jìn)行滾動(dòng)重啟
• 生產(chǎn)者進(jìn)行滾動(dòng)重啟

如果測試結(jié)果不符合預(yù)期，找到原因，修復(fù)它，全部驗(yàn)證通過后，進(jìn)入下一步。

4. 線上監(jiān)控

這一步非常重要，因?yàn)槿f一前兩步有所疏漏，或者來不及做，監(jiān)控可以確保及時(shí)發(fā)現(xiàn)問題，避免損失。

監(jiān)控的內(nèi)容可以包括：JMX、日志以及其它更復(fù)雜的自定義的指標(biāo)。

JMX 監(jiān)控

Kafka 自帶了 JMX 監(jiān)控，對(duì)于broker，生產(chǎn)者和消費(fèi)者，分別有不同的指標(biāo)可以關(guān)注。

對(duì)于 broker，值得監(jiān)控的指標(biāo)很多，比如達(dá)不到 ISR 最小副本數(shù)的分區(qū)個(gè)數(shù)，正在同步的分區(qū)副本數(shù)，下線分區(qū)數(shù)，controller 數(shù)量，失敗的生產(chǎn)請(qǐng)求數(shù)，leader 選舉次數(shù)和時(shí)間等等，都很重要。

對(duì)于生產(chǎn)者，兩個(gè)和可靠性相關(guān)的指標(biāo)是每條消息的平均錯(cuò)誤率和平均重試率，這兩個(gè)指標(biāo)如果上升了，表明系統(tǒng)肯定是出了問題。

對(duì)于消費(fèi)者，最重要的指標(biāo)是消費(fèi) lag，它表明了這個(gè)消費(fèi)者當(dāng)前消費(fèi)到的位置落后于這個(gè) topic 的各個(gè)分區(qū)最新消息有多遠(yuǎn)，理想情況是在 0 和一個(gè)很小的值之間波動(dòng)，如果增大到一定的閾值，則需要進(jìn)行處理。

日志監(jiān)控

Kafka 的日志監(jiān)控和其它應(yīng)用的日志監(jiān)控區(qū)別不大，關(guān)注日志中出現(xiàn)的 WARN 和 ERROR，任何異常都有可能影響可靠性。

其它監(jiān)控

如果不滿足于 JMX 監(jiān)控和日志監(jiān)控，可以自己擴(kuò)展或增加其它的監(jiān)控，JMX 報(bào)告的指標(biāo)是可以擴(kuò)展的，日志的內(nèi)容也是可以增加的，但可能需要修改源碼。

監(jiān)控系統(tǒng)

一般來說，Kafka 的監(jiān)控任務(wù)應(yīng)當(dāng)由專門的監(jiān)控和運(yùn)維故障管理系統(tǒng)來完成，我用過兩個(gè)系統(tǒng)來監(jiān)控 Kafka：小米的 Open-Falcon 和 InfluxData 的 Telegraf + InfluxDB + Grafana 套件。都還行，可以比較靈活的定制想要監(jiān)控的內(nèi)容，同時(shí)支持多種報(bào)警方式，比如 Open-Falcon 支持郵件和微信報(bào)警，而 Grafana 的頁面美觀性相當(dāng)不錯(cuò)，其它應(yīng)當(dāng)還有不少，但是我沒有用過就不胡扯了。