摘要：京東云一直致力于大集群的穩(wěn)定性建設(shè)，監(jiān)控系統(tǒng)也經(jīng)歷了多次完善迭代，本文將重點討論對Zookeeper集群的監(jiān)控。

整體介紹

基于京東云豐富的實戰(zhàn)經(jīng)驗，我們將陸續(xù)分享運維方面的干貨，幫助小伙伴們進(jìn)階為運維達(dá)人，歡迎持續(xù)關(guān)注。首先帶來的是“監(jiān)控”專題系列。

監(jiān)控專題介紹

監(jiān)控，可以判斷服務(wù)的健康程度、定位服務(wù)問題、透視系統(tǒng)內(nèi)部狀態(tài)，是運維工作中極其重要的一環(huán)。該系列內(nèi)容將分享京東云在服務(wù)監(jiān)控方面的最佳實踐。

本期講解內(nèi)容的介紹

本期我們重點講述Zookeeper集群的監(jiān)控。

Zookeeper（文中簡稱ZK）是一個開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google公司Chubby服務(wù)的開源實現(xiàn)，同時也是Hadoop和Hbase等開源軟件的重要組件。enjoy：

服務(wù)故障案例

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

運維儀表盤

采集項篩選

上面通過和大家分享一些ZK故障，讓大家了解了一些核心指標(biāo)的重要性，接下來，我們按照Google SRE的監(jiān)控理論，將ZK監(jiān)控進(jìn)行系統(tǒng)性的梳理和總結(jié)：

黑盒監(jiān)控

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

白盒監(jiān)控

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

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

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

其他監(jiān)控

• 進(jìn)程監(jiān)控（JVM監(jiān)控）
• 端口監(jiān)控
• 日志監(jiān)控
• 主機(jī)監(jiān)控

ZK監(jiān)控

功能監(jiān)控：https://github.com/cloud-op/monitor/tree/master/zookeeper

Zookeeper四字命令

• mntr

?

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。