Pourquoi l'action d'index de substitution dans ma politique ISM continue-t-elle d'échouer dans Amazon OpenSearch Service ?

Date de la dernière mise à jour : 05/08/2021

Je souhaite utiliser Gestion des états d'index (ISM) pour répartir mes index sur mon cluster Amazon OpenSearch Service (successeur d'Amazon Elasticsearch 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.

Pour résoudre ce problème, utilisez l'API explain pour trouver le motif de votre message d'erreur. Ensuite, vérifiez votre politique ISM. Pour plus d'informations sur la configuration de l'action de substitution dans votre politique ISM, consultez Comment utiliser la Gestion des états d'index (ISM) pour gérer un faible espace de stockage dans Amazon OpenSearch Service?

Solution

Utiliser l'API explain

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

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

Voici un exemple de sortie de l'API explain :

{
  "logs-000001" : {
    "index.opendistro.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 les index n'ont pas pu être reportés, car l'alias de substitution cible (index de roulement) n'existait pas.

La cible de substitution 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" } }
    ]
}

Une fois que vous avez attaché l'alias de substitution, réessayez l'action de substitution sur l'index géré dans OpenSearch Service :

POST _opendistro/_ism/retry/logs-000001

Pour plus d'informations, consultez Réessayer l'index ayant échoué sur le site web Open Distro for Elasticsearch.

Lorsque vous réessayez l'index ayant échoué, vous pouvez recevoir un message d'état « Nouvel essai ». 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 réussit, le message suivant s'affiche : « Index reporté avec succès ».

L'alias de substitution est manquant

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

GET <failed-index-name>/_settings

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

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

Utilisez l'API retry failed index pour relancer 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 _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 _template/<existing-template>
{
  "index_patterns": ["<index-pattern*>"], 
  "settings": {
    "index.opendistro.index_state_management.policy_id": "<policy_id>",
    "index.opendistro.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, dissociez l'alias de substitution 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 stratégie ISM au nouvel index à l'aide de l'appel d'API suivant :

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

Mettez à jour le modèle existant pour tenir compte du nouveau nom du modèle d'index :

PUT _template/<existing temaplate>

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 _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.opendistro.index_state_management.policy_id": "rollover-policy",
        "index.opendistro.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 _template/<template-name>

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

POST _opendistro/_ism/retry/my-index-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 de la mémoire JVM, consultez Comment puis-je résoudre le problème 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 _opendistro/_ism/retry/<failed-index-name>

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

Si vous rencontrez des pics JVM peu fréquents sur votre cluster, vous pouvez également mettre à jour la stratégie ISM avec le bloc de 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 votre opération précédente échoue, vérifiez le paramètre « delay » pour voir combien de temps vous devrez attendre avant qu'ISM relance 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. Ainsi, toutes les opérations d'écriture renvoient une exception 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 exception 403 IndexCreateBlockException, ce qui indique que le cluster manque 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 le problème 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 ?