Grafana Loki开源日志聚合系统代替ELK或EFK

前言

在对公司容器云的日志方案进行设计的时候，发现主流的 ELK (Elasticsearch, Logstash, Kibana) 或者 EFK (Elasticsearch, Filebeat or Fluentd, Kibana) 比较重，再加上现阶段对于 ES 复杂的搜索功能很多都用不上，最终选择了 Grafana 开源的 Loki 日志系统。下面我们来介绍下 Loki 的一些基本概念和架构，当然 EFK 作为业界成熟的日志聚合解决方案也是大家应该需要熟悉和掌握的。

Loki 2.0 released: Transform logs as you’re querying them, and set up alerts within Loki, Loki 2.0 大版本更新后更好用了

更新历史

2020年10月02日 - 初稿

阅读原文 - https://wsgzao.github.io/post/loki/

---

Loki简介

Grafana Loki is a set of components that can be composed into a fully featured logging stack.

Unlike other logging systems, Loki is built around the idea of only indexing metadata about your logs: labels (just like Prometheus labels). Log data itself is then compressed and stored in chunks in object stores such as S3 or GCS, or even locally on the filesystem. A small index and highly compressed chunks simplifies the operation and significantly lowers the cost of Loki.

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

项目地址：https://github.com/grafana/loki/

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

• 不对日志进行全文索引。通过存储压缩非结构化日志和仅索引元数据，Loki 操作起来会更简单，更省成本。

• 通过使用与 Prometheus 相同的标签记录流对日志进行索引和分组，这使得日志的扩展和操作效率更高。

• 特别适合储存 Kubernetes Pod 日志; 诸如 Pod 标签之类的元数据会被自动删除和编入索引。

• 受 Grafana 原生支持。

背景和动机

当我们的容器云运行的应用或者某个节点出现问题了，解决思路应该如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kT6dUQHG-1604371021235)(https://raw.githubusercontent.com/wsgzao/storage-public/master/img/20201030154333.png)]

我们的监控使用的是基于 Prometheus 体系进行改造的，Prometheus 中比较重要的是 Metric 和 Alert，Metric 是来说明当前或者历史达到了某个值，Alert 设置 Metric 达到某个特定的基数触发了告警，但是这些信息明显是不够的。

我们都知道，Kubernetes 的基本单位是 Pod，Pod 把日志输出到 Stdout 和 Stderr，平时有什么问题我们通常在界面或者通过命令查看相关的日志。

举个例子：当我们的某个 Pod 的内存变得很大，触发了我们的 Alert。这时管理员，去页面查询确认是哪个 Pod 有问题，然后要确认 Pod 内存变大的原因，我们还需要去查询 Pod 的日志，如果没有日志系统，那么我们就需要到页面或者使用命令进行查询：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0RhxXXuF-1604371021236)(https://raw.githubusercontent.com/wsgzao/storage-public/master/img/20201030162229.png)]

如果，这个时候应用突然挂了，这个时候我们就无法查到相关的日志了。所以需要引入日志系统，统一收集日志。而使用 ELK 的话，就需要在 Kibana 和 Grafana 之间切换，影响用户体验。所以 ，Loki 的第一目的就是最小化度量和日志的切换成本，有助于减少异常事件的响应时间和提高用户的体验。

ELK 存在的问题

现有的很多日志采集的方案都是采用全文检索对日志进行索引（如 ELK 方案），优点是功能丰富，允许复杂的操作。但是，这些方案往往规模复杂，资源占用高，操作苦难。很多功能往往用不上，大多数查询只关注一定时间范围和一些简单的参数（如：host、service 等），使用这些解决方案就有点杀鸡用牛刀的感觉了。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NKVk1g98-1604371021237)(https://raw.githubusercontent.com/wsgzao/storage-public/master/img/20201030162252.png)]

因此，Loki 的第二个目的是，在查询语言的易操作性和复杂性之间可以达到一个权衡。

成本考量

全文检索的方案也带来成本问题，简单的说就是全文搜索（如：ES&