数据库|日志系统新贵Loki，确实比笨重的ELK轻
后台回复"666" ， 获取新资料
转载自：http://suo.im/5EZQaP
最近 ， 在对公司容器云的日志方案进行设计的时候 ， 发现主流的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，确实比笨重的ELK轻】
本文插图
因此 ， Loki的第二个目的是 ， 在查询语言的易操作性和复杂性之间可以达到一个权衡 。
成本 全文检索的方案也带来成本问题 ， 简单的说就是全文搜索（如ES）的倒排索引的切分和共享的成本较高 。 后来出现了其他不同的设计方案如：OKlog(https://github.com/oklog/oklog),采用最终一致的、基于网格的分布策略 。 这两个设计决策提供了大量的成本降低和非常简单的操作 ， 但是查询不够方便 。 因此 ， Loki的第三个目的是 ， 提高一个更具成本效益的解决方案 。
整体架构 Loki的架构如下：
本文插图
不难看出 ， Loki的架构非常简单 ， 使用了和prometheus一样的标签来作为索引 ， 也就是说 ， 你通过这些标签既可以查询日志的内容也可以查询到监控的数据 ， 不但减少了两种查询之间的切换成本 ， 也极大地降低了日志索引的存储 。 Loki将使用与prometheus相同的服务发现和标签重新标记库,编写了pormtail, 在k8s中promtail以daemonset方式运行在每个节点中 ， 通过kubernetes api等到日志的正确元数据 ， 并将它们发送到Loki 。 下面是日志的存储架构：
推荐阅读
- 技术编程|如何利用数据库进行世界史研究
- 人工智能|敏捷开发框架的开发运用之智能办公管理系统的开发
- 产品|全国唯一户外15米远距离AI测温系统深兰猫头鹰获工信部嘉奖
- Android系统|超值的“超大杯”HiFi播放器，索尼NW-A105HN评测
- Android系统|国人笑而不语！Android 11新要求 相机默认不能设置为“美颜”模式
- IOS系统|苹果免签封装如何实现？苹果免签封装会不会掉签？
- 摄影|传音主导首个移动终端计算摄影系统国际标准获ITU-T正式立项
- Android系统|想玩转MIUI12全局小窗，你要先清楚它的各种打开方式
- windows系统|半年过去了：Win10 5月更新磁盘碎片整理工具问题依然存在
- Android系统,鲁大师|最新UI排名出炉：小米MIUI第九，魅族消失，黑马出现！