本文轉載自微信公眾號「虞大膽的嘰嘰喳喳」，作者虞大膽。轉載本文請聯系虞大膽的嘰嘰喳喳公眾號。

我們有zabbix和promethous兩種監控系統，其實理解監控本質很重要，正好看到《promethous監控實戰》這本書，第一章對于監控的定義描述的非常好，分上下篇說明下。

[[330382]]

監控是衡量和管理技術系統的工具和流程，但更重要的是監控能將系統和應用程序生成的指標轉換為對應的業務價值。監控不僅能檢測和解決故障，還能幫助洞察關鍵的產品和技術決策，并衡量項目是否成功。

監控的一些反模式

1：事后監控，將監控和運維工作是為應用程序的增值組件而非核心功能。

2：機械式監控

比如就監控主機的CPU，內存，而不監控應用程序是否正常運行的關鍵服務。

應該根據價值體系設計自上而下的監控系統，比如業務邏輯》應用程序》操作系統。

3：不夠準確的監控

4：不頻繁的監控

頻繁的監控能夠：

• 識別故障和異常
• 提供更細顆粒度的數據
• 滿足響應時間預期，你總不希望用戶提出故障吧

盡量保存長時間的監控數據，做出長期的趨勢圖。

5：缺少自動化和自服務

監控系統沒做好的原因可能是很難實現，比如開發人員去做監控就很難，另外不成熟的監控系統可能需要手動維護，導致監控系統本身出現問題。

所以好的監控系統：

• 全局視角，從業務層依次展開監控
• 協助故障診斷
• 基礎設施，是開發人員的信息源頭
• 內置于應用程序設計、開發和部署的生命周期中。

監控機制

1：探針和內省

內省將事件、日志和指標發送到監控工具。而探針是查詢應用程序的外部特征，比如端口是否開啟。

2：拉取和推送

是將數據發完監控系統，還是監控系統主動拉取數據

3：監控數據的類型

數據主要有兩種形式：

(1)指標，比如promethous就是典型的事件序列數據存儲，用于應用程序度量的狀態。

(2)日志，日志數據量大，一般是文本的事件，它們對于故障診斷最有用，比如ELK比較擅長日志收集和管理。

監控服務層級

來自于Google的經驗，自上而下：

• 產品設計
• 軟件開發
• 容量規劃
• 測試和發布
• 事后總結/問題根源分析
• 應急事件處理
• 監控