Elasticsearch 与 Loki 日志存储方案在成本上的区别对比

对于大多数只需保留日志用于故障排查且希望控制基础设施预算的团队，Loki 通常是成本更低的选择；若业务强依赖复杂的全文检索与分析，Elasticsearch 虽然成本较高但能力更匹配。

先说结论：日志存储成本不仅看磁盘价格，更要算上索引带来的计算与内存开销，架构选型需匹配查询需求。

适合：Kubernetes 环境、日志量巨大但查询模式简单、预算敏感的场景优先考察 Loki。
重点看：Elasticsearch 的全文索引能力是否必需，若只需按标签过滤日志，ES 的资源消耗可能过剩。
别忽略：维护成本与学习曲线，ES 集群调优复杂度高于 Loki，人力也是成本的一部分。

核心成本维度对比

成本维度	Elasticsearch	Loki
存储效率	较低。因倒排索引，占用通常为原始日志的 1.5 倍以上，具体取决于字段数量。	较高。仅索引标签，内容压缩存储，占用接近原始日志大小。
计算资源	高。写入需分词索引，查询消耗大量 CPU 与 JVM 内存。	低。写入主要是压缩，查询依赖标签过滤，资源消耗相对平稳。
维护成本	高。需管理分片、副本、JVM 调优及 ILM 策略。	中。主要关注对象存储成本及标签基数控制。

实操：资源占用评估命令

在迁移前，通过 API 获取当前实际占用数据，避免凭经验估算。

1. 查看 Elasticsearch 索引存储大小

GET /_cat/indices?v&s=store.size:desc

关注 store.size 列，对比原始日志量计算放大率。

2. 查看 Loki 存储桶占用

Loki 通常对接对象存储（如 S3），直接查看存储桶监控指标或调用 API：

curl -g -G -s http://<loki-address>:3100/loki/api/v1/index/stats `--data-urlencode` "query={job=\"varlogs\"}"

或通过 Grafana 面板观察 "Chunks Stored" 与 "Lines Stored" 指标。

成本优化配置示例

通过配置生命周期管理与压缩策略，可显著降低长期存储成本。

1. Elasticsearch ILM 策略

设置热温架构，自动删除过期索引。

PUT _ilm/policy/logs_policy
{
  "policy": {
    "phases": {
      "hot": { "actions": { "rollover": { "max_size": "50gb" } } },
      "warm": { "min_age": "7d", "actions": { "shrink": { "number_of_shards": 1 } } },
      "delete": { "min_age": "30d", "actions": { "delete": {} } }
    }
  }
}

2. Loki 保留与压缩配置

在 loki.yaml 中调整保留周期与压缩算法。

compactor:
  working_directory: /tmp/compactor
  shared_store: s3
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150

limits_config:
  retention_period: 744h  # 保留 31 天
  chunk_encoding: snappy  # 或 lz4, 影响压缩率与 CPU

验证与常见坑

完成配置后，需验证成本是否下降且不影响使用。

验证存储释放：ES 执行 POST _ilm/retry 后观察磁盘释放；Loki 观察对象存储容量趋势。
Loki 标签基数爆炸：不要将高基数字段（如 user_id, request_id）设为 Loki 的标签，否则会导致内存激增，反而增加成本。
ES 分片设置不当：Elasticsearch 分片过多会导致集群状态变绿但查询变慢，增加维护成本。
忽视网络流量：集中式日志存储会产生大量内网流量，需确认云服务商的内网带宽计费策略。

参考来源

Elastic, "Elasticsearch Overview", https://www.elastic.co/elasticsearch
Grafana Labs, "Loki Overview", https://grafana.com/oss/loki/