15.5. Dépannage pour les alertes critiques

Dépannage

1. Vérifiez l'état de santé du cluster Elasticsearch et vérifiez que le cluster status est rouge.

   oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- health

   Copy to Clipboard

2. Liste des nœuds qui ont rejoint le cluster.

   oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/nodes?v

   Copy to Clipboard

3. Listez les pods Elasticsearch et comparez-les aux nœuds dans la sortie de la commande de l'étape précédente.

   oc -n openshift-logging get pods -l component=elasticsearch

   Copy to Clipboard

4. Si certains nœuds Elasticsearch n'ont pas rejoint le cluster, procédez comme suit.

   1. Confirmer qu'Elasticsearch a un nœud de plan de contrôle élu.

      oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/master?v

      Copy to Clipboard

   2. Examinez les journaux de pods du nœud de plan de contrôle élu pour détecter les problèmes.

      oc logs <elasticsearch_master_pod_name> -c elasticsearch -n openshift-logging

      Copy to Clipboard

   3. Examinez les journaux des nœuds qui n'ont pas rejoint le cluster.

      oc logs <elasticsearch_node_name> -c elasticsearch -n openshift-logging

      Copy to Clipboard

5. Si tous les nœuds ont rejoint la grappe, effectuez les étapes suivantes pour vérifier si la grappe est en cours de récupération.

   oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/recovery?active_only=true

   Copy to Clipboard

   S'il n'y a pas de sortie de commande, le processus de récupération peut être retardé ou bloqué par des tâches en attente.

6. Vérifier s'il y a des tâches en attente.

   oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- health |grep  number_of_pending_tasks

   Copy to Clipboard

7. S'il y a des tâches en suspens, surveillez leur état.

   Si leur état change et indique que la grappe se rétablit, continuez à attendre. Le délai de récupération varie en fonction de la taille de la grappe et d'autres facteurs.

   Dans le cas contraire, si l'état des tâches en attente ne change pas, cela indique que la récupération est bloquée.

8. S'il semble que la récupération soit bloquée, vérifiez si cluster.routing.allocation.enable est réglé sur none.

   oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/settings?pretty

   Copy to Clipboard

9. Si cluster.routing.allocation.enable est défini sur none, définissez-le sur all.

   oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/settings?pretty -X PUT -d '{"persistent" : {\i1}"cluster.routing.allocation.enable":\N "all"}}'

   Copy to Clipboard

10. Vérifier quels indices sont encore rouges.

    oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/indices?v

    Copy to Clipboard

11. Si certains indices sont encore rouges, essayez de les effacer en suivant les étapes suivantes.

    1. Vider le cache.

       oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name>/_cache/clear?pretty

       Copy to Clipboard

    2. Augmenter le nombre maximum de tentatives d'allocation.

       oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name>/_settings?pretty -X PUT -d '{"index.allocation.max_retries":10}'

       Copy to Clipboard

    3. Supprimer tous les éléments du défilement.

       oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_search/scroll/_all -X DELETE

       Copy to Clipboard

    4. Augmenter le délai d'attente.

       oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name>/_settings?pretty -X PUT -d '{"index.unassigned.node_left.delayed_timeout":\N "10m"}'

       Copy to Clipboard

12. Si les étapes précédentes ne permettent pas d'effacer les indices rouges, supprimez les indices individuellement.

    1. Identifier le nom de l'index rouge.

       oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cat/indices?v

       Copy to Clipboard

    2. Supprimer l'index rouge.

       oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_red_index_name> -X DELETE

       Copy to Clipboard

13. S'il n'y a pas d'indices rouges et que l'état de la grappe est rouge, vérifiez qu'un nœud de données n'est pas soumis à une charge de traitement élevée et continue.

    1. Vérifiez si l'utilisation de la mémoire vive de la JVM Elasticsearch est élevée.

       oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_nodes/stats?pretty

       Copy to Clipboard

       Dans la sortie de la commande, examinez le champ node_name.jvm.mem.heap_used_percent pour déterminer l'utilisation de la mémoire vive de la JVM.

    2. Vérifier si l'utilisation de l'unité centrale est élevée.

Dépannage

1. Augmenter le nombre de nœuds en ajustant nodeCount dans le CR ClusterLogging.

Dépannage

1. Identifiez le nœud sur lequel Elasticsearch est déployé.

   oc -n openshift-logging get po -o wide

   Copy to Clipboard

2. Vérifier s'il y a unassigned shards.

   oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/health?pretty | grep unassigned_shards

   Copy to Clipboard

3. S'il y a des unités de stockage non attribuées, vérifiez l'espace disque sur chaque nœud.

   for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; done

   Copy to Clipboard

4. Vérifiez le champ nodes.node_name.fs pour déterminer l'espace disque libre sur ce nœud.

   Si le pourcentage de disque utilisé est supérieur à 85 %, le nœud a dépassé le filigrane bas et les barrettes ne peuvent plus être allouées à ce nœud.

5. Essayez d'augmenter l'espace disque sur tous les nœuds.
6. S'il n'est pas possible d'augmenter l'espace disque, essayez d'ajouter un nouveau nœud de données au cluster.

7. Si l'ajout d'un nouveau nœud de données pose problème, diminuez la politique de redondance totale de la grappe.

   1. Vérifier le courant redundancyPolicy.

      oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'

      Copy to Clipboard
      Note

      Si vous utilisez un CR ClusterLogging, entrez :

      oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

      Copy to Clipboard
   2. Si le cluster redundancyPolicy est plus élevé que SingleRedundancy, réglez-le sur SingleRedundancy et enregistrez cette modification.

8. Si les étapes précédentes ne permettent pas de résoudre le problème, supprimez les anciens indices.

   1. Vérifier l'état de tous les index sur Elasticsearch.

      oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices

      Copy to Clipboard
   2. Identifier un ancien index qui peut être supprimé.

   3. Supprimer l'index.

      oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE

      Copy to Clipboard

Dépannage

1. Identifiez le nœud sur lequel Elasticsearch est déployé.

   oc -n openshift-logging get po -o wide

   Copy to Clipboard

2. Vérifiez l'espace disque sur chaque nœud.

   for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; done

   Copy to Clipboard

3. Vérifier si le cluster est en cours de rééquilibrage.

   oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_cluster/health?pretty | grep relocating_shards

   Copy to Clipboard

   Si la sortie de la commande indique que des shards ont été déplacés, cela signifie que le High Watermark a été dépassé. La valeur par défaut du filigrane élevé est de 90 %.

   Les ensembles de données sont déplacés vers un nœud où l'utilisation du disque est faible et qui n'a pas franchi de seuil de filigrane.

4. Pour allouer des fragments à un nœud particulier, libérez de l'espace.
5. Essayez d'augmenter l'espace disque sur tous les nœuds.
6. S'il n'est pas possible d'augmenter l'espace disque, essayez d'ajouter un nouveau nœud de données au cluster.

7. Si l'ajout d'un nouveau nœud de données pose problème, diminuez la politique de redondance totale de la grappe.

   1. Vérifier le courant redundancyPolicy.

      oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'

      Copy to Clipboard
      Note

      Si vous utilisez un CR ClusterLogging, entrez :

      oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

      Copy to Clipboard
   2. Si le cluster redundancyPolicy est plus élevé que SingleRedundancy, réglez-le sur SingleRedundancy et enregistrez cette modification.

8. Si les étapes précédentes ne permettent pas de résoudre le problème, supprimez les anciens indices.

   1. Vérifier l'état de tous les index sur Elasticsearch.

      oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices

      Copy to Clipboard
   2. Identifier un ancien index qui peut être supprimé.

   3. Supprimer l'index.

      oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE

      Copy to Clipboard

Dépannage

1. Vérifiez l'espace disque du nœud Elasticsearch.

   for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; done

   Copy to Clipboard

   Vérifiez le champ nodes.node_name.fs pour déterminer l'espace disque libre sur ce nœud.

2. Si le pourcentage de disques utilisés est supérieur à 95 %, cela signifie que le nœud a franchi le seuil d'inondation. L'écriture est bloquée pour les disques alloués à ce nœud particulier.
3. Essayez d'augmenter l'espace disque sur tous les nœuds.
4. S'il n'est pas possible d'augmenter l'espace disque, essayez d'ajouter un nouveau nœud de données au cluster.

5. Si l'ajout d'un nouveau nœud de données pose problème, diminuez la politique de redondance totale de la grappe.

   1. Vérifier le courant redundancyPolicy.

      oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'

      Copy to Clipboard
      Note

      Si vous utilisez un CR ClusterLogging, entrez :

      oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

      Copy to Clipboard
   2. Si le cluster redundancyPolicy est plus élevé que SingleRedundancy, réglez-le sur SingleRedundancy et enregistrez cette modification.

6. Si les étapes précédentes ne permettent pas de résoudre le problème, supprimez les anciens indices.

   1. Vérifier l'état de tous les index sur Elasticsearch.

      oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices

      Copy to Clipboard
   2. Identifier un ancien index qui peut être supprimé.

   3. Supprimer l'index.

      oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE

      Copy to Clipboard

7. Continuez à libérer et à surveiller l'espace disque jusqu'à ce que l'espace disque utilisé soit inférieur à 90 %. Débloquez ensuite l'écriture sur ce nœud particulier.

   oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=_all/_settings?pretty -X PUT -d '{"index.blocks.read_only_allow_delete" : null}'

   Copy to Clipboard

Dépannage

1. Obtenir l'espace disque du nœud Elasticsearch.

   for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod -- df -h /elasticsearch/persistent; done

   Copy to Clipboard
2. Dans la sortie de la commande, vérifiez le champ nodes.node_name.fs pour déterminer l'espace disque libre sur ce nœud.
3. Essayez d'augmenter l'espace disque sur tous les nœuds.
4. S'il n'est pas possible d'augmenter l'espace disque, essayez d'ajouter un nouveau nœud de données au cluster.

5. Si l'ajout d'un nouveau nœud de données pose problème, diminuez la politique de redondance totale de la grappe.

   1. Vérifier le courant redundancyPolicy.

      oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'

      Copy to Clipboard
      Note

      Si vous utilisez un CR ClusterLogging, entrez :

      oc -n openshift-logging get cl -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'

      Copy to Clipboard
   2. Si le cluster redundancyPolicy est plus élevé que SingleRedundancy, réglez-le sur SingleRedundancy et enregistrez cette modification.

6. Si les étapes précédentes ne permettent pas de résoudre le problème, supprimez les anciens indices.

   1. Vérifier l'état de tous les index sur Elasticsearch.

      oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- indices

      Copy to Clipboard
   2. Identifier un ancien index qui peut être supprimé.

   3. Supprimer l'index.

      oc exec -n openshift-logging -c elasticsearch <elasticsearch_pod_name> -- es_util --query=<elasticsearch_index_name> -X DELETE

      Copy to Clipboard