Loki 日志平台的低成本实践

用标签克制、结构化日志和合理保留期控制日志系统成本。

核心思路

标签只放低基数字段，如应用、环境和级别；请求 ID、用户 ID 放在日志正文中查询。应用输出 JSON，统一时间、错误码和追踪字段。

落地步骤

按业务价值设置保留期，调试日志动态开启。日志不能替代指标，排障时应从指标定位范围，再用日志寻找细节。

验证清单

实施后不要只确认“能运行”，还应检查错误率、延迟、资源占用和异常路径。把验证命令、预期结果和回滚方式写进变更记录，后续维护会轻松很多。

小结

好的工程实践不是堆叠工具，而是用清晰边界、可观察结果和可逆变更降低长期成本。先解决最重要的问题，再逐步自动化。

可执行实践

标签仅使用应用、环境、集群和级别等低基数字段；请求 ID、用户 ID 和 URL 放 JSON 正文。Promtail 或 Alloy 解析失败时保留原始日志并记录解析错误。

验证与退出条件

压测查询和摄入，监控丢弃行、限流和存储增长。为调试日志设置短保留期，敏感字段在进入 Loki 前脱敏。

实践场景

以“为容器服务建立可控成本的集中日志”为例。实施前先保存当前版本、配置和关键指标基线，写明成功条件与停止条件；涉及生产数据或外部写入时，先在隔离环境验证。

分步实施

标签只放环境、服务和级别等低基数字段，请求号放正文；结构化输出时间、事件名和错误类型，并在采集端脱敏。每完成一步都记录可观察结果，不把命令返回零等同于业务正确。

故障演练

压入大量唯一请求号确认不会成为标签；模拟多行异常和敏感字段，验证解析与遮蔽。演练应使用可清理的测试数据，并验证告警、日志和恢复路径，而不只是确认系统最终又能访问。

观测与回滚

观察摄取量、活跃流和查询延迟；标签爆炸时停止错误采集配置并回退。变更单中应写清负责人、观察窗口、阈值和回滚触发器，避免故障发生后再临时争论。

完成后把使用的版本、关键命令、观测窗口和结果写入变更记录。没有验证证据的“已完成”不能作为上线结论。

第二轮实践复核

可复用交付物： 标签字典、脱敏规则和高基数基线。复用时先固定软件版本、依赖锁文件、测试数据规模和运行环境；文章中的命令包含占位符，必须替换成自己的非生产目标后再执行。

最低验证： 在测试租户比较变更前后的 active streams、摄取速率和查询延迟

执行记录要保存命令、退出码、关键输出、观察窗口和回滚结果。若验证会产生写入，先使用隔离环境或 dry-run；任何失败都不能通过扩大权限、关闭校验或跳过测试来“解决”。

完整实战：控制日志标签基数

Loki 的标签用于定位有限的日志流，不是把所有字段都做索引。一个稳妥的标签集合可能只有环境、服务、区域和级别；request_id、user_id、订单号、URL 原文放在结构化日志正文中按需解析。

{
  "ts": "2026-08-22T09:30:00Z",
  "level": "error",
  "service": "order-api",
  "event": "payment_authorize_failed",
  "request_id": "req_01J...",
  "duration_ms": 842,
  "error_code": "UPSTREAM_TIMEOUT"
}

示例查询先用低基数标签缩小流，再解析 JSON：

{env="prod", service="order-api"}
| json
| event="payment_authorize_failed"
| duration_ms > 500

不要使用 request_id、pod UID、完整路径或用户作为标签，否则流数量和索引成本会持续增长。动态路由应先归一成模板，如 /orders/:id。

采集、保留与脱敏

环节	控制点	失败信号
应用	JSON schema、级别、采样	解析失败、日志量突增
Agent	多行合并、队列、丢弃策略	backlog、dropped entries
Loki	租户限额、保留、压缩	active streams、写入拒绝
查询	时间范围、行数、并发	查询 P95、超时率

密码、令牌、Cookie、完整身份证件和支付信息在应用产生日志前就应移除；采集端正则脱敏只能兜底。异常堆栈需要稳定多行规则，避免一次异常变成数百条无上下文记录。

压测同时覆盖稳定写入、突发错误风暴和常用查询。验收标签基数、每 GB 日志成本、查询 P95、丢弃数和脱敏样本。上线先为新日志设采样或限额；异常增长时先降低噪声事件与调试级别，不能直接停止错误与审计日志。删除或缩短保留期属于数据治理动作，应单独审批并记录影响。

一手资料

资料与版本边界复核日期：2026-08-22。工具行为可能演进，实施前以锁定版本对应的官方文档为准。