再见，ELK _ELK_江苏龙网

Loki 作为一个新兴的日志解决方案，现在越来越受到关注。经过调研比较，我们正在将日志服务底层逐步从 ES 替换为 Loki。

文章插图
图片来自 Pexels
本文基于我们对 Loki 的使用和理解，从它产生的背景、解决的问题、采用的方案、系统架构、实现逻辑等做一些剖析，希望对关注 Loki 的小伙伴们提供一些帮助。
在日常的系统可视化监控过程中，当监控探知到指标异常时，我们往往需要对问题的根因做出定位。
但监控数据所暴露的信息是提前预设、高度提炼的，在信息量上存在着很大的不足，它需要结合能够承载丰富信息的日志系统一起使用。
当监控系统探知到异常告警，我们通常在 Dashboard 上根据异常指标所属的集群、主机、实例、应用、时间等信息圈定问题的大致方向，然后跳转到日志系统做更精细的查询，获取更丰富的信息来最终判断问题根因。
在如上流程中，监控系统和日志系统往往是独立的，使用方式具有很大差异。比如监控系统 Prometheus 比较受欢迎，日志系统多采用 ES+Kibana。
他们具有完全不同的概念、不同的搜索语法和界面，这不仅给使用者增加了学习成本，也使得在使用时需在两套系统中频繁做上下文切换，对问题的定位迟滞。
此外，日志系统多采用全文索引来支撑搜索服务，它需要为日志的原文建立反向索引，这会导致最终存储数据相较原始内容成倍增长，产生不可小觑的存储成本。
并且，不管数据将来是否会被搜索，都会在写入时因为索引操作而占用大量的计算资源，这对于日志这种写多读少的服务无疑也是一种计算资源的浪费。
Loki 则是为了应对上述问题而产生的解决方案，它的目标是打造能够与监控深度集成、成本极度低廉的日志系统。
Loki 日志方案
低使用成本
①数据模型
在数据模型上， Loki 参考了 Prometheus ，数据由标签、时间戳、内容组成，所有标签相同的数据属于同一日志流：

标签，描述日志所属集群、服务、主机、应用、类型等元信息，用于后期搜索服务。
时间戳，日志的产生时间。
内容，日志的原始内容。

具有如下结构：

{"stream": {"label1": "value1","label1": "value2"}, # 标签"values": [["<timestamp nanoseconds>","log content"], # 时间戳 ， 内容["<timestamp nanoseconds>","log content"]] }

Loki 还支持多租户，同一租户下具有完全相同标签的日志所组成的集合称为一个日志流。
在日志的采集端使用和监控时序数据一致的标签，这样在可以后续与监控系统结合时使用相同的标签，也为在 UI 界面中与监控结合使用做快速上下文切换提供数据基础。
LogQL：Loki 使用类似 Prometheus 的 PromQL 的查询语句 logQL ，语法简单并贴近社区使用习惯，降低用户学习和使用成本。
语法例子如下：
{file="debug.log""} |= "err" 流选择器：{label1="value1", label2="value2"} ，通过标签选择日志流，支持等、不等、匹配、不匹配等选择方式。过滤器：|= "err" ，过滤日志内容，支持包含、不包含、匹配、不匹配等过滤方式。
这种工作方式类似于 find+grep ， find 找出文件， grep 从文件中逐行匹配：
find . -name "debug.log" | grep err logQL 除支持日志内容查询外，还支持对日志总量、频率等聚合计算。
Grafana：在 Grafana 中原生支持 Loki 插件，将监控和日志查询集成在一起，在同一 UI 界面中可以对监控数据和日志进行 side-by-side 的下钻查询探索，比使用不同系统反复进行切换更直观、更便捷。