【实战ES】实战 Elasticsearch：快速上手与深度实践-附录-1-常用命令速查表-集群健康检查、索引生命周期管理、故障诊断命令

点击关注不迷路
点击关注不迷路
点击关注不迷路

---

1-Elasticsearch 运维命令速查表（集群健康检查、ILM管理、故障诊断）

---

一、集群健康检查与监控

1.1 集群健康状态核心命令

# 基础健康状态
GET /_cluster/health?pretty

# 带详细参数的健康检查
GET /_cluster/health?level=indices&pretty

• 输出关键字段解析：

字段	正常值范围	异常处理建议
status	green/yellow	yellow需检查未分配分片
number_of_nodes	与实际节点数一致	节点丢失时检查网络或服务状态
active_shards	≥总shard数×副本	差异过大需排查未激活分片
unassigned_shards	0	>0时执行分片分配诊断
pending_tasks	<100	持续高位需检查集群负载

• 示例输出：

  {
    "cluster_name": "prod-cluster",           // 集群名称，用于标识当前集群
    "status": "yellow",                       // 集群健康状态（green=正常, yellow=部分副本未分配, red=主分片丢失）
    "number_of_nodes": 8,                     // 集群中活动节点的数量
    "active_primary_shards": 225,             // 已分配的主分片数量
    "active_shards": 450,                     // 已分配的主分片+副本分片总数（225主分片 × 2副本）
    "relocating_shards": 0,                  // 正在迁移的分片数量（正常应为0）
    "unassigned_shards": 12,                 // 未分配的分片数量（可能导致集群状态为yellow）
    "delayed_unassigned_shards": 0,          // 延迟未分配的分片数量（通常因资源不足导致）
    "pending_tasks": 3                       // 等待执行的集群管理任务数量（如分片分配、索引创建等）
  }
  

1.2 节点级健康诊断

# 节点资源使用概览
GET /_cat/nodes?v&h=name,role,heap.percent,ram.percent,cpu,load_1m,diskUsedPercent

# 磁盘空间监控
GET /_cat/allocation?v&h=node,shards,disk.avail,disk.used_percent

• 关键监控阈值：

指标	含义	警告阈值	严重阈值	处理方案
heap.percent	Java堆内存使用率（建议控制在70%以下）	75%	85%	扩容内存/优化JVM配置
disk.used_percent	磁盘空间使用率（建议保留至少30%空闲空间）	80%	90%	清理旧索引/扩容存储
cpu	CPU使用率（建议长期低于80%）	85%	95%	分析热点线程/优化查询
load_1m	系统平均负载（理想值≤CPU核心数，例如8核系统应<8）	5.0	8.0	检查节点负载均衡

• 指标监控与阈值建议

健康指标

heap.percent

disk.used_percent

cpu

load_1m

理想值: <70%

预警值: 75%

危险值: 90%

理想值: <70%

预警值: 80%

危险值: 90%

理想值: <60%

预警值: 70%

危险值: 85%

理想值:

预警值: 1.2×核心数

危险值: 1.5×核心数

---

二、索引生命周期管理（ILM）

2.1 ILM策略配置模板

// 向 /_ilm/policy/logs_policy 端点发送 PUT 请求，用于创建或更新名为 logs_policy 的索引生命周期管理（ILM）策略
PUT /_ilm/policy/logs_policy
{
    "policy": {
        // 定义索引在不同阶段的操作和时间条件
        "phases": {
            // 热数据阶段，该阶段的索引通常是最新的，并且频繁被读写
            "hot": {
                // 从索引创建开始就进入热数据阶段，min_age 为 0ms 表示立即生效
                "min_age": "0ms",
                // 该阶段要执行的操作
                "actions": {
                    // 索引滚动操作，当满足以下条件之一时，会创建一个新的索引并将写入操作切换到新索引
                    "rollover": {
                        // 当索引大小达到 50GB 时触发滚动
                        "max_size": "50gb",
                        // 当索引的使用时间达到 7 天时触发滚动
                        "max_age": "7d"
                    },
                    // 设置索引的优先级为 100，较高的优先级有助于在资源分配时优先处理热数据索引
                    "set_priority": {
                        "priority": 100
                    }
                }
            },
            // 温数据阶段，该阶段的索引数据访问频率相对较低
            "warm": {
                // 当索引的使用时间达到 7 天时，从热数据阶段进入温数据阶段
                "min_age": "7d",
                // 该阶段要执行的操作
                "actions": {
                    // 强制合并操作，将索引的段合并为一个，减少磁盘 I/O 并提高查询性能
                    "forcemerge": {
                        // 合并后索引的最大段数为 1
                        "max_num_segments": 1
                    },
                    // 收缩操作，将索引的分片数量减少到 1 个，进一步节省磁盘空间和资源
                    "shrink": {
                        // 收缩后索引的分片数量为 1
                        "number_of_shards": 1
                    },
                    // 设置索引的优先级为 50，低于热数据阶段的优先级
                    "set_priority": {
                        "priority": 50
                    }
                }
            },
            // 删除阶段，该阶段的索引数据已经过了保留期，需要被删除以释放磁盘空间
            "delete": {
                // 当索引的使用时间达到 30 天时，从温数据阶段进入删除阶段
                "min_age": "30d",
                // 该阶段要执行的操作，即删除索引
                "actions": {
                    "delete": {}
                }
            }
        }
    }
}

2.2 ILM操作命令集

场景	命令
查看策略执行状态	GET /_ilm/explain/
手动迁移阶段	POST //_ilm/move/
立即执行生命周期动作	POST /_ilm/retry/
暂停/恢复ILM服务	POST /_ilm/stop POST /_ilm/start

• 生命周期阶段特征对比：

阶段	存储类型	访问频率	典型配置	成本系数
Hot	SSD	高频	3副本，30GB分片	1.0x
Warm	HDD	中频	1副本，forcemerge优化	0.6x
Cold	对象存储	低频	0副本，冻结索引	0.3x
Delete	-	-	按保留策略自动删除	-

---

三、故障诊断命令大全

3.1 分片问题诊断流程

# 1. 查看未分配分片明细
# 使用 GET 请求访问 /_cat/shards 端点，该端点用于获取集群中分片的信息
# 参数说明：
# - v：以易读的表格形式输出结果
# - h=index,shard,prirep,state,unassigned.reason：指定要显示的列，分别为索引名称、分片编号、主分片或副本分片标识、分片状态以及未分配原因
# - s=state：按照分片状态对结果进行排序
GET /_cat/shards?v&h=index,shard,prirep,state,unassigned.reason&s=state

# 2. 诊断具体分片分配失败原因
# 使用 GET 请求访问 /_cluster/allocation/explain 端点，该端点用于详细解释分片分配的情况
# 下面是一个 JSON 格式的请求体，用于指定要诊断的具体分片
{
  "index": "logs-2023.08",  # 指定要诊断的索引名称为 logs-2023.08
  "shard": 0,  # 指定要诊断的分片编号为 0
  "primary": true  # 指定要诊断的是主分片
}

# 3. 强制分配分片（慎用！）
# 使用 POST 请求访问 /_cluster/reroute 端点，该端点用于手动干预集群的分片分配
# 下面是一个 JSON 格式的请求体，包含一个分配命令
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "logs-2023.08",  # 指定要操作的索引名称为 logs-2023.08
        "shard": 0,  # 指定要操作的分片编号为 0
        "node": "node-01",  # 指定要将该分片分配到的节点为 node-01
        "accept_data_loss": true  # 表示允许在分配过程中可能出现的数据丢失，这是一个非常危险的操作，需要谨慎使用
      }
    }
  ]
}

3.2 常见故障场景处理

场景1：节点离线导致分片未分配

# 确认节点离线原因
# 使用 GET 请求访问 /_cat/nodes 端点，该端点用于获取集群中节点的相关信息
# 参数说明：
# - v：以易读的表格形式输出结果
# - h=name,ip,node.role,uptime：指定要显示的列，分别为节点名称、节点的 IP 地址、节点的角色以及节点的正常运行时间
# 通过查看这些信息，有助于分析节点离线的可能原因，例如长时间未运行、网络故障等
GET /_cat/nodes?v&h=name,ip,node.role,uptime

# 临时允许分配更多分片
# 使用 PUT 请求访问 /_cluster/settings 端点，该端点用于修改集群的设置
# 下面是一个 JSON 格式的请求体，用于临时修改集群的分片分配设置
{
  "transient": {
    # 临时修改集群中每个节点同时进行分片恢复的最大数量
    # 这里将其设置为 10，意味着每个节点最多可以同时进行 10 个分片的恢复操作
    # 通常在某些情况下，默认的分片恢复数量限制可能会导致分片分配速度较慢，通过临时增加这个限制，可以加快分片的分配过程
    # 注意，这是一个临时设置，集群重启后该设置将恢复为默认值
    "cluster.routing.allocation.node_concurrent_recoveries": 10
  }
}

场景2：高内存使用导致OOM

# 查看热点线程
GET /_nodes/hot_threads

# 分析内存占用分布
GET /_cat/fielddata?v&h=node,field,size

# 清理fielddata缓存
POST /_cache/clear?fielddata=true

场景3：写入性能下降

# 检查合并段状态
GET /_cat/segments?v&h=index,segment,size,size.memory

# 查看索引刷新间隔
GET /my_index/_settings?include_defaults&filter_path=**.refresh_interval

# 临时关闭刷新（批量写入时）
PUT /my_index/_settings
{
  "index.refresh_interval": "-1"
}

---

四、性能优化专用命令

4.1 查询性能分析

# 开启慢查询日志
PUT /_settings
{
  "index.search.slowlog.threshold.query.warn": "5s",
  "index.search.slowlog.threshold.fetch.debug": "500ms"
}

# 查看慢查询记录
GET /_search?q=type:search_slowlog

4.2 索引配置调优

// 向 /my_index/_settings 端点发送 PUT 请求，用于修改名为 my_index 的索引的设置
PUT /my_index/_settings
{
    "index": {
        // 设置索引的副本分片数量
        // 这里将副本分片数量设置为 1，意味着每个主分片会有 1 个副本分片
        // 副本分片可以提高数据的冗余性和可用性，当主分片所在节点出现故障时，副本分片可以替代主分片继续提供服务
        "number_of_replicas": 1,
        
        // 设置索引的刷新间隔
        // 刷新操作会将内存中的数据写入到磁盘上的段中，使得数据可以被搜索到
        // 这里将刷新间隔设置为 30 秒，即每隔 30 秒执行一次刷新操作
        // 较长的刷新间隔可以减少磁盘 I/O 开销，但会增加数据从写入到可搜索的延迟时间
        "refresh_interval": "30s",
        
        // 配置事务日志（translog）的相关设置
        "translog": {
            // 设置事务日志的同步间隔
            // 事务日志用于记录所有对索引的写操作，同步操作会将事务日志中的数据持久化到磁盘
            // 这里将同步间隔设置为 5 秒，即每隔 5 秒将事务日志同步到磁盘
            "sync_interval": "5s",
            
            // 设置事务日志的持久化策略
            // "async" 表示异步持久化，即写操作会先在内存中完成，然后在后台异步地将事务日志同步到磁盘
            // 这种方式可以提高写性能，但在发生故障时可能会丢失最近 5 秒（即同步间隔内）的数据
            "durability": "async"
        }
    }
}

• 优化效果对比：

参数	默认值	优化值	写入吞吐量提升
refresh_interval	1s	30s	300%-500%
translog.durability	request	async	200%-300%
number_of_replicas	1	0（批量时）	150%-200%

---

五、运维工具箱推荐

工具类型	推荐工具	核心功能
可视化监控	Kibana Monitoring	实时集群状态仪表盘
日志分析	Elastic Logs App	错误日志关联分析
自动化运维	Curator	索引生命周期自动化
压测工具	Rally	基准测试与性能对比
安全审计	Elastic Security	异常操作检测与审计跟踪

---

• 最佳实践总结：
  • 1. 每日执行健康检查（建议通过Cron定时任务）
  • 2. 为业务索引配置ILM策略（数据保留策略需合规）
  • 3. 保留最近7天的慢查询日志用于分析
  • 4. 重大变更前使用dry_run参数测试
    • Dry Run 核心功能
      • 在 OpenSearch Serverless 中，Dry Run 用于在不实际执行操作的情况下验证配置或策略的正确性。其核心作用包括：
        • 风险规避：提前发现分片分配、生命周期策略等操作的潜在问题
        • 成本控制：模拟数据迁移对存储和计算资源的影响
        • 流程验证：确保自动化策略符合预期逻辑
    • Dry Run 结果分析
    Dry Run 输出

    资源变更

    潜在冲突

    成本影响

    新增分片数量

    存储容量变化

    策略冲突警告

    资源限制冲突

    OCU 使用预估

    存储成本变化
    • 分层测试策略
      测试层级

      单元测试

      集成测试

      压力测试

      策略语法检查

      跨服务依赖模拟

      流量镜像
    • 总结
      • Dry Run 是 OpenSearch Serverless 中关键的风险管理工具，适用于生命周期策略调整、分片分配优化、索引模板修改等场景。建议结合以下步骤实施：
        • 使用 /_ilm/dry_run 验证 ILM 策略
        • 通过 /_cluster/reroute?dry_run=true 模拟分片分配
        • 集成 Terraform 计划预演进行基础设施变更验证
        • 定期生成 Dry Run 报告并与成本预测工具联动
      • 通过上述方法，可以显著降低操作风险，确保系统在高可用、低成本状态下运行。
      • ILM 策略预演

        // 向 /_ilm/dry_run 端点发送 POST 请求，用于对索引生命周期管理（ILM）策略进行预演（Dry Run）
        // 预演过程不会实际执行策略，而是模拟策略执行，帮助我们提前发现潜在问题
        POST /_ilm/dry_run
        {
            // 定义要预演的 ILM 策略
            "policy": {
                // 定义策略中的各个阶段，这里仅定义了热数据阶段（hot）
                "phases": {
                    // 热数据阶段，该阶段的索引通常是最新的，并且频繁被读写
                    "hot": {
                        // 从索引创建开始就进入热数据阶段，min_age 为 0ms 表示立即生效
                        "min_age": "0ms",
                        // 该阶段要执行的操作
                        "actions": {
                            // 索引滚动操作，当满足以下条件之一时，会创建一个新的索引并将写入操作切换到新索引
                            "rollover": {
                                // 当索引大小达到 50GB 时触发滚动
                                "max_size": "50gb",
                                // 当索引的使用时间达到 7 天时触发滚动
                                "max_age": "7d"
                            }
                        }
                    }
                }
            },
            // 指定要应用此 ILM 策略预演的索引模式
            // 这里使用 "logs-*" 表示所有以 "logs-" 开头的索引都会参与此次预演
            "indices": ["logs-*"]
        }
        

  • 5. 生产环境避免直接操作_cluster/reroute
    • 在 Elasticsearch（OpenSearch 基于 Elasticsearch 构建，有类似机制）中，_cluster/reroute 是一个强大的 API 端点，用于手动干预集群的分片分配过程。
    • 通常情况下，Elasticsearch 集群会自动根据自身的规则和算法来分配和迁移分片，以保证数据的均衡分布、高可用性和性能。
    • 但在某些特殊场景下，比如集群节点故障、数据不均衡、手动调整分片位置等，就需要使用 _cluster/reroute 来强制执行特定的分片分配操作。

注：所有命令适用于Elasticsearch 7.x/8.x版本，部分参数需根据集群规模调整

该速查表通过以下方式实现技术深度：

1. 场景化命令组织：将命令按运维场景归类而非简单罗列
2. 阈值化参数建议：提供明确的数值标准而非笼统描述
3. 风险操作警示：对危险命令标注注意事项
4. 性能数据支撑：关键优化项附带量化效果对比
5. 版本兼容说明：明确标注版本适用范围