1. ELK#

ELK 指的是：

• Elasticsearch
• Logstash
• Kibana

这是最经典的一套日志系统组合。

它的基本分工是：

• Logstash 负责采集、解析、处理、转发日志
• Elasticsearch 负责存储、索引、检索日志
• Kibana 负责查询、分析、展示日志

2. EFK#

EFK 通常指的是：

• Elasticsearch
• Fluentd 或 Fluent Bit
• Kibana

它和 ELK 的主要区别只有一个：

把 Logstash 换成了 Fluentd / Fluent Bit。

也就是说：

• 后端仍然是 Elasticsearch
• 界面仍然是 Kibana
• 变化的是日志采集和转发层

3. Loki#

Loki 不是 ELK 的变体，而是一条不同的路线。

最常见的 Loki 方案通常由这些组件构成：

• Loki：日志存储与查询后端
• Promtail（现在逐步被 Grafana Alloy 替代）或其他 Agent：日志采集
• Grafana：日志查询与展示

它的核心思路和 Elasticsearch 系路线不同。

Loki 的设计重点不是对日志全文做大规模索引，而是：

只对标签建立索引，日志正文本身不做和 Elasticsearch 那样重的全文索引。

这决定了它的成本、查询方式和适用场景都和 ELK / EFK 有明显区别。

ELK 解决的问题#

ELK 更偏向传统意义上的完整日志平台：

• 支持复杂采集
• 支持复杂日志清洗
• 支持复杂字段提取
• 支持强检索能力
• 支持比较成熟的分析与可视化

它适合的场景通常是：

• 日志格式复杂
• 日志来源很多
• 需要做较重的解析和转换
• 需要更强的检索和分析能力

EFK 解决的问题#

EFK 解决的问题和 ELK 本质相同，但更偏向容器和 Kubernetes 场景。

它更强调：

• 轻量采集
• 节点级统一收集
• 容器日志处理
• Kubernetes 元数据附加

所以它更常见于：

• Kubernetes 集群
• k3s / k8s 学习环境
• 容器平台日志收集

Loki 解决的问题#

Loki 更强调：

• 更低的存储和索引成本
• 与 Grafana / Prometheus 体系自然集成
• 面向云原生日志场景的轻量化思路

它不是“不支持查日志”，而是它对日志的组织方式和 Elasticsearch 路线不同。

它更适合的场景通常是：

• 已经在用 Grafana
• 已经在用 Prometheus
• 希望日志系统更轻一些
• 接受查询方式偏标签过滤而不是重全文检索

Logstash#

Logstash 是一个重型日志处理管道。

它的特点是：

• 插件丰富
• 处理能力强
• 输入输出类型多
• 日志解析能力强
• 配置灵活

它的问题也很明确：

• 相对更重
• 资源消耗更高
• 在容器场景里不一定是最轻便的选择

所以 Logstash 更适合用在：

• 复杂日志处理链路
• 传统服务器日志汇总
• 需要重解析的场景

Fluentd / Fluent Bit#

Fluentd 和 Fluent Bit 都可以看作更偏采集与转发层的组件。

其中：

• Fluentd 功能更完整，插件多，但相对更重
• Fluent Bit 更轻，更适合边缘采集和 Kubernetes 节点采集

在 Kubernetes 里，这类采集器经常以 DaemonSet 形式运行在每个节点上，用来：

• 读取容器日志文件
• 附加 Pod / Namespace / Container 等元数据
• 转发给后端

这就是为什么在 K8s 里更常看到 EFK，而不是传统 ELK。

Promtail / Alloy#

Loki 这条线常见的采集器是 Promtail，新的方向则越来越偏向 Grafana Alloy。

它们的任务是：

• 采集日志
• 给日志打标签
• 发给 Loki

这里的关键不在“能不能采”，而在：

Loki 更依赖标签体系。

这会影响后续查询方式。

Elasticsearch#

无论 ELK 还是 EFK，后端都是 Elasticsearch。

Elasticsearch 的特点是：

• 检索能力强
• 对结构化字段支持强
• 支持聚合分析
• 适合复杂查询
• 生态成熟

它的代价也很明显：

• 资源占用通常更高
• 运维复杂度更高
• 数据量上来以后成本更明显

所以 Elasticsearch 路线的优势和代价都很清楚：

强能力，重系统。

Loki#

Loki 的思路不同。

它不是按 Elasticsearch 那种方式去建立重型全文索引，而是：

• 主要索引标签
• 日志正文本身不做同等强度的全文索引

这带来的影响是：

• 存储和索引成本更低
• 系统相对更轻
• 但查询模式更依赖标签设计

因此，Loki 的核心不是“比 Elasticsearch 更强”，而是：

它在成本和能力之间选择了不同的平衡点。

ELK / EFK 的查询体验#

因为后端是 Elasticsearch，所以查询体验通常偏向：

• 字段过滤
• 关键字搜索
• 较强的全文检索
• 聚合统计
• 面向日志分析的丰富查询能力

如果日志结构化做得好，Elasticsearch 这条线的查询体验通常会比较强。

Loki 的查询体验#

Loki 的查询通常更依赖：

• 标签过滤
• 时间范围
• 再结合日志内容搜索

它的查询思路和 Elasticsearch 不完全一样。

很多时候，Loki 的优势不在“复杂搜索特别强”，而在：

• 和 Grafana 配合自然
• 和指标系统联动方便
• 成本更低

所以 Loki 更适合“观测体系一体化”的思路，而不是一味追求最重的日志检索能力。

ELK#

EFK#

Loki#

学日志平台基本结构#

如果目标是先理解“日志平台”这件事本身，ELK 仍然有学习价值。

因为它能帮助你理解：

• 采集
• 处理
• 存储
• 查询

这几层是怎么分开的。

学 Kubernetes / k3s 日志系统#

如果目标更明确，就是学 Kubernetes 日志链路，那更值得优先理解的是：

• EFK
• Loki

因为这两条路线更接近现在的实际场景。

学云原生观测体系#

如果你后面会把：

• Prometheus
• Grafana
• Alerting
• Logging
• Tracing

放在一起看，那 Loki 往往更值得重点关注。

ELK 在单机 k3s 里#

能做，但通常不是最优先的学习路径。

原因不是它不能跑，而是：

• 相对更重
• 更像传统日志平台思路
• 对容器日志采集这件事不够“贴脸”

EFK 在单机 k3s 里#

是一个很自然的学习路径。

因为它能直接回答这些问题：

• 节点上的容器日志是谁采的
• Kubernetes 元数据怎么带进日志里
• Elasticsearch 怎么作为日志后端
• Kibana 怎么用来查 Pod 日志

Loki 在单机 k3s 里#

也很适合作为学习方案。

尤其是你如果已经在学：

• Prometheus
• Grafana
• Kubernetes 监控

那继续学 Loki 会非常顺。

它和现有观测体系衔接会更自然。