本篇文章給大家分享的是有關(guān)Zookeeper集群運(yùn)維避坑指南是怎么樣的，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。
首先帶來(lái)的是“監(jiān)控”專(zhuān)題系列。
監(jiān)控，可以判斷服務(wù)的健康程度、定位服務(wù)問(wèn)題、透視系統(tǒng)內(nèi)部狀態(tài)，是運(yùn)維工作中極其重要的一環(huán)。該系列內(nèi)容將分享京東云在服務(wù)監(jiān)控方面的最佳實(shí)踐。
本期我們重點(diǎn)講述Zookeeper集群監(jiān)控
Zookeeper（文中簡(jiǎn)稱(chēng)ZK）是一個(gè)開(kāi)放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google公司Chubby服務(wù)的開(kāi)源實(shí)現(xiàn)，同時(shí)也是Hadoop和Hbase等開(kāi)源軟件的重要組件。文章將從ZK監(jiān)控案例的角度出發(fā)，讓大家了解ZK的一些重要監(jiān)控指標(biāo)。enjoy：
服務(wù)故障案例
容量問(wèn)題：
部分follower處于非同步狀態(tài)后，手工重啟異常的follower，結(jié)果follower依然無(wú)法加入集群。懷疑是集群有問(wèn)題，因此重啟整個(gè)集群，重啟后集群始終無(wú)法進(jìn)入正常狀態(tài)，沒(méi)有l(wèi)eader導(dǎo)致服務(wù)癱瘓。事后查看，快照體積達(dá)到GB級(jí)別，而initLimit默認(rèn)值僅為20s，follower重啟后無(wú)法在20s內(nèi)同步完GB級(jí)別的數(shù)據(jù)，因此被踢出集群。而重啟操作又加劇了這一問(wèn)題，導(dǎo)致集群整體崩潰。最終，通過(guò)將故障前l(fā)eader節(jié)點(diǎn)的快照手工同步到所有節(jié)點(diǎn)，并調(diào)大了zoo.cfg的同步時(shí)間相關(guān)的參數(shù)，服務(wù)才恢復(fù)。
在這個(gè)案例中，快照體積過(guò)大是故障的主要原因，我們需要優(yōu)化initLimit和syncLimit參數(shù)、規(guī)范業(yè)務(wù)對(duì)ZK的使用方式、避免把ZK當(dāng)作通用的文件存儲(chǔ)系統(tǒng)，同時(shí)也需要添加對(duì)快照體積（zk_approximate_data_size）的監(jiān)控，超過(guò)1GB就需要報(bào)警。類(lèi)似的問(wèn)題，如果ZK的節(jié)點(diǎn)數(shù)過(guò)多，也會(huì)造成集群性能?chē)?yán)重下降，因此也需要添加對(duì)ZK集群的節(jié)點(diǎn)數(shù)（zk_znode_count）的監(jiān)控，超過(guò)10萬(wàn)個(gè)節(jié)點(diǎn)就需要報(bào)警。
資源問(wèn)題：
ZK集群和Hadoop部署在同一批物理機(jī)上，當(dāng)Hadoop計(jì)算任務(wù)增加后，將物理機(jī)CPU打滿(mǎn)，同機(jī)部署的ZK集群就無(wú)法響應(yīng)外部請(qǐng)求，進(jìn)而所有依賴(lài)該ZK的Hadoop服務(wù)均會(huì)崩潰。不僅僅是CPU，ZK還依賴(lài)單機(jī)的磁盤(pán)空間，磁盤(pán)的IO能力，網(wǎng)絡(luò)等。鑒于此，對(duì)于ZK集群還是建議獨(dú)立部署，不要混部。同時(shí)，對(duì)ZK所在機(jī)器的CPU/MEM/NET/IO等進(jìn)行監(jiān)控，避免其資源被占用。
流量問(wèn)題：
一個(gè)分布式系統(tǒng)上線新功能，其客戶(hù)端在前幾日逐步更新后未發(fā)現(xiàn)問(wèn)題，因此在某一日對(duì)客戶(hù)端進(jìn)行了全量更新，所有客戶(hù)端均會(huì)定期請(qǐng)求ZK集群，造成ZK集群無(wú)法處理如此海量請(qǐng)求，集群直接崩潰。該客戶(hù)端也不得不全部回滾。雖然，這個(gè)ZK集群當(dāng)時(shí)設(shè)置leader不接收請(qǐng)求，且對(duì)單個(gè)IP最高并發(fā)請(qǐng)求數(shù)也進(jìn)行了限制，但這依然無(wú)法改變集群面對(duì)海量請(qǐng)求直接崩潰的結(jié)果。
在這個(gè)案例中，如果及早添加了流量相關(guān)的監(jiān)控，如ZK節(jié)點(diǎn)連接數(shù)（zk_num_alive_connections）以及ZK節(jié)點(diǎn)流量（ zk_packets_received/zk_packert_sent），可以提前感知到集群流量突增的問(wèn)題。
服務(wù)異常：
follower故障未及時(shí)處理，導(dǎo)致單個(gè)集群故障的follower數(shù)量超過(guò)了集群可以容忍的大值，集群徹底崩潰。這時(shí)候需要立即修復(fù)故障的follower。結(jié)果發(fā)現(xiàn)之前的follower因?yàn)橛布收系仍蚨虝r(shí)間內(nèi)無(wú)法恢復(fù)，而業(yè)務(wù)方大多是直連IP，因此也無(wú)法快速修改。此時(shí)集群壓力還比較大，即使強(qiáng)行轉(zhuǎn)為單機(jī)模式，也需要進(jìn)行限流。無(wú)論如何處理，都會(huì)導(dǎo)致服務(wù)受損較長(zhǎng)時(shí)間。
在這個(gè)案例中，如果及早添加了follower相關(guān)的監(jiān)控，如zk_followers /zk_synced_followers以及zk_server_state，并能保證報(bào)警發(fā)生后立即處理并恢復(fù)服務(wù)，則不會(huì)出現(xiàn)這種慘劇。
容量問(wèn)題：
ZK集群的文件句柄數(shù)，使用了系統(tǒng)默認(rèn)的10240，而系統(tǒng)實(shí)際的壓力遠(yuǎn)不止于此，因此會(huì)出現(xiàn)ZK無(wú)法處理部分新的請(qǐng)求，而問(wèn)題定位的成本和耗時(shí)也會(huì)增加。發(fā)現(xiàn)問(wèn)題后，通過(guò)調(diào)整ZK運(yùn)行賬號(hào)的文件句柄數(shù)限制并重啟服務(wù)即可解決。
在這個(gè)案例中，如果及早添加了zk_open_file_descriptor_count/zk_max_file_descriptor_count，則能夠避免該問(wèn)題。同時(shí)，很多開(kāi)源軟件都會(huì)遇到文件句柄數(shù)的問(wèn)題，且多次引發(fā)各類(lèi)系統(tǒng)的重大故障，所以還是要謹(jǐn)慎對(duì)待。
隔離問(wèn)題：
ZK集群提供了全地域的協(xié)調(diào)服務(wù)，當(dāng)ZK集群出現(xiàn)故障后，導(dǎo)致服務(wù)在全國(guó)所有地域不可用。這時(shí)候，應(yīng)該對(duì)ZK集群進(jìn)行拆分，每個(gè)地域均部署一套獨(dú)立的集群，將故障范圍控制在單一地域。在這個(gè)案例中，監(jiān)控并非主要的問(wèn)題和解決方案，而講述該案例的目的，主要是讓大家對(duì)ZK集群故障有一個(gè)更加全面的認(rèn)識(shí)。
運(yùn)維儀表盤(pán)
采集項(xiàng)篩選
上面通過(guò)和大家分享一些ZK故障，讓大家了解了一些核心指標(biāo)的重要性。接下來(lái)，我們按照Google SRE的監(jiān)控理論，將ZK監(jiān)控進(jìn)行系統(tǒng)性的梳理和總結(jié)：
黑盒監(jiān)控
集群功能
創(chuàng)建/刪除/讀取節(jié)點(diǎn)
說(shuō)明：在/zookeeper_monitor節(jié)點(diǎn)下，定期創(chuàng)建/刪除節(jié)點(diǎn)，確保該功能可用
建議：創(chuàng)建/zookeeper_monitor節(jié)點(diǎn)，不要使用業(yè)務(wù)節(jié)點(diǎn)，避免互相影響
經(jīng)驗(yàn)值：模擬用戶(hù)請(qǐng)求的節(jié)點(diǎn)至少3個(gè)，從而確保覆蓋ZK所有節(jié)點(diǎn)
讀取/更新內(nèi)容
說(shuō)明：在/zookeeper_monitor節(jié)點(diǎn)下，定期對(duì)內(nèi)容讀取和更新
建議：可以將時(shí)間戳寫(xiě)入，從而便于判斷寫(xiě)入延時(shí)
白盒監(jiān)控
采集方式
方式1：zookeeper四字命令mntr
方式2：JMX接口
錯(cuò)誤
zk_server_state
說(shuō)明：集群中有且只能有一個(gè)leader，沒(méi)有l(wèi)eader，則集群無(wú)法正常工作；兩個(gè)或以上的leader，則視為腦裂，會(huì)導(dǎo)致數(shù)據(jù)不一致問(wèn)題
重要性：高
zk_followers /zk_synced_followers
說(shuō)明：如果上述兩個(gè)值不相等，就表示部分follower異常了需要立即處理，很多低級(jí)事故，都是因?yàn)閱蝹€(gè)集群故障了太多的follower未及時(shí)處理導(dǎo)致
重要性：高
zk_outstanding_requests
說(shuō)明：常態(tài)下該值應(yīng)該持續(xù)為0，不應(yīng)該有未處理請(qǐng)求
重要性：高
zk_pending_syncs
說(shuō)明：常態(tài)下該值應(yīng)該持續(xù)為0，不應(yīng)該有未同步的數(shù)據(jù)
重要性：高
容量
zk_znode_count
說(shuō)明：節(jié)點(diǎn)數(shù)越多，集群的壓力越大，性能會(huì)隨之急劇下降
重要性：高
經(jīng)驗(yàn)值：不要超過(guò)100萬(wàn)
建議：當(dāng)節(jié)點(diǎn)數(shù)過(guò)多時(shí)，需要考慮以機(jī)房/地域/業(yè)務(wù)等維度進(jìn)行拆分
zk_approximate_data_size
說(shuō)明：當(dāng)快照體積過(guò)大時(shí)，ZK的節(jié)點(diǎn)重啟后，會(huì)因?yàn)樵趇nitLimit的時(shí)間內(nèi)同步不完整個(gè)快照而無(wú)法加入集群
重要性：高
經(jīng)驗(yàn)值：不要超過(guò)1GB體積
建議：不要把ZK當(dāng)做文件存儲(chǔ)系統(tǒng)來(lái)使用
zk_open_file_descriptor_count/zk_max_file_descriptor_count
說(shuō)明：當(dāng)上述兩個(gè)值相等時(shí)，集群無(wú)法接收并處理新的請(qǐng)求
重要性：高
建議：修改/etc/security/limits.conf，將線上賬號(hào)的文件句柄數(shù)調(diào)整到100萬(wàn)
zk_watch_count
說(shuō)明：對(duì)于watch的數(shù)量較多，那么變更后ZK的通知壓力也會(huì)較大
重要性：中
流量
zk_packets_received/zk_packert_sent
說(shuō)明：ZK節(jié)點(diǎn)接收/發(fā)送的packet的數(shù)量，每個(gè)節(jié)點(diǎn)的具體值均不同，通過(guò)求和的方式來(lái)獲取集群的整體值
建議：通過(guò)兩次命令執(zhí)行間隔1s來(lái)獲取差值
重要性：中
zk_num_alive_connections
說(shuō)明：ZK節(jié)點(diǎn)的客戶(hù)端連接數(shù)量，每個(gè)節(jié)點(diǎn)的具體值均不同，通過(guò)求和的方式來(lái)獲取集群的整體值
建議：通過(guò)兩次命令執(zhí)行間隔1s來(lái)獲取差值
重要性：中
延時(shí)
zk_avg_latency/zk_max_latency/zk_min_latency
說(shuō)明：需要關(guān)注平均延時(shí)的劇烈變化，業(yè)務(wù)上對(duì)延時(shí)有明確要求的，則可以針對(duì)具體閾值進(jìn)行設(shè)置
其他監(jiān)控
進(jìn)程監(jiān)控（JVM監(jiān)控）
端口監(jiān)控
日志監(jiān)控
主機(jī)監(jiān)控
TIPS
Zookeeper四字命令
mntr
stat
以上就是Zookeeper集群運(yùn)維避坑指南是怎么樣的，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。
重慶分公司
重慶分公司
