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

简介: 日志系统新贵Loki,确实比笨重的ELK轻

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

 

背景和动机

 

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

 

 

我们的监控使用的是基于prometheus体系进行改造的,prometheus中比较重要的是metric和alert,metric是来说明当前或者历史达到了某个值,alert设置metric达到某个特定的基数触发了告警,但是这些信息明显是不够的。

 

我们都知道,k8s的基本单位是pod,pod把日志输出到stdout和stderr,平时有什么问题我们通常在界面或者通过命令查看相关的日志,举个例子:当我们的某个pod的内存变得很大,触发了我们的alert,这个时候管理员,去页面查询确认是哪个pod有问题,然后要确认pod内存变大的原因,我们还需要去查询pod的日志,如果没有日志系统,那么我们就需要到页面或者使用命令进行查询了:

 

 

如果,这个时候应用突然挂了,这个时候我们就无法查到相关的日志了,所以需要引入日志系统,统一收集日志,而使用ELK的话,就需要在Kibana和Grafana之间切换,影响用户体验。

 

所以 ,loki的第一目的就是最小化度量和日志的切换成本,有助于减少异常事件的响应时间和提高用户的体验

 

ELK存在的问题

 

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

 

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

 

成本

 

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

 

后来出现了其他不同的设计方案如:

 

OKlog(https://github.com/oklog/oklog),采用最终一致的、基于网格的分布策略。这两个设计决策提供了大量的成本降低和非常简单的操作,但是查询不够方便。因此,Loki的第三个目的是,提高一个更具成本效益的解决方案。

 

整体架构

 

Loki的架构如下:

 

 

不难看出,Loki的架构非常简单,使用了和prometheus一样的标签来作为索引,也就是说,你通过这些标签既可以查询日志的内容也可以查询到监控的数据,不但减少了两种查询之间的切换成本,也极大地降低了日志索引的存储。

 

Loki将使用与prometheus相同的服务发现和标签重新标记库,编写了pormtail, 在k8s中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已经 在实际的生产中投入使用多年了。有了这句话,我可以放心的在环境中实验一把了。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
1月前
|
存储 监控 数据可视化
日志分析对决:揭示 ELK 与 GrayLog 的优势和差异
日志分析对决:揭示 ELK 与 GrayLog 的优势和差异
449 0
|
1月前
|
Prometheus Cloud Native 数据库
Grafana 系列文章(九):开源云原生日志解决方案 Loki 简介
Grafana 系列文章(九):开源云原生日志解决方案 Loki 简介
|
18天前
|
存储 编解码 监控
实验模拟 搭建elk 日志分析系统
实验模拟 搭建elk 日志分析系统
|
18天前
|
存储 监控 Java
ELK 企业级日志分析系统 简单介绍
ELK 企业级日志分析系统 简单介绍
|
26天前
|
监控 应用服务中间件 nginx
使用 Docker Compose V2 快速搭建日志分析平台 ELK (Elasticsearch、Logstash 和 Kibana)
ELK的架构有多种,本篇分享使用的架构如图所示: Beats(Filebeat) -> -> Elasticsearch -> Kibana,目前生产环境一天几千万的日志,内存占用大概 10G
60 4
|
1月前
|
消息中间件 存储 运维
更优性能与性价比,从自建 ELK 迁移到 SLS 开始
本文介绍了 SLS 基本能力,并和开源自建 ELK 做了对比,可以看到 SLS 相比开源 ELK 有较大优势。
55499 148
|
1月前
|
存储 监控 数据可视化
Nginx+Promtail+Loki+Grafana Nginx日志展示
通过这些步骤,你可以将Nginx的日志收集、存储、查询和可视化整合在一起。这样,你就可以在Grafana中轻松地创建和展示Nginx日志的图表和面板。
84 3
|
1月前
|
存储 监控 关系型数据库
ELK架构监控MySQL慢日志
ELK架构监控MySQL慢日志
|
1月前
|
存储 测试技术 索引
「译文」Loki 简明指南:如何处理失序和较旧的日志
「译文」Loki 简明指南:如何处理失序和较旧的日志
|
1月前
|
存储 Prometheus Cloud Native
「译文」开源日志监控:Grafana Loki 简要指南
「译文」开源日志监控:Grafana Loki 简要指南