通過本文能學習什么？

• 初步了解zookeeper監控
• 如何運用tcpdump + Wireshark抓包分析
• Dubbo在zookeeper上節點設計
• 如何查看zookeeper節點快照

背景

zookeeper作為dubbo的注冊中心，承載著服務的基礎信息(方法名，分組，版本等)，服務關系等信息。隨著業務增多，服務數增加，注冊中心的網絡IO已逐步成為瓶頸。

介紹zookeeper監控

zookeeper3.4.6后提供四字命令可以查看zookeeper集群狀態信息。

例如：

• echo conf | nc localhost 2181，查看集群配置信息，端口，最大連接數等
• echo cons | nc localhost 2181，查看客戶端鏈接的詳情，接受/發送包數，session id等
• echo crst | nc localhost 2181，重置所有客戶端的統計信息
• echo dump | nc localhost 2181，列出未經處理的會話和臨時節點
• echo envi | nc localhost 2181，查看服務器的環境信息，java.home，os.name等
• echo ruok | nc localhost 2181，測試集群是否正常運行
• echo srst | nc localhost 2181，重置服務器的統計信息
• echo srvr | nc localhost 2181，查看服務器的詳細信息。zk版本、接收/發送的包數量、連接數、運行模式、節點總數等
• echo stat | nc localhost 2181，查看客戶端列表，接收/發送包數量、連接數、運行模式、節點總數、延遲等
• echo wchs | nc localhost 2181，查看watches相關信息
• echo mntr | nc localhost 2181，列出集群的健康狀態。接受/發送的包數量、操作延遲、運行模式、節點總數、watch總數、臨時節點總數等

我們使用Grafana和Prometheus去收集zookeeper集群信息和展示，底層也是通過四字命令獲取信息。

線上案例

我們線上zookeeper監控偶爾會收到堆積請求數告警，經查看發現是網絡IO過大造成了請求堆積，不過很快又恢復了，可能某個應用那一刻爬去了大量zookeeper節點。

排查過程

如何找到調用方？

由于突發流量是不定時的，沒法通過實時流量分析，只能通過側面突破。

zookeeper上存儲的都是服務的基本信息。服務的摘掛流量，重啟等操作都會導致zookeeper節點變動，并通知上游。這樣就可以通過發布系統，找下那一段時間誰在發布，看看是否有突破口。

通過查看發布系統，找到了A服務的網絡IO與zookeeper的網絡IO圖形契合，并且出入口流量也能對上，至此，我們找到了誰在大量拉取zookeeper.

zookeeper哪些節點被頻繁拉取？

初步懷疑是A服務使用dubbo方式不對，最后查看A服務源碼，并未找到問題。

由于A服務每次重啟都會導致zookeeper流量增高，說明是可復現的，可以進行抓包分析，抓包工具主流的就是tcpdump + Wireshark。

tcpdump是linux下的網絡截取工具，是服務端抓包的首選。它支持針對網絡層、協議、主機、網絡或端口的過濾，并提供and、or、not等邏輯語句來過濾信息。通過以下命令獲取我們需要的數據包。

tcpdump host (10.10.xx.xx or 10.10.xx.xx or 10.10.xx.xx) and tcp port 4181 -s 0 -w zk.pcap

host：指定多個IP

port：指定端口

-s 0：抓取完整包，而不是默認的68字節

-w：保存文件

還有很多其他參數，大家可以通過man tcpdump查看。

我們用Wireshark打開zk.pcap抓包文件。Wireshark十分強大，可以分析TCP等各種協議，并且提供豐富的語法來過濾信息，分析TCP三次握手就能通過Wireshark查看，大家有興趣可以下來研究。

我們可以根據length排序后再跟蹤一個TCP流，查看包內容

紅色為請求，藍色為返回

我們發現請求了非常多的/dubbo/com.missfresh.algo.common.api.service.IRecoRecallService/configurators節點。

節點作用是什么？

簡單介紹下dubbo在zookeeper注冊節點作用。

routes節點：路由規則相關，永久節點。

configurators節點：dubbo配置相關，永久節點。

providers節點：服務提供者信息，臨時節點，生產者注冊到該節點，消費者會監聽該節點。

consumers節點：消費者信息，臨時節點，消費者注冊到該節點。

configurators節點記錄了服務的IP，分組和版本信息。如果有N個IP，M個分組，K個版本，那個該節點個數為N * M * K個。

如何查看zookeeper上該節點個數？

可以通過zkClient連上集群查看。今天我們通過另一種方式，分析zookeeper快照日志查看。

zookeeper有事務日志(log.*)和快照日志(snapshot.*)，可以通過zookeeper自帶工具把snapshot日志轉成文本。

java -classpath :./slf4j-api-1.7.25.jar:../zookeeper-3.4.12.jar org.apache.zookeeper.server.SnapshotFormatter ~/Documents/snapshot.b3c8cb285 > ~/Documents/zk-snapshot-20200325.log

通過本地文件分析，發現該節點接近4000個。

總結

總結原因

1、由于dubbo服務的上下線，調節權重等操作都會生成configurators永久節點，導致該節點一直積累，每次服務啟動都會去拉取該服務的所有配置，導致zookeeper出口流量增加。

2、為什么會有這么多節點？業務方在使用時存在問題，每次迭代都升級服務版本號，正確做法是盡量兼容低版本的服務，只有在完全無法兼容情況再考慮升級服務版本號。并且給每個上游一個service group，但并沒有通過service group隔離環境/機器，導致節點數是服務版本號與service group的乘積。

解決方案

1、拿到廢棄節點后，通過zkClient刪除廢棄節點。

2、業務調整服務調用方式，把service group去掉，改用多個方法對外暴露。

未來規劃

隨著業務逐漸往docker遷移，我們基礎組件也迎來新的挑戰，頻繁的擴容縮容，IP變換也會導致注冊中心越來越臃腫，需要一個注冊中心治理服務給他瘦身。

總結

以上是生活随笔為你收集整理的zookeeper 日志查看_每天使用的注册中心zookeeper，流量暴涨怎么办？的全部內容，希望文章能夠幫你解決所遇到的問題。

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