1.2. À quoi s’attendre des notifications de cluster
En tant qu’administrateur de cluster, vous devez savoir quand et pourquoi les notifications de cluster sont envoyées, ainsi que leurs types et niveaux de gravité, afin de comprendre efficacement les besoins de santé et d’administration de votre cluster.
1.2.1. La politique de notification par groupe Copier lienLien copié sur presse-papiers!
Les notifications de cluster sont conçues pour vous tenir informé de la santé de votre cluster et des événements à fort impact qui l’affectent.
La plupart des notifications de cluster sont générées et envoyées automatiquement pour vous assurer que vous êtes immédiatement informé des problèmes ou des changements importants à l’état de votre cluster.
Dans certaines situations, Red Hat Site Reliability Engineering (SRE) crée et envoie des notifications de cluster pour fournir un contexte supplémentaire et des conseils pour un problème complexe.
Les notifications de cluster ne sont pas envoyées pour les événements à faible impact, les mises à jour de sécurité à faible risque, les opérations et la maintenance de routine, ou les problèmes transitoires mineurs qui sont rapidement résolus par SRE.
Les services Red Hat envoient automatiquement des notifications lorsque:
- Les contrôles de surveillance de la santé ou de vérification de l’environnement à distance détectent un problème dans votre cluster, par exemple lorsqu’un nœud de travail a peu d’espace disque.
- Des événements importants du cycle de vie des clusters se produisent, par exemple, lorsque la maintenance ou les mises à niveau programmées commencent, ou que les opérations de cluster sont touchées par un événement, mais ne nécessitent pas d’intervention du client.
- D’importants changements de gestion des clusters se produisent, par exemple, lorsque la propriété de clusters ou le contrôle administratif est transféré d’un utilisateur à un autre.
- L’abonnement à votre cluster est modifié ou mis à jour, par exemple lorsque Red Hat met à jour les conditions d’abonnement ou les fonctionnalités disponibles pour votre cluster.
La SRE crée et envoie des notifications lorsque:
- L’incident entraîne une dégradation ou une panne qui affecte la disponibilité ou les performances de votre cluster, par exemple, votre fournisseur de cloud a une panne régionale. La SRE envoie des notifications ultérieures pour vous informer de l’état d’avancement de la résolution des incidents et lorsque l’incident est résolu.
- Des failles de sécurité, des failles de sécurité ou des activités inhabituelles sont détectées sur votre cluster.
- Le Red Hat détecte que les changements que vous avez apportés sont en train de créer ou peuvent entraîner une instabilité des clusters.
- Le Red Hat détecte que vos charges de travail causent une dégradation des performances ou une instabilité dans votre cluster.
1.2.2. Les niveaux de gravité de la notification par groupe Copier lienLien copié sur presse-papiers!
Chaque notification de cluster a un niveau de gravité associé pour vous aider à identifier les notifications ayant le plus d’impact sur votre entreprise. Dans l’onglet Historique des clusters de votre cluster, vous pouvez filtrer les notifications en fonction de ces niveaux de gravité dans la console de cloud hybride Red Hat.
Le Red Hat utilise les niveaux de sévérité suivants pour les notifications en grappe, de la plupart au moins sévère:
- Critique
- Des mesures immédiates sont nécessaires. « une ou plusieurs fonctions clés d’un service ou d’un cluster ne fonctionnent pas, ou cesseront de fonctionner bientôt. Il est suffisamment important d’alerter le personnel sur appel et d’interrompre les flux de travail réguliers.
- A) Majeur
- L’action immédiate est fortement recommandée. « une ou plusieurs fonctions clés du cluster cesseront bientôt de fonctionner. Il se peut qu’une question majeure puisse mener à une question critique si elle n’est pas traitée en temps opportun.
- Avertissement
- Il faut agir dès que possible. B) Une ou plusieurs fonctions clés du cluster ne fonctionnent pas de manière optimale et peuvent se dégrader davantage, mais ne constituent pas un danger immédiat pour le fonctionnement du groupe.
- Infos
- Aucune action nécessaire. Cette gravité ne décrit pas les problèmes qui doivent être résolus, seulement des informations importantes sur le cycle de vie significatif ou important, le service ou les événements en grappe.
- Débogage
- Aucune action nécessaire. Les notifications de débogage fournissent des informations de bas niveau sur le cycle de vie, le service ou les événements de cluster moins importants pour aider à déboger un comportement inattendu.
1.2.3. Les types de notification de cluster Copier lienLien copié sur presse-papiers!
Chaque notification de cluster a un type de notification associé pour vous aider à identifier les notifications qui sont pertinentes pour votre rôle et vos responsabilités. Dans l’onglet Historique des clusters de votre cluster, vous pouvez filtrer les notifications de cluster en fonction de ces types dans la console de cloud hybride Red Hat.
Le Red Hat utilise les types de notification suivants pour indiquer la pertinence de la notification.
- Gestion des capacités
- Les notifications d’événements liés à la mise à jour, à la création ou à la suppression de pools de nœuds, de pools de machines, de répliques de calcul ou de quotas (équilibrage de charge, stockage, etc.).
- Accès au cluster
- Les notifications pour les événements liés à l’ajout ou à la suppression de groupes, de rôles ou de fournisseurs d’identité, par exemple, lorsque SRE ne peut pas accéder à votre cluster parce que les informations d’identification STS ont expiré, lorsqu’il y a un problème de configuration avec vos rôles AWS, ou lorsque vous ajoutez ou supprimez des fournisseurs d’identité.
- Modules complémentaires
- Les notifications d’événements liés à la gestion d’add-on ou à la maintenance des mises à niveau pour les add-ons, par exemple, lorsqu’un module est installé, mis à niveau ou supprimé, ou ne peuvent pas être installés en raison d’exigences non satisfaites.
- Configuration du cluster
- Les notifications pour les événements d’accord de cluster, la surveillance de la charge de travail et les vérifications en vol.
- Cycle de vie des clusters
- Les notifications pour la création, la suppression et l’enregistrement de ressources de cluster ou de cluster, ou la modification de l’état du cluster ou de la ressource (par exemple, prêt ou hibernation).
- La mise en réseau de clusters
- Les notifications liées au réseau de clusters, y compris le proxy HTTP/S, le routeur et l’état d’entrée.
- La propriété des clusters
- Les notifications liées au transfert de propriété de cluster d’un utilisateur à un autre.
- La mise à l’échelle des clusters
- Les notifications liées à la mise à jour, à la création ou à la suppression de pools de nœuds, de pools de machines, de répliques de calcul ou de quota.
- La sécurité des clusters
- Les événements liés à la sécurité des clusters, par exemple, un nombre accru de tentatives d’accès manquées, de mises à jour de paquets de confiance ou de mises à jour logicielles ayant un impact sur la sécurité.
- Abonnement au cluster
- Expiration de cluster, notifications de cluster d’essai, ou passage de Free to Pay.
- Les mises à jour des clusters
- Ce qui concerne les mises à niveau, telles que la maintenance ou l’activation des mises à niveau.
- Assistance à la clientèle
- Des mises à jour sur l’état de l’affaire de soutien.
- La notification générale
- Le type de notification par défaut. Ceci n’est utilisé que pour les notifications qui n’ont pas une catégorie plus spécifique.