4. Loki 查询接口全景：Range Query、Instant Query、Series Query、Labels Query

在蓝绿发布场景下，日志查询的延迟直接决定了发布验证的反馈速度。Loki 提供了四种核心查询接口，分别服务于不同的可观测性需求。理解它们的底层数据流与性能特征，是后续调优的基础。

4.1 四种查询接口的定位与差异

下表从查询目标、数据范围、返回结构三个维度对比四种接口，帮助你在调优时快速定位瓶颈。

4.2 Range Query：最核心的日志检索路径

Range Query 是蓝绿发布中最常用的接口——当新版本出现 500 错误时，你需要回溯过去 5 分钟的日志。其请求路径如下：

GET /loki/api/v1/query_range
  ?query={app="green-release",env="prod"} |= "ERROR"
  &start=1710000000000000000
  &end=1710000300000000000
  &limit=5000
  &direction=backward

该接口的查询流程分为三个阶段：

1. 索引匹配：根据标签选择器（{app="green-release"}）在倒排索引中定位所有匹配的 Stream。
2. Chunk 筛选：根据时间范围 [start, end] 过滤每个 Stream 的 Chunk 列表，只保留时间重叠的 Chunk。
3. 内容扫描：对筛选后的 Chunk 进行解压，逐行执行 LogQL 过滤（如 |= "ERROR"），返回匹配行。

4.3 Instant Query：实时快照的代价

Instant Query 在蓝绿发布中常用于健康检查探针——例如每 10 秒查询一次新版本 Pod 是否输出 FATAL 日志。其请求路径与 Range Query 类似，但 time 参数替代了 start 和 end：

GET /loki/api/v1/query
  ?query={app="green-release"} |= "FATAL"
  &time=1710000300000000000
  &limit=100

Instant Query 的内部实现并非直接读取单个时间点的数据，而是将 time 扩展为一个微小的窗口（通常为 1 纳秒到 1 毫秒），然后执行与 Range Query 相同的扫描逻辑。这意味着：

• 如果 time 对应的 Chunk 不在内存缓存中，Instant Query 仍然需要从对象存储下载并解压 Chunk。
• 高频的 Instant Query（如每 5 秒一次）可能造成缓存抖动，反而拖慢整体查询性能。

4.4 Series Query 与 Labels Query：元数据发现

这两种接口不返回日志内容，只返回标签元数据。它们在蓝绿发布中的典型用途是：

• Series Query：发现当前环境中所有 app="green-release" 的 Stream 有哪些不同的 version 标签值。
• Labels Query：获取所有可用的标签名称，或某个标签（如 version）的所有取值。

请求示例：

# Series Query
GET /loki/api/v1/series
  ?match[]={app="green-release"}
  &start=1710000000000000000
  &end=1710000300000000000

# Labels Query（获取标签值）
GET /loki/api/v1/label/version/values
  ?start=1710000000000000000
  &end=1710000300000000000

4.5 四种接口的查询路径全景

下面的 SVG 图展示了四种查询接口在 Loki 组件间的数据流路径，帮助你理解不同查询类型对存储和计算资源的消耗差异。

4.6 蓝绿发布场景下的接口选择策略

根据不同的发布阶段，选择合适的查询接口可以显著降低集群负载：