查 log 的終點從來不是那一行 JSON，而是一段 Manager、RD 都看得懂的話

你有沒有被 Log 淹沒過？

你平常怎麼查Log？

打開 OpenSearch Dashboard，查關鍵字，跑查詢，看結果，然後再換下一個 index 查。

聽起來很正常。

但問題是，每次查詢都要：

❌ 調整時間、篩選欄位
❌ 時間範圍格式總是寫錯，查文檔又花 5 分鐘
❌ Index 名稱記不住 — api-gateway-2025.01.23 還是 api-gateway-logs-prod-2025-01？
❌ 好不容易查到了，結果有 500 筆，不知道哪些才是重要的

光是寫 query 就要 5 分鐘。
找到有用的資訊？可能要 15-20 分鐘。

而且這還只是一個 index。

現在的環境，滿滿是 pod、滿滿是 index。
要用 correlation-id 跨 index 追蹤？
手動複製貼上、切換 index、重新查詢，一來一回又是 10 分鐘。

我當時有個想法：「要不試試看AI?」

真正的痛點：不是「查不到」，是「看不完」

其實對 SRE 來說，Query 難寫只是第一層痛苦。

更深一層的問題是：log 量太大，你根本看不完。

想像一下這個場景：

凌晨收到告警，你查了過去 1 小時的 error log。
結果回來 2,000 筆。

你開始篩 5xx。
看第一頁，嗯，500。
第二頁， 502。
第三頁， 503。
滑到第五頁，開始眼花。

然後你懷疑：「這裡面到底有沒有真正的 500 錯誤？」

你知道答案就在這 2,000 筆 log 裡面。
但你的眼睛和大腦，已經被資訊淹沒了。

這就是我後來開始用 AI 查 log 的真正原因。

不只是因為它能幫我「寫 query」。
更重要的是，它能幫我「讀 log」，然後給我一個文字的解釋。

2,000 筆 log 丟給它，它可以：

• 自動分類錯誤類型（404 佔 85%、500 佔 10%、503 佔 5%）
• 找出時間上的異常模式（「22:05 開始突然出現大量 500」）
• 歸納受影響的 endpoint（「主要集中在 /api/user/*」）
• 過濾掉雜訊，只給你真正需要關注的那 20 筆

人腦擅長判斷，但不擅長從 2,000 筆資料中大海撈針。
AI 剛好相反。

但我後來想得更清楚了。

查 log 的目的，從來就不是「找到那一行出問題的 log」。

你查完之後要幹嘛？

回 Slack 跟 manager 說「目前狀況是什麼」。
在 Incident channel 貼「影響範圍和用戶流程」。
讓 RD 知道「問題出在哪一段」。

你真正需要的產出，是一段人能讀懂的文字。

不是 JSON，不是 raw log，不是 query 結果。
是「目前問題是 X，影響了 Y 個用戶，原因是 Z」這種話。

以前的流程是：OpenSearch → 你的腦袋 → 翻譯成文字 → 貼到 Slack。
現在的流程是：OpenSearch → AI → 直接產出文字。

AI 不只是幫你查 log。它幫你把 log 翻譯成人話。

用 AI 之後

現在我查 log 是這樣的：

「查詢過去 1 小時 User Service 的 5xx 錯誤」

AI 自動幫我：

• 選擇正確的 index
• 產生 Query DSL
• 執行查詢
• 分析結果，告訴我重點

10-20 秒搞定。

而且不只是原始數據。
它會直接告訴我：「156 筆錯誤，92% 是 504 timeout，主要發生在 22:05-22:15，集中在 /api/user/profile。」

它不只是幫你查，它幫你「讀」

舉個真實的例子。

上週有個用戶回報「註冊流程卡住」。我請 AI 幫我查這個用戶的 log。

它不是丟一堆 JSON 給我。
它直接整理出一條時間線：

14:32:07  App 啟動，進入登入頁
14:32:18  選擇 Email 註冊
14:32:45  填寫表單，送出
14:32:46  驗證信寄出
  ～4 分鐘空白（用戶等信 / 找不到信）
14:36:52  改用 Google SSO 登入
14:37:03  Google 授權成功
14:37:15  同意服務條款
14:37:28  建立個人檔案
14:37:31  註冊完成

一看就懂：用戶先試了 Email 註冊，等驗證信等了 4 分鐘沒收到，改用 Google SSO 才完成。

這段分析，AI 花了 20 秒。
如果我自己看原始 log？大概要翻 30-40 筆 JSON，花 10 分鐘拼湊出同樣的結論。

而且重點是：這段時間線，我可以直接貼到 Slack 給 manager 看。
不用再自己翻譯一次。Manager 不需要懂 JSON，RD 不需要自己去翻 OpenSearch。
一段文字，所有人都看得懂。

以前 SRE 查完 log 還要花時間寫摘要、翻譯成非技術人員能理解的語言。
現在 AI 直接幫你把散落的 log 組裝成「故事」— 而且是 Manager、RD、QA 都能讀懂的那種。

從「查 log」變成「問問題」，從「看 JSON」變成「讀報告」。

接下來，我分享兩種做法。

兩種方法，各有適合的場景

我目前用兩種方式讓 AI 查 OpenSearch：

方法 1：Curl 方式

讓 Claude Code 直接執行 curl 指令查詢 OpenSearch。

✅ 不需要安裝任何東西
✅ 設定超簡單（只要有 endpoint 和 API Key）
✅ 彈性高，想查什麼就查什麼
✅ 5 分鐘就能開始用

❌ 每次要提供 endpoint 和認證資訊
❌ Claude 需要自己組 Query DSL（偶爾需要檢查）

方法 2：MCP 方式

MCP（Model Context Protocol）是讓 AI 直接呼叫外部工具的標準協定。
透過 MCP Server 整合 OpenSearch，Claude 自動呼叫。

✅ 設定一次，永久使用
✅ AI 自動選擇 index
✅ 完全自動化
✅ 適合團隊共用

❌ 需要安裝 MCP Server
❌ 設定比較花時間（大約 30 分鐘）

我的使用比例

老實說，我日常調查 90% 的時候用 MCP。

用了一陣子之後才發現：MCP 一旦設好，回不去了。

MCP 方式（90%）：

• 日常查詢，直接用自然語言問
• Incident 調查，一次串多個 index
• 不用管 JSON 轉義、proxy 設定
• 最重要的：省 context window，複雜調查不會查到一半就斷

Curl 方式（10%）：

• 需要匯出大量原始資料（MCP 有 size 100 上限）
• 需要 debug 完整 HTTP 交互

兩種都會用，但 MCP 是絕對主力。

想跟著做？用 OpenSearch Playground 練手

在進入正式設定之前，我推薦你先用 OpenSearch 官方的 Playground 練手。

不用裝任何東西、不用 API Key、不用自己的 OpenSearch。

打開 terminal，跑這兩行：

# Step 1: 取得匿名 session
curl -s -c /tmp/os_cookies.txt -L \
  "https://playground.opensearch.org/auth/anonymous?" -o /dev/null

# Step 2: 查所有 503 錯誤
curl -s -b /tmp/os_cookies.txt \
  -H "Content-Type: application/json" \
  -H "osd-xsrf: true" \
  "https://playground.opensearch.org/api/console/proxy?path=opensearch_dashboards_sample_data_logs/_search&method=GET" \
  -d '{"query": {"term": {"response": 503}}, "size": 3}'

你會拿到真實的 web server log，長這樣：

{
  "response": 503,
  "clientip": "120.49.143.213",
  "request": "/styles/main.css",
  "host": "cdn.opensearch-opensearch-opensearch.org",
  "message": "120.49.143.213 - - [2018-07-22T03:30:25.131Z] \"GET /styles/main.css_1 HTTP/1.1\" 503 0 ...",
  "tags": ["success", "login"],
  "geo": {"src": "CO", "dest": "DE"}
}

Playground 有三個 sample dataset：

其中 logs 最貼近 SRE 日常，裡面有 HTTP status code、request path、client IP、geo 位置。

試試看：用一行 curl 做 SRE 風格的分析

查 503 錯誤分佈在哪些 host：

curl -s -b /tmp/os_cookies.txt \
  -H "Content-Type: application/json" -H "osd-xsrf: true" \
  "https://playground.opensearch.org/api/console/proxy?path=opensearch_dashboards_sample_data_logs/_search&method=GET" \
  -d '{
    "size": 0,
    "query": {"term": {"response": 503}},
    "aggs": {"by_host": {"terms": {"field": "host.keyword"}}}
  }'

結果：

artifacts.opensearch.org  — 208 筆（47%）
www.opensearch.org        — 154 筆（35%）
cdn.opensearch-...org     —  67 筆（15%）
opensearch-...org         —  12 筆（ 3%）

441 筆 503 錯誤，將近一半集中在 artifacts.opensearch.org。

如果這是真實場景，你已經知道該先查哪台了。

這就是 AI 查 log 的起點 — 只是現在你還在手動跑 curl。
接下來教你怎麼讓 Claude 幫你做這些。

方法 1：Curl 方式（快速開始）

這是我推薦新手先試的方式。

你需要什麼

1. OpenSearch endpoint URL
2. API Key（或 AWS credentials）
3. Claude Code

就這三樣。

設定方式

推薦：用環境變數

# 在 terminal 中設定
export OPENSEARCH_ENDPOINT="https://your-opensearch-endpoint"
export OPENSEARCH_API_KEY="your-api-key"

或者更簡單：每次對話時直接提供

你：用這個 endpoint 查詢 OpenSearch：
endpoint: https://xxx
api_key: yyy
查過去 1 小時的 5xx 錯誤

Claude 會記住這次對話中的資訊。
下次查詢不用再給。

實際使用範例

範例 1：基本錯誤查詢

你說：
「查 OpenSearch api-gateway index，過去 1 小時 status_code >= 500 的 logs」

Claude 會產生並執行：

curl -X POST "$OPENSEARCH_ENDPOINT/api-gateway-*/_search" \
  -H "Authorization: ApiKey $OPENSEARCH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": {
      "bool": {
        "must": [
          {"range": {"@timestamp": {"gte": "now-1h"}}},
          {"range": {"status_code": {"gte": 500}}}
        ]
      }
    },
    "size": 100
  }'

然後告訴你：

• 找到 156 筆 5xx 錯誤
• 主要是 504 timeout（92%）
• 集中在 /api/user/profile 和 /api/user/settings
• 22:05 開始突然增加

注意：它不只是回傳原始 JSON。
它會分析結果，直接給你重點。

這就是 AI 「讀 log」的價值。

範例 2：Correlation-id 追蹤

你說：
「用 correlation-id: xyz-789，先查 api-gateway index，再查 user-service index」

Claude 會：

1. 先查 api-gateway-*，找到該請求的入口
2. 再查 user-service-*，用同樣的 correlation-id
3. 串聯完整路徑
4. 告訴你每個階段發生了什麼

以前手動做這件事，要 10-15 分鐘。
現在不到 1 分鐘。

範例 3：複雜條件查詢

你說：
「找出過去 2 小時，status_code = 500、response_time > 3s、endpoint 包含 /api/user 的 log」

Claude 會自動組合正確的 bool query。
你不用記 Query DSL 語法。

方法 2：MCP 方式（長期使用）

如果你每天都要查 log，MCP 方式會更順手。

為什麼需要 MCP？

Curl 方式很方便。

但如果你：

• 每天要查詢很多次
• 需要在 Claude Desktop 環境使用
• 希望完全自動化（不用每次提供 endpoint）

那 MCP 方式更適合。

設定一次，永久受益。

安裝 MCP Server

我用的是 Python 版的 opensearch-mcp-server-py，透過 uvx 執行（不需要手動裝套件）。

一行指令搞定：

claude mcp add-json "opensearch-mcp-server" \
'{
    "command": "uvx",
    "args": [
      "opensearch-mcp-server-py"
    ],
    "env": {
      "OPENSEARCH_URL": "https://your-opensearch-endpoint"
    }
}' --scope project

--scope project 表示只對當前專案生效。如果你想全域使用，改成 --scope user。

如果你用 Claude Desktop，也可以手動編輯設定檔：

Example: 
# macOS
~/Library/Application Support/Claude/claude_desktop_config.json

# Windows
%APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "opensearch-mcp-server": {
      "command": "uvx",
      "args": ["opensearch-mcp-server-py"],
      "env": {
        "OPENSEARCH_URL": "https://your-opensearch-endpoint"
      }
    }
  }
}

設定完成後：

1. 重新啟動 Claude Code 或 Claude Desktop
2. 確認有看到 opensearch 相關的工具

測試一下

開啟 Claude Desktop，試試：

• 「列出所有 OpenSearch indices」
• 「查詢過去 1 小時的 5xx 錯誤」
• 「用 correlation-id XXX 追蹤」

如果都能正常回應，設定就成功了。

實戰對比：同一個 5xx 調查，兩種方式的體感差異

這不是假設，是我實際跑過同一個 5xx 調查流程後的比較。

每次查詢的步驟差異

Context Window — 最大的隱藏差異

Context Window 是 AI 一次對話能「記住」的資訊量上限。用完了，AI 就會開始忘記前面的內容。

這是用了之後才發現最重要的一點。

一次 curl 查詢大約佔 3 倍的 context：JSON 檔、curl 指令、raw output 全部都會吃 context window。MCP 只需要 1 次 tool call。

在簡單查詢可能無感。
但在複雜 Incident 調查中，你可能連續查 10-15 次。

curl 查 10 次 ≈ MCP 查 30 次的 context 消耗。

Context 用完了，AI 就開始忘記前面的查詢結果。
在調查中途失去上下文，比什麼都痛苦。

並行查詢

MCP 的另一個隱藏優勢：多個查詢可以同時發出。

例如調查時需要同時確認欄位 mapping 和查錯誤分佈，MCP 可以兩個 tool call 並行。
curl 做不到 — 每個都是獨立的 Bash call，只能一個一個跑。

在多步驟調查中，這省下的時間是倍數級的。

MCP 的殺手級功能

用了 MCP 之後我才發現，有些事情 curl 根本不會想去做：

• LogPatternAnalysisTool — 自動辨識 log pattern、分群、找 outlier。手寫 curl aggregation 做不到這種分析
• DataDistributionTool — 自動偵測有用欄位、計算分布、兩個時段比對 divergence。等於影響評估自動化
• MsearchTool — 一次 call 同時查 access log + app log，不用跑兩次 curl
• IndexMappingTool — 一個 call 拿到完整 mapping，不用 curl + jq 慢慢撈

不是「省幾秒鐘」的問題。
是「以前根本不會做，現在自動幫你做」的差距。

我的結論

日常調查（90% 場景）→ MCP 明顯更有效率。
主要是省步驟 + 省 context window + 並行查詢。

Curl 保留作為 fallback：
跨 cluster 查詢、大量資料匯出、需要看完整 HTTP 交互的 debug 場景。

與第二篇案例的對應

還記得第二篇的 504 timeout 案例嗎？

當時的查詢：

• [22:17] 「收到 API Gateway 5xx 錯誤，幫我調查」
• [22:20] 「追蹤到 User Service」

如果用 MCP：
Claude 直接透過 SearchIndexTool 查詢，再用 MsearchTool 同時查 access log + app log，4 次 call 搞定。

如果用 Curl：
分別跑 curl 查 api-gateway、再查 user-service，至少 6 次 Bash 呼叫。

兩種都能做到。但 MCP 的流程更順、步驟更少。

常見問題

Q：查詢會很慢嗎？

速度取決於 OpenSearch 本身、查詢的時間範圍、index 大小。

優化建議：

• 限制時間範圍（先查 1 小時，不要一次查一整天）
• 用 size 限制回傳筆數
• 善用 index pattern 縮小範圍

Q：AI 分析 log 會不會漏掉重要資訊？

有可能，但比人眼漏掉的機率低很多。

我的做法是：

• 讓 AI 先做第一輪分析和過濾
• 如果結果不對勁，再自己看原始資料
• 重要的 Incident 會交叉驗證

AI 是助手，不是替代品。最終判斷還是你自己的。

怎麼選？一句話

新手：先用 Curl 感受 AI 查 log 的威力（5 分鐘上手），用一週後再花 30 分鐘設 MCP。
老手：直接上 MCP，把 Curl 留給 MCP 還沒接的叢集。

結語

Curl 方式：零門檻入門，5 分鐘就能開始用。
MCP 方式：設定一次，之後每次查詢都更快、更省事、功能更強。

我的真實體驗是：MCP 設好之後，90% 的調查都走 MCP。

不是因為 curl 不好。
而是 MCP 省步驟、省 context window、能並行查詢，再加上 pattern analysis、multi-search、auto distribution 這些 curl 根本做不到的功能。

重點不是用哪種方式。
重點是開始讓 AI 幫你查 log、讀 log。

當你第一次體驗到「2,000 筆 log 在 30 秒內被整理成 5 條重點」的感覺，你就回不去了。

今天就試試看

下一篇預告

第四篇：Atlassian MCP — 整合 Jira + Confluence
讓 AI 幫你搜 Incident 歷史、找 Runbook、產生報告。

到時候你就有完整的 AI 協作工具鏈了！