Elasticsearch:Monitoring metrics and exception handling

Les métriques de surveillance du cluster peuvent différer de celles de Kibana ou d'outils tiers pour les raisons suivantes :

• Différences de période d'échantillonnage : La surveillance du cluster utilise une période d'échantillonnage différente de celle de Kibana et d'autres outils, ce qui entraîne des variations dans les données.

• Différences d'algorithme de requête : L'instabilité du cluster affecte la collecte des données pour la surveillance du cluster et pour Kibana. Par exemple, des fluctuations du cluster peuvent provoquer des pics, des valeurs négatives ou une absence de données pour la métrique QPS, tandis que Kibana peut afficher une valeur vide pour la même période.

  Remarque

  La surveillance du cluster offre plus de métriques que la surveillance Kibana. Par exemple, la surveillance avancée vous permet de consulter les métriques au niveau des shards, y compris le QPS des requêtes, le TPS d'écriture et la latence pour chaque shard, alors que la surveillance Kibana ne fournit que des métriques agrégées au niveau du cluster et des nœuds. Utilisez conjointement la surveillance du cluster et la surveillance Kibana pour analyser les détails de surveillance.

• Différences de source de données : Kibana récupère les métriques via l'API Elasticsearch. La surveillance du cluster collecte certaines métriques au niveau des nœuds, telles que l'utilisation du processeur, load_1m et l'utilisation du disque, à partir des interfaces système sous-jacentes. Ces métriques reflètent l'utilisation globale des ressources du système, et pas uniquement celle du processus Elasticsearch.

Description de la métrique

Indique l'état de santé du cluster. Une valeur de 0,00 signifie que le cluster est sain. Configurez des alertes pour cette métrique. Configurer les alertes du cluster. Le tableau suivant répertorie les valeurs possibles.

Causes d'un état anormal

Une valeur différente de 0.00 indique un état anormal du cluster. Causes courantes :

• Utilisation élevée du processeur ou de la mémoire heap sur un ou plusieurs nœuds, pouvant atteindre 100 %.

• Utilisation élevée du disque sur un ou plusieurs nœuds, par exemple supérieure à 85 %.

• Charge Load_1m élevée sur un ou plusieurs nœuds.

• L'état de santé d'un ou plusieurs index est jaune ou rouge.

Recommandations de dépannage

• Consultez la page Monitoring dans la console Kibana, ou consultez les journaux de l'instance pour obtenir plus de détails. Par exemple, supprimez les index inutiles si un index consomme trop de mémoire.

• Si une utilisation élevée du disque a provoqué l'état anormal, consultez la rubrique Dépanner et résoudre les problèmes d'utilisation élevée du disque du cluster et les problèmes en lecture seule.

• Pour les types d'instance de petite taille (par exemple, 1 cœur de processeur et 2 Go de mémoire), commencez par mettre à niveau le cluster vers un type d'instance avec un ratio processeur/mémoire de 1:4. Si l'état reste anormal, suivez les deux recommandations ci-dessus.

Description

Affiche l'état du snapshot pour la fonctionnalité de sauvegarde automatique. Une valeur de 0 indique qu'un snapshot existe.

Causes d'un état anormal

Une valeur de 2 indique un échec. Causes courantes :

• L'utilisation du disque sur un ou plusieurs nœuds est élevée ou proche de 100 %.

• Le cluster n'est pas sain.

Causes d'un état anormal

Une valeur supérieure à 0 indique qu'un ou plusieurs nœuds sont déconnectés du cluster. Causes courantes :

• Utilisation élevée du processeur, de la mémoire heap ou du disque sur un nœud, pouvant approcher 100 %, ce qui empêche le nœud de répondre aux signaux de maintien de connexion (heartbeats) du cluster.

• Partitionnement réseau ou échec de connectivité entre le nœud et le nœud maître.

• Le processus du nœud a planté ou a rencontré une erreur de manque de mémoire (OOM), ce qui a entraîné la sortie du nœud du cluster.

• Des opérations fréquentes de garbage collection JVM, telles qu'un full GC continu, ont rendu le nœud injoignable pendant une durée suffisante pour qu'il soit marqué comme déconnecté.

• Une défaillance au niveau du système, telle qu'un problème d'hôte sous-jacent ou un événement de modification système ayant affecté la disponibilité du nœud.

Recommandations de dépannage

• Accédez à Event Center dans la console Alibaba Cloud Elasticsearch et vérifiez les onglets System Change et Cluster Change pour confirmer si un événement de modification a provoqué la déconnexion des nœuds.

• Sur la page Cluster Monitoring, examinez l'utilisation du processeur, de la mémoire heap, du disque et la charge Load_1m de chaque nœud pendant la période de déconnexion afin d'écarter un épuisement des ressources. Pour connaître la signification de chaque métrique, reportez-vous aux sections correspondantes de cette rubrique.

• Vérifiez l'état de santé du cluster sur la page Monitoring de la console Kibana, ou consultez les journaux de l'instance, pour obtenir les erreurs spécifiques signalées pendant la déconnexion du nœud.

• Vérifiez la connectivité réseau et les configurations des groupes de sécurité pour le nœud afin de confirmer qu'aucune modification de règle ne bloque la communication entre les nœuds.

Description de la métrique

Agrège les données des entrées index.search.slowlog.query et index.search.slowlog.fetch . Regroupe les requêtes par temps d'exécution (took_millis) par intervalles de 1 seconde (0–1 s, 1–2 s, jusqu'à 10 s). Définissez votre seuil de requête lente avec le paramètre index.search.slowlog.threshold.xxx . Configuration du modèle d'index.

Causes courantes d'une valeur anormale

Si les requêtes lentes augmentent dans des plages horaires spécifiques, un problème de service peut exister. Causes courantes :

Description

Mémoire heap utilisée par Fielddata dans le cluster. Une utilisation excessive de Fielddata peut déclencher un circuit breaker et affecter la stabilité du cluster.

Causes courantes

Une utilisation élevée de Fielddata consomme de la mémoire heap et peut provoquer des exceptions de service. Causes courantes :

• Opérations fréquentes de tri ou d'agrégation sur des champs string (Text). Les données Fielddata pour ces requêtes ne sont pas effacées par défaut. Utilisez plutôt des types de champs numériques.

• Pics soudains ou fluctuations importantes du trafic Query QPS ou write QPS . Cela entraîne un chargement fréquent de Fielddata dans le cache.

• Un nombre trop élevé d'index ou de shards augmente la charge de gestion, ce qui entraîne une utilisation élevée du processeur, de HeapMemory ou de Load_1m .

Description

Nombre de requêtes bulk par seconde pour un index.

Causes courantes d'exceptions

Cette métrique peut ne pas afficher de données pour les raisons suivantes :

• Une pression élevée sur le cluster interfère avec la collecte des données de surveillance.

• L'envoi des données de surveillance a échoué.

Description

Requêtes par seconde (QPS) pour un index. La valeur dépend du nombre de shards primaires dans l'index interrogé.

Par exemple, l'interrogation d'un index comportant cinq shards primaires compte pour 5 QPS.

Causes de valeurs anormales

Cette métrique peut ne pas afficher de données. Les raisons courantes incluent :

• Une charge élevée du cluster peut interférer avec la collecte des données de surveillance.

• L'envoi des données de surveillance a échoué.

Description de la métrique

Utilisation du processeur pour chaque nœud. Une utilisation élevée, en particulier proche de 100 %, peut avoir un impact sur les services du cluster.

Causes courantes d'exceptions

Un pic ou une fluctuation importante indique un problème de service. Causes courantes :

Description

Utilisation de la mémoire heap pour chaque nœud. Une utilisation élevée ou la présence d'objets volumineux en mémoire peut affecter les performances et déclencher des opérations de garbage collection (GC).

Causes des valeurs anormales

Une augmentation soudaine ou une fluctuation importante indique souvent une anomalie de service. Causes courantes :

Description

Charge moyenne sur 1 minute pour chaque nœud, indiquant la charge de travail du système. Une valeur normale est inférieure au nombre de cœurs CPU. Le tableau suivant explique les valeurs pour un nœud monocœur.

Causes d'anomalie

Une valeur supérieure au nombre de cœurs CPU indique une surcharge du système. Causes courantes :

• L'utilisation du CPU ou de la mémoire heap sur le nœud est excessivement élevée, pouvant atteindre 100 %.

• Pic soudain ou augmentation significative du Query QPS ou du write QPS.

• Requêtes lentes coûteuses.

  Utilisez la page Log Query pour analyser ces journaux.

Description

Nombre de connexions TCP établies depuis les clients vers chaque nœud.

Causes d'anomalie

Un pic survient souvent lorsque les clients ne libèrent pas rapidement les connexions TCP. Configurez des politiques côté client pour libérer les connexions inactives.

Description

Utilisation des E/S pour chaque nœud.

Causes d'anomalie

Une utilisation élevée du disque augmente les temps d'attente en lecture/écriture et peut provoquer des pics d'utilisation des E/S jusqu'à 100 %. Analysez votre charge de travail et envisagez de mettre à niveau la configuration du cluster.

Description de la métrique

Mémoire heap de l'ancienne génération utilisée par chaque nœud. Une utilisation élevée ou la présence d'objets volumineux peut affecter les performances et déclencher une GC, entraînant potentiellement de longues pauses ou un Full GC.

Causes des anomalies de métrique

Une augmentation soudaine ou une fluctuation importante indique souvent une exception de service. Causes courantes :

Description

Nombre d'événements Full GC dans le cluster par minute.

Causes d'anomalie

Une valeur supérieure à zéro indique une exception de service. Causes courantes :

• Utilisation élevée de la mémoire heap.

• Objets volumineux en mémoire.

Description

Compte les événements GC de l'ancienne génération sur chaque nœud. Une utilisation élevée ou la présence d'objets volumineux peut déclencher une GC automatique, entraînant potentiellement de longues pauses ou un Full GC.

Causes courantes

Consultez Utilisation de l'ancienne zone des nœuds (B).

Métrique

Durée moyenne de la GC de l'ancienne génération sur chaque nœud. Une utilisation élevée de l'ancienne génération ou la présence d'objets volumineux peut déclencher une GC, entraînant des durées plus longues ou un Full GC.

Causes des valeurs anormales

Consultez JVMMemoryOldUsedBytes.

Description de la métrique

Nombre total d'entrées de journal de niveau avertissement dans les journaux du cluster sur une période d'une minute.

Causes des valeurs anormales

Une valeur différente de 0 indique une exception de service. Causes courantes :

• Requêtes de lecture anormales.

• Requêtes d'écriture anormales.

• Erreurs dans les tâches Elasticsearch.

• Opérations de garbage collection.

Dépannage

Accédez à la page Journaux des requêtes et cliquez sur Cluster Log. Sur la page Cluster Log contient des entrées GC, ces entrées sont également incluses dans la métrique Cluster Log.