隨筆
從千萬粉絲“何同學”抄襲開源專案說起，為何純技術死路一條？
資料來源的統一與拆分
監控報警系統的指標、規則與執行閉環
我們的系統應該配置哪些監控報警項？
監控報警系統如何實現自監控?
java 老矣，尚能飯否？
一騎紅塵妃子笑，無人知是荔枝來!
應用監控指北
解設我們千辛萬苦搭建好了一個監控平臺，那麼應該配置哪些監控項呢？
本文將以通俗易懂的方式，梳理簡單梳理一下需要的關鍵監控項。
一、基礎設施層監控
1. 伺服器硬體資源
- CPU使用率
高CPU使用率會導致效能瓶頸，需要及時監控和最佳化。 - 記憶體使用率
記憶體不足可能導致系統崩潰或頻繁垃圾回收（GC）。 - 磁碟IO和空間
磁碟耗盡或IO瓶頸會直接影響系統的可用性。 - 網路頻寬和延遲
網路丟包和延遲問題會影響系統效能，尤其在分散式系統中。
2. 虛擬化和容器
- 容器資源限制（CPU、記憶體、磁碟空間）
超出限制會導致應用異常。 - 主機節點資源利用率
確保多個容器或虛擬機器穩定執行。
工具推薦：使用普米（Prometheus）和 Zabbix 進行實時監控。
二、應用層監控
1. 服務健康狀態
- 介面可用性
確保核心業務介面可訪問。 - 響應時間
及時發現效能下降的問題。 - 錯誤率（如5xx、4xx）
快速識別程式異常或配置錯誤。
2. 應用效能
- QPS/TPS（每秒查詢/事務量）
衡量系統負載能力。 - 執行緒池狀態
避免執行緒池耗盡，確保服務穩定。 - GC時間和頻率
排查Java等語言的記憶體管理問題。
3. 日誌異常
- 關鍵字監控（如“ERROR”、“Exception”）
快速定位潛在問題。 - 日誌流量突增
可能是系統故障或惡意攻擊的訊號。
工具推薦：使用 CAT 監控效能，日誌指標採集工具監控日誌異常。
三、資料庫層監控
1. 連線池
- 連線池使用率
連線耗盡會直接影響業務執行。
2. 查詢效能
- 慢查詢
找出效能瓶頸的SQL語句。 - 查詢失敗率
預警潛在的資料庫問題。
3. 資料庫資源
- CPU、記憶體、磁碟IO
衡量資料庫壓力。 - 主從同步延遲
確保資料一致性。
資料庫監控也可以透過普米設定報警。連線池可以透過 CAT 中的擴充。慢日誌可以基於日誌。
四、網路層監控
1. API閘道器
- 請求數量和延遲
評估流量和效能。 - 限流/熔斷觸發次數
發現流量異常或下游問題。
2. 網路連線
- HTTP連線錯誤率
檢查連線超時或網路中斷。 - 防火牆規則日誌
檢測潛在的惡意訪問。
五、安全監控
1. 使用者行為
- 登入失敗次數
防止暴力破解。 - 敏感操作日誌
追蹤高風險操作。
2. 系統漏洞
- 異常檔案改動
檢測入侵行為。 - 未授權訪問
發現非法操作。
這些一般隸屬於安全部門處理，但是安全部門一般不是研發，也是需要藉助一個平臺的。
六、業務指標監控
1. 核心業務流程
- 訂單數量、支付成功率
確保業務正常執行。 - 使用者轉化率
發現問題並最佳化策略。
2. 自定義指標
根據業務模型定製監控指標（如庫存狀態、廣告點選率）。
業務系統是非常複雜的，一般可以配置數量+失敗率/成功率+波動比例
總結
實施監控的關鍵原則
- 全面性
覆蓋系統的各個層級，避免監控盲區。 - 實時性
快速收集資料，及時發現並處理問題。 - 高可用性
監控系統本身需要穩定可靠。 - 靈活性
支援動態調整監控規則和指標。
結合自己具體的業務，配置後及時的處理報警，而不是等使用者報警上來時，希望可以幫到你。