Elasticsearch:Utilisation élevée du disque et index en lecture seule

Symptômes

• Les requêtes d'écriture échouent avec le message suivant : FORBIDDEN/12/index read-only / allow delete (api)

• L'état de santé du cluster est rouge. Exécutez GET /_cat/nodes?v pour vérifier si les nœuds ont rejoint le cluster. Exécutez GET /_cat/allocation?v pour contrôler l'allocation des shards.

  Remarque

  Un état de santé rouge signifie que les shards primaires sont indisponibles. Les données peuvent être compromises.

• Kibana renvoie une erreur internal server error lors de la création de pipelines d'ingestion ou de l'enregistrement de Beats.

• La surveillance du cluster ou de Kibana indique une utilisation du disque approchant les 100 %.

Cause racine

Seuils d'utilisation du disque

Elasticsearch surveille en continu l'utilisation du disque et applique trois seuils d'alerte (watermarks) :

• 85 % — seuil bas (low watermark) : Elasticsearch cesse d'allouer de nouveaux shards à ce nœud.

• 90 % — seuil haut (high watermark) : Elasticsearch déplace les shards existants vers des nœuds disposant de plus d'espace disque libre.

• 95 % — stade d'inondation (flood stage) : Elasticsearch définit l'attribut read_only_allow_delete sur tous les index, bloquant ainsi toutes les opérations d'écriture.

Outre les seuils d'utilisation du disque, les conditions suivantes peuvent également provoquer des échecs d'écriture ou des alertes. Il convient d'examiner ces causes conjointement :

Limite du nombre de shards atteinte

Par défaut, chaque nœud de données d'un cluster Elasticsearch prend en charge jusqu'à 1 000 shards. Vérifiez la limite actuelle en exécutant GET /_cluster/settings?include_defaults=true&flat_settings=true et en consultant le paramètre cluster.max_shards_per_node. Lorsque le nombre de shards dépasse cette limite, Logstash ne peut plus écrire les journaux et la création de nouveaux index est impossible.

À titre de solution temporaire, exécutez la commande suivante pour augmenter la limite de shards :

PUT /_cluster/settings
{
  "transient": {
    "cluster": {
      "max_shards_per_node": 2000
    }
  }
}

Pour une solution pérenne, nettoyez les index expirés ou inutilisés, ou ajoutez davantage de nœuds de données au cluster.

Politiques de cycle de vie des index système

Si l'utilisation du disque fluctue fréquemment alors qu'aucune politique personnalisée de gestion du cycle de vie des index (ILM) n'est configurée, ces fluctuations peuvent être dues aux politiques de cycle de vie par défaut des index système, tels que .monitoring-es-* et .monitoring-kibana-*. Ces index sont créés automatiquement chaque jour et les anciens index sont supprimés automatiquement. Il s'agit d'un comportement normal.

Impact de la corrélation des ressources

Une utilisation élevée du disque peut s'accompagner d'une consommation importante de la mémoire JVM (par exemple, atteignant 90 %) et d'anomalies au niveau des nœuds, ce qui peut empêcher Kibana de se connecter. Dans ce cas, augmentez à la fois la capacité du disque et les ressources mémoire. Si le cluster est dans un état dégradé, activez les modifications forcées lors de la mise à niveau de la configuration. Effectuez cette opération pendant les heures creuses afin d'éviter toute interruption de service due aux redémarrages des nœuds.

Solution rapide (10–15 minutes)

1. Supprimez les index anciens ou inutilisés pour libérer de l'espace disque.

   Avertissement

   Les données supprimées ne peuvent pas être restaurées. Pour préserver vos données, envisagez plutôt d'augmenter la capacité de stockage.

   curl -u <username>:<password> -XDELETE http://<host>:<port>/<index-name>

   • <host> correspond à l'endpoint interne ou public de votre cluster. Configurez la liste d'autorisation d'accès avant d'exécuter cette commande.

   • Si le cluster ne répond pas, déclenchez un redémarrage forcé et exécutez cette commande pendant le redémarrage.

2. Supprimez le verrou en lecture seule. Libérer de l'espace disque ne lève pas automatiquement le blocage en écriture. Effacez-le en définissant index.blocks.read_only_allow_delete sur null :

   PUT /_all/_settings
   {
      "index.blocks.read_only_allow_delete": null
   }

3. Vérifiez l'état de santé du cluster. Si le statut reste rouge, exécutez GET /_cat/allocation?v pour détecter d'éventuels shards non assignés.

4. S'il reste des shards non assignés, exécutez GET /_cluster/allocation/explain pour identifier la cause. Si la sortie indique que les tentatives de réallocation ont été épuisées (comme illustré ci-dessous), exécutez POST /_cluster/reroute?retry_failed=true.

   "deciders": [
     {
       "decider": "max_retry",
       "decision": "NO",
       "explanation": "shard has exceeded the maximum number of retries [5] on failed allocation attempts - manually call [/_cluster/reroute?retry_failed=true] to retry, [unassigned_info[[reason=ALLOCATION_FAILED], at[2020-02-14T00:22:25.939Z], failed_attempts[5], delayed=false, details[failed shard on node [xxx]: shard failure, reason [lucene commit failed], failure IOException[No space left on device], allocation_status[deciders_no]]]]"
     }
   ]

   Des erreurs peuvent persister après avoir augmenté la capacité du disque ou nettoyé les données. Une fois que l'utilisation du disque a atteint 100 %, l'allocation des shards échoue et le compteur de tentatives échouées est épuisé. Même après avoir étendu le disque ou supprimé des données, certains shards peuvent rester non assignés et les requêtes continuent d'échouer avec des erreurs telles que 503 search_phase_execution_exception.

   Dans ce cas, exécutez manuellement POST /_cluster/reroute?retry_failed=true pour retenter l'allocation des shards ayant échoué. Une fois la commande exécutée, attendez la fin de la récupération des shards. Le cluster ne revient à un fonctionnement normal qu'une fois la récupération terminée.

5. Si l'état de santé du cluster reste rouge après toutes les étapes de récupération, contactez le support technique d'Alibaba Cloud.

FAQ

Pourquoi la console Elasticsearch affiche-t-elle un état de cluster normal alors que je reçois toujours des alertes d'utilisation du disque ?

Un état de cluster normal sur la console indique simplement que le cluster est actuellement disponible. Toutefois, l'utilisation du disque a peut-être déjà atteint le seuil d'alerte (par exemple, 91 %). Bien qu'une utilisation élevée du disque n'ait pas immédiatement déclenché le mode lecture seule, elle approche du seuil critique : à 95 %, le mode lecture seule forcé est activé et les opérations d'écriture peuvent être bloquées à tout moment.

Nous vous recommandons de vérifier immédiatement l'utilisation réelle du disque sur la page Cluster Monitoring et de prendre l'une des mesures suivantes pour éliminer le risque :

• Augmentez la capacité du disque.

• Nettoyez les index inutilisés ou expirés.

Comment ajuster temporairement le watermark du disque pour rétablir la santé du cluster ?

Augmentez temporairement le seuil bas (low watermark) uniquement en tant que mesure d'urgence : l'état du cluster est dégradé en raison des limites imposées par les watermarks du disque, des shards sont non assignés et vous ne pouvez pas augmenter la capacité immédiatement. Dans Dev Tools de Kibana, appelez l'API des paramètres du cluster pour augmenter le seuil bas, par exemple à 88 %, afin que les shards bloqués par le watermark puissent être alloués à nouveau.

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "88%"
  },
  "persistent": {
    "cluster.routing.allocation.disk.watermark.low": "88%"
  }
}

La valeur de 88 % assouplit uniquement le seuil bas pour le cluster actuel à titre temporaire. Elle ne modifie pas les watermarks par défaut de 85 %, 90 % et 95 % décrits dans la section Cause racine.

Il s'agit d'une solution de contournement temporaire. Une fois que l'état du cluster revient au vert, mettez à niveau la configuration via un changement progressif sur place dans la console ou nettoyez les données dès que possible. Ne vous fiez pas à long terme à l'augmentation du watermark.

Combien de temps faut-il pour que l'espace disque soit libéré après la suppression d'un index ?

Après avoir supprimé un index comme indiqué à la première étape de la section Solution rapide (10–15 minutes), l'espace disque commence généralement à être libéré en quelques minutes à une demi-heure, et la modification se reflète peu après dans les métriques de surveillance.

Si l'espace disque n'est toujours pas libéré après un certain temps, vérifiez si d'autres données consomment de l'espace, telles que des index restants, des snapshots ou des journaux, ou si l'actualisation des métriques de surveillance est retardée.

Prévention

Activez la surveillance de l'utilisation du disque et configurez des alertes qui se déclenchent lorsque l'utilisation dépasse 80 %. Acheminez les alertes vers votre équipe d'exploitation afin qu'elle puisse intervenir avant d'atteindre le stade d'inondation. Pour obtenir des instructions de configuration, consultez la rubrique Configurer la surveillance et les alertes.