处理 Red 状态的 ES 索引 GET _cat/shards?v=true&h=index,shard,prirep,state,node,unassigned.reason&s=state 1 2 ops-pod-loggie-2026.06.11 0 p UNASSIGNED NODE_LEFT ops-pod-loggie-2026.06.11 0 r UNASSIGNED ALLOCATION_FAILED 尝试重新分配 1 POST _cluster/reroute?retry_failed=true 或者直接删除 1 DELETE ops-pod-loggie-2026.06.11 定时清理索引 全部索引仅保留 7 天 创建 ILM 策略 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 PUT _ilm/policy/ops-delete-after-7d { "policy": { "phases": { "hot": { "actions": {} }, "delete": { "min_age": "7d", "actions": { "delete": {} } } } } } 创建索引模板 1 2 3 4 5 6 7 8 9 10 PUT _index_template/ops-delete-after-7d

1. 现象 基于 Kubernetes 的 Elasticsearch 频繁重启，导致服务几乎不可用。 在导入数据过程中，Pod 的内存使用持续增长 Pod 内存使用接近 Limit 之后，继续导入就会触发 Pod 异常退出，错误日志 ERROR: Elasticsearch exited unexpectedly Pod 内存使用率并不会下降，而是维持在 Limit 附近，不久又异常退出 Elasticsearch Pod 内存限制在 64GB，而 JVM 内

1. 在主机上挂载内存存储目录 创建目录用于挂载 1 mkdir /mnt/memory_storage 挂载 tmpfs 文件系统 1 mount -t tmpfs -o size=800G tmpfs /mnt/memory_storage 存储空间会按需使用，也就是使用 100G 存储时才会占用 100G 内存。主机节点上有 2T 内存，这里分配 800G 内存用于存储 Elasticsearch 数据。 提前创建好目录 1 2 3 mkdir /mnt/memory_storage/elasticsearch-data-es-jfs-prod-es-default-0 mkdir /mnt/memory_storage/elasticsearch-data-es-jfs-prod-es-default-1 mkdir /mnt/memory_storage/elasticsearch-data-es-jfs-prod-es-default-2 如果没有提前创建好目录，并

1. 存储方案 三种存储方案： 基于目录隔离公用一个 JuiceFS Elasticsearch 的节点共用一个 JuiceFS，通过子目录挂载不同的 Elasticsearch 节点。 /0/ 对应节点 Node-0 /1/ 对应节点 Node-1 /2/ 对应节点 Node-2 这种方式的好处主要是，易于扩展、配置方便。 基于 JuiceFS 隔离节点数据 Elasticsearch 每个节点都对接一个独立的 JuiceF

如果采用 Logstash 集中接收 Filebeat 的日志输入，容易造成单点瓶颈；如果采用 Kafka 接收 Filebeat 的日志输入，日志的时效性又得不到保障。这里直接将 Filebeat 采集的日志直接输出到 Elasticsearch。 1. 准备工作 节点规划 这里没有区分 master、data、client 节点，而是