Elasticsearch:Erreurs courantes

Cause

Cette erreur survient lorsque vous utilisez l'opérateur LIKE dans une requête du plug-in X-Pack SQL sur un champ de type text.

Solution

L'opérateur LIKE ne prend en charge que le filtrage exact sur les champs de type keyword. Modifiez la requête pour utiliser un champ keyword à la place.

Pour plus d'informations, consultez les articles Unable to run SQL query on multi fields using Elastic Search v. 7,3 et SQL and multi-fields.

Cause

Lorsqu'un champ est mappé en tant que keyword, Elasticsearch ne crée pas automatiquement de sous-champ .keyword. Une requête avec caractère générique ciblant un sous-champ inexistant, tel que titleForSearch.keyword, ne renvoie aucun résultat.

Solution

Modifiez l'instruction de requête pour exécuter la requête wildcard ou regexp sur le champ parent. Par exemple :

{
  "query": {
    "wildcard": {
      "titleForSearch": "*keyword*"
    }
  }
}

Suggestions d'optimisation

• Si vous avez besoin d'une recherche en texte intégral analysée, réindexez les données et mappez explicitement le champ en tant que text avec le tokenizer IK.

• Si vous conservez le type keyword, interrogez le champ parent et supprimez le suffixe .keyword inutile.

• Définissez explicitement le mappage dans votre code d'application afin d'éviter les différences causées par la stratégie de mappage dynamique.

Cause

Elasticsearch ne prend en charge le type keyword qu'en minuscules. L'utilisation de KEYWORD en majuscules dans un mappage provoque l'erreur No handler for type [KEYWORD].

Solution

Remplacez le type de champ concerné de "KEYWORD" par "keyword", puis soumettez à nouveau le mappage.

Dépannage supplémentaire

Si le mappage est correct mais que l'erreur persiste, vérifiez si un champ nouvellement ajouté dans la base de données source entraîne l'exécution automatique d'une tâche de synchronisation (telle qu'une tâche DataWorks) créant un mappage avec un type non valide. Vérifiez les définitions de champ dans le code de l'application ou dans l'outil de synchronisation.

Cause

Cette erreur apparaît lorsque vous utilisez le plug-in aliyun-knn pour la recherche vectorielle sur un index configuré avec la fonction de mesure de distance cosinus.

Solutions

Vérifiez les points suivants :

• Version du cluster : Le plug-in aliyun-knn nécessite Elasticsearch V6.7 avec le noyau V1.2 ou ultérieur, ou Elasticsearch V7.10 avec le noyau V1.4 ou ultérieur. Consultez la rubrique Utilisation du plug-in aliyun-knn pour connaître les exigences de version.

• Méthode de requête de script : Les requêtes de script doivent utiliser le paramètre script_score.

• Imbrication des champs : Vérifiez que les champs spécifiés dans la requête correspondent à la structure d'imbrication du mappage d'index. Si l'index utilise des champs imbriqués, la requête doit référencer ces champs imbriqués en conséquence.

Cause

Une seule requête d'écriture groupée dépasse la limite http.max_content_length, définie par défaut sur 100 Mo. Ne modifiez pas cette limite.

Solution

Le volume de données écrites par requête équivaut au nombre de documents multiplié par la taille moyenne d'un document. Étant donné que la taille des documents varie, commencez le réglage à 5 Mo par requête et augmentez progressivement jusqu'à un maximum de 15 Mo. Pour obtenir des conseils, consultez les articles Using and Sizing Bulk Requests et HTTP settings.

Cause

L'indexation automatique est désactivée sur le cluster.

Solutions

• Méthode statique (recommandée) : Activez l'indexation automatique dans le panneau YML File Configuration. Pour connaître la procédure, consultez la rubrique Configuration du fichier YML.

• Méthode dynamique : Exécutez la commande API correspondante pour activer l'indexation automatique sans redémarrer le cluster.

Description de l'erreur

Cette erreur apparaît lorsque le cluster ne peut pas traiter les requêtes provenant d'un ou plusieurs shards.

Causes

Les causes courantes incluent la déconnexion d'un nœud, des shards encore en cours de récupération après un redémarrage ou un disque endommagé.

Solution

Étape 1 : Diagnostic

Consultez les données de surveillance et les journaux du cluster pour identifier la cause racine, par exemple un espace disque insuffisant ou des paramètres d'index ou de cluster mal configurés qui bloquent l'allocation des shards.

Étape 2 : Correction des shards non attribués

Si la cause est la déconnexion d'un nœud ou des shards non attribués :

1. Connectez-vous à la console Kibana.

2. Vérifiez l'état de l'allocation des shards :

   Remarque

   Si tous les shards sont déjà attribués, cette commande renvoie une erreur ; il s'agit du comportement attendu.

   GET /_cluster/allocation/explain

3. Réessayez l'allocation des shards ayant échoué :

POST /_cluster/reroute?retry_failed=true

Cause

Lorsque l'utilisation du disque sur un nœud de données dépasse 95 %, Elasticsearch active la protection en écriture et définit read_only_allow_delete sur tous les index. Les écritures sont bloquées ; seules les lectures et les suppressions sont autorisées. Le seuil de 85 % affecte la création de shards, tandis que le seuil de 95 % déclenche la protection en écriture.

Solution

Étape 1 : Résoudre l'utilisation élevée du disque (cause racine)

Traitez d'abord le problème sous-jacent lié à l'utilisation du disque. Consultez la rubrique Utilisation élevée du disque et index en lecture seule pour découvrir les options disponibles, telles que l'extension de la capacité du disque, la suppression des index inutilisés ou la configuration de la gestion du cycle de vie des index.

Étape 2 : Restaurer l'accès en écriture

Une fois l'utilisation du disque résolue, réinitialisez l'indicateur de lecture seule sur tous les index :

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

Cause

Les journaux du cluster affichent une erreur SSL/TLS similaire à celle ci-dessous lorsque du trafic en texte clair est envoyé via une connexion SSL. Cela se produit généralement lorsqu'un nœud sans communication chiffrée tente de se connecter à un nœud dont le chiffrement est activé.

content :
[o.e.t.TcpTransport ] [XBJo5pR] exception caught on transport layer [Netty4TcpChannel{localAddress=0.0.0.0/0.0.0.0:9300, remoteAddress=/89.248.xxx}], closing connection
io.netty.handler.codec.DecoderException: io.netty.handler.ssl.NotSslRecordException: not an SSL/TLS record: 0300002f2axxxx8
61736xxx a0100080003000000

Solutions

Vérifiez les points suivants :

• Incompatibilité HTTP/HTTPS : Si HTTPS n'est pas activé sur le cluster, l'accès n'est disponible que via HTTP. L'accès au cluster via HTTPS déclenche cette erreur. Pour activer HTTPS, consultez la rubrique Activation de HTTPS.

• Adresse IP non ajoutée à la liste d'autorisation : Vérifiez que l'adresse IP indiquée dans les journaux du cluster figure dans la liste d'autorisation des adresses IP publiques. Ajoutez uniquement les adresses IP spécifiques ou les blocs CIDR nécessaires — n'ajoutez pas 0.0.0.0/0.

Pour plus d'informations sur les modèles d'erreurs SSL/TLS, consultez l'article Common SSL/TLS exceptions.

Cause

L'authentification par clé API n'est pas activée sur le cluster.

Solution

Les clés API nécessitent que HTTPS soit activé sur le cluster. Activez HTTPS pour résoudre ce problème. Consultez la rubrique Activation de HTTPS.

Description de l'erreur

Lors de l'utilisation de Transport Client 5.5 ou 5.6 pour se connecter via le port 9300, vous pouvez observer l'erreur suivante :

NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{HVdK7Cffxxxx_P0c9nxxxx}{es-cn-v1qqweee****.elasticsearch.aliyuncs.com}{172.17.XX.XX:9300}]]

Solution

L'adresse IP 172.17.XX.XX ne correspond à aucun nœud réel du cluster ; il s'agit d'un problème connu avec ces versions du client. Utilisez plutôt Transport Client 5.3.3. Consultez la rubrique Transport Client (5.x).

Description de l'erreur

Après avoir activé la limitation de débit avec apack.qos.ratelimit.enabled, cette erreur s'affiche lors de la configuration d'un limiteur :

{
   "error": {
      "root_cause": [
         {
            "type": "unsupported_operation_exception",
            "reason": "unsupported_operation_exception: only define search or bulk action for limit"
         }
      ],
      "type": "unsupported_operation_exception",
      "reason": "unsupported_operation_exception: only define search or bulk action for limit"
   },
   "status": 500
}

Cause

Le plug-in aliyun-qos n'est pas à jour. Exécutez GET /_cat/plugins?v pour vérifier la version actuelle. Les dernières versions attendues sont les suivantes :

• Elasticsearch V7.10 :7.10.0_ali1.6.0.2

• Toutes les autres versions :<ES version>-rc4

Solutions

Effectuez la mise à niveau en fonction de la version de votre cluster :

• Clusters V7.10 : Mettez à niveau le noyau vers la version V1.6.0. Consultez la rubrique Mise à niveau de la version d'un cluster.

• Autres versions :Soumettez un ticket pour demander aux ingénieurs techniques Elasticsearch de mettre à niveau le plug-in. Redémarrez le cluster après la mise à niveau pour que la modification prenne effet.

Cause

Ces erreurs sont causées par des bugs dans la version open source d'Elasticsearch 7.4 et n'affectent pas vos opérations commerciales. Ces bugs sont corrigés dans les versions ultérieures à la 7,4.

Solution

Alibaba Cloud Elasticsearch V7.4 est en fin de vie. Achetez un cluster exécutant une version ultérieure. Si vous devez migrer les données avant de changer de version, consultez la rubrique Sélection d'une solution de migration de données pour choisir l'approche adaptée à votre charge de travail.

Cause

Cette erreur se produit lors de l'exécution de PUT _snapshot/my_backup si le compartiment Object Storage Service (OSS) cible utilise la classe de stockage Archive. Les compartiments Archive nécessitent la restauration des objets avant que les données puissent être lues, ce qui est incompatible avec les opérations de snapshot d'Elasticsearch.

Solution

Utilisez un compartiment OSS avec la classe de stockage Standard dans la même région que le cluster Elasticsearch. Pour connaître la procédure, consultez la rubrique Création de snapshots manuels et restauration des données à partir de snapshots manuels.