ElasticsearchHeapUsageCritical (critical, >90%)

Что означает алерт

На одной из нод Elasticsearch утилизация heap >90% дольше 5 минут.
Это риск частых pause GC, деградации latency и отказов по памяти.

Подключение к ES в Kubernetes

kubectl -n camunda-prod port-forward svc/camunda-elasticsearch 9200:9200

Быстрая диагностика

1. Подтвердить критический heap:

curl -s 'localhost:9200/_cat/nodes?v&h=name,heap.current,heap.percent,ram.current,ram.percent,cpu,load_1m,node.role,master'

1. Проверить old GC:

curl -s 'localhost:9200/_nodes/stats/jvm?filter_path=nodes.*.name,nodes.*.jvm.gc.collectors.old.collection_count,nodes.*.jvm.gc.collectors.old.collection_time_in_millis' | jq

1. Проверить состояние кластера и шардов:

curl -s 'localhost:9200/_cluster/health?pretty'
curl -s 'localhost:9200/_cat/shards?h=index,shard,prirep,state,node,unassigned.reason&s=state'

Срочные действия

1. Снять нагрузку с проблемной ноды:
2. уменьшить тяжелые агрегации/поисковые джобы;

3. снизить ingest, если есть такая возможность.

4. Быстро освободить heap-память от кешей (временно):

curl -s -X POST 'localhost:9200/_cache/clear?fielddata=true&query=true&request=true&pretty'

1. Уменьшить давление от шардов:

curl -s 'localhost:9200/_cat/indices?format=json&h=index,pri,rep,store.size,docs.count' \
| jq -r '.[] | [.index, .pri, .rep, ((.pri|tonumber) * ((.rep|tonumber)+1)), ."store.size"] | @tsv' \
| sort -k4,4nr | head -30

1. Удалить только подтвержденные устаревшие индексы:

curl -s -X DELETE 'localhost:9200/<old-index-name>?pretty'

Пост-инцидентные действия

1. Проверить соответствие heap и ресурсов pod:
2. Xms/Xmx должны быть одинаковыми;
3. heap обычно не больше 50% доступной памяти ноды/контейнера.
4. Устранить причины роста heap:
5. oversharding;
6. очень большие bucket-агрегации;
7. слишком крупные bulk-запросы;
8. неконтролируемый рост индексов без retention.

Источник

"Elasticsearch heap size usage and JVM garbage collection"
https://www.elastic.co/search-labs/blog/elasticsearch-heap-size-jvm-garbage-collection