日志系统新贵 Loki，真香
https://blog.csdn.net/Linkthaha/
最近 ， 在对公司容器云的日志方案进行设计的时候 ， 发现主流的ELK或者EFK比较重 ， 再加上现阶段对于ES复杂的搜索功能很多都用不上最终选择了Grafana开源的Loki日志系统 ， 下面介绍下Loki的背景 。
文章图片
背景和动机当我们的容器云运行的应用或者某个节点出现问题了 ， 解决思路应该如下：
文章图片
我们的监控使用的是基于prometheus体系进行改造的 ， prometheus中比较重要的是metric和alert,metric是来说明当前或者历史达到了某个值 ， alert设置metric达到某个特定的基数触发了告警 ， 但是这些信息明显是不够的 。
我们都知道 ， k8s的基本单位是pod,pod把日志输出到stdout和stderr,平时有什么问题我们通常在界面或者通过命令查看相关的日志
【日志系统新贵 Loki，真香】举个例子：当我们的某个pod的内存变得很大 ， 触发了我们的alert ， 这个时候管理员 ， 去页面查询确认是哪个pod有问题 ， 然后要确认pod内存变大的原因 ， 我们还需要去查询pod的日志 ， 如果没有日志系统 ， 那么我们就需要到页面或者使用命令进行查询了：
文章图片
如果 ， 这个时候应用突然挂了 ， 这个时候我们就无法查到相关的日志了 ， 所以需要引入日志系统 ， 统一收集日志 ， 而使用ELK的话 ， 就需要在Kibana和Grafana之间切换 ， 影响用户体验 。
所以 ， loki的第一目的就是最小化度量和日志的切换成本 ， 有助于减少异常事件的响应时间和提高用户的体验
ELK存在的问题现有的很多日志采集的方案都是采用全文检索对日志进行索引（如ELK方案） ， 优点是功能丰富 ， 允许复杂的操作 。
但是 ， 这些方案往往规模复杂 ， 资源占用高 ， 操作苦难 。 很多功能往往用不上 ， 大多数查询只关注一定时间范围和一些简单的参数（如host、service等） ， 使用这些解决方案就有点杀鸡用牛刀的感觉了 。
文章图片
因此 ， Loki的第二个目的是 ， 在查询语言的易操作性和复杂性之间可以达到一个权衡 。
成本全文检索的方案也带来成本问题 ， 简单的说就是全文搜索（如：ES）的倒排索引的切分和共享的成本较高 。
后来出现了其他不同的设计方案如：OKlog(https://github.com/oklog/oklog),采用最终一致的、基于网格的分布策略 。
这两个设计决策提供了大量的成本降低和非常简单的操作 ， 但是查询不够方便 。 因此 ， Loki的第三个目的是 ， 提高一个更具成本效益的解决方案 。
整体架构Loki的架构如下：
文章图片
不难看出 ， Loki的架构非常简单 ， 使用了和prometheus一样的标签来作为索引 ， 也就是说 ， 你通过这些标签既可以查询日志的内容也可以查询到监控的数据 ， 不但减少了两种查询之间的切换成本 ， 也极大地降低了日志索引的存储 。
Loki将使用与prometheus相同的服务发现和标签重新标记库,编写了pormtail,在k8s中promtail以daemonset方式运行在每个节点中 ， 通过kubernetesapi等到日志的正确元数据 ， 并将它们发送到Loki 。 下面是日志的存储架构：
文章图片
读写日志数据的写主要依托的是Distributor和Ingester两个组件,整体的流程如下：
文章图片
Distributor一旦promtail收集日志并将其发送给loki ， Distributor就是第一个接收日志的组件 。 由于日志的写入量可能很大 ， 所以不能在它们传入时将它们写入数据库 。 这会毁掉数据库 。 我们需要批处理和压缩数据 。
Loki通过构建压缩数据块来实现这一点 ， 方法是在日志进入时对其进行gzip操作 ， 组件ingester是一个有状态的组件 ， 负责构建和刷新chunck ， 当chunk达到一定的数量或者时间后 ， 刷新到存储中去 。 每个流的日志对应一个ingester,当日志到达Distributor后 ， 根据元数据和hash算法计算出应该到哪个ingester上面 。
文章图片
此外 ， 为了冗余和弹性 ， 我们将其复制n（默认情况下为3）次 。
Ingesteringester接收到日志并开始构建chunk:
文章图片
基本上就是将日志进行压缩并附加到chunk上面 。 一旦chunk“填满”（数据达到一定数量或者过了一定期限） ， ingester将其刷新到数据库 。 我们对块和索引使用单独的数据库 ， 因为它们存储的数据类型不同 。
文章图片
刷新一个chunk之后 ， ingester然后创建一个新的空chunk并将新条目添加到该chunk中 。
Querier读取就非常简单了 ， 由Querier负责给定一个时间范围和标签选择器 ， Querier查看索引以确定哪些块匹配 ， 并通过greps将结果显示出来 。 它还从Ingester获取尚未刷新的最新数据 。
对于每个查询 ， 一个查询器将为您显示所有相关日志 。 实现了查询并行化 ， 提供分布式grep ， 使即使是大型查询也是足够的 。
文章图片
可扩展性Loki的索引存储可以是cassandra/bigtable/dynamodb ， 而chuncks可以是各种对象存储 ， Querier和Distributor都是无状态的组件 。
对于ingester他虽然是有状态的但是 ， 当新的节点加入或者减少 ， 整节点间的chunk会重新分配 ， 已适应新的散列环 。 而Loki底层存储的实现Cortex已经在实际的生产中投入使用多年了 。 有了这句话 ， 我可以放心的在环境中实验一把了 。
推荐阅读
- 现代迎来技术“爆发”解读第十代索纳塔动力系统
- 苹果|再次确认如果安卓系统不支持微信，鸿蒙OS是最大赢家
- Android系统|如果华为Mate40Pro定价5999元起，那我一定会劝你买它
- 精神药品|重磅！银河麒麟操作系统V10发布 支持海量安卓应用
- 华为鸿蒙系统|噱头还是真有用？如何看待PCIe 4.0
- 鸿蒙系统|华为Mate40稳了！迎来两大好消息，iPhone 12迎来劲敌
- IOS系统|iOS的TestFlight应用获得新图标 更加立体与写实
- 小米科技|鸿蒙系统手机或很快推出，小米实行合伙人制度
- 打破安卓系统垄断？华为鸿蒙系统手机或很快推出
- 华为鸿蒙系统|华为鸿蒙OS手机被曝即将推出，今年能看到真机吗？