日志系统新贵Loki，确实比笨重的ELK轻

╰+哭是因爲堅強的太久メ 2022-11-18 05:56 210阅读 0赞

## 你知道的越多，不知道的就越多，业余的像一棵小草！ ##

你来，我们一起精进！你不来，我和你的竞争对手一起精进！

## 编辑：业余草 ##

suo.im/5EZQaP

## 推荐：https://www.xttblog.com/?p=5178 ##

最近，在对公司容器云的日志方案进行设计的时候，发现主流的ELK或者EFK比较重，再加上现阶段对于ES复杂的搜索功能很多都用不上最终选择了Grafana开源的Loki日志系统，下面介绍下Loki的背景。

## 背景和动机 ##

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

![513e6d5e4ba93d210b646ed4e084cc8b.png][]

我们的监控使用的是基于prometheus体系进行改造的，prometheus中比较重要的是metric和alert,metric是来说明当前或者历史达到了某个值，alert设置metric达到某个特定的基数触发了告警，但是这些信息明显是不够的。我们都知道，k8s的基本单位是pod,pod把日志输出到stdout和stderr,平时有什么问题我们通常在界面或者通过命令查看相关的日志,举个例子：当我们的某个pod的内存变得很大，触发了我们的alert，这个时候管理员，去页面查询确认是哪个pod有问题，然后要确认pod内存变大的原因，我们还需要去查询pod的日志，如果没有日志系统，那么我们就需要到页面或者使用命令进行查询了：

![1ae5f0e44a7c76f93232e84a7eba5d8d.png][]

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

## ELK存在的问题 ##

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

![9e45d6eee942b0d2df23d2d8ba72236f.png][]

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

## 成本 ##

全文检索的方案也带来成本问题，简单的说就是全文搜索（如ES）的倒排索引的切分和共享的成本较高。后来出现了其他不同的设计方案如：OKlog(https://github.com/oklog/oklog),采用最终一致的、基于网格的分布策略。这两个设计决策提供了大量的成本降低和非常简单的操作，但是查询不够方便。因此，Loki的第三个目的是，提高一个更具成本效益的解决方案。

## 整体架构 ##

Loki的架构如下：

![8ba57fc626ce2644299d8a29e99f6e3e.png][]

不难看出，Loki的架构非常简单，使用了和prometheus一样的标签来作为索引，也就是说，你通过这些标签既可以查询日志的内容也可以查询到监控的数据，不但减少了两种查询之间的切换成本，也极大地降低了日志索引的存储。Loki将使用与prometheus相同的服务发现和标签重新标记库,编写了pormtail, 在k8s中promtail以daemonset方式运行在每个节点中，通过kubernetes api等到日志的正确元数据，并将它们发送到Loki。下面是日志的存储架构：

![20240d8642639731153f6cbd5978e1b6.png][]

## 读写    ##

日志数据的写主要依托的是Distributor和Ingester两个组件,整体的流程如下：

![335171adf354c146f84aeacc44a3e730.png][]

### Distributor    ###

一旦promtail收集日志并将其发送给loki，Distributor就是第一个接收日志的组件。由于日志的写入量可能很大，所以不能在它们传入时将它们写入数据库。这会毁掉数据库。我们需要批处理和压缩数据。

Loki通过构建压缩数据块来实现这一点，方法是在日志进入时对其进行gzip操作，组件ingester是一个有状态的组件，负责构建和刷新chunck，当chunk达到一定的数量或者时间后，刷新到存储中去。每个流的日志对应一个ingester,当日志到达Distributor后，根据元数据和hash算法计算出应该到哪个ingester上面。

![8852ba634017e4bea5862faaf1f26fd5.png][]

此外，为了冗余和弹性，我们将其复制n（默认情况下为3）次。

### Ingester ###

ingester接收到日志并开始构建chunk:

![92aac371c866946493db13e6baaa3b52.png][]

基本上就是将日志进行压缩并附加到chunk上面。一旦chunk“填满”（数据达到一定数量或者过了一定期限），ingester将其刷新到数据库。我们对块和索引使用单独的数据库，因为它们存储的数据类型不同。

![47a7864cf416363e8910a5b531356b82.png][]

刷新一个chunk之后，ingester然后创建一个新的空chunk并将新条目添加到该chunk中。

### Querier ###

读取就非常简单了，由Querier负责给定一个时间范围和标签选择器，Querier查看索引以确定哪些块匹配，并通过greps将结果显示出来。它还从Ingester获取尚未刷新的最新数据。

对于每个查询，一个查询器将为您显示所有相关日志。实现了查询并行化，提供分布式grep，使即使是大型查询也是足够的。

![4fab766dc582f56743c5695a953c4ad8.png][]

## 可扩展性    ##

Loki的索引存储可以是cassandra/bigtable/dynamodb，而chuncks可以是各种对象存储，Querier和Distributor都是无状态的组件。对于ingester他虽然是有状态的但是，当新的节点加入或者减少，整节点间的chunk会重新分配，已适应新的散列环。而Loki底层存储的实现Cortex已经 在实际的生产中投入使用多年了。有了这句话，我可以放心的在环境中实验一把了。

![e8be43dacd62a447dd75d39c1ad32dee.png][]

[513e6d5e4ba93d210b646ed4e084cc8b.png]: /images/20221022/57c1dad0258548bd859be8ff51eb21bc.png
[1ae5f0e44a7c76f93232e84a7eba5d8d.png]: /images/20221022/8fc09e7b14374046b52c253978e3f107.png
[9e45d6eee942b0d2df23d2d8ba72236f.png]: /images/20221022/679d21fae35c4b86b294b445c3d5f7a6.png
[8ba57fc626ce2644299d8a29e99f6e3e.png]: /images/20221022/18ec65cdbfbe465fa8ab094cbc5dfeec.png
[20240d8642639731153f6cbd5978e1b6.png]: /images/20221022/18bb1c1ec1964e55931392eb1be33d37.png
[335171adf354c146f84aeacc44a3e730.png]: /images/20221022/0dac44e385884ef1b6fe852dd9172a24.png
[8852ba634017e4bea5862faaf1f26fd5.png]: /images/20221022/fb8cae91343b4a19b9bf601e093f2414.png
[92aac371c866946493db13e6baaa3b52.png]: /images/20221022/ddec4077437b481fa07b0fd3a028b329.png
[47a7864cf416363e8910a5b531356b82.png]: /images/20221022/da10b666b6e3407a91f3e4a704a40587.png
[4fab766dc582f56743c5695a953c4ad8.png]: /images/20221022/19eaec4f32004b76bc40144800ef5b4f.png
[e8be43dacd62a447dd75d39c1ad32dee.png]: /images/20221022/37bfef65e30a4b069c4f6312ce95ad16.png