---

theme: default themeName: "默认主题" title: "日志分析工具选型：ELK vs Loki vs Graylog，到底该选谁？"

---

日志分析工具选型：ELK vs Loki vs Graylog，到底该选谁？

去年我帮一家电商公司做日志平台选型，他们的需求很典型：每天10GB日志，预算有限，希望能在4核8G的服务器上跑起来。最后他们选了Loki，但这个选择并不适合所有人。

今天聊聊三个主流日志分析方案的对比，帮你做个合适的选择。

三个方案的架构对比

先搞清楚这三个东西是什么。

ELK Stack

ELK是Elasticsearch + Logstash + Kibana的缩写，后来多了个Beats，有时候也叫ELKB。

• Elasticsearch：存储和搜索引擎，核心组件

• Logstash：日志收集和处理管道

• Kibana：可视化界面

• Beats：轻量级日志采集器（Filebeat、Metricbeat等）

架构是典型的中心化设计：Beats采集 → Logstash处理 → Elasticsearch存储 → Kibana展示。

Elasticsearch是基于Lucene的搜索引擎，查询能力强大，但资源消耗也大。JVM应用，内存开销不小。

Grafana Loki

Loki是Grafana Labs开发的原生日志系统，设计理念很有意思："像Prometheus，但是用于日志"。

Loki不索引日志内容，只索引标签。这让它存储成本极低，但查询方式也受到限制。

架构：

• Promtail：日志采集Agent（类似Prometheus的Node Exporter）

• Loki：存储和查询引擎

• Grafana：可视化界面（是的，和Prometheus用同一套）

Loki的设计哲学是"日志就应该便宜"。为了达到这个目标，它牺牲了部分查询能力。

Graylog

Graylog用MongoDB存元数据，用Elasticsearch存日志内容。

架构：

• Graylog Server：核心服务，处理日志流

• MongoDB：存储配置和元数据

• Elasticsearch：存储日志数据

• Sidecar：日志采集Agent

Graylog的亮点是Streams概念，你可以把日志流按照规则分发到不同的输出，比如告警、归档、丢弃等。

资源消耗实测

这是大家最关心的问题。我在4核8G的虚拟机上做了实测。

测试条件：

• 日志量：10GB/天（约5000条/秒）

• 保留周期：7天

• 测试时长：72小时

Elasticsearch资源占用

组件	CPU	内存	磁盘
Elasticsearch	60-80%	4GB+	30GB
Logstash	20-30%	1GB	-
Kibana	5-10%	512MB	-
总计	85-120%	5.5GB	30GB

实测发现，Elasticsearch在建立索引时CPU会飙到80%以上，8核才比较稳。内存方面，官方推荐是给Elasticsearch分配50%可用内存，但在这个配置下，4GB刚够用，再少就容易OOM。

磁盘占用比原始日志大3倍左右，因为要建立倒排索引。

Loki资源占用

组件	CPU	内存	磁盘
Loki	15-25%	1.5GB	12GB
Promtail	5-10%	256MB	-
Grafana	5%	256MB	-
总计	25-40%	2GB	12GB

Loki的资源占用确实小得多。因为它不做全文索引，只索引标签，所以CPU和内存压力都小。

磁盘占用和原始日志量基本持平，稍微大一点点。这是它的核心优势。

Graylog资源占用

组件	CPU	内存	磁盘
Graylog	30-40%	2GB	-
MongoDB	10-15%	512MB	2GB
Elasticsearch	40-50%	3GB	25GB
Sidecar	5%	128MB	-
总计	85-105%	5.6GB	27GB

Graylog的资源消耗介于ELK和Loki之间，但因为也要用Elasticsearch，所以差距不大。

结论

在4核8G的配置下：

• Loki：可以正常运行，资源充足

• ELK：勉强能用，但高峰期可能会卡

• Graylog：和ELK类似，资源吃紧

如果你们预算有限，Loki是唯一能在低配置机器上跑得舒服的选择。

查询语法对比

查询能力是另一个重要考量因素。

Elasticsearch Query DSL

Elasticsearch有自己的一套查询语法，叫Query DSL。功能很强大，但学习曲线陡峭。

简单查询：

message: "error" AND level: "ERROR"

复杂查询：

{
  "bool": {     "must": [       { "match": { "message": "error" }},       { "range": { "timestamp": { "gte": "now-1h" }}}     ]   } }

Query DSL能做嵌套查询、聚合分析、脚本计算等，几乎无所不能。但说实话，大部分时候你只需要简单查询。

Kibana提供了KQL（Kibana Query Language），语法更友好：

message: "error" and level: "ERROR" and @timestamp >= now-1h

LogQL

Loki的查询语法LogQL，设计上参考了PromQL：

{app="nginx", level="error"} |= "timeout" | json | line_format "{{.message}}"

LogQL用管道操作符串联处理步骤，逻辑清晰。但因为没有倒排索引，全文搜索性能不如Elasticsearch。

如果你的日志有结构化标签，LogQL查询效率很高。但如果要频繁全文搜索，Loki会比较吃力。

Graylog Query

Graylog的查询语法比较直观：

level:ERROR AND message:error AND timestamp:[now-1h TO now]

Graylog提供了Search页面，输入关键词就能搜，学习成本最低。

告警能力对比

ELK告警

Kibana内置告警功能，但需要付费许可证（Gold以上）。开源版没有告警。

第三方告警方案：

• ElastAlert：Python写的告警插件，社区活跃

• Sentry：错误追踪平台，可以集成

• 自定义脚本：通过Webhook对接现有告警系统

Loki告警

Loki原生支持Ruler组件，可以基于LogQL配置告警规则：

groups:
  - name: nginx_errors     rules:       - alert: HighErrorRate

expr:
sum(rate({app="nginx"}
= "error" [5m])) > 100

        for: 5m         labels:           severity: warning         annotations:           summary: "High error rate detected"

告警规则和Prometheus类似，统一在Grafana里管理。如果你已经用Prometheus做监控，这个体验很一致。

Graylog告警

Graylog内置告警功能，开箱即用。支持条件触发、聚合统计、消息流等触发方式。

告警可以通过邮件、Slack、Webhook、PagerDuty等方式发送，集成度高。

运维成本对比

运维成本包括：部署难度、升级复杂度、故障恢复、日常维护。

ELK运维

• 部署难度：高。组件多，配置复杂。建议用Docker Compose或Kubernetes部署。

• 升级复杂度：高。Elasticsearch跨版本升级要谨慎，有兼容性问题。

• 故障恢复：中等。Elasticsearch集群挂了重建索引很慢，建议做好备份。

• 日常维护：高。要监控JVM、调整分片、清理索引、扩容规划等。

Loki运维

• 部署难度：中等。组件少，但需要理解Loki的设计理念。

• 升级复杂度：低。版本兼容性做得不错。

• 故障恢复：低。数据恢复相对快，因为没有复杂索引。

• 日常维护：低。基本不需要调优，Prometheus配置类似。

Graylog运维

• 部署难度：中等。要管理MongoDB和Elasticsearch两套存储。

• 升级复杂度：中等。要同时升级Graylog和Elasticsearch。

• 故障恢复：中等。有MongoDB和Elasticsearch两套要恢复。

• 日常维护：中等。Streams和Pipelines的配置需要维护。

不同场景的选型建议

小团队（10人以下）

推荐：Loki

预算有限，机器配置低，Loki是唯一现实的选择。配合Grafana，和Prometheus监控放一起，体验统一。

缺点是查询能力有限，但如果你们主要是通过标签查日志（比如按app查），这不是问题。

中型企业（10-100人）

推荐：Graylog或ELK

有预算的话，两者都可以。Graylog的告警功能开箱即用，省去很多集成工作。ELK的生态更成熟，遇到问题容易找到答案。

如果你们已经有Prometheus生态，可以优先考虑Graylog。

大厂（100人以上）

推荐：ELK + 专业优化

大规模日志场景，ELK仍然是主流选择。Elasticsearch的性能天花板高，经过调优可以处理PB级日志。

但要做好投入准备：专业的Elasticsearch运维团队、充足的硬件资源、完善的监控告警。

特殊场景

• 安全日志分析：推荐ELK + Elastic Security，SIEM功能完善

• 只看错误日志：推荐Loki，便宜够用

• 需要复杂告警：推荐Graylog，Pipelines功能强大

• 云原生环境：推荐Loki，和Kubernetes集成好

那家电商公司的后续

他们用了Loki半年后，发现一个痛点：业务部门需要频繁全文搜索日志来排查问题。Loki的全文搜索性能不够好，查询动辄几十秒。

最后他们的方案是：Loki存原始日志做归档，Elasticsearch存最近7天的日志做查询。两个系统并行，成本略高但满足了需求。

这告诉我们：选型前要搞清楚需求，特别是查询模式。

选型前的检查清单

决定之前，问自己几个问题：

1. 日志量多大？每天多少GB？ 2. 主要查询模式是什么？按标签查还是全文搜索？ 3. 保留多长时间？合规要求如何？ 4. 硬件预算多少？能接受多大的资源消耗？ 5. 团队有多少人？有专门运维日志平台的人吗？ 6. 告警需求有多复杂？ 7. 有没有合规要求？比如审计日志不可篡改？

这些问题想清楚，选择就不难了。

【放心，我们兜底】

不管你是自己尝试修复，还是需要专业人员上门，易云城IT服务都给你托底。修不好不收费，修好了质保期内随时找我。

📞 服务热线：13708730161 💬 微信：eyc1689 📧 邮箱：service@eycit.com 🌐 https://www.eycit.com

您身边的IT专家。