日志系统之 EFK vs. PLG Stack
Posted 小飞写创
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了日志系统之 EFK vs. PLG Stack相关的知识，希望对你有一定的参考价值。
随着分布式系统日益复杂，云原生解决方案日益增多，监控和系统可观测性成为了解系统行为方式的一个非常重要的方面。我们需要一个可以从所有服务中收集数据的工具，一个可为我们提供系统性能、错误事件、日志和系统可用性的视图工具，如下图。在本文中，我们将讲讲两个主流的技术栈，EFK和PLG的架构和区别。
你可能听过ELK，EFK是用性能更优的 Fluentd 代替了 Logstash。Elasticsearch 是一个对象存储、搜索和分析引擎。Fluentd 是一个开源的数据收集器。Kibana 是用图形和图表对 Elasticsearch 数据进行可视化展示的工具。
EFK工作流程是这样的：
再讲讲PLG(Promtail, Loki and Grafana)
可能你在搜索引擎上搜不到这个首字母缩写，因为它大部分时间被称为 Grafana Loki（下文称为 Loki），也就是说 PLG Stack 结合起来就是 Grafana Loki。Promtail 是一个将日志送到 Loki 集群的代理。Loki 是一个可水平扩展、高可用、多租户的日志聚合系统。Grafana 与 Kibana 类似，它是消费 Loki 数据的可视化工具。
Loki 可以配置为单进程模式（单体模式）或多进程模式（微服务模式），多进程模式与 Loki 的水平扩展性和高可用性对应。
来源：https://grafana.com/docs/loki/latest/architecture
单进程模型非常适合本地开发和小数据量的监视。对于生产或较大的数据负载，建议使用多进程模型。于此同时，Loki 的读写是分离的，因此可以根据需要独立“弹”读写节点。
来源：https://grafana.com/docs/loki/latest/architecture
分发器负责处理客户端的输入流，可以类比 DispatcherServlet，是写入日志到 Loki 的第一个节点。一旦接收到一组输入流，分发器会校验每个输入流的正确性，校验完成后会将有效的部分拆分成多个批次并行地发送到多个 Ingester（没想到怎么翻译）。
Ingester 负责写日志到长期存储组件 (DynamoDB, S3, Cassandra等) ，其实就是把日志写到磁盘，和负责读日志到内存。
查询器使用 LogQL 处理查询请求，它会同时从 Ingester 和长期存储组件中拉取日志，当然在查询长期存储组件之前会先查询 Ingester。
Query Frontend 是提供查询API的可选服务，也可加快读日志的速度。如果配置了 Query Frontend，查询请求会重定向到 Query Frontend，而不是
Querier。
Read Path
Querier 接收到 HTTP 请求。
Querier 将查询请求传到 Ingester。
Ingester 接收到读请求会返回匹配的数据，如果有的话。
如果 Ingester 没有数据返回，则 Querier 会从磁盘懒加载。
Querier 会遍历所有接收到的数据并去重，然后返回给 HTTP 链接。
Write Path
Distributor 接收到 HTTP 请求。
Distributor 将 HTTP 输入流进行哈希，发送到各 Ingester。
Ingester 接收到读请求会返回匹配的数据，如果有的话。
Ingester 创建数据块存储流数据或追加到现有的数据块中。
Distributor 返回一个成功的 HTTP 链接。
查询语言 Query DSL, Lucene Query Lnguage VS. LogQL
Elasticsearch 用的是 Query DSL 和 Lucene Query Lnguage，有着全文检索的能力和有大量的运算符支持，支持相关性分数排序。Loki 使用 LogQL，是通过日志标签来检索日志数据，也有运算符支持，但不像前者这么成熟。但使用日志标签，更容易查询和监控。
都支持水平扩容，但 Loki 更有优势，
因为 Loki 的读写是分离的，可根据特定需求进行扩容，且吞吐量更大。
Loki 更经济，因为 Loki 不索引日志数据，而是仅索引元数据，所以更节省存储资源。