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

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

容量問題：

部分follower處于非同步狀態后，手工重啟異常的follower，結果follower依然無法加入集群。懷疑是集群有問題，因此重啟整個集群，重啟后集群始終無法進入正常狀態，沒有leader導致服務癱瘓。事后查看，快照體積達到GB級別，而initLimit默認值僅為20s，follower重啟后無法在20s內同步完GB級別的數據，因此被踢出集群。而重啟操作又加劇了這一問題，導致集群整體崩潰。最終，通過將故障前leader節點的快照手工同步到所有節點，并調大了zoo.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監控）

• 端口監控

• 日志監控

• 主機監控