如何使用 LogsDB 降低 Elasticsearch 日志存储成本

作者：来自 Elastic Jeffrey Rengifo

了解如何在 Elasticsearch 中启用 LogsDB 索引模式并衡量实际存储节省效果。我们将使用 Apache 日志对比标准索引与 LogsDB 索引，并展示可以节省多少存储空间。

LogsDB 是一种专门的 Elasticsearch 索引模式，它以更低的存储成本提供完整功能。你的 Kibana 仪表板、搜索、告警和可视化都可以像以前一样正常工作，不会丢失任何数据，也不需要修改查询或工作流。只需一个配置，就能让所有东西变得更便宜。

在基准测试中，LogsDB 将一个数据集从 162.7 GB 降低到 39.4 GB —— 减少了 76% 的存储空间。你可以在 elasticsearch-benchmarks.elastic.co 查看完整的夜间基准测试结果。

在本教程中，你将使用 Kibana Dev Tools 和 Apache logs 数据集复现这个实验。你会创建两个完全相同的索引，将相同的数据写入两个索引，并使用 _stats API 测量存储差异。最终你会在测试数据上看到 44% 的存储减少，并理解为什么在生产环境中节省幅度会更高。

如果你已经在使用 Elasticsearch 9.2+，任何以 logs- 开头的数据流默认已经启用了 LogsDB。你可以直接跳到 “What about your existing logs?” 来验证你的配置。

想了解完整背景？关于这些节省背后的工程演进 —— 包括 Lucene doc values、synthetic _source、index sorting 和 ZSTD 是如何在十二年间逐步叠加实现的——可以参考 “Elasticsearch 多年来的发展：LogsDB 如何将索引大小最多降低 75%”。

前提条件

• Elasticsearch 8.17+ 集群、Elastic Cloud 部署或 Serverless
• 具有 Dev Tools 访问权限的 Kibana
• 一些日志数据
• 对在 Kibana Dev Tools 中运行 API 调用有基本了解

LogsDB 如何节省存储

LogsDB 通过叠加三种机制来实现存储压缩：

• 索引排序（Index sorting）——按照 host.name 和 @timestamp 对文档排序，将相似日志行聚集在一起，使压缩算法更容易找到重复模式。单这一项就能带来大约 30% 的节省。
• ZSTD 压缩 + delta/GCD/运行长度编码——best_compression 会从 LZ4 切换到 Zstandard，并对每个 doc values 列应用数值编码。本教程中的标准索引使用的是 LZ4，因此你测量到的差异中，有一部分来自 LogsDB 自动启用的完整优化组合。
• Synthetic _source——Elasticsearch 不再存储原始 JSON blob，而是在需要时通过 doc values 重建 _source，从而额外带来 20–40% 的存储节省。

Synthetic _source 的权衡：返回文档中的字段顺序可能与原始数据不同，并且在多值数组字段的一些边缘情况下行为会有所差异。对于大多数日志分析工作负载，这些差异是不可见的，但在延迟敏感应用中启用前仍需参考 synthetic _source 文档。

关于这些机制背后的架构细节，可以查看 “Elasticsearch 多年来的发展：LogsDB 如何将索引大小最多降低 75%”。

接下来，我们将一步步讲解如何启用 LogsDB 并测量存储节省效果。

步骤 1：使用 Elastic Agent 收集日志

将 Apache 日志导入 Elasticsearch 的推荐方式是通过 Elastic Agent 并使用 Apache 集成。它可以自动处理采集、解析、ECS 字段映射以及路由。

浏览 Elastic integrations 目录中的所有可用集成。

一旦 Elastic Agent 开始收集日志并将其路由到 logs-apache.access-*，就可以进入下一步。

步骤 2：创建两个索引

本教程中的所有命令都在 Kibana Dev Tools 中运行。

创建一个标准索引和一个 LogsDB 索引，两者具有完全相同的字段映射。唯一的区别是 "index.mode": "logsdb"。

标准索引：

PUT /apache-standard
{
  "mappings": {
    "properties": {
      "@timestamp":                  { "type": "date" },
      "host.name":                   { "type": "keyword" },
      "http.request.method":         { "type": "keyword" },
      "url.path":                    { "type": "keyword" },
      "http.version":                { "type": "keyword" },
      "http.response.status_code":   { "type": "integer" },
      "http.response.bytes":         { "type": "integer" },
      "http.request.referrer":       { "type": "keyword" },
      "user_agent.original":         { "type": "keyword" }
    }
  }
}

LogsDB 索引：

PUT /apache-standard
{
  "mappings": {
    "properties": {
      "@timestamp":                  { "type": "date" },
      "host.name":                   { "type": "keyword" },
      "http.request.method":         { "type": "keyword" },
      "url.path":                    { "type": "keyword" },
      "http.version":                { "type": "keyword" },
      "http.response.status_code":   { "type": "integer" },
      "http.response.bytes":         { "type": "integer" },
      "http.request.referrer":       { "type": "keyword" },
      "user_agent.original":         { "type": "keyword" }
    }
  }
}

这一行 "index.mode": "logsdb" 会自动启用所有三种存储机制。Elasticsearch 会在后台开启以下额外设置——你无需手动配置任何一项：

{
  "index.sort.field":              ["host.name", "@timestamp"],
  "index.sort.order":              ["asc", "desc"],
  "index.codec":                   "best_compression",
  "index.mapping.ignore_malformed": true,
  "index.mapping.ignore_above":    8191
}

步骤 3：重新索引日志

使用 _reindex API 将相同的文档复制到两个测试索引中：

POST /_reindex
{
  "source": { "index": "logs-apache.access-*" },
  "dest":   { "index": "apache-standard" }
}

POST /_reindex
{
  "source": { "index": "logs-apache.access-*" },
  "dest":   { "index": "apache-logsdb" }
}

两个索引现在包含完全相同的文档，因此下一步的存储对比只反映索引模式（index mode）的差异。

步骤 4：强制合并以确保公平对比

在测量之前，对两个索引执行 force merge，将其合并为单个 segment：

POST /apache-standard/_forcemerge?max_num_segments=1

POST /apache-logsdb/_forcemerge?max_num_segments=1

这些请求会阻塞直到合并完成。请等待两个请求都返回后再继续。

为什么这一步很重要：Elasticsearch 在写入数据时会先生成多个 Lucene segment，并在后台逐步合并。如果在合并过程中进行测量，会因为每个 segment 单独压缩而导致存储数据被高估。强制合并为单一 segment 可以展示索引在稳定状态下的真实存储占用，这更接近生产环境中的最终表现。

注意：只有在索引不再写入时才应执行 _forcemerge。对仍在写入的索引执行 force merge 会消耗大量资源，并可能影响 ingestion 性能。在生产环境中，可以通过 Index Lifecycle Management（ILM）在 warm 或 cold 阶段自动执行 force merge，此时索引通常已经 rollover，不再承载写入。

步骤 5：测量差异

GET /apache-standard/_stats?filter_path=indices.*.primaries.store

GET /apache-logsdb/_stats?filter_path=indices.*.primaries.store

filter_path 参数可以让响应更聚焦。请在每个响应中查看 primaries.store.size_in_bytes。

在我们使用 Apache 日志数据的测试中，结果如下：

索引	文档数	大小
apache-standard	111,818	15.37 MB
apache-logsdb	111,818	8.6 MB
减少比例		44%

从这个角度来看：在 1 TB 的日志数据下，LogsDB 可以将其压缩到约 560 GB。这意味着在不修改任何查询的情况下节省了 450 GB。在生产规模（数十亿文档并启用 synthetic _source）下，节省比例可达到 76%——在我们的基准测试中，从 162.7 GB 降低到 39.4 GB。

在 Kibana 中可视化

要直观查看存储差异，请打开 Kibana，进入 Management → Stack Management → Index Management。你会看到两个索引并排列出，并显示各自的当前大小。

为什么 Kibana 显示的数值比 _stats 更大：Kibana Index Management 显示的是包含所有 replica shards 在内的索引总大小。而上面的 _stats 查询使用的是 primaries，只报告 primary shards 的大小。无论采用哪种方式，两种索引之间的比例关系是保持一致的。

那你现有的日志呢？

Elasticsearch 9.2+（默认已启用）

从 9.2 开始，任何匹配 logs-* 命名模式的数据流都会自动使用 LogsDB。你很可能已经在没有任何配置改动的情况下节省了存储空间。

验证你现有的数据流：

GET /.ds-logs-*/_settings?filter_path=*.settings.index.mode

如果你在响应中看到 "index.mode": "logsdb"，说明你已经在享受存储节省了。

Elasticsearch 8.x 或 9.0–9.1（通过 index template 为每个 data stream 启用）

在较早版本中，需要通过更新 index template 来为 data stream 启用 LogsDB。此配置会影响所有由该模板创建的新索引——已有索引不会被修改，因此迁移是安全且渐进的。

选项 A —— 更新现有模板：

PUT _index_template/logs-myapp-template
{
  "index_patterns": ["logs-myapp-*"],
  "data_stream": {},
  "template": {
    "settings": {
      "index.mode": "logsdb"
    }
  },
  "priority": 200
}

选项 B —— 检查并修补现有的集成模板：

首先，找到管理你数据流的模板：

GET _index_template/logs-apache*

然后在 template.settings 代码块中添加 index.mode 设置，使用 PUT _index_template/ 调用，并包含完整的模板 body（包括你新增的配置）。

更新模板之后，下一个 rollover 生成的索引就会使用 LogsDB。如果你不想等待，可以立即触发一次 rollover：

POST /logs-myapp-default/_rollover

从 8.x 升级到 9.0+：现有的数据流不会被自动修改。只有新的 rollover 才会使用 LogsDB。不需要重新索引，也不会有数据丢失——随着新的索引逐步滚动生成，节省效果会逐渐累积。

查询性能怎么样？

LogsDB 对于典型日志分析工作负载来说，不会对查询性能产生显著影响。由于按照 host.name 和 @timestamp 进行索引排序，这在某些情况下反而能提升 range 查询和聚合性能，因为匹配的数据会在磁盘上更紧密地存放在一起。对于不依赖这些字段过滤的查询，其性能与标准索引基本一致。

关于跨版本的索引写入吞吐性能数据，可以参考配套文章中的 performance 部分。

结论

LogsDB 只需一个 "index.mode": "logsdb" 配置即可启用，并立即带来可观的存储节省：在我们的实测中减少 44%，在生产基准测试中（启用 synthetic _source）可达 76%（162.7 GB → 39.4 GB）。在 Elasticsearch 9.2+ 中，所有 logs-* 数据流默认已启用 LogsDB。对于 8.x 或更早的 9.x 集群，只需在 index template 中添加一行配置，即可在下一次 rollover 生效，无需重新索引，也不会有数据丢失。

下一步

• LogsDB index mode 文档
• Synthetic _source 文档与限制
• 配置 logs data stream
• LogsDB 正式发布公告
• LogsDB 与 TSDS 性能基准测试

原文：https://www.elastic.co/observability-labs/blog/elasticsearch-logsdb-index-mode-storage-savings#next-steps