作者来自 Elastic Stef Nestor了解 Elasticsearch 磁盘水位线的工作原理、触发原因以及如何诊断 Support 团队遇到的 14 种最常见场景从索引膨胀到 ILM 停滞。更多阅读如何优化 Elasticsearch 磁盘空间和使用情况ElasticsearchLow disk watermarkElasticsearchHigh disk watermark了解将数据摄取到 Elasticsearch 的不同方式并深入研究实际示例尝试一些新的内容。Elasticsearch 提供了大量新功能帮助你针对自己的使用场景构建最佳搜索解决方案。立即开始免费的云试用或在本地机器上体验 Elastic。Elasticsearch 的磁盘水位线系统不仅仅是一个告警机制它会主动代表你采取响应措施在磁盘使用率达到 85% 时停止分配分片在达到 90% 时将分片迁移出节点在达到 95% 时阻止所有数据摄取。当它被触发时根本原因通常并不明显。本文涵盖了 Support 团队最常遇到的 14 种场景包括索引数据增长、缓存磁盘使用以及 ILM 停滞并提供诊断每种情况所需的具体 API 调用和分析思路。Elasticsearch 磁盘水位线分配机制如何工作Elasticsearch 假设同一个数据层中的所有节点都具有相同的硬件配置。这使其分配功能能够在目标节点之间分布索引分片。分配过程会依次根据集群级设置和过滤器进行计算然后检查单个节点的磁盘水位线最后再考虑分片感知机制。在这些逻辑前提下分配过程会运行一个 desired balancer 组件通过计算数据流写入负载、节点总分片数、节点磁盘使用量以及索引分片分布等权重来管理节点可用磁盘空间。分配机制及其 desired balancer 组件会根据当前集群状态计算下一步操作。随后分片会被重新路由并异步恢复到被认为能够改善整体集群均衡性的目标节点。Elasticsearch 文档强调节点暂时超过高水位线以及节点之间包括同一数据层内磁盘使用量存在较大差异都是正常现象。例如这可能发生在摄取流量激增、force merge 操作期间或者大型索引执行 ILM rollover、shrink 或 migrate 操作之间。也可能是由于分片大小差异过大造成的。Elasticsearch 管理员可能需要检查集群节点的磁盘使用情况。最常见的表现形式是 Elasticsearch 的 health API 报告问题通常显示为水位线错误或者表现为 ILM 索引停滞等常见子问题。# GET _health_report?filter_pathindicators.disk.status,indicators.ilm.status { indicators: { disk: { status: yellow }, ilm: { status: yellow } } }Elastic 建议启用监控功能以便在主机磁盘被写满之前及时收到告警。Elasticsearch 提供了磁盘水位线功能以避免磁盘耗尽问题。该功能不仅仅是业界常见的磁盘告警机制因为分配系统会自动代表管理员采取行动避免可用磁盘空间被耗尽。默认的磁盘水位线阈值及其影响如下85%的低水位线停止向该节点分配更多分片但仍允许向该节点摄取数据。90%的高水位线将分片迁移出该节点但仍允许向该节点摄取数据。95%的 Flood Stage 水位线通过将索引设置为只读模式停止向该节点进行所有数据摄取。当节点恢复到低于高水位线后只读写入阻塞会自动解除。注意Elastic Cloud HostedECH部署界面会在 75% 时显示红色警告横幅但此时 Elasticsearch 不会采取任何行动。磁盘水位线设置位于集群设置中# GET _cluster/settings?include_defaultsfilter_path*.cluster.routing.allocation.disk.watermark { defaults: { cluster: { routing: { allocation: { disk: { watermark: { flood_stage.frozen.max_headroom: 20GB, flood_stage: 95%, high: 90%, low: 85%, flood_stage.frozen: 95%, flood_stage.max_headroom: 100GB, low.max_headroom: 200GB, high.max_headroom: 150GB } } } } } } }如何使用 CAT allocation 诊断 Elasticsearch 磁盘使用情况Elasticsearch 开发团队创建了一个统一的端点CAT allocation作为你排查问题时的单一入口用于汇总磁盘信息。当前磁盘统计信息也可以在 node stats 中查看或者通过映射方式转换为 CAT allocation 的形式。使用 CAT allocation 返回的列名下面这张截图来自一个相关的数据增强请求展示了其含义解释对于这个输出我们通过“问题框定problem boxing ”开始排查检查以下几点1. 同一数据层内不同节点role的disk.total是否存在差异。如果存在则说明该集群的 硬件配置不均衡。2. 是否存在被标记为UNASSIGNED的分片。如果存在请参考 红色或黄色健康状态。3. 是否存在热点节点hot-spotted node或者整个数据层的disk.percent超过低水位线阈值。注意冻结frozen层出现disk.indices: 0gb且disk.percent: 95是预期行为因为其 部分可搜索快照 本身存放在磁盘缓存中并会自行管理以避免磁盘被填满。这也是 Elasticsearch 推荐使用 专用冻结节点 的原因之一。4. 单个或多个节点的disk.indices与disk.used之间存在较大差异。磁盘水位线问题可能来源于以下情况可用磁盘被以下因素消耗操作系统OS上的其他服务。Elasticsearch 服务未正确设置 日志保留策略。Elasticsearch 索引数据。Elasticsearch 数据缓存。也可能出现误报或漏报意外的 Elasticsearch 磁盘水位线设置。磁盘水位线设置未与 XFS 配额磁盘使用限制工具对齐导致通过disk.available降低而不是disk.used_percent升高来体现。不过我们接下来将重点关注由 Elasticsearch 索引数据和数据缓存引起的 flood-stage 磁盘水位线错误因为它们是过去一年中大多数高严重性 Support 案例的根本原因。ILM 会单独作为一个章节处理因为它可能在两种场景中同时出现。示例按出现频率从高到低排列。常见 Elasticsearch 磁盘水位线场景由索引数据导致的磁盘水位线问题当 CAT allocation 报告disk.indices接近水位线阈值时就会出现这种情况。默认的 flood-stage 水位线为 95%。由于 ECH 不会将 XFS 配额暴露给 Elasticsearch因此当disk.indices接近节点的disk.total时也会出现该问题。以下是在这些假设下的一些示例。A. 索引使用情况第一个例子我们来看一个单节点集群# GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards UNASSIGNED 2 instance-0000000000 11.5gb 11.8gb 12gb 96 36这是行业中典型的 “数据库几乎满了” 磁盘场景。磁盘几乎被占满因此它拒绝为新创建索引的两个分片分配节点。实际索引数据占用了 11.5GB也就是该节点 11.8GB 磁盘空间的 95%。为了避免磁盘达到 100%这在不同操作系统上可能会在 Elasticsearch 日志中表现为 no space left on the device应尽快进行干预。可考虑的缓解方案包括纵向扩容增加节点磁盘容量横向扩容增加节点数量删除不需要的索引可能在快照之后执行B. 索引分片与节点差异第二个简单例子现在有两个节点它们只差一个分片但其中一个节点的disk.indices比另一个高出 11GB# GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000001 11.5gb 11.8gb 12gb 96 11 instance-0000000000 0.5gb 0.8gb 12gb 0 10要排查这种情况需要结合 CAT shards 一起分析。此例的根因是某个索引配置为 1 个主分片number_of_shards且副本数为 0number_of_replicas也称 “1p0r”该分片本身就有 11GB。由于这种情况Elasticsearch 无法在节点之间均衡磁盘。修复方式可以考虑更新索引设置增加副本来平衡磁盘但这样会让另一节点进入 flood-stage 水位线因此必须同时考虑扩容磁盘。C. 大分片Large shard在上一个例子的基础上如果该单分片大小是 300GB这种情况在 Support 中更常见通常是由于分片大小超出 Elasticsearch 推荐的 10–50GB 范围。在这种情况下建议在确保有足够磁盘空间用于数据复制的前提下进行分片重构使用 split index 增加主分片数量创建目标索引并重新索引Reindex更多细节与注意事项见链接指南。理想情况下这个索引应调整为在两个节点上分成 6 个主分片以达到推荐的最大 50GB 分片大小。为了让主分片更均匀分布可能需要设置 total_shards_per_node 相关配置。D. 已删除文档Deleted docs再扩展这个例子作为临时缓解可以检查已删除文档。Elasticsearch 会定期清理索引中的docs.deleted可通过 CAT indices 查看# GET _cat/indices?vhindex,docs.* index docs.count docs.deleted my-index-000001 23791010 9192030 my-index-000002 187391903 0当docs.deleted 0时这些也会计入 CAT allocation 的disk.indices。由于分片是不可变的因此为了提前清理可以执行 forcemerge并加上only_expunge_deletes参数例如POST my-index-000001/_forcemerge?only_expunge_deletestrueE. 分片大小不均Varied shard sizes这是一个历史案例因为它在用户升级前仍然会带来较高 Support 负载。在 v8.6 之前只要同一数据层内分片数量均衡Elasticsearch 就认为集群是 balanced而不考虑分片大小差异或写入负载分布。因此可能出现“分片数量均衡但磁盘差异极大”的情况# GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000002 40.0gb 40.5gb 60.0gb 67 37 instance-0000000001 40.1gb 40.5gb 60.0gb 67 37 instance-0000000000 1.5gb 0.8gb 60.0gb 2 37这类情况虽然在旧的平衡机制下是 “均衡” 的但会导致 ingest 热点问题hot spotting。因此 Elasticsearch 在 v8.6 引入了 desired balance扩展了分配策略纳入数据流写入负载和节点磁盘使用情况从而显著减少这类问题。默认建议升级到 v8.6 或更高版本。Elastic 通常建议使用最新版本。在无法升级的情况下可以通过以下方式临时干预使用 cluster reroute 将高写入索引分散到不同节点通过合理设计分片数量并使用total_shards_per_node进行控制更多内容见 hot spotting 指南中的索引级分片分布章节。由缓存数据导致的磁盘水位线问题Elasticsearch 会在每个节点上保留数据缓存这可以通过 CAT allocation 中disk.used - disk.indices的差值来观察。这个缓存是按索引进行跟踪的并会在索引达到 health.status:green且没有待处理迁移请求时被释放。因此我们来看一些常见场景。F. 删除索引删除索引 会将其占用空间从disk.indices转移到磁盘缓存中然后由 Elasticsearch 异步清理。因此对于一个 1p0r 索引且该节点上只有这一个索引删除索引时在连续 API 查询中会看到如下变化# GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 40.0gb 40.5gb 60.0gb 67 1 # DELETE my-index-000001 # GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 0gb 40.5gb 60.0gb 67 0 # GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 0gb 0.5gb 60.0gb 0 0注意异步清理过程可能存在轻微延迟这是预期行为。G. 分片复制再来看分片复制的情况。在迁移或复制过程中可通过 CAT recovery 查看参与的每个节点都会保留一份副本直到目标节点确认分片完整性为止。这与 CAT indices 显示索引health:green的时间点一致。这意味着如果节点instance-0000000000正在向instance-0000000001复制但失败后改为向instance-0000000002复制那么在instance-0000000002确认与instance-0000000000的分片完整性之前这三个节点都会保留该分片的磁盘缓存。为了说明方便我们简化 CAT allocation 的输出# GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 10.0gb 10.5gb 100.0gb 10 1 instance-0000000001 0.0gb 0.5gb 100.0gb 0 0 instance-0000000002 0.0gb 0.5gb 100.0gb 0 0 # GET _cat/indices?vhindex,health,shards.* index health pri rep my-index-000001 yellow 1 1 # (恢复到 instance-0000000001) # GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 10.0gb 10.5gb 100.0gb 10 1 instance-0000000001 5.0gb 5.5gb 100.0gb 5 1 instance-0000000002 0.0gb 0.5gb 100.0gb 0 0 # (分片复制失败) # GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 10.0gb 10.5gb 100.0gb 10 1 instance-0000000001 0.0gb 5.5gb 100.0gb 5 0 instance-0000000002 0.0gb 0.5gb 100.0gb 0 0 # (恢复到 instance-0000000002) # GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 10.0gb 10.5gb 100.0gb 10 1 instance-0000000001 0.0gb 5.5gb 100.0gb 5 0 instance-0000000002 10.0gb 10.5gb 100.0gb 10 1 # GET _cat/indices?vhindex,health,shards.* index health pri rep my-index-000001 green 1 1 # GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 10.0gb 10.5gb 100.0gb 10 1 instance-0000000001 0.0gb 0.5gb 100.0gb 0 0 instance-0000000002 10.0gb 10.5gb 100.0gb 10 1在这种情况下Elasticsearch 行为是正常的。当 CAT allocation 显示disk.indices disk.used时首先应检查并确保 cluster health 为status:green并确认 CAT indices 也是health:green。H. 分片迁移即使索引或集群状态是 greenElasticsearch 仍可能在有意保留缓存数据这通常发生在分片迁移过程中。这在 ILM 执行时尤其常见后面章节会详细介绍。这里我们考虑 node attributes 在 index shard allocation filtering 中的影响以及 allocation explain 返回can_remain_on_current_node:no的情况。例如当你更新索引设置使副本不能留在当前节点但节点在迁移过程中重启分片开始迁移到其他节点而原节点在迁移完成前重新加入集群。这种情况下由于副本源未丢失索引不会变成status:yellow但迁移未完成因此会暂时出现相同的磁盘缓存占用直到迁移完成后释放。# GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 10.0gb 10.5gb 100.0gb 10 1 instance-0000000001 10.0gb 10.5gb 100.0gb 10 1 instance-0000000002 0.0gb 0.5gb 100.0gb 0 0 instance-0000000003 0.0gb 0.5gb 100.0gb 0 0 # GET _cat/indices?vhindex,health,shards.* index health pri rep my-index-000001 green 1 1 # GET _cat/shards/my-index-000001?vhsh prirep state node sh prirep state node 0 p STARTED instance-0000000000 0 r STARTED instance-0000000001 # (更新索引设置使 replica 需要迁移到 instance-0000000002) # GET _cat/recovery?vhidx,sh,snode,tnode idx sh snode tnode my-index-000001 0 instance-0000000001 instance-0000000002 # (instance-0000000002 丢失迁移转向 instance-0000000003随后 instance-0000000002 重新加入) # GET _cat/recovery?vhidx,sh,snode,tnode idx sh snode tnode my-index-000001 0 instance-0000000001 instance-0000000003 # GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 10.0gb 10.5gb 100.0gb 10 1 instance-0000000001 10.0gb 10.5gb 100.0gb 10 1 instance-0000000002 5.0gb 5.5gb 100.0gb 5 0 instance-0000000003 9.0gb 9.5gb 100.0gb 9 0 # (迁移完成分片完整性确认缓存释放) # GET _cat/allocation?vsnodehnode,disk.*,shards node disk.indices disk.used disk.total disk.percent shards instance-0000000000 10.0gb 10.5gb 100.0gb 10 1 instance-0000000001 0.0gb 0.5gb 100.0gb 0 0 instance-0000000002 0.0gb 0.5gb 100.0gb 0 0 instance-0000000003 10.0gb 10.5gb 100.0gb 10 1在这种情况下需要检查 shard 的 allocation explain 来判断迁移是否被阻塞或处于某个条件限制中。I. 迁移停滞前一个问题也可能发生在迁移停滞时例如 ECH 计划更新了 cluster settings 将某个节点排除但计划在迁移过程中被取消就会出现类似现象PUT _cluster/settings {transient: {cluster.routing.allocation.exclude._name: instance-0000000000}}此时应临时取消该设置直到在 Deployment Activity 中重新应用计划或通过 allocation explain 检查被排除节点上的分片为何未迁移。J. 版本问题以下是一些边缘情况通常通过升级可以避免旧版本中可能存在 disk cache reaper 服务未重试的问题已在 v8.13.0 通过 elasticsearch#106544 修复目前没有已知替代方案。在 v9.4 中仍可能存在一种情况节点重启进入 flood-stage 后如果缓存导致 disk.indices 与磁盘占用关系发生变化缓存可能不会按预期释放该问题仍在 elasticsearch#104667 讨论中。当前唯一已知解决方法是临时扩容磁盘如在 ECH 遇到该问题请联系 Elastic Support。由 ILM 相关导致的 Elasticsearch 磁盘水位线问题前面的迁移示例展示了在 ILMILM migrate 或 ILM shrink执行过程中可能出现的类似问题。这是因为 ILM 会基于时间或逻辑条件自动执行管理操作并以异步方式替用户完成。因此在正常管理操作中也可能出现类似的分配问题并且 ILM 场景下往往需要与普通情况相同的手动干预方式。Elasticsearch 的 health API 提供了 ILM 指标用于判断是否需要干预例如某个步骤停留时间过长或出现明确错误。K. Step 错误当使用 ILM rollover 的写入目标配置不正确时hot 节点可能因为 ILM rollover 错误 而被填满。由于 rollover 会通过 ILM explain 的is_auto_retryable_error:true自动重试并结合 ILM 的 indices.lifecycle.poll_interval 设置运行因此这些错误可能表现为failed_step_retry_count: 0或step:ERROR并带有最新失败信息# GET my-index-000001/_ilm/explain { index : my-index-000001, managed : true, policy : my_policy, index_creation_date : 2022-10-09T17:41:12.581Z, index_creation_date_millis : 1665337272581, time_since_index_creation : 631.68d, lifecycle_date : 2022-10-09T17:41:12.581Z, lifecycle_date_millis : 1665337272581, age : 631.68d, phase : hot, phase_time : 2022-11-06T17:58:01.766Z, phase_time_millis : 1667757481766, action : rollover, action_time : 2022-10-09T17:41:12.911Z, action_time_millis : 1665337272911, step: ERROR, step_time : 2022-11-06T17:58:01.766Z, step_time_millis : 1667757481766, failed_step : check-rollover-ready, is_auto_retryable_error : true, failed_step_retry_count : 316, step_info: { type: security_exception, reason: action [indices:admin/settings/update] is unauthorized for API key id [XXXXX] of user [test] on restricted indices [my-index-000001], this action is granted by the index privileges [manage,all] }, phase_execution : { policy : my_policy, phase_definition : { min_age : 0ms, actions : {rollover : {max_age : 30d, max_size : 50gb } } }, version : 1, modified_date : 2021-12-13T16:25:49.356Z, modified_date_in_millis : 1639412749356 } }如果当前没有显示失败信息但failed_step_retry_count: 0建议检查 ILM history index 并定位具体索引的错误原因。在该示例中问题是由于权限不足的用户修改了 ILM policy解决方式是使用具备足够权限的用户重新保存 policy或为用户赋予权限。相关问题可参考 elasticsearch#72856该讨论涉及未来可能让 ILM 执行用户变为无关用户user-agnostic。L. 为什么即使有后续数据层hot tier 仍然会被填满ILM 用于将数据从高温数据层迁移到低温数据层data tiers。如果后续数据层不存在或出现 watermark 问题就会导致前面的数据层堆积。例如一个 ILM policy 设置为hot1 小时 rollover立即移动到 frozen3 天后删除但如果 frozen tier 不存在那么 ILM 在执行 顺序执行 时就无法推进删除步骤数据会持续堆积在 hot tier并最终导致磁盘填满。这种情况下的表现可能如下# GET _cat/allocation?vsnodehnode,disk.*,shards,role node disk.indices.forecast disk.indices disk.used disk.avail disk.total disk.percent shards role UNASSIGNED 103 instance-0000000003 189gb 161.4gb 161.6gb 18.3gb 180gb 89 120 himrst instance-0000000007 135.2gb 109.6gb 179.9gb 7.1mb 180gb 99 41 himrsthealth report 中 ILM 指标会提示多个迁移停滞索引# GET _health_report?filter_pathindicators.ilm.status,indicators.ilm.symptom,indicators.ilm.details { indicators: { ilm: { status: yellow, symptom: 65 indices have stayed on the same action longer than expected., details: { stagnating_indices_per_action: { allocate: 0, shrink: 0, searchable_snapshot: 0, rollover: 0, forcemerge: 0, delete: 0, migrate: 65 }, policies: 61, stagnating_indices: 4, ilm_status: RUNNING } } } }通过 jq 分析 ILM explain可以验证状态cat ilm_explain.json | jq -c .indices[]|select(.managedtrue)|.phase/.action/.step | sort | uniq -c | sort -r结果显示 frozen tier 没有可用节点65 frozen/searchable_snapshot/wait-for-data-tier同时也可以看到65 no nodes for tiers [data_frozen] available因此要解决 hot 磁盘水位线问题你需要添加 frozen 节点。如果这些索引在 frozen 步骤上等待了好几天你也可以考虑手动 删除索引。在这个例子中我们根据 min age 的计算方式 预计索引最多只会存在“一天加一小时”但实际数据却显示已经存在七天。$ cat ilm_explain.json | jq -c .indices[]|select(.managedtrue)|.age | sort | uniq -c | sort -r | head -4 24 7d 20 4d 20 5d 10 6dElastic Cloud 可以代表你处理 autoscaling以避免这些问题的发生。M. 为什么 ILM 索引卡在 migrate 步骤接下来我们来看一个更常见的历史案例。在 Elasticsearch 还没有正式引入 data tiers 之前用户通常使用 自定义节点属性 来区分不同类型的机器。这种方式在很大程度上已经被 迁移到 node roles 的方式 所取代但仍然偶尔会遇到只完成部分迁移的集群。同样地虽然 data tiers 假设同一 data tier 内节点具有相同硬件配置但在一些特殊场景中仍然有人将自定义节点属性与 ILM 一起使用。这里我们先讨论第一种情况因为“自定义节点属性与 ILM 发生冲突”是更常见的问题来源。这一次我们假设有 hot 和 warm 两个数据层而 hot 层几乎满了warm 层是完全空的。ILM 本应在 rollover 一小时后立即将数据迁移过去。但与前面的例子一样ILM health report 仍然会显示索引停滞不过这次会是# GET _all/_ilm/explain?humanexpand_wildcardsall $ cat ilm_explain.json | jq -c .indices[]|select(.managedtrue)|.phase/.action/.step | sort | uniq -c | sort -r 30 warm/migrate/check-migration 10 hot/rollover/check-rollover-ready有时step_info.message会直接给出具体的分配错误信息但有时你需要运行 allocation explain以及其 常见输出来判断分片为什么无法迁移到 warm 节点。# GET _cluster/allocation/explain # {index: my-index-000001, shard: 0, primary: true} ... # 为简化仅截取当前分片所在 hot 节点的部分输出 deciders: [ { decider: filter, decision: NO, explanation: node does not match index setting [index.routing.allocation.include] filters [box_type:\hot\] }, { decider: data_tier, decision: NO, explanation: index has a preference for tiers [data_warm] and node does not meet the required [data_warm] tier } ] ...这个例子展示了一个冲突同一个分片同时被要求留在 hot 节点又被要求迁移到 warm 节点。Elastic 建议用户使用默认开启的 ILM migrate 来在 data tiers 之间移动数据。也可以选择禁用它改为使用 ILM allocate 自定义属性的方式。理论上两者也可以同时使用但如本例所示如果同时启用必须非常谨慎地避免冲突。尤其要注意 ILM 的执行顺序是 allocate 在 migrate 之前如果在第一步就设置了阻塞条件即使第二步可以解决也会导致整体流程卡住因此所有设置必须在每个步骤中都保持自洽。N. ILM 中 min_age 与 rollover 是如何交互的前面我们已经简单提到过 ILM rollover 与阶段min_age设置之间的关系这里我们单独用一个例子来说明。当用户在 Elasticsearch 中平衡 10–50GB 分片大小 的建议与索引生命周期策略时通常会同时考虑多种 rollover 触发条件。在这个例子中我们假设索引从创建开始使用默认 rollover 策略# GET _ilm/policy/ilm-history-ilm-policy?filter_path*.policy.phases.hot.actions.rollover {ilm-history-ilm-policy: {policy: {phases: {hot: { actions: { rollover: { max_age: 30d, max_primary_shard_size: 50gb } } } } } } }只要任何一个主分片没有达到 50GB这个索引就会一直在 hot 节点上写入数据直到达到max_age:30d时触发 rollover。但关键问题是rollover 之后会发生什么这取决于下一个阶段的min_age。在这个例子中下一个阶段是 warm tier而默认配置如下# GET _ilm/policy/ilm-history-ilm-policy?filter_path*.policy.phases.warm.min_age { ilm-history-ilm-policy: {policy: {phases: { warm: { min_age: 0ms } } } } }一个阶段的min_age是基于索引的 rollover 时间来计算的。但如果索引还没有发生 rollover那么它的 age 就等于creation_date。用户有时会错误地理解min_age和age把它当成 “数据应该在某个 tier 存放的总时间”但他们往往忽略了 rollover 本身消耗的时间。因为没有从总时间里扣除 rollover 所花费的时间索引在 rollover 之后会“立即”进入 warm tier。这本身不会立刻报错但会导致数据比预期更快进入 warm 层从而逐渐增加磁盘压力最终可能引发 watermark磁盘水位线问题。获取 Elasticsearch 磁盘问题帮助根据我在 Elastic Support 中看到的情况这就是最常见的集群磁盘问题总结。希望你现在也已经理解了相关原理和对应的解决思路。不过如果你在解决问题时仍然卡住也可以随时联系我们我们很乐意提供帮助你可以通过以下渠道联系Elastic DiscussElastic Stack Community SlackElastic Professional Services 咨询服务Elastic Training 培训Elastic Support 支持服务本文中描述的任何功能或发布时间均由 Elastic 单方面决定。任何当前不可用的功能或特性可能不会按时交付甚至可能不会交付。原文Elasticsearch disk watermark: 14 troubleshooting scenarios - Elasticsearch Labs