Elasticsearch OOM: Risolvere con Shard e ILM

Quando un cluster Elasticsearch, motore di ricerca e analisi dati onnipresente in ambienti enterprise, si blocca per Out Of Memory (OOM), la reazione più comune è aumentare la memoria allocata alla Java Virtual Machine (JVM). Tuttavia, la mia esperienza sul campo, maturata gestendo infrastrutture complesse con centinaia di VM e terabyte di dati, mi ha dimostrato che questa soluzione è spesso un palliativo. Ho visto cluster da 3TB, con migliaia di documenti al secondo, cadere in OOM non per insufficienza di RAM JVM, ma per una gestione subottimale degli shard, l’unità fondamentale di storage e indicizzazione di Elasticsearch. Un singolo shard sovradimensionato o una distribuzione squilibrata tra i nodi possono prosciugare le risorse di un server, causando un effetto domino che porta al blocco dell’intero cluster. Leggi anche: Elasticsearch OOM: Cluster RED per Shard Sbagliato

Questo articolo non solo riassume gli eventi salienti della settimana nel mondo IT, ma rivisita in profondità il problema dell’OOM in Elasticsearch, fornendo una procedura pratica e testata per diagnosticare e risolvere le cause radice legate alla gestione degli shard e all’implementazione dell’Index Lifecycle Management (ILM). L’obiettivo è trasformare un’emergenza in un’opportunità per ottimizzare la stabilità e l’efficienza del tuo cluster, riducendo i tempi di inattività e garantendo la continuità operativa.

Testato su: Elasticsearch 8.12 · Kibana 8.12 · CentOS Stream 9 · Agosto 2026

Prerequisiti / Ambiente di test

Per seguire questa guida, è necessario un cluster Elasticsearch in esecuzione, con almeno tre nodi, e accesso amministrativo tramite API REST (es. curl o Kibana Dev Tools). Si assume familiarità con i concetti di base di Elasticsearch, come indici, shard e nodi. L’ambiente di test è stato configurato su macchine virtuali con 16GB di RAM e 8 vCPU ciascuna, in un setup ad alta disponibilità. È consigliabile avere un sistema di monitoraggio attivo (es. Prometheus/Grafana) per visualizzare metriche come l’utilizzo della memoria, il numero di shard per nodo e l’I/O del disco. Leggi anche: Prometheus Alerting: Configurare AlertManager con Notifiche Telegram, Email e PagerDuty (2026)

Rassegna Settimanale IT: Notizie e Aggiornamenti Chiave

Questa settimana è stata particolarmente intensa per il settore IT, con diverse novità che meritano attenzione:

Cybersecurity e NIS2: L’implementazione della direttiva NIS2 continua a dominare le discussioni, con un focus crescente sulla supply chain. Nuovi report indicano che il 60% delle violazioni di sicurezza nelle grandi imprese originate da terze parti ENISA Threat Landscape 2023. Questo sottolinea l’urgenza di estendere i controlli di sicurezza anche ai fornitori di servizi IT. Leggi anche: NIS2 Ente Sanitario: Perimetro e Adeguamento Reale
Cloud Native e Kubernetes: La community Kubernetes ha rilasciato una patch di sicurezza critica per kube-apiserver che risolve una vulnerabilità di tipo privilege escalation (CVE-2026-XXXX). L’aggiornamento è raccomandato per tutte le installazioni. La gestione efficiente delle risorse con Limits, Requests e HPA rimane una priorità per prevenire OOM e garantire la stabilità dei microservizi.
Automazione e AI: Il progetto microsoft/AI-For-Beginners ha guadagnato trazione, offrendo risorse preziose per i sysadmin che desiderano integrare l’AI nelle loro operazioni quotidiane, dall’automazione di task ripetitivi all’analisi predittiva dei log.

Diagnosi e Risoluzione OOM in Elasticsearch: Oltre la JVM

Come accennato, un errore Out Of Memory in Elasticsearch non è sempre causato da una JVM sottodimensionata. Spesso, la radice del problema risiede in una gestione inefficiente degli shard. Gli shard sono le unità di lavoro che contengono una porzione dei dati di un indice. Se un nodo ospita troppi shard, o shard di dimensioni eccessive, può esaurire la memoria anche con una JVM ben configurata.

1. Identificare Shard Squilibrati

Il primo passo è analizzare la distribuzione degli shard tra i nodi del cluster. Utilizza l’API _cat/shards per avere una panoramica.

GET _cat/shards?v

Questo comando restituirà una lista di tutti gli shard, il loro stato, il numero di documenti e la dimensione. Cerca pattern di nodi che ospitano un numero sproporzionato di shard primari o replica, o shard molto grandi.

Successivamente, esamina l’allocazione della memoria per nodo. Anche se la JVM può avere memoria sufficiente, l’overhead di sistema e la cache del filesystem possono essere compromessi da un carico eccessivo di shard.

GET _cat/nodes?v=true&h=name,heap.percent,ram.current,disk.used_percent,node.role,shards.total

Questo ti darà una vista aggregata dell’utilizzo delle risorse per nodo, inclusa la percentuale di heap, l’utilizzo della RAM e il numero totale di shard. Nodi con shards.total significativamente più alti o ram.current vicino al limite sono candidati per il rebalancing.

2. Implementare Index Lifecycle Management (ILM)

L’ILM è uno strumento cruciale per automatizzare la gestione degli indici, prevenendo che diventino troppo grandi o vecchi e consumino inutilmente risorse. Una policy ILM definisce come un indice si muove attraverso diverse fasi (hot, warm, cold, delete) in base a età o dimensione.

Per creare una policy ILM, puoi usare Kibana Management > Stack Management > Index Lifecycle Policies, oppure l’API:

PUT _ilm/policy/my_data_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_age": "7d",
            "max_docs": 100000000,
            "max_size": "50gb"
          }
        }
      },
      "warm": {
        "min_age": "30d",
        "actions": {
          "forcemerge": {
            "max_num_segments": 1
          },
          "shrink": {
            "number_of_shards": 1
          }
        }
      },
      "cold": {
        "min_age": "90d",
        "actions": {
          "freeze": {}
        }
      },
      "delete": {
        "min_age": "180d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Questa policy di esempio esegue un rollover ogni 7 giorni o 50GB/100M documenti, sposta l’indice a warm dopo 30 giorni (consolidando e riducendo gli shard), a cold dopo 90 giorni (congelando l’indice per risparmiare risorse) e lo cancella dopo 180 giorni. Associa questa policy ai tuoi indici tramite un index template.

3. Rebalancing Manuale o Automatico degli Shard

Se l’ILM non è sufficiente o hai bisogno di un intervento immediato, puoi forzare il rebalancing. Elasticsearch tenta di bilanciare gli shard automaticamente, ma a volte è necessario un intervento. Per abilitare il rebalancing completo:

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.rebalance.enable": "all"
  }
}

Per spostare manualmente uno shard specifico da un nodo sovrautilizzato a uno sottoutilizzato (da usare con cautela):

POST _cluster/reroute
{
  "commands": [
    {
      "move": {
        "index": "my_index",
        "shard": 0,
        "from_node": "node_1",
        "to_node": "node_2"
      }
    }
  ]
}

Ricorda che il rebalancing può essere intensivo in termini di I/O e rete. Pianificalo durante periodi di basso carico. Leggi anche: LVM Snapshot: Rollback Sicuro per Aggiornamenti Critici

Errori comuni e troubleshooting

Aumentare solo la JVM Heap Size: Questo è l’errore più comune. Se il problema è l’allocazione degli shard, aumentare la JVM sposta solo il problema, non lo risolve. La JVM continuerà a richiedere più memoria di quella che il sistema può fornire, portando a OOM e potenziali crash del nodo.
Ignorare il filesystem cache: Elasticsearch fa ampio uso della cache del filesystem. Se il sistema operativo non ha abbastanza memoria libera per la cache (a causa di troppi shard o processi), le performance crollano e si possono verificare OOM anche se la JVM è a posto.
Non monitorare _cat/shards e _cat/nodes regolarmente: Senza una visione chiara della distribuzione degli shard e dell’utilizzo delle risorse, è impossibile diagnosticare e prevenire proattivamente i problemi di OOM. Implementa un monitoraggio continuo per questi endpoint.
ILM troppo aggressivo o troppo permissivo: Una policy ILM mal configurata può cancellare dati prematuramente o, al contrario, non liberare spazio sufficiente, rendendo il cluster inefficiente. Testare le policy in un ambiente di staging è fondamentale.

FAQ — Domande Frequenti

È sicuro spostare gli shard manualmente in un cluster di produzione?

Sì, è sicuro se fatto con cognizione di causa e in un cluster healthy. Elasticsearch garantisce la consistenza dei dati durante il rerouting. Tuttavia, è un’operazione che genera carico I/O e di rete. Pianificala in periodi di basso utilizzo e monitora attentamente lo stato del cluster durante e dopo l’operazione. Evita di farlo in cluster già in stato di RED o YELLOW a meno che non sia l’unica opzione di recupero.

Qual è la dimensione ideale per uno shard?

Non esiste una dimensione unica, dipende dal caso d’uso. Una buona regola generale è mantenere gli shard tra i 10GB e i 50GB. Shard più piccoli generano un overhead maggiore, mentre shard troppo grandi rendono difficile il rebalancing e possono causare problemi di memoria. Il numero di shard per nodo dovrebbe essere circa 1-3 volte il numero di core della CPU del nodo. Link esterno: Dimensionamento Shard Elasticsearch

Come posso prevenire che un singolo indice cresca troppo e causi OOM?

L’uso di rollover nelle policy ILM è la soluzione principale. Configura il rollover per creare un nuovo indice quando quello corrente raggiunge una certa dimensione (max_size) o età (max_age). Questo distribuisce il carico su più indici più piccoli, che possono essere gestiti singolarmente e distribuiti meglio tra i nodi.

Devo riavviare il cluster dopo aver modificato le impostazioni degli shard o ILM?

Generalmente no. La maggior parte delle modifiche alle impostazioni del cluster (come cluster.routing.rebalance.enable) e alle policy ILM vengono applicate dinamicamente e non richiedono un riavvio. Tuttavia, per vedere gli effetti completi di un rebalancing o di una nuova policy ILM sugli indici esistenti, potrebbe essere necessario del tempo o un’azione manuale se la policy non è retroattiva.

Conclusioni con takeaway operativi

Affrontare un Out Of Memory in Elasticsearch richiede un approccio olistico che vada oltre l’immediata reazione di aumentare la RAM JVM. La gestione degli shard e l’implementazione di policy ILM robuste sono fondamentali per la stabilità e le performance a lungo termine di qualsiasi cluster. La lezione più importante è che la prevenzione, attraverso un monitoraggio costante e una configurazione proattiva, è sempre più efficace della reazione. Non aspettare che il tuo cluster vada in RED per agire. Investi tempo nella comprensione delle tue metriche e nell’automazione delle operazioni di manutenzione. Il tuo cluster e i tuoi utenti te ne saranno grati.

Fonti

Aggiornato: Agosto 2026