【实战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	检查节点负载均衡

• 指标监控与阈值建议

---

二、索引生命周期管理（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/<index-name>
手动迁移阶段	POST /<index-name>/_ilm/move/<phase>
立即执行生命周期动作	POST /_ilm/retry/<index-name>
暂停/恢复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 是 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. 版本兼容说明：明确标注版本适用范围