Alibaba Cloud Elasticsearch fournit des métriques de surveillance de base pour les clusters en cours d'exécution, telles que l'état de santé du cluster, le QPS des requêtes, l'utilisation du CPU des nœuds et l'utilisation du disque, ainsi que des métriques avancées de surveillance et d'alerte pour les clusters, les index et les ressources des nœuds. Découvrez comment afficher les détails de surveillance et comprendre chaque métrique, ses anomalies courantes et les actions recommandées.
, ainsi que des métriques avancées de surveillance et d'alerte pour les clusters, les index et les ressources des nœuds
Différences de surveillance
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 de 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, les 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.
RemarqueSi la surveillance du cluster fournit plus de métriques que Kibana, utilisez les deux outils pour une surveillance complète.
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 CPU,
load_1met l'utilisation du disque, à partir des interfaces système sous-jacentes. Ces métriques reflètent l'utilisation des ressources à l'échelle du système, et pas uniquement celle du processus Elasticsearch.
Surveillance du cluster
Connectez-vous à la console Alibaba Cloud Elasticsearch.
Dans le menu de navigation de gauche, sélectionnez Elasticsearch Clusters.
-
Accédez au cluster cible.
Dans la barre de navigation supérieure, sélectionnez le groupe de ressources auquel appartient le cluster et la région où il se trouve.
Sur la page Elasticsearch Clusters, localisez le cluster et cliquez sur son ID.
Dans le volet de navigation de gauche, accédez à .
-
Consultez les détails de surveillance.
-
Consultez les détails de la Basic Monitoring
Sous l'onglet Basic Monitoring, sélectionnez un Group Name et une plage horaire pour afficher les détails de surveillance correspondants.
RemarqueCliquez sur Custom pour afficher les détails de surveillance sur une plage horaire personnalisée.
La surveillance et les alertes sont activées par défaut. Consultez les données historiques sur la page Cluster Monitoring. Les données ont une granularité d'une minute et sont conservées pendant 30 jours.
Les métriques de surveillance de base sont répertoriées dans la section Présentation des métriques de surveillance de base.
-
Métriques de surveillance de base
Les tableaux suivants répertorient les métriques de surveillance de base d'un cluster.
L'interface utilisateur réelle peut varier.
Présentation
|
Nom de la métrique |
Description |
|
Indique l'état de santé du cluster. Une valeur de |
|
|
État des snapshots issus de la fonctionnalité de sauvegarde automatique. Une valeur de |
|
|
Nombre total de nœuds dans le cluster. |
|
|
Nombre total de nœuds inaccessibles dans le cluster (compteur) |
Nombre total de nœuds inaccessibles dans le cluster. |
|
Nombre d'index dans le cluster. |
|
|
Nombre de shards dans le cluster. |
|
|
Nombre de shards primaires dans le cluster. |
|
|
Nombre de requêtes lentes dans le cluster. |
|
|
Nombre de documents écrits dans le cluster par seconde. |
|
|
Requêtes par seconde (QPS) pour le cluster. La valeur dépend du nombre de shards primaires dans les index interrogés. |
|
|
Utilisation du CPU de chaque nœud. |
|
|
Utilisation de la mémoire heap de chaque nœud. |
|
|
Utilisation du disque de chaque nœud. Nous vous recommandons de définir le seuil d'alerte pour l'utilisation du disque à |
|
|
Charge moyenne du système au cours de la dernière |
|
|
Débit des données entrantes pour chaque nœud. Période de surveillance : 1 minute. Unité : Kio/s. |
|
|
Débit des données sortantes pour chaque nœud. Période de surveillance : 1 minute. Unité : Kio/s. |
|
|
Nombre de paquets réseau entrants pour chaque nœud. Période de surveillance : 1 minute. |
|
|
Nombre de paquets réseau sortants de chaque nœud. Période de surveillance : 1 minute. |
|
|
Nombre de connexions TCP initiées par les clients vers chaque nœud. |
|
|
Utilisation des E/S pour chaque nœud. |
|
|
Quantité de données lues par seconde depuis chaque nœud du cluster. |
|
|
Quantité de données écrites par seconde sur chaque nœud du cluster. |
|
|
Nombre de requêtes de lecture terminées par seconde sur chaque nœud du cluster. |
|
|
Nombre de requêtes d'écriture terminées par seconde sur chaque nœud du cluster. |
Métriques de cluster
|
Nom de la métrique |
Description |
|
Indique l'état de santé du cluster. Une valeur de |
|
|
Nombre total de nœuds dans le cluster. |
|
|
Nombre total de nœuds inaccessibles dans le cluster (compteur) |
Nombre total de nœuds inaccessibles dans le cluster. |
|
Nombre d'index dans le cluster. |
|
|
Nombre de shards dans le cluster. |
|
|
Nombre de shards primaires dans le cluster. |
|
|
Nombre de requêtes lentes dans le cluster. |
|
|
Basé sur les journaux de |
|
|
État des snapshots issus de la fonctionnalité de sauvegarde automatique. Une valeur de |
|
|
Nombre de documents écrits dans le cluster par seconde. |
|
|
Requêtes par seconde (QPS) pour le cluster. La valeur dépend du nombre de shards primaires dans les index interrogés. |
|
|
Mémoire heap utilisée par fielddata dans le cluster. Une utilisation élevée peut déclencher le disjoncteur fielddata et affecter la stabilité du cluster. |
Métriques d'index
|
Nom de la métrique |
Description |
|
Requêtes groupées par seconde pour l'index. |
|
|
Requêtes par seconde (QPS) pour un index. La valeur dépend du nombre de shards primaires dans l'index interrogé. |
|
|
Temps maximal de requête pour un index, en millisecondes. |
Métriques de ressources des nœuds
|
Nom de la métrique |
Description |
|
Utilisation du CPU de chaque nœud. Une utilisation élevée du CPU, ou proche de 100 %, peut affecter les services du cluster. |
|
|
Utilisation de la mémoire heap pour chaque nœud. Une utilisation élevée ou des objets volumineux en mémoire peuvent affecter les performances et déclencher des opérations GC automatiques. |
|
|
Utilisation du disque de chaque nœud. Nous vous recommandons de définir le seuil d'alerte pour l'utilisation du disque à |
|
|
Utilisation de la mémoire système du nœud. Remarque
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Pourcentage de temps pendant lequel le CPU attend des opérations d'E/S. Remarque
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Charge moyenne du système au cours de la dernière |
|
|
Utilisation CPU totale du nœud (%) |
Utilisation totale du CPU d'un nœud, hors temps d'inactivité. Il s'agit de la somme de l'utilisation du CPU en mode noyau, en mode utilisateur et dans les états d'attente d'E/S. Remarque
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
Métriques réseau des nœuds
|
Nom de la métrique |
Description |
Remarques |
|
Débit des données entrantes pour chaque nœud du cluster. Période de surveillance : 1 minute. Unité : Kio/s. |
Sans objet |
|
|
Débit des données sortantes pour chaque nœud du cluster. Période de surveillance : 1 minute. Unité : Kio/s. |
Sans objet |
|
|
Bande passante réseau du nœud (Kio/s) = Bande passante réseau entrante du nœud (Kio/s) + Bande passante réseau sortante du nœud (Kio/s). |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Utilisation de la bande passante réseau du nœud (%) = (Bande passante réseau_Entrée du nœud (Kio/s) + Bande passante réseau_Sortie du nœud (Kio/s)) / Bande passante réseau de base du nœud (Gbit/s). |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Nombre de connexions TCP initiées par les clients vers chaque nœud. |
Sans objet |
|
|
Taux de retransmission des paquets réseau du nœud. |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Nombre de paquets réseau entrants pour chaque nœud. Période de surveillance : 1 minute. |
Sans objet |
|
|
Nombre de paquets réseau sortants de chaque nœud. Période de surveillance : 1 minute. |
Sans objet |
|
|
Paquets réseau du nœud (compteur) = Paquets réseau sortants du nœud (compteur) + Paquets réseau entrants du nœud (compteur). |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Utilisation des paquets réseau du nœud (%) = (Paquets réseau sortants du nœud (compteur) + Paquets réseau entrants du nœud (compteur)) / PPS de transmission et de réception des paquets réseau du nœud. |
Sans objet |
Métriques disque des nœuds
|
Nom de la métrique |
Description |
Remarques |
|
Quantité de données lues par seconde depuis chaque nœud du cluster. |
Sans objet |
|
|
Quantité de données écrites par seconde sur chaque nœud du cluster. |
Sans objet |
|
|
Bande passante disque (Mio/s) = Bande passante disque_Lecture (Mio/s) + Bande passante disque_Écriture (Mio/s). |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Utilisation de la bande passante disque_Disque cloud (%) = (Bande passante disque_Lecture (Mio/s) + Bande passante disque_Écriture (Mio/s)) / Débit d'un seul disque ESSD (Mio/s). |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). Pour plus d'informations sur le débit d'un seul disque ESSD, consultez la section ESSD. |
|
|
Utilisation de la bande passante disque_Nœud (%) = (Bande passante disque_Lecture (Mio/s) + Bande passante disque_Écriture (Mio/s)) / Bande passante de base du disque cloud du nœud (Gbit/s). |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Utilisation des E/S pour chaque nœud. |
Sans objet |
|
|
Nombre de requêtes de lecture terminées par seconde sur chaque nœud du cluster. |
Sans objet |
|
|
Nombre de requêtes d'écriture terminées par seconde sur chaque nœud du cluster. |
Sans objet |
|
|
IOPS disque (compteur) = IOPS disque_Lecture (compteur) + IOPS disque_Écriture (compteur). |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Utilisation des IOPS disque_Disque cloud (%) = (IOPS disque_Lecture (compteur) + IOPS disque_Écriture (compteur)) / IOPS d'un seul disque ESSD. |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). Pour plus d'informations sur le débit d'un seul disque ESSD, consultez la section ESSD. |
|
|
Utilisation des IOPS disque_Nœud (%) = (IOPS disque_Lecture (compteur) + IOPS disque_Écriture (compteur)) / IOPS de base du disque cloud du nœud. |
Cette métrique est prise en charge uniquement par le nouveau plan de contrôle cloud-native (v3). |
|
|
Longueur moyenne de la file d'attente des requêtes. |
Sans objet |
Métriques JVM des nœuds
|
Nom de la métrique |
Description |
|
Mémoire heap de l'ancienne génération utilisée par chaque nœud. Une utilisation élevée ou des objets volumineux peuvent affecter les performances et déclencher le garbage collection (GC), entraînant potentiellement des pauses prolongées ou un full GC. |
|
|
Nombre total d'événements full GC dans le cluster sur une période de |
|
|
Événements GC de l'ancienne génération sur chaque nœud. Une utilisation élevée ou des objets volumineux dans l'ancienne génération peuvent affecter les performances du cluster et déclencher un GC automatique. La collecte d'objets volumineux peut entraîner des pauses prolongées ou un full GC. |
|
|
Durée moyenne passée sur le GC de l'ancienne génération sur chaque nœud. Une utilisation élevée ou des objets volumineux dans l'ancienne génération peuvent déclencher un GC, et la collecte d'objets volumineux peut entraîner des pauses prolongées ou un full GC. |
Métriques du pool de threads
|
Nom de la métrique |
Description |
|
Threads exécutant actuellement des tâches dans le pool de threads de recherche. |
|
|
Requêtes rejetées du pool de threads de recherche (Nouveau) (compteur) |
Requêtes rejetées dans le pool de threads de recherche du cluster. |
Autres métriques
|
Nom de la métrique |
Description |
|
Nombre total d'entrées de journal de niveau WARNING dans le journal principal du cluster sur une période d'une minute. |
Métriques obsolètes
|
Nom de la métrique |
Description |
|
Requêtes rejetées du pool de threads de recherche (compteur) |
Requêtes rejetées dans le pool de threads de requête. Cette métrique est calculée différemment de la métrique SearchThreadpoolRejectedV2 et est désormais obsolète. Utilisez plutôt SearchThreadpoolRejectedV2. |
État du cluster (valeur)
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 de cluster. Le tableau suivant répertorie les valeurs possibles.
|
Valeur |
Couleur |
État |
Description |
|
0,00 |
Vert |
Tous les shards primaires et réplicas sont alloués. |
Tous les index du cluster sont sains et ne comportent aucun shard non attribué. |
|
1,00 |
Jaune |
Tous les shards primaires sont alloués, mais un ou plusieurs shards réplicas ne le sont pas. |
Au moins un index comporte des shards réplicas non attribués. |
|
2,00 |
Rouge |
Au moins un shard primaire n'est pas alloué. |
Au moins un index comporte des shards primaires non attribués, ce qui signifie que certaines données sont indisponibles. |
Les couleurs de ce tableau correspondent à l'état du cluster affiché sur la page Informations de base de votre instance.
Causes d'un état anormal
Une valeur autre que 0.00 indique un état de cluster anormal. Causes courantes :
Utilisation élevée du CPU 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_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
Vérifiez la page Monitoring dans la console Kibana, ou consultez les journaux de l'instance pour 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 section Dépanner et résoudre les problèmes d'utilisation élevée du disque du cluster et les problèmes de lecture seule.
Pour les types d'instance de petite taille (par exemple, 1 cœur de CPU et 2 Go de mémoire), mettez d'abord à niveau le cluster vers un type d'instance avec un ratio CPU/mémoire de 1:4. Si l'état reste anormal, suivez les deux recommandations ci-dessus.
État du snapshot
Description
Affiche l'état du snapshot pour la fonctionnalité de sauvegarde automatique. Une valeur de 0 indique qu'un snapshot existe.
|
Valeur |
Description |
|
0 |
Un snapshot existe. |
|
-1 |
Aucun snapshot n'existe. |
|
1 |
Un snapshot est en cours. |
|
2 |
La tâche de snapshot a échoué. |
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.
Nombre de nœuds du cluster
Nombre total de nœuds dans le cluster. Utilisez cette métrique pour confirmer que l'échelle des nœuds correspond aux attentes.
Nombre de nœuds déconnectés
Nombre total de nœuds déconnectés. Les nœuds déconnectés peuvent entraîner des réaffectations de shards ou une augmentation de la latence des requêtes.
Nombre d'index du cluster
Nombre d'index dans le cluster. Un nombre excessif d'index peut provoquer une contention des ressources (mémoire et CPU).
Nombre de shards du cluster (compteur)
Nombre de shards dans le cluster. Un nombre excessif de shards augmente la charge de gestion, tandis qu'un nombre insuffisant dégrade les performances des requêtes en raison d'une répartition inégale de la charge.
Nombre de shards primaires du cluster
Nombre de shards primaires dans le cluster. Un nombre insuffisant de shards primaires peut provoquer un goulot d'étranglement en écriture.
Requêtes lentes du cluster
Nombre de requêtes lentes dans le cluster. Utilisez cette métrique pour identifier les goulots d'étranglement de performance, tels que des requêtes complexes ou des problèmes de conception d'index.
QPS d'écriture du cluster (compteur/s)
Des pics soudains du QPS d'écriture peuvent entraîner une utilisation élevée du CPU, de la mémoire heap ou une charge importante des nœuds, dégradant ainsi les performances du cluster. Évitez ces pics.
Nombre de documents écrits dans le cluster par seconde. Calculé comme suit :
Une requête d'écriture de document unique compte pour 1. Plusieurs requêtes au cours d'une seconde sont additionnées.
Pour une requête _bulk API, le QPS d'écriture équivaut au nombre total de documents dans la requête. Plusieurs requêtes _bulk au cours d'une seconde sont additionnées.
QPS de requête du cluster (compteur/s)
Évitez les pics soudains du QPS de requête. Ils peuvent entraîner une utilisation élevée du CPU, de la mémoire heap ou une charge moyenne élevée sur 1 minute, dégradant ainsi les performances du cluster.
QPS de requête pour le cluster. 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 comme cinq requêtes distinctes.
Distribution de la latence des requêtes lentes du cluster
Description de la métrique
Agrège les données des entrées index.search.slowlog.query et index.search.slowlog.fetch . Groupe les requêtes par temps d'exécution (took_millis) par intervalles de 1 seconde (0–1s, 1–2s, jusqu'à 10s). 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 :
|
Cause |
Description |
|
QPS élevé |
Des pics soudains ou des fluctuations importantes du Query QPS ou du write QPS augmentent la charge du cluster, entraînant des temps d'exécution de requête plus longs. |
|
Requêtes d'agrégation ou de script |
Les requêtes d'agrégation sont gourmandes en ressources. Utilisez-les avec prudence. |
|
Requêtes term sur des champs numériques |
L'exécution de nombreuses requêtes term sur des champs numériques (byte, short, integer, long) peut être lente car la construction du bitset pour les ID de document prend du temps. Si les requêtes de plage ou les agrégations ne sont pas nécessaires, modifiez le type de champ en keyword. |
|
Correspondance floue |
Les requêtes wildcard, regex ou fuzzy analysent la liste des termes de l'index inversé et collectent les ID de document correspondants, consommant ainsi des ressources substantielles. Effectuez des tests de charge pour déterminer un volume de requête approprié. |
|
Quelques requêtes ou écritures lentes individuelles |
Les fluctuations globales du QPS peuvent être mineures. Pour enquêter, accédez à la page Journaux de requête et cliquez sur Search Slow Log. |
|
Un nombre excessif d'index ou de shards dans le cluster |
Trop d'index ou de shards peuvent entraîner une utilisation élevée du CPU, de HeapMemory ou de Load_1m, dégradant ainsi les performances globales des requêtes. |
|
Opérations de fusion |
Les opérations de fusion sont gourmandes en CPU et provoquent une chute brutale du nombre de segments. Surveillez le nombre de segments sur la page Overview pour chaque nœud dans la console Kibana. |
|
Opérations de garbage collection (GC) |
Les opérations GC, en particulier le full GC, libèrent de la mémoire mais consomment du CPU, provoquant des pics d'utilisation du CPU et ralentissant les requêtes. |
|
Tâches planifiées |
Les tâches planifiées, telles que les sauvegardes de données, peuvent consommer des ressources d'E/S importantes, affectant la vitesse des requêtes. |
Utilisation mémoire Fielddata du cluster (o)
Description
Mémoire heap utilisée par Fielddata dans le cluster. Une utilisation excessive de Fielddata peut déclencher un disjoncteur 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 de tri ou d'agrégation fréquentes 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
Fielddatadans le cache.Un nombre excessif d'index ou de shards augmente la charge de gestion, entraînant une utilisation élevée du CPU, de
HeapMemoryou deLoad_1m.
TPS d'écriture groupée
Description
Nombre de requêtes groupées 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é.
IndexSearchQPS (compteur/s)
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 comme 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é.
Un pic soudain d'IndexSearchQPS peut indiquer qu'un index provoque une utilisation élevée du CPU, de la mémoire heap ou de Load_1m, affectant la stabilité du cluster. Envisagez d'optimiser l'index.
IndexSearchDelayMax (ms)
Délai maximal de requête sur un index, en millisecondes.
Utilisation CPU du nœud (%)
Description de la métrique
Utilisation du CPU pour chaque nœud. Une utilisation élevée, surtout 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 :
|
Cause |
Description |
|
QPS |
Pics soudains ou grandes fluctuations du trafic Query QPS ou write QPS. |
|
Requêtes ou écritures lentes |
Les fluctuations du QPS peuvent être mineures. Pour enquêter, accédez à la page LogSearch et cliquez sur Search Slow Log. |
|
Index ou shards excessifs |
Trop d'index ou de shards augmentent la charge de gestion, entraînant une utilisation élevée du CPU, de HeapMemory ou de Load_1m. |
|
Opérations de fusion du cluster |
Les opérations de fusion consomment du CPU et provoquent une chute brutale du nombre de segments. Vérifiez le nombre de segments sur la page Overview du nœud dans la console Kibana. |
|
Opérations GC |
Les opérations GC, en particulier le full GC, libèrent de la mémoire mais sont gourmandes en CPU, provoquant des pics d'utilisation du CPU. |
|
Tâches planifiées |
L'exécution de tâches planifiées, telles qu'une sauvegarde de données ou d'autres travaux personnalisés, peut être gourmande en ressources. |
L'utilisation du CPU du nœud inclut la consommation de ressources des processus au niveau du système et des tâches Elasticsearch.
Utilisation du disque du nœud (%)
Utilisation du disque pour chaque nœud. Maintenez l'utilisation du disque en dessous de 75 % et ne dépassez pas 85 %. Le dépassement de ces seuils peut affecter les services du cluster.
|
Utilisation du disque |
Description |
|
>85 % |
Le cluster empêche l'allocation de nouveaux shards au nœud. |
|
>90 % |
Le cluster tente de déplacer les shards du nœud vers d'autres nœuds de données présentant une utilisation du disque plus faible. |
|
>95 % |
Elasticsearch applique le paramètre |
Configurez des alertes de surveillance pour cette métrique. Si elles se déclenchent, augmentez rapidement la capacité des disques et des nœuds ou effacez les données d'index pour éviter les interruptions.
L'utilisation du disque du nœud inclut les ressources utilisées par les processus au niveau du système et les tâches Elasticsearch.
Utilisation de la mémoire heap du nœud (service ES) (%)
Description
Utilisation de la mémoire heap pour chaque nœud. Une utilisation élevée ou des objets volumineux en mémoire peuvent affecter les performances et déclencher des opérations GC.
Causes de valeurs anormales
Un pic soudain ou une fluctuation importante indique souvent une anomalie de service. Causes courantes :
|
Cause |
Description |
|
QPS |
Pics soudains ou grandes fluctuations du Query QPS ou du write QPS. |
|
Quelques requêtes lentes |
Les fluctuations du QPS peuvent être mineures. Pour enquêter, analysez le Search Slow Log sur la page LogSearch. |
|
Un grand nombre de requêtes d'écriture lentes |
Le QPS présente des fluctuations importantes. Pour enquêter, analysez le Indexing Slow Log sur la page LogSearch. |
|
Le cluster comporte trop d'index ou un nombre total élevé de shards |
Trop d'index ou de shards augmentent la charge de gestion, entraînant une utilisation élevée du CPU, de la mémoire heap ou de Load_1m. |
|
Opération de fusion |
Les opérations de fusion sont gourmandes en CPU et provoquent une chute brutale du nombre de segments. Vérifiez la page Overview du nœud dans la console Kibana. |
|
Opération GC |
Une opération GC, telle qu'un Full GC, libère de la mémoire mais consomme des ressources CPU. Cela peut provoquer une chute brutale de l'utilisation de la mémoire heap. |
|
Tâche planifiée |
Par exemple, une sauvegarde de données ou une autre tâche personnalisée. |
Charge_1m du nœud
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.
|
Charge_1m du nœud |
Description |
|
<1 |
Aucun processus n'attend des ressources. |
|
=1 |
Le système est pleinement utilisé, sans capacité pour des processus supplémentaires. |
|
>1 |
Les processus sont mis en file d'attente, en attente de ressources. |
La métrique Node Workload Within One Minute inclut la consommation de ressources des processus au niveau du système et des tâches Elasticsearch.
Des fluctuations de la métrique Node Workload Within One Minute sont attendues. Pour une analyse plus précise, concentrez-vous sur la métrique Node CPU usage.
Causes d'anomalies
Une valeur dépassant le 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 %.
Un pic soudain ou une augmentation significative du Query QPS ou du write QPS.
-
Requêtes lentes coûteuses.
Utilisez la page Requête de journal pour analyser ces journaux.
La métrique Node Load_1m inclut la consommation de ressources des processus au niveau du système et des tâches Elasticsearch.
Utilisation mémoire totale du nœud (%)
Utilisation de la mémoire système pour le nœud.
Pourcentage d'attente E/S CPU du nœud (%)
Pourcentage de temps pendant lequel le CPU du nœud attend des opérations d'E/S.
Paquets entrants du nœud (compteur)
Nombre de paquets réseau entrants pour chaque nœud. Cycle de surveillance : 1 minute.
Paquets réseau sortants du nœud (compteur)
Nombre de paquets envoyés depuis chaque nœud par minute.
Bande passante entrante du nœud (Kio/s)
Débit des données entrantes pour chaque nœud. Cycle de surveillance : 1 minute. Unité : Kio/s.
Bande passante réseau_sortante du nœud (Kio/s)
Bande passante réseau sortante pour chaque nœud, en Kio/s. Mise à jour toutes les minutes.
Connexions TCP du nœud
Description
Nombre de connexions TCP établies des clients vers chaque nœud.
Causes d'anomalies
Un pic se produit souvent lorsque les clients ne libèrent pas rapidement les connexions TCP. Configurez des politiques côté client pour libérer les connexions inactives.
IOUtil (%)
Description
Utilisation des E/S pour chaque nœud.
Causes d'anomalies
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.
Taux de retransmission réseau du nœud (%)
Pourcentage de paquets réseau retransmis par le nœud.
Bande passante réseau du nœud (Kio/s)
Somme de bande passante réseau_Entrée du nœud et bande passante réseau_Sortie du nœud.
Utilisation de la bande passante réseau du nœud (%)
Utilisation de la bande passante réseau du nœud (%) = (Bande passante réseau_Entrée du nœud (Kio/s) + Bande passante réseau_Sortie du nœud (Kio/s)) / Bande passante réseau de base du nœud (Kio/s).
Paquets réseau du nœud (compteur)
Somme de paquet_réseau_sortant du nœud et paquet_réseau_entrant du nœud.
Utilisation des paquets réseau du nœud (%)
Utilisation des paquets réseau du nœud (%) = (paquet_réseau_sortant du nœud (PPS) + paquet_réseau_entrant du nœud (PPS)) / nombre maximal de paquets réseau par seconde (PPS).
Bande passante disque lecture (Mio/s)
Données lues depuis chaque nœud par seconde.
Bande passante disque_écriture (Mio/s)
Bande passante d'écriture pour chaque nœud.
IOPS de lecture disque
Requêtes de lecture terminées par seconde sur chaque nœud.
IOPS d'écriture disque
Requêtes d'écriture terminées par seconde par chaque nœud.
Longueur moyenne de la file d'attente des requêtes
Longueur moyenne de la file d'attente des requêtes.
Bande passante disque (Mio/s)
Bande passante disque (Mio/s) = bande passante disque_lecture (Mio/s) + bande passante disque_écriture (Mio/s).
Utilisation de la bande passante du disque cloud (%)
Utilisation de la bande passante du disque cloud (%) = (Bande passante disque_Lecture (Mo/s) + Bande passante disque_Écriture (Mo/s)) / Débit d'un seul disque (Mo/s).
Utilisation de la bande passante disque_nœud (%)
Calculé comme (bande passante disque_lecture (Mio/s) + bande passante disque_écriture (Mio/s)) / bande passante de base du disque (Gbit/s). Convertissez toutes les valeurs dans les mêmes unités.
IOPS disque (compteur)
IOPS disque (compteur) = IOPS de lecture disque (compteur) + IOPS d'écriture disque (compteur).
Utilisation des IOPS disque (Cloud) (%)
Utilisation des IOPS disque_disque (%) = (IOPS disque_Lecture (compteur) + IOPS disque_Écriture (compteur)) / Capacité IOPS d'un seul disque.
Utilisation des IOPS disque_nœud (%)
utilisation des IOPS disque_nœud (%) = (IOPS disque_lecture (compteur) + IOPS disque_écriture (compteur)) / IOPS de base du disque cloud
Utilisation de l'ancienne génération du nœud (o)
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 des objets volumineux peuvent affecter les performances et déclencher un GC, entraînant potentiellement des pauses prolongées ou un full GC.
Causes d'anomalies de métrique
Un pic soudain ou une fluctuation importante indique souvent une exception de service. Causes courantes :
|
Cause |
Description |
|
QPS |
Pics soudains ou fluctuations importantes du Query QPS ou du write QPS. |
|
Requêtes d'agrégation ou de script |
Les requêtes d'agrégation sont gourmandes en ressources. Utilisez-les avec prudence. |
|
Requêtes term sur des champs numériques |
L'exécution de nombreuses requêtes term sur des champs numériques (byte, short, integer, long) peut être lente en raison de la construction longue du bitset. Si les requêtes de plage ou les agrégations ne sont pas nécessaires, modifiez le type de champ en keyword. |
|
Correspondance floue |
Les requêtes wildcard, regex ou fuzzy analysent la liste des termes de l'index inversé et collectent les ID de document correspondants, consommant ainsi des ressources substantielles. Effectuez des tests de charge pour déterminer un volume de requête approprié. |
|
Quelques requêtes lentes |
Les fluctuations du QPS peuvent être mineures. Pour enquêter, accédez à la page journal de requête et cliquez sur Search Slow Log. |
|
Quelques requêtes d'écriture lentes |
Les fluctuations du QPS peuvent être mineures. Pour enquêter, accédez à la page journal de requête et cliquez sur Indexing Slow Log. |
|
Un nombre excessif d'index ou de shards dans le cluster |
Trop d'index ou de shards peuvent entraîner une utilisation élevée du CPU, de la mémoire heap ou de Load_1m. |
|
Opérations de fusion |
Les opérations de fusion sont gourmandes en CPU et provoquent une chute brutale du nombre de segments. Surveillez cela sur la page Overview pour chaque nœud dans la console Kibana. |
|
Opérations GC |
Une opération GC, telle qu'un full GC, libère de la mémoire mais consomme des ressources CPU. Cela peut provoquer une chute soudaine de l'utilisation de la mémoire heap. |
|
Tâches planifiées |
Sauvegarde de données ou autres tâches personnalisées. |
Nombre de Full GC
Des événements Full GC fréquents peuvent dégrader les performances du cluster.
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.
Nombre de GC ancien du nœud
Description
Compte les événements GC de l'ancienne génération sur chaque nœud. Une utilisation élevée ou des objets volumineux peuvent déclencher un GC automatique, entraînant potentiellement des pauses prolongées ou un full GC.
La métrique Full GC pour la surveillance de base provient des journaux, tandis que les métriques de mémoire dans la surveillance avancée sont collectées par le moteur ES. Pour tenir compte de ces différentes sources de données, évaluez les performances du cluster en combinant toutes les métriques disponibles.
Causes courantes
Durée du GC ancien du nœud (ms)
Métrique
Durée moyenne du GC de l'ancienne génération sur chaque nœud. Une utilisation élevée de l'ancienne génération ou des objets volumineux peuvent déclencher un GC, entraînant des durées plus longues ou un full GC.
Causes de valeurs anormales
Voir JVMMemoryOldUsedBytes.
Threads actifs du pool de threads de recherche (compteur)
Threads actifs dans le pool de threads de requête du cluster.
Requêtes rejetées dans le pool de threads de requête (compteur)
Cette métrique obsolète compte les requêtes rejetées dans le pool de threads de requête du cluster. Utilisez plutôt SearchThreadpoolRejectedV2.
Requêtes de requête rejetées
Requêtes rejetées dans le pool de threads de requête du cluster. Lorsque le pool de threads est plein, les nouvelles requêtes de requête sont rejetées.
Nombre d'exceptions
Description de la métrique
Nombre total d'entrées de journal de niveau warning dans les journaux du cluster sur une période d'une minute.
Causes de valeurs anormales
Une valeur autre que 0 indique une exception de service. Causes courantes :
Requêtes de requête anormales.
Requêtes d'écriture anormales.
Erreurs dans les tâches Elasticsearch.
Opérations de garbage collection.
Dépannage
Accédez à la page Journaux de requête et cliquez sur Cluster Log. Sur la page Cluster Log, examinez les détails des exceptions pour trouver la cause racine.
Si le Cluster Log contient des enregistrements GC, ces enregistrements sont également inclus dans la métrique NodeStatsExceptionLogCount.