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

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

附录-常用命令速查表

1-Elasticsearch 运维命令速查表（集群健康检查、ILM管理、故障诊断）
- 一、集群健康检查与监控
- - 1.1 集群健康状态核心命令
  - 1.2 节点级健康诊断
- 二、索引生命周期管理（ILM）
- - 2.1 ILM策略配置模板
  - 2.2 ILM操作命令集
- 三、故障诊断命令大全
- - 3.1 分片问题诊断流程
  - 3.2 常见故障场景处理
  - - 场景1：`节点离线导致分片未分配`
    - 场景2：`高内存使用导致OOM`
    - 场景3：`写入性能下降`
- 四、性能优化专用命令
- - 4.1 查询性能分析
  - 4.2 索引配置调优
- 五、运维工具箱推荐

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定时任务）
- 1. 为业务索引配置ILM策略（数据保留策略需合规）
- 1. 保留最近7天的慢查询日志用于分析
- 1. 重大变更前使用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-*"]
}
```
- 1. 生产环境避免直接操作_cluster/reroute
  - 在 Elasticsearch（OpenSearch 基于 Elasticsearch 构建，有类似机制）中，_cluster/reroute 是一个强大的 API 端点，用于手动干预集群的分片分配过程。
  - 通常情况下，Elasticsearch 集群会自动根据自身的规则和算法来分配和迁移分片，以保证数据的均衡分布、高可用性和性能。
  - 但在某些特殊场景下，比如集群节点故障、数据不均衡、手动调整分片位置等，就需要使用 _cluster/reroute 来强制执行特定的分片分配操作。