前言 欸，監控比談戀愛還難懂？

老實說，第一次聽到 Monitoring 跟 Observability，我的反應跟剛分手時一樣：「蛤？不是都差不多意思嗎？」

結果我去 Google，一堆文章不是在講 metrics、tracing、logging，就是貼幾張雲端架構圖，玄到跟算命一樣。
就好比占卜師對著你說：「你這段感情業障太重，容易斷線。」
呃，對不起，我只是想知道到底是 Redis 掛了還是我程式寫太爛啦。

而我們工程師的日常，就像一個 失戀卻還要上班的勇者：系統會炸，老闆會催，客戶會抱怨，但你還是得打開 Grafana 假裝「一切盡在掌握中」。

所以這系列文章的玩法很簡單：

概念 → 架構 → 工具 → 視覺化 → 告警

就像 RPG 一樣，解鎖技能一路打怪。

0.「監控無所遁形！從伺服器到使用者，你的系統都在被監視！」

想像一下，你去 7-11，頭頂那顆攝影機默默錄你深夜買泡麵的樣子。
監控，就是那顆攝影機。

在 IT 系統裡，Monitoring 的重點就是：

• 伺服器快掛了？
• API 回應慢到像我早上起床一樣？
• 使用者是不是快被卡到退貨？

它就是那種：平常你根本不理它，一出事它就跳出來**「欸嘿，我早就知道了」** 的東西。

比方說：

• Performance Monitoring：應用程式有沒有快掛掉。
• Infrastructure Monitoring：伺服器 CPU/Memory 會不會突然衝到 100%，像跑馬拉松跑到一半直接昏倒。
• User Monitoring：使用者體驗是不是卡到像打開 IE。

簡單來說：監控不會讓你變快樂，但它至少能提早告訴你「悲劇快要發生了」。
就像交往中那種「感覺她最近很冷淡」的預警指標一樣。

1. Monitoring Levels：系統比你還需要心理醫生

來，給各位一張監控層級小抄：

1. Application Level
   • 看應用程式跑得快不快。查 DB 像聊天，一開始秒回，後來已讀不回。
   • 例如查詢花多久、快取 hit/miss。
2. Infrastructure Level
   • CPU、Memory、Disk、Network。月底沒錢吃飯的焦慮，伺服器也有。
3. Service Provider Level
   • 外部 API、雲端服務。外包就像朋友的感情，永遠不可控。
4. User Level
   • 使用者體驗：「這網頁到底要跑幾秒？」老闆只在乎這個。
5. Full-Stack Observability
   • 把所有層一起看，透明到像被另一半裝 GPS。

1. **Application Level**：監控應用程式的效能與指標，如資料庫查詢時間、快取狀態。
2. **Infrastructure Level**：伺服器負載、記憶體、磁碟、網路效率。
3. **Service Provider Level**：第三方提供的可用性、資源使用統計。
4. **User Level**：使用者體驗與滿意度指標。
5. **Full-Stack Observability**：即時監控每個元件，提供整體系統可見性。

指標（Metrics）

指標是量化系統表現的數據：

• OS Metrics：CPU、記憶體、磁碟、跑了幾個 process
• Application Metrics：平均回應時間、記憶體使用、process 數量
• User Metrics：頁面加載時間、首次渲染、使用者滿意度、用戶掉頭率。

重點：

• 量化。
• 可視化。
• 方便事後檢討你為什麼會爆肝。

為什麼需要監控？

• 避免伺服器炸掉，錢跟名聲一起損失
• 評估資源消耗，合理調整伺服器
• 提前發現問題，別等它炸了才手忙腳亂

Checkpoint：

• 主動回應問題
• 避免停機
• 保持使用者滿意
• 提高資源配置效率

2. Prometheus 與 Grafana：止痛藥＋咖啡

來到大家最愛的 combo。
Prometheus 是收集數據的，Grafana 是把數據畫成圖的。
就像止痛藥＋咖啡：救不了命，但能讓你撐到天亮。

Prometheus 架構與組件

• Server：抓取與儲存時間序列資料
• Client Libraries：幫程式碼吐 metrics。
• Pushgateway：支援短期任務推送指標
• Exporters：把第三方系統（MySQL、Redis）翻譯成 Prometheus 語言。
• Alertmanager：系統爆炸時，傳 Slack/Email 把你吵醒。

Metric Types

• Counter：只能加不能減，像你的年紀。
• Gauge：可加可減，像體重（但通常只加）。
• Histogram：分布，像「你平均多久被叫去開會」。
• Summary：統計摘要，方便事後檢討為什麼 bug 那麼多。

3. PromQL（Prometheus Query Language）

PromQL 是 Prometheus 的查詢語言。
語法雖然直白，但寫久了會懷疑人生。

rate(http_requests_total[5m])

意思是：過去五分鐘的 HTTP 請求速率。
但你心裡真正想問的是：「為什麼使用者要在半夜三點狂打 API？」

另一個範例：

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

意思是：95% 的請求延遲是多少。
但對我來說，這就像問自己：「95% 的人生是不是都在 debug？」

4. Observability vs Monitoring：健檢報告 vs 心理醫生

Monitoring ≠ Observability。

講白了：

• Monitoring 就像健檢報告，會告訴你膽固醇太高。
• Observability 則是心理醫生，會問你「最近是不是壓力太大？」

兩者缺一不可。光有 Monitoring，你只會知道「系統炸了」。
但有 Observability，你才能知道「是 Redis 爆炸還是 DBA 半夜不小心 drop table」。

5. Observability 三劍客

1. Metrics：數字，延遲、成功率。
2. Tracing：流程全程追蹤，像你從早到晚被監視。
3. Alert / Log：即時吐槽，幫你定位未知問題。

三者合體，才是真的「全面監控」。
只帶一個去副本？必滅。

簡單來說，Metrics 量化、Tracing 跟蹤流程、Alert / Log 告訴你系統哪裡出問題。

6. 我踩過的坑（實務經驗分享）

工具選型

• Prometheus：收集系統與應用 Metrics
• Grafana：畫圖。
• AlertManager：發警報。
• Langfuse（選配）：專門看 LLM。

Metrics 收集策略

• API 路由：請求數（Counter）、延遲（Histogram）。
• Redis / DB：GET/SET 次數、查詢延遲、錯誤率
• LLM 調用：延遲、成功率、異常次數（可用 Langfuse 擴充細節觀測）

Tracing 策略

• RAG pipeline：從 query rewrite → hybrid search → rerank → prompt → LLM response。
• Background Tasks（Ingest / Email / Notes Service）流程追蹤，方便分析瓶頸

告警設計

• 服務 down：instance 掛了。
• 資源爆炸：CPU、RAM 爆滿。
• API 過頻：某 endpoint 被狂打。

7. 架構圖示意

上圖示意整個平台與 Observability 架構關係，Metrics / Tracing 由 Prometheus 收集，Grafana 可視化，AlertManager 負責告警。

8. 小結:監控是健檢，觀測是心理諮商

總結一下：

• Monitoring：告訴你系統炸了。
• Observability：告訴你為什麼炸。

沒有 Monitoring，你會突然被老闆半夜叫起來。
沒有 Observability，你會 debug 到懷疑人生。

所以記住：
系統健康管理，不是工具，而是你能不能少掉髮的關鍵。

👉 好啦，這篇寫到這裡，字數也夠讓我懷疑是不是該收個顧問費了。
反正，下次系統炸掉的時候，記得先打開 dashboard，不要先打開冰箱找啤酒。
（雖然我懂，通常兩個會同時打開。）