Grafana Loki 日志关联代理

解决的问题

当请求跨多个微服务跳转时，日志通常会散落在 Loki、Tempo 等不同后端里。排查一条 trace 时，开发者不得不手动复制 trace ID，再去日志平台做多次正则搜索，才能把关键日志找齐。这种割裂的流程不仅耗时，还容易漏掉真正与故障相关的日志行。

Loki 本身采用“压缩非结构化日志、只索引元数据”的设计，天然不擅长全文检索。一旦团队把业务字段塞到日志消息里，想按某个业务维度（例如 user_id、order_id）快速过滤，就会遇到要么查不动、要么成本飙升的尴尬。

技能如何工作

该技能围绕 LogQL 与 Tempo 集成，把上述流程自动化。

• 指标定义：在接入阶段先声明 logs_in_total 等基础指标，便于后续按标签组合做聚合。
• 标签治理：引导你识别哪些标签值过于分散（例如把整段日志消息当标签），避免高基数拖垮 Loki。
• 测试查询：在正式编写 Prometheus 规则前，允许你先用 LogQL 验证过滤条件是否准确，减少无效告警。
• 规则生成：根据输入的 SLO 或错误率阈值，自动产出可用的 Record / Alert 规则，并给出 metric 导出建议，方便导入 Prometheus。

核心代码片段看起来类似：

sum by (service, status_code) (rate({namespace="app"}[5m]))

适用边界与注意事项

• 仅对 结构化字段 与 现有标签 有效；如果你的应用仍把业务 ID 写在日志正文里，需要先做结构化输出。
• 不支持对日志全文做模糊检索；想要历史全文本搜索，仍需要额外方案。
• 生成的告警规则依赖上游 Loki、Tempo 与 Prometheus 指标格式保持一致，请确认代理版本与监控栈匹配。
• 所有参数、示例均摘录自上游仓库文档，使用前请结合自身版本测试。