ElasticSearch recovery相关监控命令的使用技巧

ElasticSearch recovery 概述

在 ElasticSearch 中，recovery 是指节点之间数据恢复的过程。当 ElasticSearch 集群发生节点故障、新增节点、重新分配分片等情况时，就会触发 recovery 机制。这一机制对于维持集群的数据完整性和可用性至关重要。

数据恢复的场景

节点故障恢复：当集群中的某个节点发生故障下线时，该节点上的分片副本会在其他节点上重新恢复，以确保数据的可用性。例如，假设集群中有三个节点，节点1上有一个主分片和一个副本分片，当节点1故障时，ElasticSearch 会自动在节点2和节点3上恢复这些分片。
新增节点：当向集群中添加新节点时，ElasticSearch 会自动将部分分片分配到新节点上，以实现负载均衡。这个过程涉及到将现有节点上的分片数据复制到新节点，也就是 recovery 过程。
重新分配分片：有时候，由于集群的配置变更或者手动干预，需要对分片进行重新分配。比如，为了提高查询性能，可能会调整分片的数量或者副本数量，这就会触发分片的重新分配和 recovery。

Recovery 的类型

本地 recovery：当节点重启或者由于某些原因导致分片短暂不可用，但数据文件仍然存在于本地磁盘时，会进行本地 recovery。这种情况下，ElasticSearch 会直接从本地磁盘加载数据，而不需要从其他节点复制数据，速度相对较快。
普通 recovery：在大多数情况下，如节点故障导致数据丢失，需要从其他节点复制数据来恢复分片，这就是普通 recovery。它会从拥有该分片副本的其他节点传输数据，过程相对复杂，并且依赖网络带宽等因素。

监控命令的重要性

了解和掌握 ElasticSearch recovery 相关监控命令对于集群的运维和优化至关重要。通过监控命令，我们可以实时了解 recovery 的进度、资源使用情况，及时发现潜在的问题并采取相应的措施。

发现性能瓶颈

通过监控 recovery 过程中的网络带宽、磁盘 I/O 等指标，我们可以发现是否存在性能瓶颈。例如，如果发现 recovery 速度缓慢，通过监控发现网络带宽被占满，就可以考虑优化网络配置或者调整 recovery 的并发度。

确保数据完整性

监控 recovery 状态可以确保数据在恢复过程中没有丢失或者损坏。如果在监控中发现某个分片的 recovery 一直处于异常状态，就需要及时排查原因，避免数据丢失的风险。

提前预警

通过持续监控 recovery 相关指标，可以设置合理的阈值，当指标超出阈值时及时发出预警。例如，当 recovery 时间过长或者资源使用过高时，及时通知运维人员进行处理，防止问题恶化影响整个集群的性能。

常用监控命令及使用技巧

_cat/recovery 命令

命令基本格式 GET _cat/recovery?v 这个命令用于查看集群中正在进行的 recovery 任务的详细信息。?v 参数表示以详细模式显示结果，这样可以看到更多有用的信息。
返回结果解析
- index：表示正在进行 recovery 的索引名称。
- shard：分片编号。
- stage：recovery 的当前阶段，常见的阶段有 INIT（初始化）、TRANSLOG（传输事务日志）、SNAPSHOT（传输快照数据）、FINALIZE（完成 finalize 操作）、DONE（完成）。
- status：状态，如 STARTED（已开始）、IN_PROGRESS（进行中）、DONE（完成）。
- source_host：源节点的主机名，即数据复制的源节点。
- source_node：源节点的节点名。
- target_host：目标节点的主机名，即数据复制的目标节点。
- target_node：目标节点的节点名。
- type：recovery 的类型，如 NORMAL（普通 recovery）、LOCAL（本地 recovery）。
- time：已花费的时间。
- total_shards：该索引的总分片数。
- start：recovery 开始的时间。
- stop：recovery 结束的时间（如果已完成）。
- total_time：总耗时（如果已完成）。
- translog_ops：事务日志操作数。
- translog_size：事务日志大小。
- store_ops：存储操作数。
- store_size：存储大小。
- percent：已完成的百分比。
示例假设我们执行 GET _cat/recovery?v 命令后得到如下结果：

index   shard stage   status source_host    source_node target_host    target_node type   time total_shards start stop total_time translog_ops translog_size store_ops store_size percent
myindex 0    SNAPSHOT STARTED 192.168.1.100 node1       192.168.1.101 node2       NORMAL 30s  5          2023-01-01T10:00:00 2023-01-01T10:00:30 30s        1000        10MB        5000     50MB      30%

从这个结果中我们可以看出，myindex 索引的 0 号分片正在从 node1 复制到 node2，当前处于 SNAPSHOT 阶段，已经进行了 30 秒，完成了 30%，事务日志操作数为 1000，大小为 10MB 等信息。 4. 使用技巧

按索引过滤：如果只想查看某个特定索引的 recovery 情况，可以在命令后加上索引名，例如 GET _cat/recovery/myindex?v。
按节点过滤：可以通过查询参数 source_node 或 target_node 来过滤特定节点相关的 recovery 任务。比如，GET _cat/recovery?v&source_node=node1 可以查看从 node1 作为源节点的所有 recovery 任务。

_cluster/health 命令

命令基本格式 GET _cluster/health 这个命令主要用于获取集群的健康状态信息，但它也能间接反映 recovery 对集群健康的影响。
返回结果解析
- cluster_name：集群名称。
- status：集群状态，有 green（健康）、yellow（部分副本未分配，但数据仍可访问）、red（存在未分配的主分片，数据部分不可用）。在 recovery 过程中，如果集群状态从 green 变为 yellow 或 red，则需要关注 recovery 的进展情况。
- timed_out：是否超时。
- number_of_nodes：集群中的节点数。
- number_of_data_nodes：数据节点数。
- active_primary_shards：活动的主分片数。
- active_shards：活动的分片数（包括主分片和副本分片）。
- relocating_shards：正在重新分配的分片数，这与 recovery 密切相关，重新分配分片就会触发 recovery。
- initializing_shards：正在初始化的分片数，初始化过程通常涉及 recovery。
- unassigned_shards：未分配的分片数。
示例执行 GET _cluster/health 命令后可能得到如下结果：

{
    "cluster_name": "my_cluster",
    "status": "yellow",
    "timed_out": false,
    "number_of_nodes": 3,
    "number_of_data_nodes": 3,
    "active_primary_shards": 5,
    "active_shards": 10,
    "relocating_shards": 2,
    "initializing_shards": 0,
    "unassigned_shards": 0
}

从这个结果中我们可以看到集群状态为 yellow，有 2 个分片正在重新分配，这意味着正在进行 recovery 操作，需要进一步关注这些分片的 recovery 进度。 4. 使用技巧

设置详细度：可以通过 level 参数设置返回信息的详细度，如 GET _cluster/health?level=indices 可以获取每个索引的健康状态信息，更详细地了解哪些索引在 recovery 过程中影响了集群健康。
监控集群状态变化：可以使用脚本定时执行这个命令，观察集群状态的变化趋势。如果集群状态持续处于 yellow 或 red，且 relocating_shards 或 initializing_shards 长时间不为 0，就需要深入排查 recovery 问题。

_cluster/stats 命令

命令基本格式 GET _cluster/stats 该命令用于获取集群的统计信息，包括 recovery 相关的资源使用情况。
返回结果解析 在返回结果的 nodes 部分，会有关于 recovery 的相关统计：
- recovery：包含 recovery 相关的统计信息。
  - current_as_source：当前作为源节点正在进行的 recovery 任务数。
  - current_as_target：当前作为目标节点正在进行的 recovery 任务数。
  - throttled_as_source：作为源节点被限流的 recovery 任务数。
  - throttled_as_target：作为目标节点被限流的 recovery 任务数。
  - total_as_source：作为源节点完成的总 recovery 任务数。
  - total_as_target：作为目标节点完成的总 recovery 任务数。
  - total_time_in_millis_as_source：作为源节点花费的总 recovery 时间（毫秒）。
  - total_time_in_millis_as_target：作为目标节点花费的总 recovery 时间（毫秒）。
示例执行 GET _cluster/stats 命令后，在返回结果中找到 nodes 部分，可能有如下信息：

{
    "nodes": {
        "recovery": {
            "current_as_source": 1,
            "current_as_target": 0,
            "throttled_as_source": 0,
            "throttled_as_target": 0,
            "total_as_source": 10,
            "total_as_target": 15,
            "total_time_in_millis_as_source": 10000,
            "total_time_in_millis_as_target": 15000
        }
    }
}

从这个结果可以看出，当前有 1 个以该节点作为源节点的 recovery 任务正在进行，作为源节点总共完成了 10 个 recovery 任务，花费了 10000 毫秒等信息。 4. 使用技巧

对比不同时间的统计：可以定时执行这个命令，对比不同时间点的 recovery 统计信息，观察 recovery 任务的变化趋势。例如，如果发现 current_as_source 或 current_as_target 持续增加，而 total_time_in_millis_as_source 或 total_time_in_millis_as_target 增长缓慢，可能意味着 recovery 效率低下，需要进一步排查。
结合其他指标分析：将 recovery 相关统计与节点的 CPU、内存、网络等指标结合分析。比如，如果 current_as_source 较高，同时网络带宽使用率也很高，可能需要优化网络设置以提高 recovery 速度。

索引级别的监控命令

_settings 命令查看索引恢复设置
- 命令基本格式 GET myindex/_settings 这个命令可以查看索引的各种设置，包括与 recovery 相关的设置。例如，index.translog.durability 设置会影响 recovery 过程中事务日志的持久化方式，进而影响 recovery 的性能。
- 返回结果解析 在返回结果中，index 部分包含了索引的各种设置。例如：
```
{
    "myindex": {
        "settings": {
            "index": {
                "number_of_shards": "5",
                "number_of_replicas": "1",
                "translog": {
                    "durability": "async"
                }
            }
        }
    }
}
```
这里可以看到 myindex 索引的分片数、副本数以及事务日志的持久化方式为 async（异步）。
- 使用技巧 根据 recovery 的需求和性能情况，可以调整这些设置。例如，如果希望提高 recovery 速度，可以将 index.translog.durability 设置为 request，这样每次写入操作都会同步刷新事务日志，但会增加 I/O 开销。在调整设置前，需要充分测试对集群性能的影响。
_stats 命令查看索引恢复统计
- 命令基本格式 GET myindex/_stats 该命令用于获取索引的统计信息，其中包含 recovery 相关的统计数据。
- 返回结果解析 在返回结果的 primaries 和 total 部分，会有 recovery 相关的统计：
- recovery：
  - current_as_source：当前作为源分片正在进行的 recovery 任务数。
  - current_as_target：当前作为目标分片正在进行的 recovery 任务数。
  - total_as_source：作为源分片完成的总 recovery 任务数。
  - total_as_target：作为目标分片完成的总 recovery 任务数。
- 示例执行 GET myindex/_stats 命令后，在返回结果中找到 primaries 部分，可能有如下信息：
```
{
    "primaries": {
        "recovery": {
            "current_as_source": 0,
            "current_as_target": 1,
            "total_as_source": 5,
            "total_as_target": 3
        }
    }
}
```
这表明 myindex 索引的主分片当前有 1 个以目标分片身份正在进行的 recovery 任务，作为源分片总共完成了 5 个 recovery 任务，作为目标分片总共完成了 3 个 recovery 任务。
- 使用技巧 通过查看这些统计信息，可以了解单个索引的 recovery 情况。如果发现某个索引的 recovery 任务异常，比如 current_as_target 长时间不为 0，可以进一步深入分析该索引的设置和数据情况，找出问题所在。

基于监控结果的优化策略

调整网络配置

增加带宽：如果在监控中发现 recovery 速度受网络带宽限制，例如通过 _cluster/stats 命令发现 total_time_in_millis_as_source 和 total_time_in_millis_as_target 较长，且网络带宽使用率一直处于高位，可以考虑增加网络带宽。这可以通过升级网络设备或者与网络管理员协商调整网络策略来实现。
优化网络拓扑：不合理的网络拓扑可能导致网络延迟增加，影响 recovery 速度。例如，某些节点之间存在过多的网络跳数。可以通过优化网络拓扑，减少节点之间的网络路径长度，降低网络延迟。这可能需要重新规划网络布线或者调整网络设备的连接方式。

优化磁盘 I/O

使用高速磁盘：在 recovery 过程中，磁盘 I/O 性能对恢复速度有重要影响。如果监控发现磁盘 I/O 繁忙，且 recovery 速度缓慢，可以考虑将数据存储迁移到高速磁盘，如 SSD。SSD 的读写速度远高于传统机械硬盘，可以显著提高 recovery 的效率。
调整磁盘调度算法：不同的磁盘调度算法适用于不同的应用场景。对于 ElasticSearch 的 recovery 操作，一些调度算法可能更有利于提高 I/O 性能。例如，在 Linux 系统中，可以根据磁盘类型和负载情况调整 elevator 参数，选择合适的调度算法，如 deadline 算法对于随机 I/O 有较好的性能表现。

调整 ElasticSearch 配置

调整 recovery 并发度：ElasticSearch 允许通过配置参数来调整 recovery 的并发度。在 elasticsearch.yml 文件中，可以设置 cluster.routing.allocation.node_concurrent_recoveries 参数来控制每个节点同时进行的 recovery 任务数。如果发现集群资源（如网络、磁盘 I/O）有剩余，但 recovery 速度较慢，可以适当增加这个值；如果资源紧张，导致 recovery 影响了集群的正常业务，可以适当降低这个值。
优化索引设置：如前文提到的，可以根据 recovery 的需求调整索引的设置。例如，对于写入频繁且对 recovery 速度要求较高的索引，可以将 index.translog.durability 设置为 async，但需要注意数据一致性的风险。同时，合理调整 index.number_of_shards 和 index.number_of_replicas 也能影响 recovery 的性能和资源消耗。如果分片数过多，recovery 时的资源开销会增大；副本数过多可能导致 recovery 任务增多。

监控与优化的持续进行

建立监控体系：为了确保 ElasticSearch 集群的稳定运行，需要建立一套完善的监控体系。可以使用 ElasticSearch 自带的监控命令结合第三方监控工具，如 Grafana 和 Prometheus，实现对集群各项指标的实时监控和可视化展示。通过设置合理的告警规则，当 recovery 相关指标出现异常时及时通知运维人员。
定期优化：随着集群数据量的增长和业务需求的变化，需要定期对集群进行优化。根据监控数据和业务实际情况，适时调整网络配置、磁盘 I/O 策略以及 ElasticSearch 配置参数，以保持集群在 recovery 过程中的高效运行。

在 ElasticSearch 中，熟练掌握 recovery 相关监控命令并基于监控结果进行优化，是保障集群数据完整性和高性能运行的关键。通过对各种监控命令的深入理解和灵活运用，以及不断优化集群的配置和环境，可以有效地应对 recovery 过程中可能出现的各种问题，提高 ElasticSearch 集群的整体可靠性和可用性。