loki (一) 简介

0. 前言#

基于 centos7.9 docker-ce-20.10.18 kubelet-1.22.3-0 loki-2.3.0 promtail-2.3.0

1. 简介#

项目地址 官方文档

Loki 是 Grafana Labs 团队最新的开源项目，是一个水平可扩展，高可用性，多租户的日志聚合系统。它的设计非常经济高效且易于操作，因为它不会为日志内容编制索引，而是为每个日志流编制一组标签，专门为 Prometheus 和 Kubernetes 用户做了相关优化。该项目受 Prometheus 启发，官方的介绍就是： Like Prometheus, But For Logs.

2. 优缺点#

与其他日志聚合系统相比， Loki 具有下面的一些特性:

• 低索引开销
  • 不对日志进行全文索引。通过存储压缩非结构化日志和仅索引元数据，Loki 操作起来会更简单，更省成本。
  • 这样做可以大幅降低索引资源开销, es无论你查不查，巨大的索引开销必须时刻承担
• 并发查询
  • 为了弥补没有全文索引带来的查询降速使用，Loki 将把查询分解成较小的分片，可以理解为并发的 grep
• 和 prometheus 采用相同的标签，对接 alertmanager
  • Loki 和 Prometheus 之间的标签一致是 Loki 的超级能力之一
• 受到 Grafana 原生支持
  • 避免 kibana 和 grafana 来回切换
• 服务发现
  • 支持与 prometheus 一样的服务发现功能, 特别适合储存 Kubernetes Pod 日志
  • 无需使用日志落盘或者 sidecar

当然, 它也有一定的缺点:

• 技术比较新颖，相对应的论坛不是非常活跃。
• 功能单一，只针对日志的查看，筛选有好的表现，对于数据的处理以及清洗没有 ELK 强大，同时与 ELK 相比，对于后期，ELK 可以连用各种技术进行日志的大数据处理，但是 loki 不行。

3. 架构#

3.1 整体架构#

1c8596771859db9599e7f0d92187a4c5.webp

在 Loki 架构中有以下几个概念：

• Grafana：相当于 EFK 中的 Kibana ，用于 UI 的展示。
• Loki：相当于 EFK 中的 ElasticSearch ，用于存储日志和处理查询。
• Promtail：相当于 EFK 中的 Filebeat/Fluentd ，用于采集日志并将其发送给 Loki 。
• LogQL：Loki 提供的日志查询语言，类似 Prometheus 的 PromQL，而且 Loki 支持 LogQL 查询直接转换为 Prometheus 指标。

3.2 promtail#

官方文档

promtail 是 loki 架构中最常用的采集器, 相当于 EFK 中的 filebeat/fluentd

它的主要工作流程:

• 使用 fsnotify 监听指定目录下（例如：/var/log/*.log）的文件创建与删除
• 对每个活跃的日志文件起一个 goroutine 进行类似 tail -f 的读取，读取到的内容发送给 channel
• 有一个单独的 goroutine 会读取 channel 中的日志行，分批并附加上标签后推送给 Loki

3.3 loki#

img

Loki 采用读写分离架构，关键组件有：

• Distributor 分发器：日志数据传输的“第一站”，Distributor 分发器接收到日志数据后，根据元数据和 hash 算法，将日志分批并行地发送到多个 Ingester 接收器上
• Ingester 接收器：接收器是一个有状态的组件，在日志进入时对其进行 gzip 压缩操作，并负责构建和刷新 chunck 块，当 chunk 块达到一定的数量或者时间后，就会刷新 chunk 块和对应的 Index 索引存储到数据库中
• Querier 查询器：给定一个时间范围和标签选择器，Querier 查询器可以从数据库中查看 Index 索引以确定哪些 chunck 块匹配，并通过 greps 将结果显示出来，它还会直接从 Ingester 接收器获取尚未刷新的最新数据
• Query frontend 查询前端：查询前端是一个可选的组件，运行在 Querier 查询器之前，起到缓存，均衡调度的功能，用于加速日志查询

Loki 提供了两种部署方式：

• 单体模式，ALL IN ONE：Loki 支持单一进程模式，可在一个进程中运行所有必需的组件。单进程模式非常适合测试 Loki 或以小规模运行。不过尽管每个组件都以相同的进程运行，但它们仍将通过本地网络相互连接进行组件之间的通信（grpc）。使用 Helm 部署就是采用的该模式。
• 微服务模式：为了实现水平可伸缩性，Loki 支持组件拆分为单独的组件分开部署，从而使它们彼此独立地扩展。每个组件都产生一个用于内部请求的 gRPC 服务器和一个用于外部 API 请求的 HTTP 服务，所有组件都带有 HTTP 服务器，但是大多数只暴露就绪接口、运行状况和指标端点。

4. 日志告警#

Loki 支持三种模式创建日志告警：

• 在 Promtail 中的 pipeline 管道的 metrics 的阶段，根据需求增加一个监控指标，然后使用 Prometheus 结合 Alertmanager 完成监控报警。
• 通过 Loki 自带的报警功能（ Ruler 组件）可以持续查询一个 rules 规则，并将超过阈值的事件推送给 AlertManager 或者其他 Webhook 服务。
• 将 LogQL 查询转换为 Prometheus 指标。可以通过 Grafana 自带的 Alert rules & notifications，定义有关 LogQL 指标的报警，推送到 Notification channels（ Prometheus Alertmanager ， Webhook 等）。