監(jiān)控

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

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

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

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

監(jiān)控什么呢

當搭建一個集群，要監(jiān)測三大類數(shù)據(jù)

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

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

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

實際的壓力問題怎么發(fā)生的

壓力問題主要發(fā)生在兩個時刻

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

我用的工具

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

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