ELK
ES方案是传统成熟的日志采集的方案，也是目前团队内外部项目采用的方案。
之前一直采用的是传统的采集方案：日志 -> filebeat -> kafka ->logstash ->es
涉及组件多，部署运维链路复杂。同时，ES有存储空间占用高的问题。从而引发了日志方案调研比较的讨论。
ELK的话，调研验证了一套可行的轻量级方案，在轻量级场景下（比如单纯给一个小的Doris集群采集日志），相比传统的ELK方案更加简单轻便：
日志 -> filebeat -> es
Loki
Loki是新兴的，面向云原生的方案。与监控告警(grafana\alertmanager)的集成好，存储成本低。缺点是复杂搜索和分析支持弱、查询语言和标签系统用户上手需要学习成本，团队内没有实际落地过。也是我们这次重点比较的一套方案。
功能性能比较
|
对比项 |
说明 |
重要程度 |
ELK方案 |
Loki方案 |
ELK更优 |
Loki更优 |
|
数据存储成本 |
|
P0 |
官方数据是通常可以将数据压缩20%~30%，实测下来在某些场景下可以达到50%，使用DEFLATE压缩算法，最低可以降低超过70% |
10倍的压缩比 5G数据输入 存储实际增长0.5G |
|
√ |
|
数据查询成本 |
占用的CPU等 |
P0 |
500条并发查询大概消耗不到一个cpu core |
500条并发查询大概0.1个CPU |
- |
- |
|
查询速度 |
1.同一个查询语句，多久返回结果 2.关键字检索、过滤、提取 |
P0 |
十亿条数据规模的文本数据下（单条260B），包括关键词检索、范围检索、组合检索、模糊查询等都可以在秒级完成。 |
1.13G总数据量，查询30天内数据， 耗时21.9秒 |
√ |
|
|
特定字段检索 |
|
P0 |
支持 |
支持 |
- |
- |
|
分析能力 |
|
P3 |
支持多种分析方法，包括聚合分析，ML，自定义分析器等； |
过滤关键词式查询分析 |
√ |
|
|
采集方式 |
支持几种采集方式，链路轻量化、插件性能 |
P3 |
可以支持filebeat -> es的轻量化采集，也可以支持大规模采集 |
Promtail，大规模场景未验证 |
√ |
|
|
采集速度 |
|
P3 |
单个日志文件采集速度约4MB/s，2W条/s。 |
单文本1.2MB/s |
√ |
|
|
吞吐量 |
单位时间的写入量、写入速度 |
P2 |
3台的ES集群，吞吐数据最高可以达到100MB/s |
单台，3MB/s |
√ |
|
|
监控告警 |
是否支持监控告警、支持程度、复杂度等 |
P2 |
Filebeat和es都有监控接口。可以通过prometheus相应的exporter进行监控告警。 对日志做监控告警需要ElasticAlert ES支持高可用。Filebeat支持数据重传。 |
支持集群本身监控告警和日志监控告警。原生集成grafana |
|
√ |
|
高可用 |
主备、副本 |
P0 |
副本方式，需要3台 |
副本方式，需要3台 |
- |
- |
|
大数据组件支持 |
支持采集的大数据组件列表 |
P0 |
全部支持 |
全部支持 |
- |
- |
|
支持审计日志采集 |
|
P0 |
支持 |
支持 |
- |
- |
|
可扩展性 |
|
P2 |
可动态扩展 |
支持 |
- |
- |
|
Manager纳管难度 |
|
P2 |
ES已纳管，filebeat/logstash/kibana已具备纳管条件。 |
目前不支持 |
√ |
|
Loki在存储和监控告警方面更优，而ELK在查询速度、采集能力、分析能力、吞吐量、Manager纳管等方面都更优。如果是供客户使用，ELK更加通用和客户友好，Loki的话客户需要有个学习成本。
场景支持比较
|
序号 |
场景 |
场景说明 |
优先级 |
ELK方案 |
Loki方案 |
|
场景1 |
查询特定节点在特定时间段内的所有日志 |
在此场景中，我们将查询特定节点在特定时间段内的所有日志。预计查询速度较快，因为我们已经根据时间戳和主机名进行了优化 |
P0 |
支持 |
支持 |
|
场景2 |
查询特定时间段内所有节点的 ERROR 日志 |
在此场景中，我们将查询特定时间段内所有节点的 ERROR 日志。预计查询速度较快，因为我们已经根据时间戳进行了优化 |
P0 |
支持 |
支持 |
|
场景3 |
查询特定时间段内某个类别的日志数量（按主机名分组 |
在此场景中，我们将查询特定时间段内某个日志类别的数量，并按主机名分组。预计查询速度较快，因为我们已经根据时间戳进行了优化 |
P2 |
支持 |
支持 |
|
场景4 |
查询某个关键词出现在日志信息中的所有记录 |
在此场景中，我们将查询某个关键词出现在日志信息中的所有记录。预计查询速度较慢，因为我们需要在“日志信息”列中搜索关键词 |
P0 |
支持 |
支持 |
|
场景5 |
查询特定日志记录的上下文（例如前后5条记录） |
在此场景中，我们将查询特定日志记录（例如场景5中找到的记录）的上下文，包括前后5条记录。预计查询速度较快，因为我们可以通过时间戳和主机名快速定位目标日志及其上下文 |
P0 |
支持 |
支持 |
|
场景6 |
查询特定时间段内某个节点的 ERROR 日志 |
|
P0 |
支持 |
支持 |
|
场景7 |
指定节点、集群、实例维度、指定时间范围的日志查询，自由排列组合对日志进行筛选查询 |
|
P0 |
支持 |
支持 |
|
场景8 |
解析日志里面关键字出现数量达到一定的阈值触发告警 |
|
P2 |
方案需要验证，通过kibana实现 |
支持 |
场景支持方面，两套方案都可以支持绝大部分的场景。解析日志关键词出发监控告警这个，ELK方案的实现还未验证过。
结论
根据各方案现状以及功能性能场景比较测试下来看，目前比较合适的方案是继续使用ELK方案。轻量级场景下，通过filebeat直接发送到es来简化部署链路降低复杂性。大规模场景下，继续使用之前的filebeat->kafka->logstash->es方案。
Loki方案作为一个备选方案，如果出现ELK无法支持的场景，可以看看Loki能否支持。
