Loki部署模式

Loki程序基于微服务架构，由多个组件构成，不同部署模式下用户的组件亦有所不同

“all”表示单体模式

“individual”表示微服务模式

“simple scalable deployment”模式下则存在三个逻辑组“read”、“write”和“backend”

系统架构

• 写路径

  • Distributor

    • 负责接收并处理客户端（例如promtail） 的push请求，无状态服务组件

  • Ingester

    • 负责持久化数据至本地存储，以及将数据存储至后端对象存储系统以长期保存数据
    • 基于最近抓取的、缓存于内存中的日志流响应用户的查询请求

• 读路径

  • Query Frontend
    • 用于加速查询请求的组件，位于Querier API的前端，可选组件
  • Query Scheduler
    • 负责调度查询请求，能够为Query Frontend提供更为高级的队列机制，可选组件
  • Querier
    • 负责执行LogQL查询的组件，可从客户端、Query Frontend或Query Scheduler接收查询请求

• Index Gateway

  • 负责处理元数据查询，因此它专用于“shipper stores”，例如单一存储模式中的TSDB或BoltDB

• Compactor

  • 将那些由多个Ingester生成的多个索引，以天为单位基于tenant合并成单个索引文件，实现高效索引查询

• Ruler

  • 管理和评估告警表达式中的规则

写路径

发往Loki的写请求，会基于特定的顺序由多个组件协同处理
① Distributor从客户端接收到关于流和日志行的HTTP POST请求
② Distributor对接收到的每个流进行hash计算，以判定要发往的Ingester实例
③ Distributor将每个流及其副本（replicas，取决于replication factor的定义）发往对应的Ingester
④ Ingester收到带有日志行的流后，将其存储至新建的chunk或附加到现有的chunk上
◆ 对于每个tenant来说，其每个标签集所唯一标识的流会存储在专用的chunk中
⑤ Ingester能返回写操作的结果状态
⑥ Distributor等待满足多数方（quorum）数量要求的Ingester确认写入状态
⑦ 根据写操作的结果，Distributor响应写入成功(2xx status code)或写入失败(4xx or 5xx status code)的状态给客户端

读路径

发往Loki的查询请求，也会基于特定的顺序由多个组件协同处理
① Query Frontend基于HTTP GET从客户端接收到LogQL请求
② Query Frontend将查询请求切分成多个子查询，并将它们传递给后端的Query Scheduler进行调度
③ Querier从Query Scheduler接收到子查询
④ Querier将子查询发送给所有的Ingester进行内存数据查询
⑤ 若存在匹配的数据，Ingester则会将内存中匹配到的数据予以返回
⑥ 若不存在匹配的数据或匹配的数据量不足，Querier将从后端存储系统加载数据
⑦ Querier遍历接收到的所有数据及副本，并返回结果给Query Frontend
⑧ Query Frontend等待所有Query上的子查询响应完成
⑨ Query Frontend合并各个子查询的结果，并以之响应给客户端

Distributor

Distributor的基本工作逻辑

• 校验接收到的每个stream以确保其未超出tenant或global的限制
• 合规的stream会基于复制因子的定义，以并行方式发送n个副本至n个Ingester进行存储
• Distributor基于一致性哈希算法，为每个stream及其副本挑选对应的Ingester

Distributor的关键功能

• 校验（Validation）
  • 负责确保所有的流合乎规范
  • 主要检查标签是否符合Prometheus标签规范、时间戳是否异常（过旧或者过新），以及日志行是否过长
• 预处理（Preprocessing）
  • 对标签进行排序，提高缓存和哈希的效果
• 限流（Rate limiting）
  • 根据配置对每个tenant进行限流
• 转发（Forwarding）
  • 校验环节完成后，将写请求转发至Ingester以完成数据存储
  • 根据复制因子的定义，可能需要发送多个副本至不同的Ingester
• 哈希（Hashing）
  • 对流的每个数据副本进行hash计算，以映射至Ingester

单体模式

将Loki的所有微服务组件打包部署到单一进程中

适合小规模系统的日志存储场景（每天不超过100G）

在必要时，可部署共享外部对象存储的多实例进行水平扩容

• 在配置文件loki.yaml的ring配置段中定义日志数据的跨实例分发

支持高可的部署方式

• 多个实例需要配置共享的外部对象存储
• 需要设定合理的复制因子

最简单的操作模式是整体部署模式。

可以通过设置命令行参数来启用整体模式。此模式将 Loki 的所有微服务组件作为单个二进制或 Docker 映像在单个进程中运行。

需要给loki加个参数-target=all

简单可扩展模式

将组件分割到独立的Read path、Write path和Backend path中，并各自进行扩展

另外还需要一个独立的后端存储路径（backend path）

是大部分场景中采用的部署模式，也是基于Helm Chart部署时默认采用的模式

支持每日TB级别的日志存储

简单可扩展的部署模式是大多数安装部署 Loki 的首选方式。

简单可扩展的部署是 Loki Helm Chart 安装的默认配置。

此部署模式是大规模部署 Loki 的最简单方法。

它在以整体模式部署或将每个组件部署为单独的微服务之间取得了平衡。

简单可扩展模式下的三个执行路径都是通过在启动时将以下参数附加到 Loki 来激活的：

• -target=write- 写入目标是有状态的，由 Kubernetes StatefulSet 控制。它包含以下组件： – Distributor(分配器) – Ingester(收集器)
• -target=read- 读取目标是无状态的，可以作为可以自动扩展的 Kubernetes 部署运行（请注意，在官方 helm chart 中，它当前部署为有状态集）。它包含以下组件： – Query frontend(查询前端) – Queriers(查询者)
• -target=backend- 后端目标是有状态的，由 Kubernetes StatefulSet 控制。包含以下组件： – Compactor – Index gateways(索引网关) – Query scheduler(查询调度器) – Ruler(规则)

简单可扩展的部署模式要求在 Loki 前面部署一个反向代理，以将客户端 API 请求定向到读取或写入节点。

Loki Helm 图表包括使用 Nginx 的默认反向代理配置。

微服务模式

每个微服务组件均独立运行

• 2.9版本的Loki要运行的组件包括
  • Cache Generation Loader
  • Compactor
  • Distributor
  • Index-gateway
  • Ingester
  • Ingester-Querier
  • Overrides Exporter
  • Querier
  • Query-frontend
  • Query-scheduler
  • Ruler
• 仅适用于超大规模日志场景，或者需要对Loki进行精细化控制的场景