一千萬個為什麽

搜索

監控清單 - 我應該監控哪些事項?



我們正在為我們的應用構建一個(基於Zabbix的)監控系統; hovewer,我在定義要監視的內容時遇到困難?

到目前為止,我已經提出了以下幾個大類:

  • hardware data: cpu, ram, swap, etc.
  • middleware data: perfomance/health for MySQL instantces, Tomcat instances, JVMs, etc.
  • logical or application data: the current status/health of the system, e.g. number of active users, page request, etc.
  • kpi data: data for business, e.g. user registration over time.
  • dashboard: quick overview of the system (e.g. microservices are running or not).

是否有其他基本類別需要監測?還是有另一個類別系統可以使用?

UPDATE: the purpose of the monitoring is

  • 查看系統是否正常工作(在高級別,例如沒有服務停機等情況下 - 很像煙霧測試)
  • 如果有任何指標,請參閱系統可能崩潰(例如,歷史數據預測我們將耗盡磁盤空間)
  • 如果發生這些情況,請向適當的員工發送警告(例如通過電子郵件)

UPDATE: the complexity of our system does not demand an extra application for reporting (e.g. monitoring KPIs); also, we are running in local/local cloud infrastructure, so the cost of the application is not (that)relevant - but it might be someday :-)

轉載註明原文: 監控清單 - 我應該監控哪些事項?

一共有 3 個回答:

I like this video: GOTO 2016 • Monitoring Microservices • Tom Wilkie

enter image description here

其中一個關鍵的想法(至少對我來說)是實現 host 監視和 application 監視之間的區別。基本上,主機監控告訴你現在 是致命錯誤,但應用程序監控應該能夠通過檢測更高的錯誤率來預測問題,或者請求需要更長的時間,在你的用戶註意到它們之前修復問題

(我不以任何方式隸屬於weaveworks或goto會議,我只是喜歡內容,並認為有一些有趣的想法。使用downvote按鈕讓我知道這個答案不好:))

這很大程度上取決於您的基礎設施情況。如果您正在進行自動縮放,則個別實例的健康狀況通常是無關緊要的。重要的指標是總成本和每單位工作成本(例如,每個請求)。就我個人而言,如果我可以避免它,我不喜歡監視單個實例狀態 - 我試圖更多地關註更廣泛的服務級別和應用程序級別度量標準:

  • 整體每次服務正常運行時間(至少一個實例健康並能夠立即響應新請求的時間百分比)
  • 整體最終用戶正常運行時間(用戶認為該產品可用的時間百分比 - 如果某些核心服務停機,這可能是面向用戶的停機時間,但較少使用的服務或後臺工作人員可能不會)
  • 每項服務的第95個百分點響應時間
  • 消息隊列長度和每個隊列的凈隊列增長量
  • 消費者每隊列數
  • 每個隊列的平均完成時間(不僅僅是隊列中的時間,而是排隊等待消息完成工作的時間)
  • 每項服務的錯誤率
  • 每項服務的單位工作成本
  • 對於每個服務器角色,平均CPU利用率與平均內存利用率的比率是多少?這對於確定我們是否縮小比例非常有用 - 如果CPU使用率為70%但內存為20%,則實例內存太多,反之亦然。
  • 峰值CPU /內存利用率相同
  • 交付部署時間

您列出的一些指標(例如用戶註冊時長,對我而言)不屬於像Zabbix這樣的基礎架構監視系統。有什麽人看著Zabbing要做10%的註冊下降?沒有。這是業務報告數據,應該通過報告數據庫向任何需要它的人提供,可能會在不錯的儀表板中呈現,因為尖尖的老板喜歡儀表板。

對於任何給定的節點,有4個基本資源可用於監視以下項目:

  • CPU
    • Total
    • Per-core
  • Storage
    • Free space
    • Free inodes
    • Throughput
    • Backups
  • Memory
    • Free
    • Swap
    • Buffers
    • Cache
  • Network
    • Latency
    • Throughput
    • Jitter

這四個基本資源將為您的應用程序或應用程序的每一層提供服務。這將根據您的環境設計為多達5層,並且您將希望在每個層監視它們。這可能看起來像:

Application Stack

這可能會根據環境的架構而變化。例如,如果您將所有數據都從NFS掛載運行,那麽存儲層將位於計算旁邊而不是其後面。如果您有一個工作站連接到的基於C ++的應用程序,則可能沒有前端層。如果您的應用程序使用平面文件,則可能沒有數據庫層。如果您不使用虛擬機或容器並使用本地存儲,則可能沒有計算和存儲層。你會想要在每一層監控上述4個基本資源。

這代表了供應商,軟件和硬件可以提供的基本監控。在每個層面覆蓋這四個基本資源應該是你的第一個目標。一旦達到100%的覆蓋率,您可以額外在應用程序中建立鉤子來報告額外的健康狀態,但就其本質而言,這些通常會建立為對停機的反應,您將不得不與內部開發人員一起構建這些類型的鉤子。

監測這4個基本資源應該可以發現導致中斷的問題的80%,然後你就可以開始研究其余的20%。