文章目录【0】简介为什么不是ELK 【1】loki聚合组件 检查loki配置文件修改loki 的数据默认路径loki 生产配置配置优化测试loki启动loki参考【2】 收集组件 启动参考【3】接入qms ap log 和nginx日志【4】接入k8s 日志【5】接入etl日志【6】接入k8s pod日志 【7】接入MFG 日志 【8】 接入日志 【9】接入HMS、FL 日志 【】随想【】疑问 日志可视化系统 RMS如何学习
【-1】效果展示 Loki 指标展示
日志展示
内存分析案例
业务请求量分析统计
自由探索日志
【0】简介
GLP全称:loki , 一个轻量级的云原生日志检索系统 。
对于数据，Loki 不会构建全文索引，而是通过 Label 的方式去构建索引，并通过 Grep 查询匹配对应的 COS 。
对于存储，Index 和 ，是可以刷到廉价的第三方 COS 对象存储中 。
这样跟 ELK 一对比，成本的优化是巨大的 。
且在 Loki 2.0 版本之后，对于存储索引做了较大的升级，采取 - 模式，可以直接让 Loki 索引存储在 S3 中，无需。
考虑到当前压测日志业务场景无需支撑 TB 级别的检索，所以设计一套读写分离架构的非分布式 Loki 服务即可 。
架构如下
学习 自定义查询按钮
每个查询按钮都定义在的，如下图.
如果需要自定义查询条件在这里添加 。
为什么不是ELK
是个开源分布式搜索引擎，对非结构化的数据，也能进行分词，倒排索引，从而提供快速的全文搜索 。
所以这里存储的索引，是一个巨大的量级 。
更关键的是， 需要的是内存！
底层存储引擎是基于 ， 的倒排索引，需要先在内存里生成，然后定期以段文件的形式刷到硬盘里 。
所以的堆内存最好不要超过物理机内存的一半，需要预留一半的内存给使用 。
好用是好用，就是真的贵，构建一个 ELK 成本高 。
所以在降本增效的主题下，PLG 成为了新贵！
ELK
优势：
1、功能丰富，允许复杂的操作
劣势：
1、主流的ELK（全文检索）或者EFK比较重
2、ES复杂的搜索功能很多都用不上 规模复杂，资源占用高，操作苦难
大多数查询只关注一定时间范围和一些简单的参数（如host、等）
3、和之间切换，影响用户体验
4、倒排索引的切分和共享的成本较高
Loki
1、最小化度量和日志的切换成本
有助于减少异常事件的响应时间和提高用户的体验
2、在查询语言的易操作性和复杂性之间可以达到一个权衡
3、更具成本效益
【1】loki聚合组件 架构
读写
日志数据的写主要依托的是和两个组件，整体的流程如下：
一旦收集日志并将其发送给loki，就是第一个接收日志的组件 。由于日志的写入量可能很大，所以不能在它们传入时将它们写入数据库 。这会毁掉数据库 。我们需要批处理和压缩数据 。
Loki通过构建压缩数据块来实现这一点，方法是在日志进入时对其进行gzip操作，组件是一个有状态的组件，负责构建和刷新，当chunk达到一定的数量或者时间后，刷新到存储中去 。每个流的日志对应一个，当日志到达后，根据元数据和hash算法计算出应该到哪个上面 。
此外，为了冗余和弹性，我们将其复制n（默认情况下为3）次 。
接收到日志并开始构建chunk：
基本上就是将日志进行压缩并附加到chunk上面 。一旦chunk“填满”（数据达到一定数量或者过了一定期限），将其刷新到数据库 。我们对块和索引使用单独的数据库，因为它们存储的数据类型不同 。
刷新一个chunk之后，然后创建一个新的空chunk并将新条目添加到该chunk中 。