1 前言
我們已經完成了metric收集工具類的開發。我們需要通過插件的方式，收集指定metric。部分重要metric 上報給效能平臺的監控平臺，當達到閥值時，告警，通知開發同學，然後開發同學直接通過日誌平臺看到更加具體詳細的metric信息，幫助我們快速定位接口流量，rt返回慢，tomcat 請求隊列積壓，以及pod 重啓問題。
監控metric收集設計文檔地址https://www.jianshu.com/p/930811562fbc
1.0 目前存在情況
* 目前 pod 重啓嚴重， 存活檢測是以發請求的形式的檢測。如果tomcat 請求堆積。 多次超過pod存活檢測的時長，pod 會重啓。我們需要監控tomcat 請求隊列，線程池等情況
* 目前接口出現請求超時 ， 調用es服務超時。你沒有法快速定位到接口，以及獲取接口最近1m，5m，15m 實際rt ，tps 。 這對於線上高併發環境，可以快速定位接口
* 當你提供服務的時候，別人需要對你接口的實際運行情況，有個初步瞭解，比如生命週期內服務接口的99% rt時間在20ms 之內 ，ok ，你這個接口是值得信任的。 如果是1s ，你的接口是需要優化的。
* grafana 數據不準確。隊列消費 幾千tps變成幾十億。沒有提前告警能力
1.1 目前監控平臺
主要是以key value 記錄metric信息。目前時間維度1分鐘級別，選擇該平臺主要還是因爲可以快速告警，後期如果有需要強大圖表展示能力，也能快速接入公司的promethues平臺
1.2 需要上報的metric-上報監控平臺
指標儘量pod級別爲主，以高風險指標爲主
pod 級別 最近1分鐘 tps ，
pod 級別 最近1分鐘 99% rt ， max rt ， 平均rt
pod 級別 tomcat 請求隊列 收集
java gc 內存相關metric （後期再做）
1.3 需要收集的metric-日誌輸出
當收到報警，說明已經超過閥值。比如1分鐘 99% rt 已經超過1秒，tomcat 請求隊列已經出現大量請求堆積。我們需要的是快速定位問題接口，以及方法。
指標以服務接口級別爲主，超過固定閥值或者有高風險指標上報時，打印日誌。
| 指標作用域 | 指標 | 打印條件 | 備註 |
|---|---|---|---|
| pod 服務方法級別 | 最近15s 99%rt ，max rt ，平均rt | 最近15s 99% 方法rt 超過1s 時打印 warn 級別 | 危險程度高 |
| pod服務生命週期方法級別 | 75%，95，99% rt ，99.9% rt | 每1小時打印一次 info級別 | 作爲接口性能評價 |
| pod 級別 | 最近5分鐘 tps | 最近5分鐘 tps >200 打印warning 級別 | 最近5分鐘 pod 負載較高，危險程度低 |
| pod 服務方法級別 | 最近1分鐘 tps | 最近1分鐘 tps >200 打印warning 級別 | 最近1分鐘 pod 方法負載較高，危險程度低 |
| pod 級別 | 最近1分鐘 99% rt max rt ， 平均rt | 最近1分鐘 pod 級別平均rt>1s warning 級別 | 最近1分鐘 pod 級別平均rt>1s 危險較高 |
| pod 級別 | tomcat 請求隊列 | 堆積超過100 warning 級別 | 堆積長度超過100個請求，有一定危險度 |
| pod 級別 | tomcat 請求隊列 | 堆積超過200 warning 級別 | 堆積長度超過200個請求，危險度高，每分鐘打印一次 |
| pod 級別 | 最近1分鐘tps ，tomcat 請求隊列 | 最近1分鐘tps <5 且 tomcat 請求隊列>0 | 請求隊列有堆積，且tps很低時候 ，通常都是有阻塞發生，容易引起pod重啓 |
1.5 與監控平臺對接
目前是通過tqmq的方式接入監控預警平臺。類似於
metric
key: podIp_1m_tps value: tps
key：podIp_1m_99rt value: rt
監控平臺告警閥值，通知都和以前一樣。可以每個應用設計獨特的告警規則，通知人，每分鐘檢查等。
1.6 未來開發計劃
如果大家用的還挺好的話，希望有更多metric收集上報 ，更豐富的圖表展示，可以找我和範銳，我們是大大的歡迎的