503 錯誤，log 只告訴你「回了 503」。真正的原因，藏在 Prometheus 裡。

Log 不是萬能的

你有沒有遇過這種情況？

收到 503 告警。打開 OpenSearch 查 log。

找到了。log 告訴你：response status 503。

然後呢？

沒有 stack trace。
沒有 error message。
就只有一行「回了 503」。

你知道壞了，但 log 不告訴你為什麼。

還有一種更慘的。

你去查 log，OpenSearch 上一片空白。

不是沒出錯。是 log 根本送不出來。

這兩種情況，靠 log 都沒用。

你需要的是另一個維度的資料 — Metrics 和基礎設施監控。

但問題來了。

你的監控工具不只一個。

Prometheus 看 application 指標。
Icinga2 看基礎設施。
外部監控（Site24x7、PagerDuty 等）看可用性。

三個 dashboard，切來切去。

這篇用兩個真實案例，展示怎麼透過 MCP（Model Context Protocol，讓 AI 直接呼叫外部工具的標準協定），補上 log 的盲區。

一個 AI 對話，串起三個監控工具。

案例 1：Payment Service 503 — 三個工具找一個真相

故事

某天中午 12:09，告警響了。

Payment Service 回了一批 503。

身為 SRE，你開始調查。

Step 1：確認問題 — Icinga2 + Site24x7

第一件事：確認問題是真的，影響多大。

我直接問 AI：

「Payment Service 最近有沒有 alert？外部可用性有沒有下降？」

AI 同時查了兩個工具：

• Icinga2：回報有 critical alert，Payment Service 相關的服務告警中
• Site24x7：外部可用性從 99.9% 掉到 94.5%，用戶已經受到影響

Icinga2: Payment Service - CRITICAL
  ├ payment-api health check: CRITICAL since 12:09
  └ payment-worker: OK

Site24x7: Payment Service endpoint
  ├ Availability: 94.5% (normally 99.9%)
  └ Response time: 2.3s → 8.7s

1 分鐘，確認兩件事：問題是真的，用戶有感。

如果手動做呢？

開 Icinga Web → 篩選 Payment Service → 看告警狀態。
再開 Site24x7 dashboard → 找到對應的 monitor → 看可用性數據。

兩個畫面切來切去，光是確認「問題存不存在」就要 3-5 分鐘。

Step 2：查 Log — 碰壁

確認問題後，習慣性去查 log。

OpenSearch 裡找到了 503 的 response log。

但就只有這樣：

12:09:35 [INFO] POST /api/payment - 503 - 0.02s
12:09:36 [INFO] POST /api/payment - 503 - 0.01s
12:09:37 [INFO] POST /api/payment - 200 - 0.45s
12:09:37 [INFO] POST /api/payment - 503 - 0.02s

沒有 error message。
沒有 stack trace。
沒有任何線索告訴你「為什麼是 503」。

Log 能告訴你「結果」，但不能告訴你「原因」。

知道壞了，但不知道為什麼。

Step 3：Prometheus — 找到真相

Log 碰壁了。換個方向。

我問 AI：

「查一下 12:09 附近 Payment Service 的 pod 有沒有異常。」

AI 去查 Prometheus，回來的東西讓一切串起來了：

kube_pod_status_ready:
  payment-api-7b8d9f-abc12  Ready since 12:08:15 ✓
  payment-api-7b8d9f-def34  Ready since 12:08:15 ✓
  payment-api-7b8d9f-ghi56  Created 12:09:31, Ready 12:09:52

kube_hpa_status_current_replicas:
  12:09:00 → 2 replicas
  12:09:31 → 3 replicas (scaling up)

container_cpu_usage_seconds_total:
  payment-api-ghi56: CPU spike at 12:09:31-12:09:52 (cold start)

看到了嗎？

HPA（Horizontal Pod Autoscaler，自動水平擴展）在 12:09:31 啟動了一個新 pod。

但這個 pod 在 12:09:52 才 Ready。

中間有 21 秒，pod 還沒準備好就收到了流量。

503 就是這 21 秒產生的。

根因方向出來了：pod 還沒 ready 就收到流量，health probe 配置有問題。

如果手動查 Prometheus 呢？

開 Grafana → 找到對的 dashboard → 切到 pod 狀態的 panel。

然後手寫 PromQL（Prometheus 的查詢語言）查 kube_pod_status_ready，再比對時間軸。

你得先知道要查什麼 metric，還要會寫 PromQL。

10 分鐘起跳。

用 AI？一句話，2 分鐘。

三個工具，三個問題

回頭看，三個工具各回答了一個不同的問題：

一個 AI 對話串起三個維度，不用再切 dashboard。

案例 2：Auth Service 間歇性異常 — Icinga2 當主角

故事

Support 反應：「登入有時候會失敗，但不是每次。」

這種間歇性問題最難查。

不是每次都壞，重現不了，但用戶確實在抱怨。

Log 查不到，因為 log 根本沒有

第一步還是查 log。

打開 OpenSearch，搜 Auth Service 的 error log。

什麼都沒有。

不是沒有錯誤。

是那台出問題的機器，log 根本送不出來。

EC2 主機資源耗盡，連 log agent 都跑不動了。

OpenSearch 上一片空白，不是因為沒問題 — 是因為問題太嚴重，連 log 都發不出去。

Prometheus 也看不到

你可能想：那查 Prometheus？

但 Auth Service 跑在 EC2 上，不是 K8s。

Prometheus 監控的是 K8s 層的 pod 和 container。

EC2 主機的 disk 和 CPU？沒有額外設定的話，Prometheus 看不到。

Icinga2 找到了

我問 AI：「Auth Service 相關的主機有沒有異常？」

Icinga2 回來了：

Host: auth-service-host-02
  ├ DISK: CRITICAL - /dev/sda1 100% used
  ├ CPU: WARNING - 98.2% usage
  └ Memory: WARNING - 93.1% usage

某台 EC2 主機 disk full、CPU 100%。

而這台主機，剛好跑的是登入 API。

Auth Service 的 ALB（Application Load Balancer，應用層負載均衡器）target group 有 3 台機器。

只有這台不穩。

但 ALB 的 health check 不夠靈敏，沒把它踢掉，還是繼續送流量過去。

3 次 request 有 1 次打到這台 → 失敗。
其他 2 次打到正常的機器 → 成功。

「有時候會失敗，但不是每次」— 完美解釋了。

清理資源、擴容之後，問題消失。Support 確認恢復正常。

洞察：Log 的結構性盲區

這個案例最重要的一點：

當問題出在基礎設施本身，log 不只是「查不到原因」— 是根本送不出來。

Prometheus 看 K8s 層，看不到 EC2 主機的 disk。

OpenSearch 收不到 log，因為機器已經癱了。

只有 Icinga2 這種基礎設施監控，才能抓到這類問題。

這就是為什麼你需要不同層次的監控工具 — 它們看的東西不一樣。

完整 Incident 工作流

到這裡，整個系列的工具篇三部曲（MCP 三部曲）已經完成了。

把它們串起來：

📢 告警觸發
   ↓
🔍 搜歷史：Confluence 查過往案例（#04）
   ↓
📊 查監控：Icinga2 / Site24x7 / Prometheus（本篇）
   ↓
📋 查 Log：OpenSearch 查錯誤日誌（#03）
   ↓
🔬 分析根因：AI 協助判斷（#02）
   ↓
🎫 建 Ticket：批量建立 Jira action items（#04）

重點是：監控和 log 是交叉使用的，不是線性的。

Metrics 找到方向 → Log 驗證細節 → Metrics 確認影響範圍。

實際調查的時候，你會在工具之間來回跳。

用 AI 的好處是：不管你跳到哪個工具，都是同一個對話。

不用切視窗、不用重新登入、不用重新建立查詢條件。

時間對比

上一篇缺了「查監控」這一行。

現在補上了。工具篇完整了。

安裝 Monitoring MCP

這篇用了三個 Monitoring MCP。

有趣的是，三個安裝方式都不一樣 — Docker、Python venv、proxy。

這也反映了 MCP 生態的多樣性。

不同的 MCP server 有不同的實作方式。但對你來說，設定完就是一樣的用法。

以下是 mcp.json 的設定範例:
(以下為範例，詳細需要參考icinga2 mcp 官方、Site24x7 mcp zoho官方)

{
  "prometheus-mcp": {
    "command": "docker",
    "args": [
      "run", "-i", "--rm",
      "-e", "PROMETHEUS_URL",
      "ghcr.io/pab1it0/prometheus-mcp-server:latest"
    ],
    "env": {
      "PROMETHEUS_URL": "http://your-prometheus:9090"
    }
  },
  "icinga-mcp": {
    "command": "/path/to/icinga-mcp/venv/bin/python",
    "args": ["-m", "icinga_mcp_server"],
    "env": {
      "ICINGA2_API_URL": "https://your-icinga2:5665",
      "ICINGA2_API_USER": "your-user",
      "ICINGA2_API_PASSWORD": "your-password"
    }
  },
  "site24x7-mcp": {
    "command": "/path/to/site24x7-mcp/venv/bin/python",
    "args": ["proxy.py"],
    "env": {
      "ZOHO_CLIENT_ID": "your-client-id",
      "ZOHO_CLIENT_SECRET": "your-client-secret",
      "ZOHO_REFRESH_TOKEN": "your-refresh-token"
    }
  }
}

把 URL、帳號、token 換成你自己的就好。

安全提醒

• Prometheus MCP 通常是唯讀的，風險較低
• Icinga2 / Site24x7 注意 token 管理 — 不要 commit 到 git，定期更換
• 跟上一篇一樣的原則：先用自己帳號測試，穩定後再考慮 service account

結語

Log 不是萬能的。

有些問題，log 只告訴你結果。
有些問題，log 根本送不出來。

這時候，你需要 Metrics 和基礎設施監控來補位。

三個 Monitoring MCP 做的事情很簡單：

讓你不用再切換 dashboard。

Prometheus 查 pod 狀態？一句話。
Icinga2 查主機告警？一句話。
Site24x7 查外部可用性？也是一句話。

而且是在同一個對話裡，跟你的 log 查詢、歷史搜尋串在一起。

到這裡，工具篇三部曲完結了：

• #03 OpenSearch MCP — 查 log
• #04 Atlassian MCP — 搜歷史、建 ticket
• #05 Monitoring MCP — 查監控

工具都齊了。

下一篇，我們要把這些工具全部串起來：從調查到報告，一條龍。

一次真實的 Incident 調查，從收到告警到產出 RCA 報告，看 AI 怎麼幫你走完全程。

如果你試了 Monitoring MCP，歡迎留言分享你的使用經驗。