2、Loki架构基础：日志存储、索引与查询路径的核心组件

理解Loki的架构是进行版本漂移校准的前提。Loki的设计哲学与Elasticsearch等传统日志系统截然不同：它不全文索引日志内容，而是仅对日志的元数据（标签）建立索引，日志数据本身以压缩块的形式存储在对象存储中。这种“索引与数据分离”的架构大幅降低了存储成本，但也带来了查询路径的独特性。

2.1 核心组件概览

Loki的部署由多个微服务组件构成，每个组件负责日志生命周期的特定阶段。下表列出了与查询接口版本漂移最相关的核心组件：

2.2 日志存储：从写入到持久化

Loki的日志存储路径遵循“写入时低开销，查询时按需解压”的原则。其存储模型分为三个层次：

• Chunks（日志块）：日志数据被压缩并打包成Chunk，默认使用gzip/snappy压缩。每个Chunk包含同一标签集（Stream）的连续日志行。
• Index（索引）：仅存储标签（Label）到Chunk的映射关系。索引格式经历了从Boltdb-shipper到TSDB的演进，这是版本漂移的主要来源之一。
• Object Store（对象存储）：Chunk和Index最终持久化到S3、GCS、MinIO或本地文件系统。

2.3 索引架构演进：Boltdb-shipper vs TSDB

索引格式的变更直接影响了查询接口的底层行为。下表对比了两种索引模式的关键差异：

2.4 查询路径详解：从LogQL到结果

一次完整的日志查询请求经过以下路径，每个环节都可能因版本差异产生接口行为变化：

1. HTTP API 入口：Grafana或客户端调用/loki/api/v1/query_range或/loki/api/v1/query端点。
2. Query Frontend 处理：
   • 检查API版本（v1 vs 即将到来的v2）。
   • 根据X-Scope-OrgID头进行多租户路由。
   • 将大时间范围查询拆分为多个子查询（time-slicing）。
3. Querier 执行：
   • 解析LogQL语法（不同版本支持的函数和操作符不同）。
   • 通过Index Gateway查找匹配标签的Chunk元数据。
   • 从对象存储或Ingester拉取Chunk数据。
4. 结果合并与返回：
   • Querier对多个Chunk的结果进行去重、排序和聚合。
   • 返回JSON响应，包含status、data.resultType、data.result字段。

2.5 关键数据结构：Stream、Chunk与Entry

理解查询接口返回的数据结构，是校准版本漂移的基础。Loki的日志数据模型由三个层级组成：

2.6 版本漂移在架构层面的体现

基于上述架构，版本漂移主要出现在以下三个层面：

• 索引格式不兼容：TSDB索引无法被旧版Querier读取，导致查询失败或返回空结果。
• API响应结构变化：如data.resultType字段的引入、stats对象的字段增减。
• LogQL语法演进：新版本支持的模式（如| pattern、| unpack）在旧版本中会导致解析错误。