面向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處理、集成表面和自修復機制。