Loki 架构是什么
Loki 是只索引标签、不索引日志正文的日志系统：写入路径由 distributor 校验并分发，ingester 在内存里攒块后周期性下传对象存储；读取路径由 querier 并行拉取索引与块内容，query-frontend 做查询拆分、排队与缓存。与 Elasticsearch 的核心差别就在这里——标签收敛查询范围，正文匹配靠暴力扫块加并行计算换成本，因此存储便宜，但模糊全文检索的代价高。
基本信息
| 适用平台 | Grafana Loki 2.x / 3.x，可单进程也可微服务拆分部署 |
|---|---|
| 数据真源 | 对象存储（S3、MinIO、GCS 等），本地磁盘不是持久层 |
| 索引内容 | 仅标签与块的元信息，正文压缩后存为块 |
| 查询入口 | HTTP 3100（读写同端口），前端组件做队列与缓存 |
典型使用场景
- 成本敏感的日志集中：日志量大但检索以「按服务和标签筛 + 关键字」为主
- 与 Grafana 生态联动：日志与指标、链路共享同一套数据源与看板
- Kubernetes 容器日志采集：配合 Promtail 或采集 Agent 按标签落库
- 多租户日志：用租户标识隔离不同团队的数据与配额
- 长期留存：把冷数据留在对象存储，按保留周期自动压缩清理
组件分工与部署形态
组件分工与部署形态
distributor → 校验限额、按标签哈希分发，拒绝超限请求
ingester → 内存攒块，定时下传对象存储，查询时提供近实时数据
querier → 并行查询索引与块，聚合、去重、排序后返回
query-frontend → 拆分查询、排队重试、结果缓存，减轻后端压力
compactor → 压缩块、按保留策略清理过期数据
部署形态：单进程一体化（小规模与验证用）
读、写、后端各自拆分（按负载独立扩展）组件与常见瓶颈
| 组件 | 关注指标 | 瓶颈表现 |
|---|---|---|
| distributor | 每秒写入量、被拒请求数 | 超过限额时直接返回错误而不是排队 |
| ingester | 内存中块数、下传延迟 | 内存打满会触发重复下传与重启 |
| querier | 查询并发、扫描块数 | 模糊正则配大范围会拉满 CPU |
| compactor | 压缩任务积压 | 积压时保留策略不生效，存储持续增长 |
| 对象存储 | 请求延迟与错误率 | 后端抖动直接放大为写入失败与查询超时 |
标签基数决定成败：标签只放低基数维度（服务、环境、级别），高基数信息（请求 ID、用户 ID）留在日志正文里，用检索条件过滤。
查询性能依赖并行度与块索引结构；同一条查询在 1 小时窗口和 7 天窗口的代价差异是数量级级别的，排障先从窄窗口开始定位。