哈喽哈喽大家好，上次初探Loki之后，就决定把ELK下掉，
上次的初探文章中，只是简单的对Loki做了一个入门介绍，并且很多小伙伴对于我要把ELK换掉的想法有不同的意见
所以这次我来说说我的想法
运维的核心目标是保障系统的稳定性和可靠性，而监控是贯穿整个运维生命周期的，为系统的稳定和可靠提供了可观察性及历史可追溯性，可以说，没有监控，运维就是在抓瞎
在整个运维生命周期中，监控覆盖硬件/系统级监控、应用服务指标监控、程序运行日志监控、业务监控、链路监控
而日志监控主要就是关注程序运行状态，当然，如果涉及业务日志，日志监控也能体现业务运行情况及业务访问量等
日志架构通常的做法就是：
- 日志收集
- 日志处理
- 日志存储
- 日志可视化
Loki与ELK抉择
而在Loki之前，你要问运维开源的日志解决方案，似乎只有ELK
不可否认，ELK通过对日志全文索引及列式存储，为日志存储及分析带来极大的便利性
但是从另一个角度来讲，这样的便利是通过极高的成本换来的，包括服务器成本和运维成本，而存储的日志中，高价值的日志却很少，这样的成效比是极低的
而Loki则恰恰相反，Loki不会对日志数据建立全文索引，取而代之的是对非结构化日志数据进行压缩存储，并且只对日志数据的metadata(时间戳、labels等)建立索引，所以相比ELK，它的存储成本更低，查询效率也更高
但是Loki也有缺点，就是如果想实现像ELK一样的复杂度比较高的查询，需要设计好Labels，如果对labels设计不合理，会使Loki对数据流的存储和查询带来极大的挑战，会使Loki崩溃，后面会专门写一篇对Loki的labels进行详细的分析的文章，今天只对Loki数据处理及功能组件进行分析
Loki的功能组件
Loki包含以下几个功能组件
- Promtail
- Distributor
- Ingester
- Querier
- Query Frontend
- Overrides
- TableManager
- RuntimeConfig
Loki架构图
Promtail
Promtail是负责日志数据的采集、提取、匹配、过滤、打lables、Push to loki这些工作的
支持的采集方式包括File Target、Journal Target、Syslog Target、Stdin Target
整个Promtail对日志数据处理流程如下
Promtail数据处理流程图
Distributor
Distributor主要接收Promtail Push过来的日志数据，并把日志数据分发给Ingester
Distributor与Ingester之间以RPC的方式进行通信，它通过对元数据进行hash算法计算出将日志数据分发到哪一个Ingester上
Distributor以日志数据的TenantID、Labels作为Hash key
Ingester
Ingester负责接收数据并构建chunk，存储日志索引及数据
Ingester构建chunk
当一个chunk填充满之后，ingester将其刷新到数据库，块和索引分别进行存储
Ingester存储chunk和index
刷新完一个chunk之后，Ingester会创建一个空的chunk
Querier
Querier负责数据读取，它通过给定的一个时间范围和标签选择器，查看索引以确定哪些块匹配，并通过greps聚合各个Ingester中的数据，并将结果返回给client
Grafana
Loki的数据查询，都是通过Grafana，在Grafana中支持loki的数据源，通过配置Loki的接口地址即可
Grafana的查询，支持LogQL，在Grafana中查询都是通过Label或log文本，支持语法如下：
Lable的操作符：
- = exactly equal
- != not equal
- =~ regex-match
- !~ do not regex-match
示例：{app="mysql",name=~"mysql-backup"}
Log文本内容操作：
- |= exactly equal
- != not equal
- |~ regex-match
- !~ do not regex-match
示例：
- {app="mysql",name=~"mysql-backup"} |~ "relog“
- {app="mysql",name=~"mysql-backup"} |~ "relog" !~ "slow"
以上就是今天整理的Loki的数据处理流程及功能组件作用的详细解释，下一篇会对Loki中数据流的概念以及Grafana中查询语法，Labels设计进行详细的分析，敬请期待！
