两者差异的根源
ELK 与 Loki 的取舍围绕「索引什么」这一条：Elasticsearch 对正文建倒排索引，换来强大的全文检索与多维聚合能力，代价是 CPU、内存与存储开销；Loki 只索引标签，正文压缩成块按需解压，成本与运维复杂度都低，代价是查询能力偏向过滤与指标化。选型时先问查询深度与预算，再看与现有栈的整合度。
基本信息
| 常见组合 | ELK / EFK 栈，Grafana Loki 配 Promtail 或 Alloy |
|---|---|
| 索引方式 | ES 倒排索引可全文检索；Loki 仅索引标签 |
| 查询语言 | ES 用 DSL、KQL、Lucene；Loki 用 LogQL |
| 资源特征 | ES 吃内存与磁盘；Loki 开销与写入量相关 |
| 常见版本 | Elastic 7.x / 8.x，Loki 2.x / 3.x |
选型判断
- 需要复杂全文检索、正则与多维聚合分析时倾向 ELK
- 审计与合规追溯要求任意字段可检索时倾向 ELK
- 日志主要用于按服务与时间过滤排查时倾向 Loki
- 已有 Prometheus 与 Grafana 体系、希望统一体验时倾向 Loki
- 预算与人力有限、日志量大但查询简单时倾向 Loki
混用注意事项
- trace_id 与时间字段命名必须统一，否则两边关联查询成本高到没人用
- 同一类日志不要双写两套栈，存储与维护成本会翻倍
- 明确主栈与辅栈边界，例如审计类进 ES、运行日志进 Loki
- 两边的保留期要一起看，避免查不到旧数据却误判为数据丢失
- 选型前先量化日志量、保留期与查询模式，再据此估算容量
同一需求的两种写法
同一需求的两种写法
# 检索一条错误：
# ES：status:500 AND service:"api"（正文任意字段均可检索）
# Loki：{app="api"} |= "status=500"（先按标签缩小，再过滤正文）
# 按维度聚合：
# ES：terms 聚合 service.keyword，分析能力完整
# Loki：用 LogQL 的指标查询近似，复杂分析较弱对照速查
| 维度 | Elasticsearch（ELK） | Loki |
|---|---|---|
| 索引方式 | 倒排索引，全文可检索 | 只索引标签，正文压缩存块 |
| 查询语言 | DSL、KQL、Lucene | LogQL |
| 资源占用 | 内存与 CPU 开销较大 | 相对轻量，与写入量相关 |
| 分析能力 | 聚合与全文检索强 | 围绕日志的过滤与指标化 |
| 典型场景 | 审计、复杂检索、多维分析 | 云原生日志、与指标同栈 |
选型看问题形态而不是看热度：需要复杂检索与审计追溯倾向 ELK，需要低成本日志与指标统一体验倾向 Loki。两者可以并存，但要先划定边界。