Sidekick 是數字營銷公司 HubSpot 的一款產品，用於在接收者打開郵件時實時通知發送者。創建和發送通知的基礎設施以 Kafka 為基礎創建。Ze'ev Klapow 是 Sidekick 基礎設施團隊的一名資深軟件工程師。近日，他撰文介紹了他們如何在 Sidekick 中監控 Kafka 的性能。
Sidekick 通知管道的架構大致如下：
Ze'ev 指出，像上圖這樣就許多 Kafka 消費者連接在一起，需要監控每個消費者的性能，而且需要在消費者出現問題時快速定位。為此，他們開發了如下兩個指標。
“增量（Delta）”
該指標用於確定消費者是否能夠跟上某個主題的數據生成速度，如下圖所示：
在 Kafka 中，每條消息會發送到某個主題的一個分區上，每條消息在寫入時會獲得一個遞增的偏移量數值。消費者在消費消息時會記錄它消費的最後一條消息的偏移量。增量即是該偏移量與分區頭之前差異。對於每個 Kafka 消費者，他們會記錄如下兩個增量數據：
增量總和為所有分區的增量之和。增量總和增加說明消費者太慢或數據量太大，可以考慮擴展消費者，或者增加並發。
最大增量為所有分區中的最大增量。最大增量增加說明只有一個工作進程出現問題，或者分區之間沒有實現很好的負載均衡。
“延遲（Lag）”
該指標用於監控消息處理延遲。在 Sidekick 中，他們會在所有的消息上都存儲一個時間戳。如下圖所示，總延遲為事件創建和通知發送之間的時間，可以幫助他們監控整個管道：
另外，如下圖所示:
他們還可以進行更細粒度地延遲監控，這有助於在總延遲開始偏離正常軌道時進行調試。
按照 Ze'ev 的說法，上述兩個指標提供了系統健康狀況的一個完整視圖。當消費者出現問題時，他們首先會依據下表進行問題判斷：
Ze'ev 表示，當出現問題時，此表可以為問題調試指明方向；當沒有問題時，此表可以讓他們對系統的性能更加自信。
