摘要：京東云一直致力于大集群的穩定性建設，監控系統也經歷了多次完善迭代，本文將重點討論對Zookeeper集群的監控。

整體介紹

基于京東云豐富的實戰經驗，我們將陸續分享運維方面的干貨，幫助小伙伴們進階為運維達人，歡迎持續關注。首先帶來的是“監控”專題系列。

監控專題介紹

監控，可以判斷服務的健康程度、定位服務問題、透視系統內部狀態，是運維工作中極其重要的一環。該系列內容將分享京東云在服務監控方面的最佳實踐。

本期講解內容的介紹

本期我們重點講述Zookeeper集群的監控。

Zookeeper（文中簡稱ZK）是一個開放源碼的分布式應用程序協調服務，是Google公司Chubby服務的開源實現，同時也是Hadoop和Hbase等開源軟件的重要組件。enjoy：

服務故障案例

• 容量問題：部分follower處于非同步狀態后，手工重啟異常的follower，結果follower依然無法加入集群。懷疑是集群有問題，因此重啟整個集群，重啟后集群始終無法進入正常狀態，沒有leader導致服務癱瘓。事后查看，快照體積達到GB級別，而initLimit默認值僅為20s，follower重啟后無法在20s內同步完GB級別的數據，因此被踢出集群。而重啟操作又加劇了這一問題，導致集群整體崩潰。最終，通過將故障前leader節點的快照手工同步到所有節點，并調大了cfg的同步時間相關的參數，服務才恢復。在這個案例中，快照體積過大是故障的主要原因，我們需要優化initLimit和syncLimit參數、規范業務對ZK的使用方式、避免把ZK當作通用的文件存儲系統，同時也需要添加對快照體積（zk_approximate_data_size）的監控，超過1GB就需要報警。類似的問題，如果ZK的節點數過多，也會造成集群性能嚴重下降，因此也需要添加對ZK集群的節點數（zk_znode_count）的監控，超過10萬個節點就需要報警。
• 資源問題：ZK集群和Hadoop部署在同一批物理機上，當Hadoop計算任務增加后，將物理機CPU打滿，同機部署的ZK集群就無法響應外部請求，進而所有依賴該ZK的Hadoop服務均會崩潰。不僅僅是CPU，ZK還依賴單機的磁盤空間，磁盤的IO能力，網絡等。鑒于此，對于ZK集群還是建議獨立部署，不要混部。同時，對ZK所在機器的CPU/MEM/NET/IO等進行監控，避免其資源被占用。
• 流量問題：一個分布式系統上線新功能，其客戶端在前幾日逐步更新后未發現問題，因此在某一日對客戶端進行了全量更新，所有客戶端均會定期請求ZK集群，造成ZK集群無法處理如此海量請求，集群直接崩潰。該客戶端也不得不全部回滾。雖然，這個ZK集群當時設置leader不接收請求，且對單個IP最高并發請求數也進行了限制，但這依然無法改變集群面對海量請求直接崩潰的結果。在這個案例中，如果及早添加了流量相關的監控，如ZK節點連接數（zk_num_alive_connections）以及ZK節點流量（ zk_packets_received/zk_packert_sent），可以提前感知到集群流量突增的問題。
• 服務異常：follower故障未及時處理，導致單個集群故障的follower數量超過了集群可以容忍的最大值，集群徹底崩潰。這時候需要立即修復故障的follower。結果發現之前的follower因為硬件故障等原因短時間內無法恢復，而業務方大多是直連IP，因此也無法快速修改。此時集群壓力還比較大，即使強行轉為單機模式，也需要進行限流。無論如何處理，都會導致服務受損較長時間。在這個案例中，如果及早添加了follower相關的監控，如zk_followers /zk_synced_followers以及zk_server_state，并能保證報警發生后立即處理并恢復服務，則不會出現這種慘劇。
• 容量問題：ZK集群的文件句柄數，使用了系統默認的10240，而系統實際的壓力遠不止于此，因此會出現ZK無法處理部分新的請求，而問題定位的成本和耗時也會增加。發現問題后，通過調整ZK運行賬號的文件句柄數限制并重啟服務即可解決。在這個案例中，如果及早添加了zk_open_file_descriptor_count/zk_max_file_descriptor_count，則能夠避免該問題。同時，很多開源軟件都會遇到文件句柄數的問題，且多次引發各類系統的重大故障，所以還是要謹慎對待。
• 隔離問題：ZK集群提供了全地域的協調服務，當ZK集群出現故障后，導致服務在全國所有地域不可用。這時候，應該對ZK集群進行拆分，每個地域均部署一套獨立的集群，將故障范圍控制在單一地域。在這個案例中，監控并非主要的問題和解決方案，而講述該案例的目的，主要是讓大家對ZK集群故障有一個更加全面的認識。

運維儀表盤

采集項篩選

上面通過和大家分享一些ZK故障，讓大家了解了一些核心指標的重要性，接下來，我們按照Google SRE的監控理論，將ZK監控進行系統性的梳理和總結：

黑盒監控

• 集群功能
  • 創建/刪除/讀取節點
    • 說明：在/zookeeper_monitor節點下，定期創建/刪除節點，確保該功能可用
    • 建議：創建/zookeeper_monitor節點，不要使用業務節點，避免互相影響
    • 經驗值：模擬用戶請求的節點至少3個，從而確保覆蓋zk所有節點
  • 讀取/更新內容
    • 說明：在/zookeeper_monitor節點下，定期對內容讀取和更新
    • 建議：可以將時間戳寫入，從而便于判斷寫入延時

白盒監控

• 采集方式
  • 方式1：zookeeper四字命令mntr
  • 方式2：JMX接口
• 錯誤
  • zk_server_state
    • 說明：集群中有且只能有一個leader，沒有leader，則集群無法正常工作；兩個或以上的leader，則視為腦裂，會導致數據不一致問題
    • 重要性：高
  • zk_followers /zk_synced_followers
    • 說明：如果上述兩個值不相等，就表示部分follower異常了需要立即處理，很多低級事故，都是因為單個集群故障了太多的follower未及時處理導致
    • 重要性：高
  • zk_outstanding_requests
    • 說明：常態下該值應該持續為0，不應該有未處理請求
    • 重要性：高
  • zk_pending_syncs
    • 說明：常態下該值應該持續為0，不應該有未同步的數據
    • 重要性：高
  • 容量
    • zk_znode_count
      • 說明：節點數越多，集群的壓力越大，性能會隨之急劇下降
      • 重要性：高
      • 經驗值：不要超過100萬
      • 建議：當節點數過多時，需要考慮以機房/地域/業務等維度進行拆分
    • zk_approximate_data_size
      • 說明：當快照體積過大時，ZK的節點重啟后，會因為在initLimit的時間內同步不完整個快照而無法加入集群
      • 重要性：高
      • 經驗值：不要超過1GB體積
      • 建議：不要把ZK當做文件存儲系統來使用
    • zk_open_file_descriptor_count/zk_max_file_descriptor_count
      • 說明：當上述兩個值相等時，集群無法接收并處理新的請求
      • 重要性：高
      • 建議：修改/etc/security/limits.conf，將線上賬號的文件句柄數調整到100萬
    • zk_watch_count

• 說明：對于watch的數量較多，那么變更后ZK的通知壓力也會較大
• 重要性：中

• 流量
  • zk_packets_received/zk_packert_sent
    • 說明：ZK節點接收/發送的packet的數量，每個節點的具體值均不同，通過求和的方式來獲取集群的整體值
    • 建議：通過兩次命令執行間隔1s來獲取差值
    • 重要性：中
  • zk_num_alive_connections
    • 說明：ZK節點的客戶端連接數量，每個節點的具體值均不同，通過求和的方式來獲取集群的整體值
    • 建議：通過兩次命令執行間隔1s來獲取差值
    • 重要性：中
  • 延時
    • zk_avg_latency/zk_max_latency/zk_min_latency
      • 說明：需要關注平均延時的劇烈變化，業務上對延時有明確要求的，則可以針對具體閾值進行設置

其他監控

• 進程監控（JVM監控）
• 端口監控
• 日志監控
• 主機監控

ZK監控

功能監控：https://github.com/cloud-op/monitor/tree/master/zookeeper

Zookeeper四字命令

• mntr

?

• stat
• crst、dump、envi、ruok、srst、srvr、cons、wchs、wchc、wchp、conf

總結

以上是生活随笔為你收集整理的步步惊心，Zookeeper集群运维“避坑”指南的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。