面向AI時代的可觀測性設計——應用、基礎設施、CI、LLM（第一部分）

本文是系列的第一部分，作者Ryan（airCloset CTO）闡述了為AI時代重塑可觀測性堆疊的設計理念。核心觀點是：資料必須事先塑形，AI才能有效消費。原始生產日誌直接餵給AI會淹沒上下文視窗、無法區分錯誤和噪聲，且指標、日誌、追蹤互不關聯。因此，作者將監控面按目的分為四個維度。

應用：標準OTel堆疊。所有cortex應用均使用OpenTelemetry進行儀表化，追蹤傳送至Tempo，日誌至Loki，指標至Mimir——典型的Grafana Cloud配置。關鍵在於每項服務日誌和追蹤的形狀一致，便於後續AI透過MCP跨服務查詢。

基礎設施：GCP指標統一到Mimir。cortex執行於GCP，將Cloud Run、BigQuery、Pub/Sub等資源的CPU、記憶體、延遲等指標透過Cloud Monitoring流入Mimir。單一儲存使AI能自然回答“上週哪個服務CPU使用最高？”等問題。

CI：事後拉取日誌到Loki。CI執行在GitHub Actions上，但作者選擇在CI完成後透過GitHub API拉取日誌，而非從執行內部推送。這樣做的好處：解耦CI執行與可觀測性；避免PR程式碼接觸API金鑰；可獨立重試和告警。日誌結構化後（job/status/ref等），可使用LogQL篩選主分支失敗，觸發自動修復。

LLM：Gemini與Claude Code不同形狀。Gemini因作者控制呼叫程式碼，採用Prometheus指標即時監控，包括token數、延遲和客戶端估算的成本。成本計算選擇客戶端估算（方案B），因為能按呼叫站點（服務/模型/用途）細分，即時可見，而云計費API有數小時延遲且無法提供細粒度。Claude Code是外部CLI，無法從內部插樁，其使用記錄作為結構化資料存入BigQuery，便於SQL聚合分析（如按使用者、倉庫、快取命中率等）。作者解釋了為何不將Claude Code日誌放入Loki：因為其問題本質是結構化聚合，BigQuery更適合。

最後，作者預告了第二部分將涵蓋PII處理、整合表面和自修復機制。