elk日志收集系统linux_比ELK轻量的日志系统新贵Loki

作者&＃xff1a; inkt1234

来源&＃xff1a;https://blog.csdn.net/Linkthaha/article/details/100575278

• 背景和动机
• ELK存在的问题
• 成本
• 整体架构
• 读写
• 可扩展性

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

背景和动机

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

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

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

ELK存在的问题

现有的很多日志采集的方案都是采用全文检索对日志进行索引&＃xff08;如ELK方案&＃xff09;&＃xff0c;优点是功能丰富&＃xff0c;允许复杂的操作。但是&＃xff0c;这些方案往往规模复杂&＃xff0c;资源占用高&＃xff0c;操作苦难。很多功能往往用不上&＃xff0c;大多数查询只关注一定时间范围和一些简单的参数&＃xff08;如host、service等&＃xff09;&＃xff0c;使用这些解决方案就有点杀鸡用牛刀的感觉了。因此&＃xff0c;Loki的第二个目的是&＃xff0c;在查询语言的易操作性和复杂性之间可以达到一个权衡。

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

成本

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

整体架构

Loki的架构如下&＃xff1a;

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

读写

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

Distributor

一旦promtail收集日志并将其发送给loki&＃xff0c;Distributor就是第一个接收日志的组件。由于日志的写入量可能很大&＃xff0c;所以不能在它们传入时将它们写入数据库。这会毁掉数据库。我们需要批处理和压缩数据。 Loki通过构建压缩数据块来实现这一点&＃xff0c;方法是在日志进入时对其进行gzip操作&＃xff0c;组件ingester是一个有状态的组件&＃xff0c;负责构建和刷新chunck&＃xff0c;当chunk达到一定的数量或者时间后&＃xff0c;刷新到存储中去。每个流的日志对应一个ingester,当日志到达Distributor后&＃xff0c;根据元数据和hash算法计算出应该到哪个ingester上面。

此外&＃xff0c;为了冗余和弹性&＃xff0c;我们将其复制n&＃xff08;默认情况下为3&＃xff09;次。

Ingester

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

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

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

Querier

读取就非常简单了&＃xff0c;由Querier负责给定一个时间范围和标签选择器&＃xff0c;Querier查看索引以确定哪些块匹配&＃xff0c;并通过greps将结果显示出来。它还从Ingester获取尚未刷新的最新数据。 对于每个查询&＃xff0c;一个查询器将为您显示所有相关日志。实现了查询并行化&＃xff0c;提供分布式grep&＃xff0c;使即使是大型查询也是足够的。

可扩展性

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