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.

    Important

    Lorsqu’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.

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.

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.

Note

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

  1. Créez un fichier YAML pour les règles d’alerte. Dans cet exemple, il est appelé example-app-alerting-rule.yaml.
  2. 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:

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: example-alert
      namespace: ns1
    spec:
      groups:
      - name: example
        rules:
        - alert: VersionAlert 
    1
    
          for: 1m 
    2
    
          expr: version{job="prometheus-example-app"} == 0 
    3
    
          labels:
            severity: warning 
    4
    
          annotations:
            message: This is an example alert. 
    5
    Copy to Clipboard Toggle word wrap
    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.
  3. Appliquer le fichier de configuration au cluster:

    $ oc apply -f example-app-alerting-rule.yaml
    Copy to Clipboard Toggle word wrap

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é.

    Note

    Lorsque 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

  1. É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
    Copy to Clipboard Toggle word wrap
  2. Configurez des projets dans lesquels vous souhaitez créer des règles d’alerte qui ne sont pas liées à un projet spécifique:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: user-workload-monitoring-config
      namespace: openshift-user-workload-monitoring
    data:
      config.yaml: |
        namespacesWithoutLabelEnforcement: [ <namespace> ] 
    1
    
        # ...
    Copy to Clipboard Toggle word wrap
    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.
  3. Créez un fichier YAML pour les règles d’alerte. Dans cet exemple, il est appelé exemple-cross-project-alerting-rule.yaml.
  4. 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

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: example-security
      namespace: ns1 
    1
    
    spec:
      groups:
        - name: pod-security-policy
          rules:
            - alert: "ProjectNotEnforcingRestrictedPolicy" 
    2
    
              for: 5m 
    3
    
              expr: kube_namespace_labels{namespace!~"(openshift|kube).*|default",label_pod_security_kubernetes_io_enforce!="restricted"} 
    4
    
              annotations:
                message: "Restricted policy not enforced. Project {{ $labels.namespace }} does not enforce the restricted pod security policy." 
    5
    
              labels:
                severity: warning 
    6
    Copy to Clipboard Toggle word wrap

    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.
    Important

    Assurez-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.

  5. Appliquer le fichier de configuration au cluster:

    $ oc apply -f example-cross-project-alerting-rule.yaml
    Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat