HubSpot是如何監控Kafka的性能的
Sidekick 是數字營銷公司 HubSpot 的一款產品，用于在接收者打開郵件時實時通知發送者。創建和發送通知的基礎設施以 Kafka 為基礎創建。 Ze'ev Klapow 是 Sidekick 基礎設施團隊的一名資深軟件工程師。近日，他 撰文介紹了他們如何在 Sidekick 中監控 Kafka 的性能。
Sidekick 通知管道的架構大致如下：
Ze'ev 指出，像上圖這樣就許多 Kafka 消費者連接在一起，需要監控每個消費者的性能，而且需要在消費者出現問題時快速定位。為此，他們開發了如下兩個指標。
“增量（Delta）”
該指標用于確定消費者是否能夠跟上某個主題的數據生成速度，如下圖所示：
在 Kafka 中，每條消息會發送到某個主題的一個分區上，每條消息在寫入時會獲得一個遞增的偏移量數值。消費者在消費消息時會記錄它消費的最后一條消息的偏移量。增量即是該偏移量與分區頭之前差異。對于每個 Kafka 消費者，他們會記錄如下兩個增量數據：
- 增量總和為所有分區的增量之和。增量總和增加說明消費者太慢或數據量太大，可以考慮擴展消費者，或者增加并發。
- 最大增量為所有分區中的最大增量。最大增量增加說明只有一個工作進程出現問題，或者分區之間沒有實現很好的負載均衡。 </ul>
“延遲（Lag）”
該指標用于監控消息處理延遲。在 Sidekick 中，他們會在所有的消息上都存儲一個時間戳。如下圖所示，總延遲為事件創建和通知發送之間的時間，可以幫助他們監控整個管道：
另外，如下圖所示:
他們還可以進行更細粒度地延遲監控，這有助于在總延遲開始偏離正常軌道時進行調試。
按照 Ze'ev 的說法，上述兩個指標提供了系統健康狀況的一個完整視圖。當消費者出現問題時，他們首先會依據下表進行問題判斷：
|
Δ↑ </td> |
情況糟糕！ 有地方出現問題了。 </td> |
情況可能并不壞。 增量增加但延遲穩定可能代表流量峰值或類似的問題。 </td> </tr> | |||||||
| Δ↑ |
增量沒有增加，但延遲增加。 可能是該消費者的上游存在問題。 </td> |
一切正常！ </td> </tr> | |||||||
|
LAG↑ </td> |
LAG↓ </td> </tr> </tbody> </table>Ze'ev 表示，當出現問題時，此表可以為問題調試指明方向；當沒有問題時，此表可以讓他們對系統的性能更加自信。 來自: InfoQ
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
相關經驗相關資訊 |