面向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处理、集成表面和自修复机制。