更适合中小企业的日志系统loki

运维的核心目标是保障系统的稳定性和可靠性&＃xff0c;而监控是贯穿整个运维生命周期的&＃xff0c;为系统的稳定和可靠提供了可观察性及历史可追溯性&＃xff0c;可以说&＃xff0c;没有监控&＃xff0c;运维就是在抓瞎

在整个运维生命周期中&＃xff0c;监控覆盖硬件/系统级监控、应用服务指标监控、程序运行日志监控、业务监控、链路监控

而日志监控主要就是关注程序运行状态&＃xff0c;当然&＃xff0c;如果涉及业务日志&＃xff0c;日志监控也能体现业务运行情况及业务访问量等

日志架构通常的做法就是&＃xff1a;

• 日志收集
• 日志处理
• 日志存储
• 日志可视化

Loki与ELK抉择

而在Loki之前&＃xff0c;你要问运维开源的日志解决方案&＃xff0c;似乎只有ELK

不可否认&＃xff0c;ELK通过对日志全文索引及列式存储&＃xff0c;为日志存储及分析带来极大的便利性

但是从另一个角度来讲&＃xff0c;这样的便利是通过极高的成本换来的&＃xff0c;包括服务器成本和运维成本&＃xff0c;而存储的日志中&＃xff0c;高价值的日志却很少&＃xff0c;这样的成效比是极低的

而Loki则恰恰相反&＃xff0c;Loki不会对日志数据建立全文索引&＃xff0c;取而代之的是对非结构化日志数据进行压缩存储&＃xff0c;并且只对日志数据的metadata(时间戳、labels等)建立索引&＃xff0c;所以相比ELK&＃xff0c;它的存储成本更低&＃xff0c;查询效率也更高

但是Loki也有缺点&＃xff0c;就是如果想实现项ELK一样的复杂度比较高的查询&＃xff0c;需要设计好Labels&＃xff0c;如果对labels设计不合理&＃xff0c;会使Loki对数据流的存储和查询带来极大的挑战&＃xff0c;会使Loki崩溃&＃xff0c;后面会专门写一篇对Loki的labels进行详细的分析的文章&＃xff0c;今天只对Loki数据处理及功能组件进行分析

Loki的功能组件

Loki包含以下几个功能组件

• Promtail
  

Promtail是负责日志数据的采集、提取、匹配、过滤、打lables、Push to loki这写工作的

支持的采集方式包括File Target、Journal Target、Syslog Target、Stdin Target

整个Promtail对日志数据处理流程如下

• Distributor

Distributor主要接收Promtail Push过来的日志数据&＃xff0c;并把日志数据分发给Ingester

Distributor与Ingester之间以RPC的方式进行通信&＃xff0c;它通过对元数据进行hash算法计算出将日志数据分发到哪一个Ingester上

Distributor以日志数据的TenantID、Labels作为Hash key

• Ingester

Ingester负责接收数据并构建chunk&＃xff0c;存储日志索引及数据

当一个chunk填充满之后&＃xff0c;ingester将其刷新到数据库&＃xff0c;块和索引分别进行存储

刷新完一个chunk之后&＃xff0c;Ingester会创建一个空的chunk

• Querier
  

Querier负责数据读取&＃xff0c;它通过给定的一个时间范围和标签选择器&＃xff0c;查看索引以确定哪些块匹配&＃xff0c;并通过greps聚合各个Ingester中的数据&＃xff0c;并将结果返回给client

• Grafana

Loki的数据查询&＃xff0c;都是通过Grafana&＃xff0c;在Grafana中支持loki的数据源&＃xff0c;通过配置Loki的接口地址即可

Grafana的查询&＃xff0c;支持LogQL&＃xff0c;在Grafana中查询都是通过Label或log文本