最近，在对公司容器云的日志方案进行设计的时候，发现主流的ELK或者EFK比较重，再加上现阶段对于ES复杂的搜索功能很多都用不上最终选择了Grafana开源的Loki日志系统，下面介绍下Loki的背景。
背景和动机
当我们的容器云运行的应用或者某个节点出现问题了，解决思路应该如下：
我们的监控使用的是基于Prometheus体系进行改造的，Prometheus中比较重要的是Metric和Alert，Metric是来说明当前或者历史达到了某个值，Alert设置Metric达到某个特定的基数触发了告警，但是这些信息明显是不够的。我们都知道，Kubernetes的基本单位是Pod，Pod把日志输出到stdout和stderr，平时有什么问题我们通常在界面或者通过命令查看相关的日志，举个例子：当我们的某个Pod的内存变得很大，触发了我们的Alert，这个时候管理员，去页面查询确认是哪个Pod有问题，然后要确认Pod内存变大的原因，我们还需要去查询Pod的日志，如果没有日志系统，那么我们就需要到页面或者使用命令进行查询了：
如果，这个时候应用突然挂了，这个时候我们就无法查到相关的日志了，所以需要引入日志系统，统一收集日志，而使用ELK的话，就需要在Kibana和Grafana之间切换，影响用户体验。所以 ，loki的第一目的就是最小化度量和日志的切换成本，有助于减少异常事件的响应时间和提高用户的体验。
ELK存在的问题
现有的很多日志采集的方案都是采用全文检索对日志进行索引（如ELK方案），优点是功能丰富，允许复杂的操作。但是，这些方案往往规模复杂，资源占用高，操作苦难。很多功能往往用不上，大多数查询只关注一定时间范围和一些简单的参数（如host、service等），使用这些解决方案就有点杀鸡用牛刀的感觉了。
因此，Loki的第二个目的是，在查询语言的易操作性和复杂性之间可以达到一个权衡。
成本
全文检索的方案也带来成本问题，简单的说就是全文搜索（如ES）的倒排索引的切分和共享的成本较高。后来出现了其他不同的设计方案如：
OKlog
，采用最终一致的、基于网格的分布策略。这两个设计决策提供了大量的成本降低和非常简单的操作，但是查询不够方便。因此，Loki的第三个目的是，提高一个更具成本效益的解决方案。
整体架构
Loki的架构如下：
不难看出，Loki的架构非常简单，使用了和Prometheus一样的标签来作为索引，也就是说，你通过这些标签既可以查询日志的内容也可以查询到监控的数据，不但减少了两种查询之间的切换成本，也极大地降低了日志索引的存储。Loki将使用与Prometheus相同的服务发现和标签重新标记库，编写了pormtail，在Kubernetes中promtail以DaemonSet方式运行在每个节点中，通过Kubernetes API等到日志的正确元数据，并将它们发送到Loki。下面是日志的存储架构：
