ELK太笨重了?想放弃?快试试日志系统新贵Loki吧!
程序员的成长之路
共 2368字,需浏览 5分钟
· 2020-07-17
程序员的成长之路互联网/程序员/技术/资料共享 关注
阅读本文大概需要 4 分钟。
来自:suo.im/5EZQaP
最近,在对公司容器云的日志方案进行设计的时候,发现主流的ELK或者EFK比较重,再加上现阶段对于ES复杂的搜索功能很多都用不上最终选择了Grafana开源的Loki日志系统,下面介绍下Loki的背景。背景和动机
当我们的容器云运行的应用或者某个节点出现问题了,解决思路应该如下:![100fdceac77e2258859111d5813502fd.webp](https://filescdn.proginn.com/59bfd72e7d6fbc9b317502cfe55c7881/100fdceac77e2258859111d5813502fd.webp)
![d6e487752833f389700f72fe57d241f7.webp](https://filescdn.proginn.com/0d2d810eea59f500d5d1c68d36f33b62/d6e487752833f389700f72fe57d241f7.webp)
所以 ,loki的第一目的就是最小化度量和日志的切换成本,有助于减少异常事件的响应时间和提高用户的体验
ELK存在的问题
现有的很多日志采集的方案都是采用全文检索对日志进行索引(如ELK方案),优点是功能丰富,允许复杂的操作。但是,这些方案往往规模复杂,资源占用高,操作苦难。很多功能往往用不上,大多数查询只关注一定时间范围和一些简单的参数(如host、service等),使用这些解决方案就有点杀鸡用牛刀的感觉了。![cbc582da02dc11c34893fca0a5518f9f.webp](https://filescdn.proginn.com/ea5cd2c22c90168600a3c4bcc6c8588d/cbc582da02dc11c34893fca0a5518f9f.webp)
成本
全文检索的方案也带来成本问题,简单的说就是全文搜索(如ES)的倒排索引的切分和共享的成本较高。后来出现了其他不同的设计方案如:OKlog(https://github.com/oklog/oklog),采用最终一致的、基于网格的分布策略。这两个设计决策提供了大量的成本降低和非常简单的操作,但是查询不够方便。因此,Loki的第三个目的是,提高一个更具成本效益的解决方案。整体架构
Loki的架构如下:![f168ed4af096374ac3abc69d835c79ac.webp](https://filescdn.proginn.com/490421255c40cd85575fe98a6ff75335/f168ed4af096374ac3abc69d835c79ac.webp)
Loki将使用与prometheus相同的服务发现和标签重新标记库,编写了pormtail, 在k8s中promtail以daemonset方式运行在每个节点中,通过kubernetes api等到日志的正确元数据,并将它们发送到Loki。
下面是日志的存储架构:
![1118e643fb94075fb46fd48e800ff11f.webp](https://filescdn.proginn.com/5e4a47d789e5f134e79379e727c39d8a/1118e643fb94075fb46fd48e800ff11f.webp)
读写
日志数据的写主要依托的是Distributor和Ingester两个组件,整体的流程如下:![827f92b0f99e5d2053c95204c5999afe.webp](https://filescdn.proginn.com/2ce14feac2ae09e2780d970f6f48dddf/827f92b0f99e5d2053c95204c5999afe.webp)
Distributor
一旦promtail收集日志并将其发送给loki,Distributor就是第一个接收日志的组件。由于日志的写入量可能很大,所以不能在它们传入时将它们写入数据库。这会毁掉数据库。我们需要批处理和压缩数据。Loki通过构建压缩数据块来实现这一点,方法是在日志进入时对其进行gzip操作,组件ingester是一个有状态的组件,负责构建和刷新chunck,当chunk达到一定的数量或者时间后,刷新到存储中去。每个流的日志对应一个ingester,当日志到达Distributor后,根据元数据和hash算法计算出应该到哪个ingester上面。![c3e1ab630252806e086dc6b78de1209f.webp](https://filescdn.proginn.com/0d16735ad5ad2be9a3c20f8e4a2c80a4/c3e1ab630252806e086dc6b78de1209f.webp)
Ingester
ingester接收到日志并开始构建chunk:![ea0825464094ad57ed3f0e81e760e47e.webp](https://filescdn.proginn.com/737aaebcfb5f3d755a31a19e82fba086/ea0825464094ad57ed3f0e81e760e47e.webp)
![65bff885e5cf9da6140e439d2b48185e.webp](https://filescdn.proginn.com/3bdb7820a0d5e857d78729574cec1fcd/65bff885e5cf9da6140e439d2b48185e.webp)
Querier
读取就非常简单了,由Querier负责给定一个时间范围和标签选择器,Querier查看索引以确定哪些块匹配,并通过greps将结果显示出来。它还从Ingester获取尚未刷新的最新数据。对于每个查询,一个查询器将为您显示所有相关日志。实现了查询并行化,提供分布式grep,使即使是大型查询也是足够的。![70ab90a20639a20bbc79e3110e23802b.webp](https://filescdn.proginn.com/493f6aa205756fc40ddc56cdd00283e4/70ab90a20639a20bbc79e3110e23802b.webp)
可扩展性
Loki的索引存储可以是cassandra/bigtable/dynamodb,而chuncks可以是各种对象存储,Querier和Distributor都是无状态的组件。对于ingester他虽然是有状态的但是,当新的节点加入或者减少,整节点间的chunk会重新分配,已适应新的散列环。而Loki底层存储的实现Cortex已经 在实际的生产中投入使用多年了。有了这句话,我可以放心的在环境中实验一把了。推荐阅读:
微信扫描二维码,关注我的公众号
写留言朕已阅
评论