日志系统新贵Loki，真香！

做者：linkt1234git

原文：https://blog.csdn.net/Linkthaha/article/details/100575278github

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

背景和动机数据库

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

咱们的监控使用的是基于 Prometheus 体系进行改造的，Prometheus 中比较重要的是 Metric 和 Alert。微信

Metric 是来讲明当前或者历史达到了某个值，Alert 设置 Metric 达到某个特定的基数触发了告警，可是这些信息明显是不够的。架构

咱们都知道，Kubernetes 的基本单位是 Pod，Pod 把日志输出到 stdout 和 stderr，平时有什么问题咱们一般在界面或者经过命令查看相关的日志。app

举个例子：当咱们的某个 Pod 的内存变得很大，触发了咱们的 Alert，这个时候管理员，去页面查询确认是哪一个 Pod 有问题，而后要确认 Pod 内存变大的缘由。分布式

咱们还须要去查询 Pod 的日志，若是没有日志系统，那么咱们就须要到页面或者使用命令进行查询了：

若是，这个时候应用忽然挂了，这个时候咱们就没法查到相关的日志了，因此须要引入日志系统，统一收集日志。spa

而使用 ELK 的话，就须要在 Kibana 和 Grafana 之间切换，影响用户体验。.net

因此，Loki 的第一目的就是最小化度量和日志的切换成本，有助于减小异常事件的响应时间和提升用户的体验。

ELK 存在的问题

现有的不少日志采集的方案都是采用全文检索对日志进行索引（如 ELK 方案），优势是功能丰富，容许复杂的操做。可是，这些方案每每规模复杂，资源占用高，操做苦难。

不少功能每每用不上，大多数查询只关注必定时间范围和一些简单的参数（如 host、service 等），使用这些解决方案就有点杀鸡用牛刀的感受了。

所以，Loki 的第二个目的是，在查询语言的易操做性和复杂性之间能够达到一个权衡。

成本

全文检索的方案也带来成本问题，简单的说就是全文搜索（如 ES）的倒排索引的切分和共享的成本较高。

后来出现了其余不一样的设计方案如：OKlog（https://github.com/oklog/oklog），采用最终一致的、基于网格的分布策略。

这两个设计决策提供了大量的成本下降和很是简单的操做，可是查询不够方便。所以，Loki 的第三个目的是，提升一个更具成本效益的解决方案。

总体架构

Loki 的架构以下：

不难看出，Loki 的架构很是简单，使用了和 Prometheus 同样的标签来做为索引。

也就是说，你经过这些标签既能够查询日志的内容也能够查询到监控的数据，不但减小了两种查询之间的切换成本，也极大地下降了日志索引的存储。

Loki 将使用与 Prometheus 相同的服务发现和标签从新标记库，编写了 Pormtail，在 Kubernetes 中 Promtail 以 DaemonSet 方式运行在每一个节点中，经过 Kubernetes API 等到日志的正确元数据，并将它们发送到 Loki。

下面是日志的存储架构：

读写

日志数据的写主要依托的是 Distributor 和 Ingester 两个组件，总体的流程以下：

Distributor

一旦 Promtail 收集日志并将其发送给 Loki，Distributor 就是第一个接收日志的组件。

因为日志的写入量可能很大，因此不能在它们传入时将它们写入数据库。这会毁掉数据库。咱们须要批处理和压缩数据。

Loki 经过构建压缩数据块来实现这一点，方法是在日志进入时对其进行 Gzip 操做，组件 Ingester 是一个有状态的组件，负责构建和刷新 Chunck，当 Chunk 达到必定的数量或者时间后，刷新到存储中去。

每一个流的日志对应一个 Ingester，当日志到达 Distributor 后，根据元数据和 Hash 算法计算出应该到哪一个 Ingester 上面。

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

Ingester

Ingester 接收到日志并开始构建 Chunk：

基本上就是将日志进行压缩并附加到 Chunk 上面。一旦 Chunk“填满”（数据达到必定数量或者过了必定期限），Ingester 将其刷新到数据库。

咱们对块和索引使用单独的数据库，由于它们存储的数据类型不一样。

刷新一个 Chunk 以后，Ingester 而后建立一个新的空 Chunk 并将新条目添加到该 Chunk 中。

Querier

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

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

可扩展性

Loki 的索引存储能够是 cassandra/bigtable/dynamodb，而 Chuncks 能够是各类对象存储，Querier 和 Distributor 都是无状态的组件。

对于 Ingester 他虽然是有状态的可是，当新的节点加入或者减小，整节点间的 Chunk 会从新分配，已适应新的散列环。

而 Loki 底层存储的实现 Cortex 已经在实际的生产中投入使用多年了。有了这句话，我能够放心的在环境中实验一把了。

END

Kubernetes CKA实战培训班推荐：

北京站：8月14-16日

本文分享自微信公众号 - K8S中文社区（k8schina）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。