doc-locale/fr-fr/integration/elasticsearch/troubleshooting/indexing.md
{{< details >}}
{{< /details >}}
Lorsque vous utilisez l'indexation ou la recherche Elasticsearch, vous pouvez rencontrer les problèmes suivants.
En cas de problèmes d'indexation, essayez d'abord de créer un index vide. Vérifiez l'instance Elasticsearch pour voir si l'index gitlab-production existe. Si c'est le cas, supprimez manuellement l'index sur l'instance Elasticsearch et essayez de le recréer à partir de la tâche Rake recreate_index.
Si vous rencontrez toujours des problèmes, essayez de créer un index manuellement sur l'instance Elasticsearch. Si vous :
Vous pouvez rechercher des erreurs lors de l'indexation des projets. Des erreurs peuvent survenir sur :
Si l'indexation ne renvoie pas d'erreurs, vérifiez le statut des projets indexés avec les tâches Rake suivantes :
sudo gitlab-rake gitlab:elastic:index_projects_status pour le statut globalsudo gitlab-rake gitlab:elastic:projects_not_indexed pour les projets spécifiques qui ne sont pas indexésSi l'indexation est :
sudo gitlab-rake gitlab:elastic:index_projects ID_FROM=<project ID> ID_TO=<project ID>.Si la réindexation du projet affiche des erreurs sur :
Nous mettons continuellement à jour nos stratégies d'indexation et visons à prendre en charge les versions plus récentes d'Elasticsearch. Lorsque des modifications d'indexation sont apportées, vous devrez peut-être réindexer après la mise à jour de GitLab.
[!note] N'utilisez pas ces instructions pour les scénarios qui n'indexent qu'un sous-ensemble d'espaces de nommage.
Assurez-vous d'avoir indexé toutes les données de la base de données.
S'il n'y a pas de résultats (hits) dans la recherche de l'interface utilisateur, vérifiez si vous obtenez les mêmes résultats via la console Rails (sudo gitlab-rails console) :
u = User.find_by_username('your-username')
s = SearchService.new(u, {:search => 'search_term', :scope => 'blobs'})
pp s.search_objects.to_a
Au-delà de cela, vérifiez via l'API de recherche Elasticsearch si les données s'affichent côté Elasticsearch :
curl --request GET <elasticsearch_server_ip>:9200/gitlab-production/_search?q=<search_term>
Des appels d'API Elasticsearch plus complexes sont également possibles.
Si les résultats :
Consultez les portées d'index Elasticsearch pour plus d'informations sur la recherche de types de données spécifiques.
Après avoir activé la recherche avancée, vous pourriez constater que les documents ne sont pas indexés et que le code n'est pas consultable. Vous pourriez voir un message dans les journaux Sidekiq similaire au suivant :
"job_status":"concurrency_limit","message":"Search::Elastic::CommitIndexerWorker JID-352e0b9ee88af9f455c69b81: concurrency_limit: paused"
Pour résoudre ce problème :
gitlab-rake gitlab:elastic:info pour vérifier le statut des Indexing queues.Pour réindexer la base de données, les dépôts et les wikis, indexez l'instance.
error: elastic: Error 429 (Too Many Requests) {#indexing-fails-with-error-elastic-error-429-too-many-requests}Si les workers Sidekiq Search::Elastic::CommitIndexerWorker échouent avec cette erreur lors de l'indexation, cela signifie généralement qu'Elasticsearch n'est pas en mesure de suivre la simultanéité des demandes d'indexation. Pour y remédier, modifiez les paramètres suivants :
Bulk request concurrency (voir Paramètres de recherche avancée). Cette valeur est définie à 10 par défaut, mais vous pouvez la réduire jusqu'à 1 pour diminuer le nombre d'opérations d'indexation simultanées.Bulk request concurrency n'a pas aidé, vous pouvez utiliser l'option règles de routage pour limiter les jobs d'indexation à des nœuds Sidekiq spécifiques, ce qui devrait réduire le nombre de demandes d'indexation.Elasticsearch::Transport::Transport::Errors::RequestEntityTooLarge {#error-elasticsearchtransporttransporterrorsrequestentitytoolarge}[413] {"Message":"Request size exceeded 10485760 bytes"}
Cette exception se produit lorsque votre cluster Elasticsearch est configuré pour rejeter les demandes dépassant une certaine taille (10 Mio dans ce cas). Cela correspond au paramètre http.max_content_length dans elasticsearch.yml. Augmentez-le à une taille supérieure et redémarrez votre cluster Elasticsearch.
AWS impose des limites réseau sur la taille maximale des charges utiles des requêtes HTTP en fonction de la taille de l'instance sous-jacente. Définissez la taille maximale des requêtes en bloc à une valeur inférieure à 10 Mio.
rejected execution of coordinating operation {#indexing-is-very-slow-or-fails-with-rejected-execution-of-coordinating-operation}Les requêtes en bloc rejetées par les nœuds Elasticsearch sont probablement dues à la charge et au manque de mémoire disponible. Assurez-vous que votre cluster Elasticsearch répond à la configuration système requise et dispose de suffisamment de ressources pour effectuer des opérations en bloc. Voir également l'erreur « 429 (Too Many Requests) ».
strict_dynamic_mapping_exception {#indexing-fails-with-strict_dynamic_mapping_exception}L'indexation peut échouer si toutes les migrations de recherche avancée n'ont pas été terminées avant d'effectuer une mise à niveau majeure. Un important backlog Sidekiq peut accompagner cette erreur. Pour corriger les échecs d'indexation, vous devez réindexer la base de données, les dépôts et les wikis.
Mettez en pause l'indexation pour que Sidekiq puisse rattraper son retard :
sudo gitlab-rake gitlab:elastic:pause_indexing
Reprenez l'indexation :
sudo gitlab-rake gitlab:elastic:resume_indexing
elasticsearch_pause_indexing setting is enabled {#indexing-keeps-pausing-with-elasticsearch_pause_indexing-setting-is-enabled}Vous pourriez remarquer que les nouvelles données ne sont pas détectées lorsque vous effectuez une recherche.
Cette erreur se produit lorsque les nouvelles données ne sont pas indexées correctement.
Pour résoudre cette erreur, réindexez vos données.
Cependant, lors de la réindexation, vous pourriez obtenir une erreur où le processus d'indexation continue de se mettre en pause et les journaux Elasticsearch affichent ce qui suit :
"message":"elasticsearch_pause_indexing setting is enabled. Job was added to the waiting queue"
Si la réindexation ne résout pas ce problème et que vous n'avez pas mis en pause le processus d'indexation manuellement, cette erreur peut se produire parce que deux instances GitLab partagent un même cluster Elasticsearch.
Pour résoudre cette erreur, déconnectez l'une des instances GitLab du cluster Elasticsearch.
Pour plus d'informations, consultez le ticket 3421.
too_many_clauses: maxClauseCount is set to 1024 {#search-fails-with-too_many_clauses-maxclausecount-is-set-to-1024}Cette erreur se produit lorsqu'une requête a plus de clauses que ce qui est défini dans le paramètre indices.query.bool.max_clause_count :
1024.4096.Pour résoudre ce problème, augmentez la valeur ou mettez à niveau vers Elasticsearch 8.1 ou une version ultérieure. L'augmentation de la valeur peut entraîner une dégradation des performances.
Lorsque vous utilisez la recherche avancée, les résultats de recherche qui s'étendent sur plusieurs pages peuvent contenir des doublons. Lorsque des doublons apparaissent, certains résultats correspondants ne sont pas retournés.
GitLab pagine les résultats en fonction du nombre de résultats correspondants uniques provenant d'Elasticsearch. Cependant, en raison de la façon dont Elasticsearch ordonne les résultats, le même résultat peut apparaître sur plusieurs pages. Ce problème est plus susceptible de se produire lorsque vous triez les résultats par pertinence.
Comme solution de contournement, envisagez ce qui suit :
Pour plus d'informations, consultez le ticket 416286.
disk usage exceeded flood-stage watermark, index has read-only-allow-delete block {#error-disk-usage-exceeded-flood-stage-watermark-index-has-read-only-allow-delete-block}Cette erreur se produit lorsque votre cluster Elasticsearch possède au moins un nœud dont l'espace disque est dangereusement faible. Un cluster qui dépasse le seuil de limite par défaut de 95 % applique un blocage en lecture seule qui empêche toute opération d'écriture ultérieure. Ce blocage peut entraîner l'échec des nouvelles opérations d'indexation et produire des résultats de recherche obsolètes.
Vous pouvez vérifier si le cluster est en mode lecture seule avec la tâche Rake suivante :
sudo gitlab-rake gitlab:elastic:info
Recherchez une sortie indiquant que blocks.write ou blocks.read_only_allow_delete est true.
Pour vérifier l'utilisation du disque sur votre cluster Elasticsearch, exécutez la commande suivante :
curl --request GET '<your_ES_cluster>:9200/_cat/allocation?v&pretty'
Pour résoudre ce problème, augmentez le volume de disque sur les nœuds pleins. Vous pouvez estimer la taille du cluster avec la tâche Rake suivante :
sudo gitlab-rake gitlab:elastic:estimate_cluster_size
Il peut arriver que des données n'aient jamais été indexées et ne se trouvent pas dans la file d'attente, ou que l'index soit dans un état où les migrations ne peuvent tout simplement pas progresser. Il est toujours préférable d'essayer de résoudre la cause racine du problème en consultant les journaux.
En dernier recours, vous pouvez recréer l'index à partir de zéro. Pour les petites installations GitLab, recréer l'index peut être un moyen rapide de résoudre certains problèmes. Pour les grandes installations GitLab, cependant, cette méthode peut prendre très longtemps. Votre index n'affiche pas les résultats de recherche corrects tant que l'indexation n'est pas terminée. Vous pouvez décocher la case Recherche avancée pendant l'exécution de l'indexation.
Si vous êtes sûr d'avoir lu les mises en garde précédentes et souhaitez continuer, vous devez exécuter la tâche Rake suivante pour recréer l'intégralité de l'index à partir de zéro.
{{< tabs >}}
{{< tab title="Paquet Linux (Omnibus)" >}}
# WARNING: DO NOT RUN THIS UNTIL YOU READ THE DESCRIPTION ABOVE
sudo gitlab-rake gitlab:elastic:index
{{< /tab >}}
{{< tab title="Auto-compilée (source)" >}}
# WARNING: DO NOT RUN THIS UNTIL YOU READ THE DESCRIPTION ABOVE
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:elastic:index
{{< /tab >}}
{{< /tabs >}}
Les éléments se retrouvent dans la file d'attente morte lorsqu'ils échouent après une nouvelle tentative. Les éléments de la file d'attente morte nécessitent une investigation manuelle et ne font pas l'objet de nouvelles tentatives automatiques.
Pour vérifier la taille et les détails de la file d'attente morte :
Démarrez la console Rails :
sudo gitlab-rails console
Vérifiez le nombre d'éléments en échec :
Search::Elastic::DeadQueue.queue_size
Inspectez les détails des éléments en échec :
Search::Elastic::DeadQueue.queued_items
Cette commande retourne un hash où chaque clé est un numéro de shard et chaque valeur est un tableau de paires [spec, score]. La spécification contient des informations sur l'élément en échec.
Mettez en file d'attente les éléments que vous souhaitez réessayer. Si ces éléments échouent à nouveau, ils sont renvoyés dans la file d'attente morte.
Pour réessayer les éléments dans la file d'attente morte :
Démarrez la console Rails :
sudo gitlab-rails console
Déplacez les éléments de la file d'attente morte vers la file d'attente de nouvelle tentative :
specs = Search::Elastic::DeadQueue.queued_items.flat_map { |_, items| items.map { |spec, _| spec } }
Search::Elastic::DeadQueue.clear_tracking!
Search::Elastic::RetryQueue.track!(*specs)
Facultatif. Vérifiez le statut d'indexation.
Pour supprimer des éléments de la file d'attente morte sans les réessayer, exécutez la commande suivante :
Search::Elastic::DeadQueue.clear_tracking!
Si vous avez besoin d'aide concernant les éléments de la file d'attente morte, partagez les informations suivantes avec le support GitLab :
Search::Elastic::DeadQueue.queue_sizePour améliorer les performances, assurez-vous que :
Pour entrer dans les détails, si Elasticsearch s'exécute sur le même serveur que GitLab, des conflits de ressources sont très susceptibles de se produire. Idéalement, Elasticsearch, qui nécessite des ressources importantes, devrait s'exécuter sur son propre serveur (éventuellement couplé avec Logstash et Kibana).
En ce qui concerne Elasticsearch, la RAM est la ressource clé. Elasticsearch recommande :
Pour les CPU, Elasticsearch recommande au moins 2 cœurs CPU, mais Elasticsearch indique que les configurations courantes utilisent jusqu'à 8 cœurs. Pour plus de détails sur les spécifications du serveur, consultez le guide matériel Elasticsearch.
Au-delà de l'évident, le sharding entre en jeu. Le sharding est un élément central d'Elasticsearch. Il permet la mise à l'échelle horizontale des indices, ce qui est utile lorsque vous traitez une grande quantité de données.
Avec la façon dont GitLab effectue l'indexation, il y a une énorme quantité de documents indexés. En utilisant le sharding, vous pouvez accélérer la capacité d'Elasticsearch à localiser les données, car chaque shard est un index Lucene.
Si vous n'utilisez pas le sharding, vous risquez de rencontrer des problèmes lorsque vous commencez à utiliser Elasticsearch dans un environnement de production.
Un index avec un seul shard n'a aucun facteur de mise à l’échelle et est susceptible de rencontrer des problèmes lorsqu'il est sollicité avec une certaine fréquence. Consultez la documentation Elasticsearch sur la planification de capacité.
Le moyen le plus simple de déterminer si le sharding est utilisé est de vérifier la sortie de l'API de santé Elasticsearch :
Pour une utilisation en production, il devrait toujours être vert.
Au-delà de ces étapes, vous abordez certaines des vérifications plus complexes, telles que les fusions et la mise en cache. Celles-ci peuvent devenir complexes et demandent du temps à maîtriser ; il est donc préférable d'escalader le problème ou de collaborer avec un expert Elasticsearch si vous devez approfondir ces aspects.
Contactez le support GitLab, mais cela est probablement quelque chose qu'un administrateur Elasticsearch expérimenté connaît mieux.
Plus votre instance GitLab contient de données, plus l'indexation prend du temps. Vous pouvez estimer la taille du cluster avec la tâche Rake sudo gitlab-rake gitlab:elastic:estimate_cluster_size.
Assurez-vous d'avoir suffisamment de nœuds et de processus Sidekiq pour indexer efficacement le code, les commits et les wikis. Si votre indexation initiale est lente, envisagez des nœuds ou processus Sidekiq dédiés.
Si l'indexation initiale est lente mais que Sidekiq dispose de suffisamment de nœuds et de processus, vous pouvez ajuster les paramètres des workers de recherche avancée dans GitLab. Pour Remettre en file d'attente les workers d'indexation, la valeur par défaut est false. Pour Nombre de shards pour l'indexation non codée, la valeur par défaut est 2. Ces paramètres limitent l'indexation à 2 000 documents par minute.
Prérequis :
Pour ajuster les paramètres des workers :
2.