📚 课程目录第1章课程导论

1. Loki 架构概述：读写路径、核心组件与数据流

在深入排查查询超时与内存溢出问题之前，必须首先理解 Loki 的架构设计。Loki 采用 微服务 + 读写分离 架构，其核心设计理念是“仅索引元数据，不索引日志内容”，这使得它比 Elasticsearch 等全文检索引擎在日志场景下具有更低的资源消耗。然而，这种设计也带来了独特的故障模式，尤其是查询路径上的延迟与内存压力。

1.1 核心组件与职责

Loki 的生产部署通常包含以下五个核心组件，每个组件均可独立水平扩展：

组件	职责	关键特性
Distributor	接收来自 Promtail 等客户端的日志推送，验证数据完整性，并将日志转发至 Ingester。	无状态，可水平扩展；负责数据分片与副本分发。
Ingester	接收并缓存日志流，将数据写入对象存储（如 S3、MinIO），并构建内存中的索引。	有状态，负责数据持久化；内存中维护最近日志的倒排索引。
Querier	处理读取请求，从 Ingester（热数据）和对象存储（冷数据）中检索日志。	无状态，执行 LogQL 查询；是内存消耗的主要来源之一。
Query Frontend	作为查询入口，负责查询拆分、缓存、限流与合并结果。	无状态，可选组件；显著提升大范围查询性能。
Compactor	合并对象存储中的索引文件，删除过期数据，优化查询效率。	后台任务，周期性运行；不直接影响实时读写路径。

运维要点： 在排查内存溢出时，Querier 和 Ingester 是最需要关注的组件。Querier 的内存压力通常来自大范围未拆分查询或高基数标签；Ingester 的内存压力则来自高写入吞吐或过长的内存保留时间。

1.2 写入路径数据流

日志写入路径是典型的“生产者-消费者”模式，数据流经过 Distributor 验证与分发后，由 Ingester 完成持久化。下图展示了写入路径的完整流程：

  写入路径故障排查提示： 如果写入延迟高或 Distributor 返回 429/503，通常意味着 Ingester 写入压力过大或对象存储响应变慢。此时应检查 Ingester 的内存使用率和对象存储的吞吐限制。

1.3 读取路径数据流

读取路径是故障排查的核心场景。查询请求经过 Query Frontend 拆分后，由 Querier 并行从 Ingester（热数据）和对象存储（冷数据）中检索日志。下图展示了读取路径的完整流程：

常见故障模式： 当查询时间范围过大（如 7 天）且未设置合理的 split_queries_by_interval 时，Query Frontend 可能生成数千个子查询，导致 Querier 并发数飙升，最终引发内存溢出（OOM）或 gRPC 超时。这是本课程后续章节重点解决的场景。

1.4 数据流关键路径总结

为了便于记忆和故障排查，下表总结了读写路径中每个环节的关键特征与潜在风险点：

路径	组件	数据流向	常见故障
写入	Distributor	客户端 → Distributor → Ingester	写入限流、网络延迟
写入	Ingester	Ingester → 对象存储	内存溢出、写入背压
读取	Query Frontend	Grafana → Query Frontend → Querier	查询拆分不合理、缓存击穿
	Querier	Querier → Ingester + 对象存储	内存溢出、gRPC 超时
	Ingester（读取）	Ingester → Querier	热数据查询延迟

架构设计启示： Loki 的读写分离设计使得写入压力不会直接影响读取性能，但 Ingester 同时承担写入和热数据读取 的双重角色。当写入吞吐过高时，Ingester 的内存占用会上升，进而影响热数据查询的响应时间。在生产环境中，建议为 Ingester 设置独立的内存限制，并启用 ingester.max-transfer-retries 以平滑处理故障转移。