前言
这篇文章应朋友的要求，让写一篇loki日志系统，咱定义不容辞 一定要好好写 开干！
现实中的需求
公司的容器云运行的应用或某一个节点出现了问题，解决的思路
问题首先被prometheus监控
1、metric是来说明当前或者历史达到了某个值
2、alert设置metric达到某个特定的基数触发了告警
仅仅这些日志是不能够解决问题的 还需要看下应用的日志
k8s的基本单位是pod
pod把日志输出到stdout和stderr
当某个pod的内存变得很大
触发了我们的alert
这个时候管理员
去页面查询确认是哪个pod有问题
然后要确认pod内存变大的原因
我们还需要去查询pod的日志
如果没有日志系统
那么我们就需要到页面或者使用命令进行查询了
如果这个时候应用挂掉了 那么就没有办法再查询到相关日志了
解决该需求可供选择的方案
ELK
优势：
1、功能丰富，允许复杂的操作
劣势：
1、主流的ELK（全文检索）或者EFK比较重
2、ES复杂的搜索功能很多都用不上 规模复杂，资源占用高，操作苦难
大多数查询只关注一定时间范围和一些简单的参数（如host、service等）
3、Kibana和Grafana之间切换，影响用户体验
4、倒排索引的切分和共享的成本较高
Loki
1、最小化度量和日志的切换成本
有助于减少异常事件的响应时间和提高用户的体验
2、在查询语言的易操作性和复杂性之间可以达到一个权衡
3、更具成本效益
loki组件介绍
Promtail
- 用来将容器日志发送到 Loki 或者 Grafana 服务上的日志收集工具
- 该工具主要包括发现采集目标以及给日志流添加上 Label 标签 然后发送给 Loki
- Promtail 的服务发现是基于 Prometheus 的服务发现机制实现的
Loki
- 受 Prometheus 启发的可以水平扩展、高可用以及支持多租户的日志聚合系统
- 使用了和 Prometheus 相同的服务发现机制，将标签添加到日志流中而不是构建全文索引
- 从 Promtail 接收到的日志和应用的 metrics 指标就具有相同的标签集
- 不仅提供了更好的日志和指标之间的上下文切换，还避免了对日志进行全文索引
Grafana
- 一个用于监控和可视化观测的开源平台
- 支持非常丰富的数据源
- 在 Loki 技术栈中它专门用来展示来自 Prometheus 和 Loki 等数据源的时间序列数据
- 可进行查询、可视化、报警等操作
- 可以用于创建、探索和共享数据 Dashboard
- 鼓励数据驱动
Loki架构
1、
Loki使用了和prometheus一样的标签来作为索引
通过标签既可以查询日志的内容也可以查询到监控的数据
不但减少了两种查询之间的切换成本
也极大地降低了日志索引的存储
2、
Loki将使用与prometheus相同的服务发现和标签重新标记库编写了pormtail
在k8s中promtail以daemonset方式运行在每个节点中
通过kubernetes api等到日志的正确元数据
并将它们发送到Loki
日志的存储架构
