Pourquoi l'action d'index de roulement dans ma politique ISM échoue-t-elle constamment dans Amazon OpenSearch Service ?

Dernière mise à jour : 03/10/2022

Je veux utiliser la gestion d'états d'index (ISM – Index State Management) pour effectuer le roulement de mes index sur mon cluster Amazon OpenSearch Service. Cependant, je ne parviens pas à reporter mon index et reçois en plus un message d'erreur. D'où vient le problème et comment puis-je le résoudre ?

Brève description

Si vous avez reçu le message d'erreur « Échec de l'index de substitution », votre action de substitution peut avoir échoué pour l'une des raisons suivantes :

  • La cible de substitution n'existe pas.
  • L'alias de substitution est manquant.
  • Le nom de l'index ne correspond pas au modèle d'index.
  • L'alias de substitution pointe vers un alias dupliqué dans un modèle d'index.
  • Vous avez atteint l'utilisation maximale des ressources sur votre cluster.

Afin de résoudre ce problème, utilisez l'API explain pour en trouver la cause. Ensuite, vérifiez votre politique ISM. Pour plus d'informations sur la configuration de l'action de roulement dans votre politique ISM, veuillez consulter Comment puis-je utiliser Index State Management (ISM) pour gérer un espace de stockage réduit dans Amazon OpenSearch Service ?

Remarque : la solution suivante s'applique uniquement à l'API OpenSearch. Pour l'ancienne API Open Distro, consultez les opérations de l'API ISM Open Distro.

Solution

Utiliser l'API explain

Pour identifier la cause racine de l'erreur « Échec de l'index de roulement », utilisez l'API explain :

GET _plugins/_ism/explain/logs-000001?pretty

Voici un exemple de sortie de l'API explain :

{
     "logs-000001": {
          "index.plugins.index_state_management.policy_id": "rollover-workflow",
          "index": "logs-000001",
          "index_uuid": "JUWl2CSES2mWYXqpJJ8qlA",
          "policy_id": "rollover-workflow",
          "policy_seq_no": 2,
          "policy_primary_term": 1,
          "rolled_over": false,
          "state": {
               "name": "open",
               "start_time": 1614738037066
          },
          "action": {
               "name": "rollover",
               "start_time": 1614739372091,
               "index": 0,
               "failed": true,
               "consumed_retries": 0,
               "last_retry_time": 0
          },
          "retry_info": {
               "failed": false,
               "consumed_retries": 0
          },
          "info": {
               "cause": "rollover target [rolling-indices] does not exist",
               "message": "Failed to rollover index [index=logs-000001]"
          }
     }
}

Cet exemple de sortie indique que le roulement des index n'a pas pu être effectué car l'alias de roulement cible (index de roulement) n'existait pas.

La cible de roulement n'existe pas

Si l'API explain renvoie la cause « cible de substitution [index de roulement] n'existe pas », vérifiez que l'index n'a pas été amorcé avec l'alias de substitution :

GET _cat/aliases

La sortie répertorie tous les alias actuels du cluster et leurs index associés. Si ISM indique que votre cible de roulement n'existe pas, c'est qu'il manque un nom d'alias de roulement et une association d'index ayant échoué.

Pour résoudre l'association d'index ayant échoué, attachez l'alias de substitution à l'index :

POST /_aliases
{
     "actions": [{
          "add": {
               "index": "logs-000001",
               "alias": "my-data"
          }
     }]
}

Après avoir attaché l'alias de roulement, réessayez l'action de roulement sur l'index géré dans OpenSearch Service :

POST _plugins/_ism/retry/logs-000001

Pour plus d'informations, veuillez consulter la section Réessayer l'index ayant échoué sur le site Web d'OpenSearch (français non garanti).

Lorsque vous réessayez l'index ayant échoué, vous pouvez recevoir un message d'état « Attempting to retry » (Nouvelle tentative). Si Amazon OpenSearch Service effectue un nouvel essai, attendez la prochaine exécution du cycle ISM. Les cycles ISM s'exécutent toutes les 30 à 48 minutes. Si l'action de roulement est réussie, le message suivant s'affiche : « Index reporté avec succès ».

L'alias de substitution est manquant

Si la sortie de l'API explain identifie le manque d'un alias de roulement comme étant la cause de l'échec du roulement, vérifiez les paramètres de l'index ayant échoué :

GET <failed-index-name>/_settings

Si vous constatez que le paramètre index.plugins.index_state_management.rollover_alias est manquant, ajoutez-le manuellement à votre index :

PUT /<failed-index-name>/_settings
{
     "index.plugins.index_state_management.rollover_alias" : "<rollover-alias>"
}

Utilisez l'API retry failed index afin de réessayer l'opération de roulement sur l'index ayant échoué. Pendant qu'une nouvelle action de roulement est en cours, mettez à jour votre modèle de stratégie :

PUT _index_template/<template-name>

Veillez à utiliser les mêmes paramètres que votre modèle de stratégie existant afin que votre alias de roulement soit appliqué aux indices nouvellement créés. Par exemple :

PUT _index_template/<existing-template> 
{
     "index_patterns": [
          "<index-pattern*>"
     ],
     "template": {
          "settings": {
               "plugins.index_state_management.rollover_alias": "<rollover-alias>"
          }
     }
}

Le nom de l'index ne correspond pas au modèle d'index

Si votre politique ISM indique que votre opération de roulement a échoué parce que le nom et le modèle de votre index ne correspondent pas, vérifiez le nom de l'index ayant échoué. Dans le cas des roulements réussis, les noms d'index doivent correspondre au modèle regex suivant :

`^.*-\d+$`

Ce modèle regex indique que les noms d'index doivent inclure du texte suivi d'un trait d'union (-) et d'un ou plusieurs chiffres. Si le nom d'index ne suit pas ce modèle et que votre premier index contient des données écrites, envisagez de réindexer les données. Au moment de réindexer les données, renommez correctement le nouvel index. Par exemple :

POST _reindex
{
     "source": {
          "index": "<failed-index>"
     },
     "dest": {
          "index": "my-new-index-000001"
     }
}

Pendant l'exécution de l'API reindex data, détachez l'alias de roulement de l'index ayant échoué. Ajoutez ensuite l'alias de substitution au nouvel index afin que la source de données puisse continuer à écrire les données entrantes dans un nouvel index.

Par exemple :

POST /_aliases
{
     "actions": [{
          "remove": {
               "index": "<failed-index>",
               "alias": "<rollover-alias>"
          }
     },
     {
          "add": {
               "index": "my-new-index-000001",
               "alias": "<rollover-alias>"
          }
     }]
}

Attachez manuellement la politique ISM au nouvel index à l'aide de l'appel d'API suivant :

POST _plugins/_ism/add/my-new-index-*
{
     "policy_id": "<policy_id>"
}

Mettez à jour le modèle existant de manière à tenir compte du nouveau nom de modèle d'index. Par exemple :

PUT _index_template/<existing-template> 
{
     "index_patterns": ["<my-new-index-pattern*>"],
}

Remarque : votre politique ISM et votre alias de roulement doivent tenir compte des index successifs créés avec le même modèle d'index.

L'alias de roulement pointe vers un alias dupliqué dans un modèle d'index

Si l'API explain indique que votre roulement d'index a échoué, car un alias de roulement pointe vers un alias dupliqué, vérifiez les paramètres de votre modèle d'index :

GET _index_template/<template-name>

Vérifiez si votre modèle contient une section supplémentaire pour les alias (avec un autre alias pointant vers le même index) :

{
     "index_patterns": ["my-index*"],
     "settings": {
          "index.plugins.index_state_management.rollover_alias": "<rollover-alias>"
     },
     "aliases": {
          "another_alias": {
               "is_write_index": true
          }
     }
}

La présence d'un alias supplémentaire confirme la raison de l'échec de votre opération de roulement, car plusieurs alias entraînent l'échec du roulement. Pour résoudre ce problème, mettez à jour les paramètres du modèle sans spécifier d'alias :

PUT _index_template/<template-name>

Ensuite, exécutez l'API retry sur l'index en échec :

POST _plugins/_ism/retry/logs-000001

Important : si un alias pointe vers plusieurs index, assurez-vous qu'un seul index ait accès en mode écriture. L'API rollover active automatiquement l'accès au mode écriture pour l'index vers lequel pointe l'alias de roulement. Cela signifie que vous n'avez pas besoin de spécifier d'alias pour le paramètre « is_write_index » lorsque vous effectuez l'opération de substitution dans ISM.

Vous avez atteint l'utilisation maximale des ressources sur votre cluster

L'utilisation maximale des ressources sur votre cluster peut être due à une exception du disjoncteur ou à un manque d'espace de stockage.

Exception du disjoncteur

Si l'API explain renvoie une exception de disjoncteur, votre cluster subissait probablement une forte sollicitation JVM lorsque l'API de substitution a été appelée. Pour résoudre les problèmes liés à une forte sollicitation JVM, consultez Comment puis-je résoudre les problèmes de forte sollicitation de la mémoire JVM sur mon cluster Amazon OpenSearch Service ?

Une fois la mémoire JVM sollicitée en dessous de 75 %, vous pouvez relancer l'activité sur l'index ayant échoué avec l'appel d'API suivant :

POST _plugins/_ism/retry/<failed-index-name>

Remarque : vous pouvez utiliser des modèles d'index (*) pour relancer les activités sur plusieurs index ayant échoué.

Dans le cas de pics JVM peu fréquents sur votre cluster, vous pouvez également mettre à jour la politique ISM avec le bloc de nouvelles tentatives suivant pour l’opération de roulement :

{
     "actions": {
          "retry": {
               "count": 3,
               "backoff": "exponential",
               "delay": "10m"
          }
     }
}

Dans votre stratégie ISM, chaque action comporte une nouvelle tentative automatisée basée sur le paramètre « count ». Si l'opération précédente échoue, vérifiez le paramètre « delay » (retard) afin de vérifier le temps d'attente avant que l'ISM réessaie l'action.

Manque d'espace de stockage

Si votre cluster manque d'espace de stockage, OpenSearch Service déclenche un bloc d'écriture sur le cluster et toutes les opérations d'écriture renvoient une ClusterBlockException. Votre métrique ClusterIndexWritesBlocked affiche la valeur « 1 », ce qui indique que le cluster bloque les requêtes. Par conséquent, toute tentative de création d'un nouvel index échoue. L'appel d'API explain renvoie également une erreur 403 IndexCreateBlockException, qui signifie que le cluster n'a plus d'espace de stockage. Pour résoudre l'exception de bloc de cluster, consultez Comment puis-je résoudre l'erreur 403 « index_create_block_exception » dans Amazon OpenSearch Service ?

Une fois la métrique ClusterIndexWritesBlocked revenue à « 0 », relancez l'action ISM sur l'index échoué. Si la sollicitation de la mémoire JVM dépasse 92 % pendant plus de 30 minutes, un bloc d'écriture peut être déclenché. Si vous rencontrez un bloc d'écriture, vous devez plutôt régler le problème de forte sollicitation de la mémoire JVM. Pour plus d'informations sur le dépannage de la pression de la mémoire JVM, consultez Comment puis-je résoudre les problèmes de forte sollicitation de la mémoire JVM sur mon cluster Amazon OpenSearch Service ?


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?