監控

簡單來說，分布式系統需要實現一個基本的監控工具。最簡單的辦法是在每個節點上部署一個agent，定時上報該機器的信息。這一塊魚龍混雜。開源的實施起來就比較復雜了。這一塊主要分四層：

• 收集，具體怎么收集數據（比如sar命令、JMX等）
• 傳輸，收集到的數據如何傳到存儲（比如用syslog，fluentd，statsd）
• 存儲+分析，如何存儲收集到的數據，并提供查詢（比如用mysql，postgres等一般數據庫，RRD Tools工具，或者InfluxDB這樣的專用時序數據庫）
• 界面展示和報警，數據怎么變成好看的圖表，并提供不同維度的查詢；如果可以，一些參數超過一定的閾值，就要自動報警（發郵件、發短信、發微信等）。（比如grafana, icinga等）

也有很多All-in-one的收費方案，比如New Relic，聽云等。

不同監控的側重點不同，有的主打通用，于是可以對接一堆其他工具。有的則主打特定領域，比如Java自帶的JMC可以監控JVM的GC，線程等情況；Percona Monitoring Plugins可以監控MySql的內部情況等。可以根據需要具體選擇。有些云服務提供商也會提供一些最基本的監控，比如阿里云的相關工具。

監控什么呢

當搭建一個集群，要監測三大類數據

• 機器數據：最主要包括
  • CPU idle，io，load值等
  • 內存的使用和swap
  • 磁盤io KB/s，iops （如果是數據庫的的機器特別重要）
  • 網絡，總帶寬占用，io KB/s， packet/s （如果是服務的機器就特別重要）
• 框架/服務級別的監控
  • 例如，如果是JVM，Java的堆內存情況；GC，尤其是FullGC的頻率和暫停時間；線程數量和狀態；如果可以的話，方法執行的耗時排名；
  • 如果是DB，為內存占用，磁盤io，慢查詢，鏈接數的監控
• 業務級別監控
  • 比如單位時間下單數、Cache命中率等等、Log中500錯誤數等等。隨著業務的變化，這些監控會不斷的變化

這是一個浩大的工程。不可能一蹴而就，也不可能一套工具就全搞定。必須結合Infra和業務開發工程師的共同努力才能構建出來。如果預算不是那么緊，建議采購一兩套收費的方案來減少這方面的開發資源消耗。畢竟做公司的主要精力是業務本身，而不是開發完備的基礎設施。當公司體量大到一定程度，自然就會建立專門的團隊來做這些。

構建監控體系時注意 報警不能淹沒使用者的接收。鋪天蓋地的報警只會讓人把報警直接關了。所以設計時要考慮報警的頻率，級別，ACK等機制。而且可能會反復調整。盡量把“關鍵問題的報警”提供出來。

實際的壓力問題怎么發生的

壓力問題主要發生在兩個時刻

• 上線的時候。比如曾經有一個同學做了一個實現，勿用了正則表達式，造成了一上線CPU飆高直接打到100%。這時通過監控工具和報警可以馬上識別所有上線的包都有問題，立刻實施緊急回滾。類似的問題還有，比如寫代碼的SQL沒有用好索引造成全表掃描。異步代碼寫成了同步的，卡死了接收端等等。
• 用戶流量壓力突然增加。比如我們的長贏指數投資計劃非常受歡迎。一發車就流量（帶寬）升高10倍。這個第一次發生時沒有應對的策略。事后我們使用K8S，提前準備熱備機器來頂住流量。此外，很多壓力會集中到DB，因此需要花跟多精力開發Cache（Cache其實是個很難的問題，回頭單獨講）

我用的工具

工具太多了，我們粗選了幾個就用了，不一定是最好的，但至少目前還是可以解決問題的

• 收集端就用服務自帶的命令即可，比如操作系統的top、sar，redis的info命令等
• 傳輸和存儲使用influxdb
• 分析工具使用grafana和icinga