這篇文章是寫給想對目前的業務系統進行監控但是又不知道從何入手的小夥伴看的，又或者是對於現有監控機制的一個反思，具體爲什麼要做這件事情，可以參照一下下邊這篇，結合着看看。
如下翻譯，checkpoint -> cp
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: 異常數據監控
業務流程處理是成功的，系統業務成功的，但是還是有一些隱患，比如數據不正確或者關鍵數據丟失。這類問題會出現在調用方或者某些代碼分支出現問題的時候，一些關鍵數據丟失了，導致最終在進行客戶履約的時候數據缺失。比如外賣丟了送貨地址護着送貨電話等，依然需要以自動化的形式做好異常數據監控。
大概需要關注的東西：關鍵業務節點的關鍵參數。