cp1 : 業務系統宿主機監控

現在一般系統都不直接跑物理機了，基本都跑在虛擬機器或者容器上邊，無論你們所謂的宿主機或者遷移做到多好，都要密切關注宿主機這塊事情，很可能分分鐘被其他業務或者宿主機本身把系統搞掛。一旦有異常必須關注起來，特別是機器數量比較少的時候，系統沒發起自動遷移的情況下，及時遷移宿主機。

大概需要關注的東西：宿主機網路、磁碟IO、CPU load、memory load

cp2 : 資料庫監控

對於一個普通的業務系統來說，最重要的底層元件莫過於資料庫了，根據我的經驗，現在非常多業務並沒有對資料庫進行設計，所以一般情況下，資料庫要是掛了，那麼這時候業務系統通常來說就是直接不可用狀態。資料庫本身的容災固然重要，但是資料庫一般情況下來說，並不能識別哪些業務SQL是重要的，哪些是不重要的，它只能根據它固有的執行緒池、CPU、記憶體來提供一定量級的服務。

一旦發現有異常，一定要第一優先順序介入，業務上進行限流，資料庫層面SQL處理，比如強行kill慢SQL。

大概需要關注的東西：連線池、讀/寫RT(響應時間)、讀/寫QPS(每秒請求數)、CPU、網路IO、記憶體命中率、慢SQL

cp3 : 虛擬機器或容器健康度

關注點跟宿主機一樣，宿主機做了什麼監控，這裡就做什麼監控。

cp4: 業務系統基礎關鍵引數監控

對於虛擬機器或者容器來說，可能一切都是正常的，但是業務系統上已經出現了大面積拒絕服務，大面積的響應超時，這時候其實可能已經出現了極大的問題，還需要結合一定的監控和排查才能發現問題所在。

大概需要關注的東西：HTTP RT(響應時間)、HTTP QPS(每秒請求數)、HTTP 空閒連線數。對於 Java 類系統來說還有JVM各種引數的監控，比如 各個代的gc時間、總gc次數和時間、堆記憶體、堆外記憶體、執行緒數 等。

cp5: 關鍵公共依賴系統的監控

很多業務系統本身並不止有資料庫，還有很多外部系統。比如 Redis、Memcached 這類外部快取系統。比如類似 ElasticSearch 、 Solor 、阿里雲 OpenSearch 這類搜尋系統。比如Kafka 、RocketMQ、RabbitMQ 這類訊息中介軟體。而且業務系統對於這些外部系統的依賴性一般來說還是比較高的，這類系統一旦出現問題，對於業務的影響也不容小噓，很多時候也是致命的。

大概需要關注的東西：外部系統本身的穩定性監控，這類應該有專人維護，只需要要求他們做好監控，有任何告警訂閱一下就好了。主要監控的還是業務系統本身對於外部系統的呼叫情況，比如連線池、讀/寫RT(響應時間)、讀/寫QPS(每秒請求數)、讀/寫成功率、網路IO。

cp6: 關鍵業務介面系統性監控

就算上邊一切都是正常的，你係統可能還是崩潰的，為什麼呢？可能你的系統早就拒絕服務了，返回了一大堆 isSuccess=false 的資料，這對於使用者，對於業務方來說就是系統不可用，所以我們還要針對我們自己的業務進行一些業務層面的監控。一旦發現關鍵介面有問題，儘快介入排查原因，比如對於異常介面進行限流保障其他系統。比如對於關鍵介面的失敗進行原因排查，儘快定位原因恢復業務。這塊其實是很多人平時在寫業務系統忽略最多的點，目前實現路徑還是比較多的比如資料庫實時查詢，http連線實時檢查、日誌實時採集分析，業務資料準實時分析。

大概需要關注的東西：各個關鍵介面的成功率、RT(響應時間)、QPS。

cp7: 監控自動化和視覺化

cp6做完善後，如果需要人實時盯著，其實用處也比較有限，還是要有一套機制自動化告警甚至自動化處理的機制。如果是正常輪班有人在盯著呢，最好是對於監控資料進行視覺化。

cp8: 異常資料監控

業務流程處理是成功的，系統業務成功的，但是還是有一些隱患，比如資料不正確或者關鍵資料丟失。這類問題會出現在呼叫方或者某些程式碼分支出現問題的時候，一些關鍵資料丟失了，導致最終在進行客戶履約的時候資料缺失。比如外賣丟了送貨地址護著送貨電話等，依然需要以自動化的形式做好異常資料監控。

大概需要關注的東西：關鍵業務節點的關鍵引數。