Loki 日志聚合实践：从采集链路到查询与告警的运维视角
Loki 把“日志”重新定义成一组带标签的流，而不是全文索引库：它只索引标签，正文压缩后落到对象存储。这个取舍让存储成本大幅下降，也把压力从“写索引”转移到了“标签设计与查询范围控制”上。本页不重复官方安装步骤，而是从极客运维的日常视角，梳理采集链路怎么分层、标签怎么定、查询怎么不把集群拖垮、告警怎么收敛，以及和 Prometheus、Grafana 组成可观测闭环时的边界在哪里。
标签即索引
标签基数决定查询与写入的稳定性，是设计的第一约束。
对象存储承载正文
chunk 落盘成本低，但查询范围必须靠时间窗与标签收窄。
与指标互补
指标看趋势，日志看现场，二者用同一套标签语义对齐。
一、采集链路分层：谁负责收，谁负责送
常见做法是在每台节点上跑一个轻量采集器（Promtail 或 Alloy），只负责发现日志文件、打上少量静态标签后推送；Loki 的 distributor 做校验与分片，ingester 在内存中聚合 chunk，最终 flush 到对象存储。分层之后，节点侧不承担解析与富化，减少了故障面。
- 采集端只打“来源类”标签：集群、环境、命名空间、应用名。
- 解析与结构化尽量后置，避免采集端 CPU 抖动影响业务。
- 多租户场景用 tenant 隔离，而不是靠标签区分业务线。
- 采集器自身要有资源上限与限流，防止日志风暴反噬节点。
二、标签设计：基数控制是生死线
Loki 的查询性能几乎完全由标签选择器决定。把请求 ID、用户 ID、时间戳这类高基数字段塞进标签，会直接把索引撑爆；正确做法是它们留在日志正文里，靠过滤表达式在查询阶段处理。
三、查询与告警：把范围压在可控区间
查询侧
- 始终带时间窗，避免全量扫描 chunk。
- 先标签选择器，再行过滤，顺序影响很大。
- 大范围排查优先用 LogQL 聚合而非拉全量。
告警侧
- 用 ruler 基于日志计数做阈值告警。
- 告警规则要带 for 持续时间，抑制瞬时抖动。
- 与 Prometheus 告警统一收敛到同一通道。
四、常见疑问
Loki 能替代 Elasticsearch 做全文检索吗？
定位不同。Loki 面向“按标签找日志流”的运维场景，成本低；需要复杂全文检索与聚合分析时，ES 仍更合适。
日志量突然翻倍怎么办？
先在采集端做采样与限流，再检查是否有异常刷屏的应用；不要靠扩容 ingester 硬扛。
和 Prometheus 的标签要统一吗？
建议对齐 cluster、namespace、app 等核心维度，这样在 Grafana 里可以从指标面板一键跳到对应日志。
继续深入可观测体系
日志、指标、看板三者打通，才是完整的运维闭环。