為什麼從 Metrics 談起#
監控（Monitoring）是橫跨多個世代、用來確保系統穩定運作的維運技術，而 Metrics 一直都是它的核心關注。對 Observability 來說，Metrics 同樣是不可或缺的基石。
特別是在實踐 SRE（Site Reliability Engineering）時，常見的概念都圍繞著 Metrics 在打轉：
- SLI（Service-Level Indicator）：服務水準指標。
- SLO（Service-Level Objective）：服務水準目標。
- SLA（Service-Level Agreement）：服務水準協議。
這些概念協助我們定義「什麼是重要的指標」、「指標要達到什麼水準才算合格」、「怎麼對指標做出承諾」。彼得・杜拉克的名言「If you can’t measure it, you can’t manage it」放在這裡再貼切不過。
一個指標包含哪些要素#
以「量體溫」這個動作為例，思考指標通常需要包含哪些元素：
- 指標名稱：例如「體溫」。
- 數值：實際量到的數字。
- 時間：什麼時候量的；同一天可能會多次測量。
- 補充資訊：被測量者的姓名、組別等屬性。
把多次量測串起來，就能得到「跨時間」的體溫變化。這種隨時間累積的資料就是時間序列資料（Time Series Data）。
時間序列資料通常會存放在專為它設計的時序資料庫（Time Series Database, TSDB）中。相較於一般資料庫，TSDB 針對寫入與時間範圍查詢進行了優化，因為這類資料幾乎不會被修改，主要的存取行為就是「寫入」與「依時間範圍讀取」。
Prometheus Metrics 的四個要素#
本系列在討論 Metrics 時主要以 Prometheus Metrics 為例。一筆 Prometheus 指標由四個部分組成：
- 指標名稱：說明指標內容，常見會把單位帶進名稱中，例如
process_time、memory_usage_byte。 - 時間：以 Unix timestamp 表示，單位為毫秒。
- 數值：以 Float64 表示。
- 補充資訊：多組 Key-Value Pair Label，例如
os=ubuntu、ip=1.1.1.1。
應用程式可透過 Prometheus Client Library 自行生成 Metrics；對於沒辦法直接埋點的服務或機器，可以使用對應的 Exporter 採集後轉成 Prometheus 格式。
收集則分為 Pull Model（Prometheus 定期抓取 HTTP Endpoint）與 Push Model（透過 Pushgateway 中介），詳細運作與儲存、查詢部分留到下一章 Prometheus 中說明。
小結#
本章只是把 Metrics 與 Prometheus 的整體輪廓拉出來。後續章節會逐一深入：
- Prometheus 本身的設計與 PromQL。
- 各式 Exporter 怎麼補齊「沒辦法自己埋點」的監控對象。
- Mimir / Cortex / Thanos 等長期儲存方案。
- 兩個在 Metrics 領域深耕已久的工具：StatsD 與 Zabbix。
原文出處#
- 原書/iThome：https://ithelp.ithome.com.tw/articles/10321021