illegalCreed

中文

English

中文

English

Appearance

与 Grafana LGTM 对比：ELK vs Loki vs Prometheus ​

基于 ELK 8.x / Loki / Prometheus · 核于 2026-08

速查 ​

  • 可观测性三大支柱：①指标（Prometheus/Mimir）——数值时序；②日志（ELK/Loki）——文本事件；③追踪（Jaeger/Tempo）——请求链路。三者正交，互补不替代。
  • ELK vs Loki：ELK 全文检索强（倒排索引每 token），存储贵（约 Loki 10 倍）；Loki 只索引 label 不索引内容，省存储但弱全文检索（grep 流式）。
  • 选 Loki：查询是「按 label 定位 + 关键词过滤」、存储成本敏感、已上 Grafana 栈。
  • 选 ELK：要全文模糊检索、复杂多字段聚合、日志内容是核心检索对象、审计/安全分析。
  • ELK vs Prometheus（指标）：指标监控一律选 Prometheus（PromQL 专精、Pull 模型、告警强）；ELK 的 Metricbeat 是补充不是替代——ES 做时序指标聚合成本高，无 PromQL。
  • ELK vs Jaeger/Tempo（追踪）：ELK 不做追踪（无 trace/span 模型）；追踪归 Jaeger/Tempo。ELK 的 APM 是另一回事（采集 trace 但用 ES 存）。
  • 并存而非互斥：成熟架构常 ELK（深度日志检索）+ Loki（常规日志省钱）+ Prometheus（指标）+ Jaeger（追踪）并存，按场景选工具。
  • 总拥有成本（TCO）：ELK 的 ES 集群（JVM 堆内存、分片均衡、磁盘）+ Logstash（CPU/内存）+ Kibana 三组件运维重，TCO 远高于 Loki（单组件 + 对象存储）。

一、可观测性三大支柱的边界 ​

可观测性（Observability）三大支柱，每支柱有专门的工具，ELK 只覆盖其中之一：

支柱数据形态典型工具ELK 角色
指标数值时序（CPU/QPS/延迟）Prometheus、MimirMetricbeat（补充，非首选）
日志文本事件（应用日志/审计）ELK、Loki核心主场
追踪请求链路（trace/span）Jaeger、Tempo不做（APM 另算）
剖析（第四支柱）函数资源（CPU/内存火焰图）Pyroscope不做
  • 不要用 ELK 做指标监控：ES 做时序聚合成本高（要扫描倒排索引）、无 PromQL、告警弱——指标监控选 Prometheus。
  • 不要用 ELK 做追踪：ES 没有 trace/span 模型，分布式追踪归 Jaeger/Tempo（ELK APM 采集的 trace 用 ES 存，但检索体验不如专用追踪工具）。

二、ELK vs Loki：全文检索 vs 省存储 ​

ELK 和 Loki 都是日志工具，但设计哲学相反：

维度ELK（Elasticsearch）Loki（Grafana）
索引模型倒排索引（每 token 都索引）只索引 label，不索引内容
全文检索强（任意关键词秒级）弱（grep 流式，慢）
复杂聚合强（多字段 GROUP BY）弱（LogQL 聚合有限）
存储成本高（索引膨胀，约 Loki 10 倍）低（只存 label + 压缩原文）
查询模式任意关键词/模糊/复杂查询按 label 定位 + 关键词过滤
运维复杂度高（JVM 集群 + 分片均衡）低（单组件 + 对象存储）
典型场景审计、安全分析、业务埋点检索应用日志、错误排查、省钱

选型决策 ​

  • 选 ELK：①需要全文模糊检索（搜任意关键词，如「排查某用户的所有操作」）；②复杂多字段聚合分析（如「按地区+时段+服务三维统计错误率」）；③日志内容是核心检索对象（审计/安全/合规）；④预算充足。
  • 选 Loki：①查询模式是「按 label 定位（service/env）+ 关键词过滤」；②存储成本敏感（Loki 约 ES 1/10）；③已上 Grafana 栈，要 traceID 关联；④运维资源有限。
  • 并存：成熟架构常两者并存——ELK 存需要深度检索的核心日志（审计/业务），Loki 存量大但检索需求简单的应用日志。

实例对比 ​

查「订单服务过去 1 小时的所有 ERROR 日志」：

  • ELK：level:error AND service:order AND @timestamp:[now-1h TO now]——秒级，因为 error/order 都有倒排索引。
  • Loki：{service="order"} |= "error"——先按 label 定位 order 日志流，再 grep 过滤含 error 的行。比 ELK 慢（要拉流），但便宜。

三、ELK vs Prometheus：日志 vs 指标 ​

ELK 做日志，Prometheus 做指标——边界清晰：

维度ELKPrometheus
数据类型日志（文本事件）指标（数值时序）
查询语言Lucene/KQL + 聚合PromQL
采集模型Push（Beats 推）Pull（Prometheus 拉）
检索全文检索（强）时序聚合（强）
告警ES 查询告警（弱于 AM）Alertmanager（强）
指标监控弱（Metricbeat 补充）核心主场
日志监控核心主场不做
  • Metricbeat 的定位：ELK 的 Metricbeat 采集系统/服务指标存 ES，但 ES 做时序指标不如 Prometheus——指标监控应选 Prometheus，Metricbeat 是补充（如要把指标和日志放一起分析时）。
  • 典型组合：Prometheus（指标）+ ELK（日志）+ Jaeger（追踪）——各司其职。

四、ELK vs Jaeger/Tempo：日志 vs 追踪 ​

ELK 不做分布式追踪：

  • 追踪的模型：trace（一次请求的完整链路）+ span（每个服务的处理段），带 parent/child 关系，是图结构。
  • ES 的模型：扁平文档（每个日志是一条 doc），没有 trace/span 关系建模。
  • ELK APM：Elastic 的 APM 产品采集 trace 数据用 ES 存，可在 Kibana 看 trace——但检索/分析体验不如专用追踪工具（Jaeger/Tempo）。
  • 结论：分布式追踪归 Jaeger/Tempo；ELK 看与 trace 相关的日志（在日志里搜 traceID）。

五、TCO（总拥有成本）对比 ​

ELK 的运维与资源成本显著高于 Loki：

成本项ELKLoki
存储高（索引膨胀，每 GB 日志 2-3GB 索引）低（只存 label + 压缩原文，约 ES 1/10）
内存ES 堆内存建议 ≤32GB × N 节点单组件，内存占用低
CPULogstash grok 解析 CPU 密集低
运维ES 集群（分片/脑裂/升级）+ Logstash + Kibana单组件 + 对象存储
人员需 ES 专精运维门槛低
  • 何时 ELK 仍然值得：当全文检索/复杂聚合的业务价值（审计合规、安全分析、数据变现）超过存储成本时。金融、安全、电商搜索等场景 ELK 不可替代。

六、典型可观测性架构组合 ​

成熟架构按场景组合，而非单一工具包打天下：

┌─ 指标（数值时序）─────────────────────┐
│ Prometheus（采集）→ Mimir/Thanos（长存）│
└───────────────────────────────────────┘
┌─ 日志（文本事件）─────────────────────┐
│ 应用 → Filebeat → ELK（深度检索）       │
│      → Promtail → Loki（常规省钱）       │
└───────────────────────────────────────┘
┌─ 追踪（请求链路）─────────────────────┐
│ OTel SDK → Jaeger / Tempo               │
└───────────────────────────────────────┘
┌─ 错误（异常聚合）─────────────────────┐
│ 应用 SDK → Sentry                        │
└───────────────────────────────────────┘
统一可视化：Grafana（连接所有数据源）

下一步 ​

理解了 ELK 的定位与边界后，可看本叶参考（Beats 家族速查、Logstash 插件、ES 聚合、易错点），或横向看其他可观测性工具——Prometheus（指标）、Grafana（可视化）、Sentry（错误）、Jaeger（追踪）。