Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

11.2. Alertes de journalisation personnalisées

Dans l’enregistrement des versions 5.7 et ultérieures, les utilisateurs peuvent configurer le déploiement LokiStack pour produire des alertes personnalisées et des métriques enregistrées. Lorsque vous souhaitez utiliser des règles d’alerte et d’enregistrement personnalisées, vous devez activer le composant règle LokiStack.

Les alertes basées sur les logs LokiStack et les métriques enregistrées sont déclenchées en fournissant des expressions LogQL au composant règle. L’opérateur Loki gère une règle optimisée pour la taille LokiStack sélectionnée, qui peut être 1x.extra-petit, 1x.petit, ou 1x.medium.

Afin de fournir ces expressions, vous devez créer une ressource personnalisée AlertingRule (CR) contenant des règles d’alerte compatibles Prometheus, ou une RecordingRule CR contenant des règles d’enregistrement compatibles Prometheus.

Les administrateurs peuvent configurer des alertes logées ou des métriques enregistrées pour les locataires d’applications, d’audits ou d’infrastructures. Les utilisateurs sans autorisation d’administrateur peuvent configurer des alertes log-based ou des métriques enregistrées pour les locataires des applications auxquelles ils ont accès.

Les alertes d’application, d’audit et d’infrastructure sont envoyées par défaut au service Red Hat OpenShift sur la pile de surveillance AWS Alertmanager dans l’espace de noms de surveillance openshift, sauf si vous avez désactivé l’instance Alertmanager locale. Lorsque le gestionnaire d’alerte qui est utilisé pour surveiller les projets définis par l’utilisateur dans l’espace de noms de surveillance de la charge de travail openshift-user est activé, des alertes d’application sont envoyées au gestionnaire d’alerte dans cet espace de noms par défaut.

11.2.1. Configuration de la règle
Copier lien

Lorsque le composant de règle LokiStack est activé, les utilisateurs peuvent définir un groupe d’expressions LogQL qui déclenchent des alertes de journalisation ou des métriques enregistrées.

Les administrateurs peuvent activer la règle en modifiant la ressource personnalisée LokiStack (CR).

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift et l’opérateur Loki ont été installés.
  • « vous avez créé un LokiStack CR.
  • Il y a des autorisations d’administrateur.

Procédure

  • Activer la règle en s’assurant que le LokiStack CR contient la configuration spec ci-dessous: 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: <name>
  namespace: <namespace>
spec:
# ...
  rules:
    enabled: true
    1 
    
    selector:
      matchLabels:
        openshift.io/<label_name>: "true"
    2 
    
    namespaceSelector:
      matchLabels:
        openshift.io/<label_name>: "true"
    3
    Copy to Clipboard Toggle word wrap
    1
    Activez les règles d’alerte et d’enregistrement Loki dans votre cluster.
    2
    Ajoutez une étiquette personnalisée qui peut être ajoutée aux espaces de noms où vous souhaitez activer l’utilisation des alertes et des métriques de journalisation.
    3
    Ajoutez une étiquette personnalisée qui peut être ajoutée aux espaces de noms où vous souhaitez activer l’utilisation des alertes et des métriques de journalisation.

11.2.2. Autoriser les règles LokiStack Autorisations RBAC
Copier lien

Les administrateurs peuvent permettre aux utilisateurs de créer et de gérer leurs propres règles d’alerte et d’enregistrement en liant les rôles de cluster aux noms d’utilisateurs. Les rôles de cluster sont définis comme des objets ClusterRole qui contiennent les autorisations nécessaires de contrôle d’accès basé sur les rôles (RBAC) pour les utilisateurs.

Dans l’enregistrement 5.8 et plus tard, les rôles de cluster suivants pour les règles d’alerte et d’enregistrement sont disponibles pour LokiStack:

Expand
Le nom de la règleDescription

alertingrules.loki.grafana.com-v1-admin

Les utilisateurs ayant ce rôle ont un accès administratif pour gérer les règles d’alerte. Ce rôle de cluster accorde des autorisations pour créer, lire, mettre à jour, supprimer, répertorier et regarder les ressources AlertingRule au sein du groupe API loki.grafana.com/v1.

alertingrules.loki.grafana.com-v1-crdview

Les utilisateurs ayant ce rôle peuvent afficher les définitions des définitions de ressources personnalisées (CRD) liées aux ressources AlertingRule dans le groupe API loki.grafana.com/v1, mais n’ont pas d’autorisations pour modifier ou gérer ces ressources.

alertingrules.loki.grafana.com-v1-edit

Les utilisateurs ayant ce rôle ont la permission de créer, de mettre à jour et de supprimer les ressources AlertingRule.

alertingrules.loki.grafana.com-v1-view

Les utilisateurs avec ce rôle peuvent lire les ressources AlertingRule dans le groupe API loki.grafana.com/v1. Ils peuvent inspecter les configurations, les étiquettes et les annotations pour les règles d’alerte existantes, mais ne peuvent y apporter aucune modification.

recordingrules.loki.grafana.com-v1-admin

Les utilisateurs ayant ce rôle ont un accès administratif pour gérer les règles d’enregistrement. Ce rôle de cluster accorde des autorisations pour créer, lire, mettre à jour, supprimer, répertorier et regarder les ressources RecordingRule au sein du groupe API loki.grafana.com/v1.

recordingrules.loki.grafana.com-v1-crdview

Les utilisateurs avec ce rôle peuvent afficher les définitions de Définitions de Ressources Personnalisées (CRD) liées aux ressources RecordingRule dans le groupe API loki.grafana.com/v1, mais n’ont pas d’autorisations pour modifier ou gérer ces ressources.

recordingrules.loki.grafana.com-v1-edit

Les utilisateurs ayant ce rôle ont la permission de créer, de mettre à jour et de supprimer les ressources RecordingRule.

recordingrules.loki.grafana.com-v1-view

Les utilisateurs avec ce rôle peuvent lire les ressources RecordingRule dans le groupe API loki.grafana.com/v1. Ils peuvent inspecter les configurations, les étiquettes et les annotations pour les règles d’alerte existantes, mais ne peuvent y apporter aucune modification.

11.2.2.1. Exemples
Copier lien

Afin d’appliquer des rôles de cluster pour un utilisateur, vous devez lier un rôle de cluster existant à un nom d’utilisateur spécifique.

Les rôles de cluster peuvent être définis en cluster ou en espace de noms, en fonction du type de liaison de rôle que vous utilisez. Lorsqu’un objet RoleBinding est utilisé, comme lors de l’utilisation de la commande add-role-to-user de la stratégie adm oc, le rôle de cluster ne s’applique qu’à l’espace de noms spécifié. Lorsqu’un objet ClusterRoleBinding est utilisé, comme lors de l’utilisation de la commande add-cluster-role-to-user de la stratégie adm oc, le rôle de cluster s’applique à tous les espaces de noms du cluster.

La commande d’exemple suivante donne à l’utilisateur spécifié des autorisations de création, de lecture, de mise à jour et de suppression (CRUD) pour les règles d’alerte dans un espace de noms spécifique dans le cluster:

Exemple de commande de liaison de rôle de cluster pour alerter les autorisations CRUD de règle dans un espace de noms spécifique

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>
Copy to Clipboard Toggle word wrap

La commande suivante donne les autorisations d’administrateur d’utilisateur spécifiées pour les règles d’alerte dans tous les espaces de noms:

Exemple de commande de liaison de rôle de cluster pour les autorisations d’administrateur

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>
Copy to Clipboard Toggle word wrap

La règle d’alerte CR contient un ensemble de spécifications et de définitions de validation webhook pour déclarer des groupes de règles d’alerte pour une seule instance LokiStack. En outre, la définition de validation webhook prend en charge les conditions de validation des règles:

  • Lorsqu’une règle d’alerte CR inclut une période d’intervalle invalide, il s’agit d’une règle d’alerte invalide
  • Lorsqu’une règle d’alerte CR inclut une période invalide, il s’agit d’une règle d’alerte invalide.
  • Dans le cas où une règle d’alerte CR inclut une expr de LogQL invalide, il s’agit d’une règle d’alerte invalide.
  • Lorsqu’une règle d’alerte CR inclut deux groupes portant le même nom, il s’agit d’une règle d’alerte invalide.
  • Dans le cas où aucun des éléments ci-dessus ne s’applique, une règle d’alerte est considérée comme valide.
Expand
Le type de locataireEspaces de noms valides pour AlertingRule CRs

application

 

audit

journalisation OpenShift

l’infrastructure

d’OpenShift-/*, kube-/\*, par défaut

Conditions préalables

  • L’opérateur de journalisation de Red Hat OpenShift 5.7 et versions ultérieures
  • Le Red Hat OpenShift Service sur AWS 4.13 et versions ultérieures

Procédure

  1. Créer une ressource personnalisée AlertingRule (CR):

    Exemple d’infrastructure AlertingRule CR

      apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat
    1 
    
    labels:
    2 
    
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "infrastructure"
    3 
    
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: |
    4 
    
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical
    5 
    
            annotations:
              summary: High Loki Operator Reconciliation Errors
    6 
    
              description: High Loki Operator Reconciliation Errors
    7
    Copy to Clipboard Toggle word wrap

    1
    L’espace de noms où cette AlertingRule CR est créée doit avoir une étiquette correspondant à la définition LokiStack spec.rules.namespaceSelector.
    2
    Le bloc d’étiquettes doit correspondre à la définition de LokiStack spec.rules.selector.
    3
    AlertingRule CRs pour les locataires de l’infrastructure sont uniquement pris en charge dans les espaces de noms openshift-*, kube-\* ou par défaut.
    4
    La valeur de kubernetes_namespace_name: doit correspondre à la valeur de métadonnées.namespace.
    5
    La valeur de ce champ obligatoire doit être critique, mise en garde ou info.
    6
    Ce champ est obligatoire.
    7
    Ce champ est obligatoire.

    Exemple d’application AlertingRule CR

      apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns
    1 
    
    labels:
    2 
    
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: |
    3 
    
            sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical
    4 
    
            annotations:
              summary:
    5 
    
              description:
    6
    Copy to Clipboard Toggle word wrap

    1
    L’espace de noms où cette AlertingRule CR est créée doit avoir une étiquette correspondant à la définition LokiStack spec.rules.namespaceSelector.
    2
    Le bloc d’étiquettes doit correspondre à la définition de LokiStack spec.rules.selector.
    3
    La valeur de kubernetes_namespace_name: doit correspondre à la valeur de métadonnées.namespace.
    4
    La valeur de ce champ obligatoire doit être critique, mise en garde ou info.
    5
    La valeur de ce champ obligatoire est un résumé de la règle.
    6
    La valeur de ce champ obligatoire est une description détaillée de la règle.

  2. Appliquer la règle d’alerte CR: 

    $ oc apply -f <filename>.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