監控系統 Monitoring System

Why Monitoring?

以往 AInimal 軟體出現問題，往往是要等到軟體上線一段時間後，使用者在使用上遇到問題時才向我們回報，這時我們才會開始處理。若是有個自動化的流程可以檢查生產環境是否正常的話，就可以更早的發現問題。

而使用監控(Monitoring)就可以在服務上線之後，幫助我們確認服務是否正常，並且在需要的時候主動通知相關人員，避免我們是在錯誤發生一段時間之後才發現，爭取更多修復的時間。

Goal

好的監控系統能讓我們更輕易地看見我們系統運作的全貌，像是每個服務的狀態或是 server 硬體系統使用狀況、網路狀況，並且能將 log 集中以及通報，監控系統甚至可以預測哪裡運作需要注意、哪裡異常了，讓我們在處理問題時可以更有效率。

Golden Triangle in observability

Observability 是一個概念, 字面上可以簡單的解讀為"透過系統外部所揭露資訊的觀察，能有效的掌握到系統內部的運作狀態"，也就是說，讓系統中的數據可以被取得、可以被觀察，且因為有這樣的能力，才有辦法做 Monitoring

在使用一些 monitor 工具讓本來很不容易取得的資訊，能更容易的被觀察、分析、監控之前，我們要先來了解我們需要取得哪些重要的數據，這時就不得不提到一下 Observability 的金三角:

指標 Metrics

• 一組描述過程或活動的數據
• 隨時間變化的時間序列數據
• 可聚合的 K-V 數據
• 可以被壓縮、存儲、處理和檢索

Metrics 是以數字化的方式來有效率的解讀系統運作狀態的重要資訊，舉凡 CPU loading, Memory, Disk I/O, Disk free space, Network bandwidth, DB metrics, ... 等各種數字化的指標資訊，透過這些指標能做到最基本的異常的判斷，而這些 Metrics 也會是資料量極多的資訊，如何更有效的保留這些資料也會是管理上的重點。

日誌 Logs

Logs 紀錄, 描述一些離散(不連續的)事件或者是數據，如果 metrics 可以告訴我們系統或應用程式出現問題，那麼 logs 可以告訴我們為什麼會出現問題。關於 log 的收集現在也有很多方法，比如：filebeat, fluented, loki 等。

蹤跡 Traces

• 通常是記錄應用程式操作的數據
• 一次 request 的完整生命週期
• 分散式系統中一次請求經歷過多個服務產生操作的數據（Spans）

一個 request 在系統處理時，經過了哪些環節、哪些子系統、當中做了什麼事、在哪個地方會產生效能的瓶頸、在哪個服務元件之中有發生異常，能夠在複雜的系統架構中協助開發維運的人員一目瞭然的掌握 request 運作的細節。

三者的關係:

儲存容量的大小: 因為 Logging 往往紀錄很多請求資訊,參數,執行時間等等的, 內容跟數量暴多。 但是 Metrics 通常在意的只有過去幾小時內的資料, 更久之前的不是被壓縮就是被刪除了。

四個黃金訊號 (Four Golden Signals)

那麼，有哪些重要的指標(metrics)是我們應該要監控呢，在 Google 的 SRE (Site Reliability Engineering) 的書裡面，提出了「四個黃金訊號」：

延遲 Latency

延遲表示處理某個請求所花的時間，這項指標會直接的影響使用者的體驗，畢竟我們都不喜歡等待。

流量 Traffic

流量通常直接代表系統承受了多大的壓力，以一個網路服務來說，它可能是單位時間的 HTTP 請求數量。

錯誤 Errors

服務產生錯誤的比例，而錯誤又會被分類為顯示錯誤，例如一個 HTTP 500 的回覆；或是隱式的錯誤，例如 HTTP 200 成功但內容部分錯誤的回覆。

飽和度 Saturation

飽和度直接地指出了服務現在有多「滿」，通常會是 CPU、記憶體或是硬碟等用量資訊，通常以百分比表示

監控工具

系統監控:

• Prometheus

Logs:

• Loki: 主要核心服務， 儲存日誌及索引
• Promtail : 蒐集日誌 Agent ，並發送至 Loki

資料圖形化:

• Grafana