Red Hat Summit7.3. Affichage des tableaux de bord de cluster
Les tableaux de bord Logging/Elasticsearch et Openshift Logging dans OpenShift Cluster Manager contiennent des détails approfondis sur votre instance Elasticsearch et les nœuds Elasticsearch individuels que vous pouvez utiliser pour prévenir et diagnostiquer les problèmes.
Le tableau de bord OpenShift Logging contient des graphiques qui montrent des détails sur votre instance Elasticsearch à un niveau de cluster, y compris les ressources de cluster, la collecte des ordures, les fragments dans le cluster et les statistiques Fluentd.
Le tableau de bord Logging/Elasticsearch Nodes contient des graphiques qui montrent des détails sur votre instance Elasticsearch, beaucoup au niveau des nœuds, y compris des détails sur l’indexation, les éclats, les ressources, etc.
7.3.1. Accéder aux tableaux de bord Elasticsearch et OpenShift Logging
Dans OpenShift Cluster Manager, vous pouvez consulter les tableaux de bord Logging/Elasticsearch et OpenShift Logging.
Procédure
Lancer les tableaux de bord:
-
Dans la console OpenShift Dedicated Red Hat Hybrid Cloud Console, cliquez sur Observer
Tableau de bord. Dans la page Tableau de bord, sélectionnez Logging/Elasticsearch Nodes ou OpenShift Logging dans le menu Tableau de bord.
Dans le tableau de bord Logging/Elasticsearch Nodes, vous pouvez sélectionner le nœud Elasticsearch que vous souhaitez afficher et définir la résolution des données.
Le tableau de bord approprié est affiché, montrant plusieurs graphiques de données.
- Facultatif: Sélectionnez une plage de temps différente pour afficher ou rafraîchir le taux des données dans les menus Time Range et Refresh Interval.
Informations sur les tableaux de bord, voir À propos du tableau de bord OpenShift Logging et About the Logging/Elastisearch Nodes dashboard.
7.3.2. À propos du tableau de bord OpenShift Logging
Le tableau de bord OpenShift Logging contient des graphiques qui montrent des détails sur votre instance Elasticsearch à un niveau de cluster que vous pouvez utiliser pour diagnostiquer et anticiper les problèmes.
| De la métrique | Description |
|---|---|
| État du cluster élastique | Le statut actuel Elasticsearch:
|
| Les nœuds élastiques | Le nombre total de nœuds Elasticsearch dans l’instance Elasticsearch. |
| Des Shards élastiques | Le nombre total de fragments Elasticsearch dans l’instance Elasticsearch. |
| Documents élastiques | Le nombre total de documents Elasticsearch dans l’instance Elasticsearch. |
| La taille totale de l’indice sur le disque | L’espace disque total utilisé pour les indices Elasticsearch. |
| Élastique en attente des tâches | Le nombre total de changements Elasticsearch qui n’ont pas été achevés, tels que la création d’indices, la cartographie de l’index, l’allocation de fragments ou l’échec du fragment. |
| Elastique JVM GC temps | Le temps que le JVM a passé à exécuter les opérations de collecte des ordures Elasticsearch dans le cluster. |
| Elastique JVM GC Rate | Le nombre total de fois que JVM a exécuté des activités d’ordures par seconde. |
| Élastique Query/Fetch Latency Sum |
La latence de recherche prend généralement moins de temps que la latence de requête. Lorsque la latence augmente constamment, elle peut indiquer des disques lents, l’enrichissement des données ou de grandes demandes avec trop de résultats. |
| Le taux de requête élastique | Le total des requêtes exécutées contre l’instance Elasticsearch par seconde pour chaque nœud Elasticsearch. |
| CPU | La quantité de CPU utilisée par Elasticsearch, Fluentd et Kibana, affichée pour chaque composant. |
| Élastique JVM Heap Utilisé | La quantité de mémoire JVM utilisée. Dans un cluster sain, le graphique montre des gouttes régulières lorsque la mémoire est libérée par la collecte des ordures JVM. |
| Elasticsearch Disk Usage | L’espace disque total utilisé par l’instance Elasticsearch pour chaque nœud Elasticsearch. |
| Descripteurs de fichiers utilisés | Le nombre total de descripteurs de fichiers utilisés par Elasticsearch, Fluentd et Kibana. |
| Comptage d’émission Fluentd | Le nombre total de messages Fluentd par seconde pour la sortie par défaut Fluentd, et le nombre de réessayer pour la sortie par défaut. |
| Fluentd Buffer Utilisation | Le pourcentage du tampon Fluentd qui est utilisé pour les morceaux. Le tampon complet pourrait indiquer que Fluentd n’est pas en mesure de traiter le nombre de logs reçus. |
| Élastique rx octets | Le nombre total d’octets qu’Elasticsearch a reçu de FluentD, des nœuds Elasticsearch et d’autres sources. |
| Indice élastique Taux d’échec | Le nombre total de fois par seconde qu’un indice Elasticsearch échoue. Le taux élevé peut indiquer un problème d’indexation. |
| Débit d’erreur de sortie Fluentd | Le nombre total de fois par seconde que FluentD n’est pas capable de produire des journaux. |
7.3.3. Graphiques sur le tableau de bord des nœuds Logging/Elasticsearch
Le tableau de bord Logging/Elasticsearch Nodes contient des graphiques qui montrent des détails sur votre instance Elasticsearch, beaucoup au niveau des nœuds, pour d’autres diagnostics.
- Elasticsearch statut
- Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur l’état de votre instance Elasticsearch.
| De la métrique | Description |
|---|---|
| État du cluster | L’état de santé des grappes au cours de la période sélectionnée, en utilisant les statuts vert, jaune et rouge Elasticsearch:
|
| Les nœuds de cluster | Le nombre total de nœuds Elasticsearch dans le cluster. |
| Cluster des nœuds de données | Le nombre de nœuds de données Elasticsearch dans le cluster. |
| Groupe de tâches en attente | Le nombre de changements d’état de cluster qui ne sont pas terminés et qui attendent dans une file d’attente de cluster, par exemple, la création d’index, la suppression d’index ou l’allocation shard. La tendance croissante indique que le cluster n’est pas en mesure de suivre les changements. |
- Elasticsearch cluster index shard status
- Chaque indice Elasticsearch est un groupe logique d’un ou de plusieurs fragments, qui sont des unités de base de données persistantes. Il existe deux types de fragments d’index: les fragments primaires et les répliques. Lorsqu’un document est indexé dans un index, il est stocké dans l’un de ses fragments primaires et copié dans chaque réplique de ce fragment. Le nombre de fragments primaires est spécifié lorsque l’index est créé, et le nombre ne peut pas changer pendant la durée de vie de l’index. Il est possible de modifier le nombre de répliques à tout moment.
Le fragment d’index peut être dans plusieurs états en fonction de sa phase de cycle de vie ou des événements se produisant dans le cluster. Lorsque le shard est capable d’effectuer des requêtes de recherche et d’indexation, le shard est actif. Dans le cas où le shard ne peut pas exécuter ces requêtes, le shard n’est pas actif. Il se peut qu’un fragment ne soit pas actif si le fragment est initialisant, réaffectant, non affecté, et ainsi de suite.
Les fragments d’index se composent d’un certain nombre de blocs internes plus petits, appelés segments d’index, qui sont des représentations physiques des données. Le segment d’index est un indice de Lucene relativement petit et immuable qui est créé lorsque Lucene commet des données nouvellement indexées. Lucene, une bibliothèque de recherche utilisée par Elasticsearch, fusionne les segments d’index en segments plus grands en arrière-plan pour maintenir le nombre total de segments bas. Lorsque le processus de fusion des segments est plus lent que la vitesse à laquelle de nouveaux segments sont créés, cela pourrait indiquer un problème.
Lorsque Lucene effectue des opérations de données, telles qu’une opération de recherche, Lucene effectue l’opération contre les segments d’index dans l’index pertinent. À cette fin, chaque segment contient des structures de données spécifiques qui sont chargées dans la mémoire et cartographiées. La cartographie des index peut avoir un impact significatif sur la mémoire utilisée par les structures de données segmentées.
Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur les fragments d’index Elasticsearch.
| De la métrique | Description |
|---|---|
| Fragments actifs | Le nombre de fragments primaires actifs et le nombre total de fragments, y compris les répliques, dans le cluster. Lorsque le nombre de fragments augmente, les performances des clusters peuvent commencer à se dégrader. |
| Les fragments d’initialisation du cluster | Le nombre de fragments non actifs dans le cluster. Le fragment non actif est celui qui initialise, est réaffecté à un nœud différent, ou qui n’est pas affecté. En général, un cluster a des fragments non actifs pendant de courtes périodes. De plus en plus de fragments non actifs sur des périodes plus longues pourraient indiquer un problème. |
| A) Déplacement des fragments de clusters | Le nombre de fragments qu’Elasticsearch déménage vers un nouveau nœud. Elasticsearch déplace les nœuds pour plusieurs raisons, telles que l’utilisation de mémoire élevée sur un nœud ou après l’ajout d’un nouveau nœud au cluster. |
| Fragments non attribués | Le nombre de fragments non attribués. Les fragments d’Elasticsearch peuvent être non attribués pour des raisons telles qu’un nouvel index est ajouté ou l’échec d’un nœud. |
- Elasticsearch métriques des nœuds
- Chaque nœud Elasticsearch a une quantité limitée de ressources qui peuvent être utilisées pour traiter les tâches. Lorsque toutes les ressources sont utilisées et qu’Elasticsearch tente d’effectuer une nouvelle tâche, Elasticsearch met les tâches dans une file d’attente jusqu’à ce que certaines ressources deviennent disponibles.
Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur l’utilisation des ressources pour un nœud sélectionné et le nombre de tâches en attente dans la file d’attente Elasticsearch.
| De la métrique | Description |
|---|---|
| Les tâches de threadpool | Le nombre de tâches d’attente dans les files d’attente individuelles, affichée par type de tâche. L’accumulation à long terme de tâches dans n’importe quelle file d’attente pourrait indiquer des pénuries de ressources de nœuds ou un autre problème. |
| L’utilisation du CPU | La quantité de CPU utilisée par le nœud Elasticsearch sélectionné en pourcentage du CPU total alloué au conteneur hôte. |
| L’utilisation de la mémoire | La quantité de mémoire utilisée par le nœud Elasticsearch sélectionné. |
| L’utilisation du disque | L’espace disque total utilisé pour les données d’index et les métadonnées sur le nœud Elasticsearch sélectionné. |
| Le taux d’indexation des documents | Le taux que les documents sont indexés sur le nœud Elasticsearch sélectionné. |
| Latence d’indexation | Le temps nécessaire pour indexer les documents sur le nœud Elasticsearch sélectionné. La latence d’indexation peut être affectée par de nombreux facteurs, tels que la mémoire JVM Heap et la charge globale. La latence croissante indique une pénurie de ressources dans le cas. |
| Le taux de recherche | Le nombre de requêtes de recherche s’exécute sur le nœud Elasticsearch sélectionné. |
| Latence de recherche | Le temps nécessaire pour remplir les demandes de recherche sur le nœud Elasticsearch sélectionné. La latence de recherche peut être affectée par de nombreux facteurs. La latence croissante indique une pénurie de ressources dans le cas. |
| Comptage des documents (avec répliques) | Le nombre de documents Elasticsearch stockés sur le nœud Elasticsearch sélectionné, y compris les documents stockés dans les fragments primaires et les fragments de réplique qui sont alloués sur le nœud. |
| Le taux de suppression des documents | Le nombre de documents Elasticsearch supprimés de l’un des fragments d’index qui sont attribués au nœud Elasticsearch sélectionné. |
| Le taux de fusion des documents | Le nombre de documents Elasticsearch étant fusionnés dans l’un des fragments d’index qui sont attribués au nœud Elasticsearch sélectionné. |
- Données de terrain des nœuds Elasticsearch
- FieldData est une structure de données Elasticsearch qui contient des listes de termes dans un index et est conservée dans le JVM Heap. Etant donné que la construction de données de terrain est une opération coûteuse, Elasticsearch met en cache les structures de données de terrain. Elasticsearch peut expulser un cache de données de champ lorsque le segment d’index sous-jacent est supprimé ou fusionné, ou s’il n’y a pas assez de mémoire JVM HEAP pour tous les caches de données de terrain.
Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur les données de terrain Elasticsearch.
| De la métrique | Description |
|---|---|
| FieldData taille de la mémoire | La quantité de JVM Heap utilisée pour le cache de données de terrain sur le nœud Elasticsearch sélectionné. |
| Expulsions de données de terrain | Le nombre de structures de données de terrain qui ont été supprimées du nœud Elasticsearch sélectionné. |
- Elasticsearch Node Query cache
- Dans le cas où les données stockées dans l’index ne changent pas, les résultats des requêtes de recherche sont mis en cache dans un cache de requête de niveau nœud pour réutilisation par Elasticsearch.
Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur le cache de requête de nœud Elasticsearch.
| De la métrique | Description |
|---|---|
| La taille du cache de requête | La quantité totale de mémoire utilisée pour le cache de requête pour tous les fragments alloués au nœud Elasticsearch sélectionné. |
| Expulsions de cache de requête | Le nombre d’expulsions de cache de requête sur le nœud Elasticsearch sélectionné. |
| Cliquez sur le cache de requête | Le nombre de cache de requête frappe sur le nœud Elasticsearch sélectionné. |
| Le cache de requête manque | Le nombre de cache de requête manque sur le nœud Elasticsearch sélectionné. |
- Elasticsearch index d’étroitesse
- Lors de l’indexation des documents, Elasticsearch stocke les documents dans des segments d’index, qui sont des représentations physiques des données. Dans le même temps, Elasticsearch fusionne périodiquement des segments plus petits dans un segment plus large afin d’optimiser l’utilisation des ressources. Lorsque l’indexation est plus rapide alors la possibilité de fusionner des segments, le processus de fusion ne se termine pas assez rapidement, ce qui peut entraîner des problèmes de recherche et de performance. Afin d’éviter cette situation, Elasticsearch accélère l’indexation, généralement en réduisant le nombre de threads alloués à l’indexation en un seul thread.
Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants au sujet de l’accélération de l’index Elasticsearch.
| De la métrique | Description |
|---|---|
| Indexation de l’étroitesse | Le temps qu’Elasticsearch a réduit les opérations d’indexation sur le nœud Elasticsearch sélectionné. |
| Fusion de l’étroitesse | Le temps pendant lequel Elasticsearch a été en train de freiner les opérations de fusion du segment sur le nœud Elasticsearch sélectionné. |
- Les statistiques de Node JVM Heap
- Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur les opérations JVM Heap.
| De la métrique | Description |
|---|---|
| Le tas utilisé | Le montant de l’espace JVM Heap alloué qui est utilisé sur le nœud Elasticsearch sélectionné. |
| Compte de GC | Le nombre d’opérations de collecte des ordures qui ont été effectuées sur le nœud Elasticsearch sélectionné, par collecte des ordures âgées et jeunes. |
| Heure du GC | Le temps que le JVM a consacré à l’exécution des opérations de collecte des ordures sur le nœud Elasticsearch sélectionné, par la collecte des ordures âgées et jeunes. |
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}