Red Hat Summit1.2. Comprendre la pile de surveillance
La pile de surveillance comprend les composants suivants:
Composants de surveillance de plate-forme par défaut. Des composants de surveillance de plate-forme sont installés dans le projet de surveillance openshift par défaut lors d’un Red Hat OpenShift Service sur l’installation AWS. Les ingénieurs de fiabilité du site Red Hat (SRE) utilisent ces composants pour surveiller les composants principaux des clusters, y compris les services Kubernetes. Cela inclut des métriques critiques, telles que CPU et mémoire, collectées à partir de toutes les charges de travail dans chaque espace de noms.
Ces composants sont illustrés dans la section Installé par défaut dans le diagramme suivant.
- Composants pour le suivi des projets définis par l’utilisateur. Dans l’installation AWS, un ensemble de composants de surveillance de projet définis par l’utilisateur sont installés par défaut dans le projet de surveillance de la charge de travail ouverte de l’utilisateur lors d’un service OpenShift Red Hat. Ces composants peuvent être utilisés pour surveiller les services et les pods dans les projets définis par l’utilisateur. Ces composants sont illustrés dans la section Utilisateur dans le diagramme suivant.
1.2.1. Cibles de surveillance par défaut
Ce qui suit sont des exemples de cibles surveillées par Red Hat Site Reliability Engineers (SRE) dans votre Red Hat OpenShift Service sur AWS cluster:
- CoreDNS
- etc.
- HAProxy
- Enregistrement d’images
- Kubelets
- Kubernetes serveur API
- Gestionnaire de contrôleur Kubernetes
- Kubernetes planificateur
La liste exacte des cibles peut varier en fonction des capacités de votre cluster et des composants installés.
1.2.2. Composants pour le suivi des projets définis par l’utilisateur
Le service OpenShift Red Hat sur AWS inclut une amélioration optionnelle de la pile de surveillance qui vous permet de surveiller les services et les pods dans les projets définis par l’utilisateur. Cette fonctionnalité comprend les composants suivants:
| Composante | Description |
|---|---|
| L’opérateur Prometheus | L’opérateur Prometheus (PO) dans le projet openshift-user-workload-monitoring crée, configure et gère les instances Prometheus et Thanos Ruler dans le même projet. |
| Le Prométhée | Le Prometheus est le système de surveillance par lequel la surveillance est assurée pour les projets définis par l’utilisateur. Le Prometheus envoie des alertes à Alertmanager pour le traitement. |
| Le chef de Thanos | Le Thanos Ruler est un moteur d’évaluation de règles pour Prometheus qui est déployé en tant que processus séparé. Dans Red Hat OpenShift Service sur AWS, Thanos Ruler fournit une évaluation des règles et des alertes pour le suivi des projets définis par l’utilisateur. |
| Alertmanager | Le service Alertmanager gère les alertes reçues de Prometheus et Thanos Ruler. Alertmanager est également responsable de l’envoi d’alertes définies par l’utilisateur aux systèmes de notification externes. Le déploiement de ce service est facultatif. |
L’ensemble de ces composants sont surveillés par la pile et sont automatiquement mis à jour lorsque Red Hat OpenShift Service sur AWS est mis à jour.
1.2.3. Cibles de suivi pour les projets définis par l’utilisateur
La surveillance est activée par défaut pour Red Hat OpenShift Service sur les projets définis par l’utilisateur AWS. Il est possible de surveiller:
- Les métriques fournies par l’intermédiaire de points de terminaison de service dans les projets définis par l’utilisateur.
- Des pods s’exécutant dans des projets définis par l’utilisateur.
1.2.4. La pile de surveillance dans les clusters à haute disponibilité
Dans les clusters multi-nœuds par défaut, les composants suivants s’exécutent en mode haute disponibilité (HA) pour éviter la perte de données et l’interruption de service:
- Le Prométhée
- Alertmanager
- Le chef de Thanos
Le composant est reproduit sur deux pods, chacun fonctionnant sur un nœud séparé. Cela signifie que la pile de surveillance peut tolérer la perte d’une gousse.
- Le Prométhée en mode HA
- Les deux répliques grattent indépendamment les mêmes cibles et évaluent les mêmes règles.
- Les répliques ne communiquent pas entre elles. Les données peuvent donc différer entre les pods.
- Alertmanager en mode HA
- Les deux répliques synchronisent les états de notification et de silence les uns avec les autres. Cela garantit que chaque notification est envoyée au moins une fois.
- Lorsque les répliques ne parviennent pas à communiquer ou s’il y a un problème du côté de la réception, des notifications sont toujours envoyées, mais elles peuvent être dupliquées.
Les Prometheus, Alertmanager et Thanos Ruler sont des composants d’état. Afin d’assurer une disponibilité élevée, vous devez les configurer avec un stockage persistant.
'%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}