7.7. Création de règles d’alerte pour les projets définis par l’utilisateur
Dans OpenShift Dedicated, vous pouvez créer des règles d’alerte pour les projets définis par l’utilisateur. Ces règles d’alerte déclencheront des alertes basées sur les valeurs des métriques choisies.
Lorsque vous créez des règles d’alerte pour un projet défini par l’utilisateur, considérez les comportements clés et les limites importantes suivants lorsque vous définissez les nouvelles règles:
La règle d’alerte définie par l’utilisateur peut inclure des métriques exposées par son propre projet en plus des métriques par défaut de la surveillance de la plate-forme de base. Il n’est pas possible d’inclure des métriques d’un autre projet défini par l’utilisateur.
À titre d’exemple, une règle d’alerte pour le projet défini par l’utilisateur ns1 peut utiliser des métriques exposées par le projet ns1 en plus des métriques de plate-forme de base, telles que les métriques CPU et mémoire. Cependant, la règle ne peut pas inclure des métriques d’un projet défini par l’utilisateur ns2 différent.
- Lorsque vous créez une règle d’alerte, l’étiquette de l’espace de noms est appliquée par défaut, même si une règle avec le même nom existe dans un autre projet. Afin de créer des règles d’alerte qui ne sont pas liées à leur projet d’origine, voir « Créer des règles d’alerte croisée pour les projets définis par l’utilisateur ».
Afin de réduire la latence et de minimiser la charge sur les composants de surveillance de plate-forme de base, vous pouvez ajouter à une règle l’étiquette openshift.io/prometheus-rule-evaluation-scope: feuille-prometheus. Cette étiquette force uniquement l’instance Prometheus déployée dans le projet openshift-user-workload-monitoring à évaluer la règle d’alerte et empêche l’instance Thanos Ruler de le faire.
ImportantLorsqu’une règle d’alerte comporte cette étiquette, votre règle d’alerte ne peut utiliser que les métriques exposées par votre projet défini par l’utilisateur. Les règles d’alerte que vous créez en fonction des métriques de plate-forme par défaut peuvent ne pas déclencher d’alertes.
7.7.1. L’optimisation de l’alerte pour les projets définis par l’utilisateur Copier lienLien copié sur presse-papiers!
Lors de la création de règles d’alerte, vous pouvez optimiser l’alerte pour vos propres projets en tenant compte des recommandations suivantes:
- Minimisez le nombre de règles d’alerte que vous créez pour votre projet. Créez des règles d’alerte qui vous informent des conditions qui vous affectent. Il est plus difficile de remarquer des alertes pertinentes si vous générez de nombreuses alertes pour des conditions qui ne vous impactent pas.
- Créez des règles d’alerte pour les symptômes au lieu des causes. Créez des règles d’alerte qui vous informent des conditions quelle que soit la cause sous-jacente. La cause peut ensuite faire l’objet d’une enquête. Il vous faudra beaucoup plus de règles d’alerte si chacune se rapporte uniquement à une cause spécifique. Certaines causes sont alors susceptibles d’être manquées.
- Planifiez avant d’écrire vos règles d’alerte. Déterminez quels symptômes sont importants pour vous et quelles actions vous voulez prendre s’ils se produisent. Ensuite, construisez une règle d’alerte pour chaque symptôme.
- Fournissez une messagerie d’alerte claire. Indiquez le symptôme et les actions recommandées dans le message d’alerte.
- Incluez les niveaux de gravité dans vos règles d’alerte. La gravité d’une alerte dépend de la façon dont vous devez réagir si le symptôme rapporté se produit. À titre d’exemple, une alerte critique doit être déclenchée si un symptôme nécessite une attention immédiate de la part d’une personne ou d’une équipe d’intervention critique.
7.7.2. Création de règles d’alerte pour les projets définis par l’utilisateur Copier lienLien copié sur presse-papiers!
Il est possible de créer des règles d’alerte pour les projets définis par l’utilisateur. Ces règles d’alerte déclencheront des alertes basées sur les valeurs des métriques choisies.
Afin d’aider les utilisateurs à comprendre l’impact et la cause de l’alerte, assurez-vous que votre règle d’alerte contient un message d’alerte et une valeur de gravité.
Conditions préalables
- La surveillance des projets définis par l’utilisateur a été activée.
- Il est connecté en tant qu’administrateur de cluster ou en tant qu’utilisateur qui a le rôle de cluster monitoring-règle-edit pour le projet où vous souhaitez créer une règle d’alerte.
- L’OpenShift CLI (oc) a été installé.
Procédure
- Créez un fichier YAML pour les règles d’alerte. Dans cet exemple, il est appelé example-app-alerting-rule.yaml.
Ajoutez une configuration de règle d’alerte au fichier YAML. L’exemple suivant crée une nouvelle règle d’alerte nommée exemple-alerte. La règle d’alerte déclenche une alerte lorsque la métrique de version exposée par le service d’échantillon devient 0:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Le nom de la règle d’alerte que vous souhaitez créer.
- 2
- La durée pour laquelle la condition doit être vraie avant qu’une alerte ne soit déclenchée.
- 3
- L’expression de requête PromQL qui définit la nouvelle règle.
- 4
- La sévérité que la règle d’alerte attribue à l’alerte.
- 5
- Le message associé à l’alerte.
Appliquer le fichier de configuration au cluster:
oc apply -f example-app-alerting-rule.yaml
$ oc apply -f example-app-alerting-rule.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.7.3. Création de règles d’alerte croisée pour les projets définis par l’utilisateur Copier lienLien copié sur presse-papiers!
Il est possible de créer des règles d’alerte pour les projets définis par l’utilisateur qui ne sont pas liés à leur projet d’origine en configurant un projet dans la config map. Cela vous permet de créer des règles d’alerte génériques qui s’appliquent à plusieurs projets définis par l’utilisateur au lieu d’avoir des objets PrometheusRule individuels dans chaque projet utilisateur.
Conditions préalables
En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
NoteLorsque vous êtes un utilisateur non-administrateur, vous pouvez toujours créer des règles d’alerte croisée si vous avez le rôle de cluster monitoring-règles-édition pour le projet où vous souhaitez créer une règle d’alerte. Cependant, ce projet doit être configuré dans la carte de configuration de configuration utilisateur-workload-monitoring-config sous la propriété namespaces WithoutLabelEnforcement, qui ne peut être effectuée que par les administrateurs de clusters.
- L’objet ConfigMap existe. Cet objet est créé par défaut lorsque le cluster est créé.
- L’OpenShift CLI (oc) a été installé.
Procédure
Éditez la carte de configuration de la configuration de l’utilisateur-workload-monitoring dans le projet openshift-user-workload-monitoring:
oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Configurez des projets dans lesquels vous souhaitez créer des règles d’alerte qui ne sont pas liées à un projet spécifique:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez un ou plusieurs projets dans lesquels vous souhaitez créer des règles d’alerte croisée. Les règles Prometheus et Thanos pour la surveillance définie par l’utilisateur n’appliquent pas l’étiquette de l’espace de noms dans les objets PrometheusRule créés dans ces projets.
- Créez un fichier YAML pour les règles d’alerte. Dans cet exemple, il est appelé exemple-cross-project-alerting-rule.yaml.
Ajoutez une configuration de règle d’alerte au fichier YAML. L’exemple suivant crée une nouvelle règle d’alerte croisée appelée exemple-sécurité. La règle d’alerte s’allume lorsqu’un projet utilisateur n’applique pas la politique de sécurité des pods restreints:
Exemple de règle d’alerte croisée de projet
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Assurez-vous de spécifier le projet que vous avez défini dans le champ namespaces WithoutLabelEnforcement.
- 2
- Le nom de la règle d’alerte que vous souhaitez créer.
- 3
- La durée pour laquelle la condition doit être vraie avant qu’une alerte ne soit déclenchée.
- 4
- L’expression de requête PromQL qui définit la nouvelle règle.
- 5
- Le message associé à l’alerte.
- 6
- La sévérité que la règle d’alerte attribue à l’alerte.
ImportantAssurez-vous de créer une règle d’alerte croisée spécifique dans un seul des projets que vous avez spécifiés dans le champ namespaces WithoutLabelEnforcement. Lorsque vous créez la même règle d’alerte croisée dans plusieurs projets, cela se traduit par des alertes répétées.
Appliquer le fichier de configuration au cluster:
oc apply -f example-cross-project-alerting-rule.yaml
$ oc apply -f example-cross-project-alerting-rule.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow