Contrôle

Procédure

1. Modifiez l'objet ConfigMap.

   • To configure core OpenShift Container Platform monitoring components:

     1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. Ajoutez votre configuration sous data/config.yaml sous la forme d'une paire clé-valeur <component_name>: <component_configuration>:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>:
              <configuration_for_the_component>

        Remplacer <component> et <configuration_for_the_component> en conséquence.

        L'exemple d'objet ConfigMap suivant configure une revendication de volume persistant (PVC) pour Prometheus. Cela concerne uniquement l'instance Prometheus qui surveille les composants de base d'OpenShift Container Platform :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: fast
                  volumeMode: Filesystem
                  resources:
                    requests:
                      storage: 40Gi

        1

        Définit le composant Prometheus et les lignes suivantes définissent sa configuration.

   • To configure components that monitor user-defined projects:

     1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. Ajoutez votre configuration sous data/config.yaml sous la forme d'une paire clé-valeur <component_name>: <component_configuration>:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              <configuration_for_the_component>

        Remplacer <component> et <configuration_for_the_component> en conséquence.

        L'exemple suivant d'objet ConfigMap configure une période de rétention des données et des demandes minimales de ressources de conteneur pour Prometheus. Cela concerne l'instance Prometheus qui surveille uniquement les projets définis par l'utilisateur :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus: 1
              retention: 24h 2
              resources:
                requests:
                  cpu: 200m 3
                  memory: 2Gi 4

        1

        Définit le composant Prometheus et les lignes suivantes définissent sa configuration.

        2

        Configure une période de rétention des données de 24 heures pour l'instance Prometheus qui surveille les projets définis par l'utilisateur.

        3

        Définit une demande de ressources minimale de 200 millicores pour le conteneur Prometheus.

        4

        Définit une demande de ressource pod minimale de 2 GiB de mémoire pour le conteneur Prometheus.

        Note

        Le composant Prometheus config map est appelé prometheusK8s dans l'objet cluster-monitoring-config ConfigMap et prometheus dans l'objet user-workload-monitoring-config ConfigMap .

2. Enregistrez le fichier pour appliquer les modifications à l'objet ConfigMap. Les pods concernés par la nouvelle configuration sont redémarrés automatiquement.

   Note

   Les configurations appliquées à l'objet user-workload-monitoring-config ConfigMap ne sont pas activées à moins qu'un administrateur de cluster n'ait activé la surveillance pour les projets définis par l'utilisateur.

   Avertissement

   Lorsque des modifications sont enregistrées dans une carte de configuration de surveillance, les pods et autres ressources du projet concerné peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également être redémarrés.

Procédure

1. Modifiez l'objet ConfigMap:

   • To move a component that monitors core OpenShift Container Platform projects:

     1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. Spécifiez la contrainte nodeSelector pour le composant sous data/config.yaml:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>:
              nodeSelector:
                <node_key>: <node_value>
                <node_key>: <node_value>
                <...>

        Remplacez <component> en conséquence et remplacez <node_key>: <node_value> par la carte de paires clé-valeur qui spécifie un groupe de nœuds de destination. Souvent, une seule paire clé-valeur est utilisée.

        Le composant ne peut être exécuté que sur les nœuds dont les étiquettes sont constituées de chacune des paires clé-valeur spécifiées. Les nœuds peuvent également avoir des étiquettes supplémentaires.

        Important

        De nombreux composants de surveillance sont déployés en utilisant plusieurs pods sur différents nœuds du cluster afin de maintenir une haute disponibilité. Lorsque vous déplacez des composants de surveillance vers des nœuds étiquetés, assurez-vous que suffisamment de nœuds correspondants sont disponibles pour maintenir la résilience du composant. Si une seule étiquette est spécifiée, assurez-vous que suffisamment de nœuds contiennent cette étiquette pour distribuer tous les pods du composant sur des nœuds distincts. Vous pouvez également spécifier plusieurs étiquettes, chacune se rapportant à des nœuds individuels.

        Note

        Si les composants de surveillance restent dans l'état Pending après avoir configuré la contrainte nodeSelector, vérifiez dans les journaux du pod les erreurs relatives aux taches et aux tolérances.

        Par exemple, pour déplacer les composants de surveillance des projets principaux d'OpenShift Container Platform vers des nœuds spécifiques étiquetés nodename: controlplane1, nodename: worker1, nodename: worker2, et nodename: worker2, utilisez :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusOperator:
              nodeSelector:
                nodename: controlplane1
            prometheusK8s:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            alertmanagerMain:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            kubeStateMetrics:
              nodeSelector:
                nodename: worker1
            telemeterClient:
              nodeSelector:
                nodename: worker1
            k8sPrometheusAdapter:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            openshiftStateMetrics:
              nodeSelector:
                nodename: worker1
            thanosQuerier:
              nodeSelector:
                nodename: worker1
                nodename: worker2

   • To move a component that monitors user-defined projects:

     1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. Spécifiez la contrainte nodeSelector pour le composant sous data/config.yaml:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              nodeSelector:
                <node_key>: <node_value>
                <node_key>: <node_value>
                <...>

        Remplacez <component> en conséquence et remplacez <node_key>: <node_value> par la carte des paires clé-valeur qui spécifie les nœuds de destination. Souvent, une seule paire clé-valeur est utilisée.

        Le composant ne peut être exécuté que sur les nœuds dont les étiquettes sont constituées de chacune des paires clé-valeur spécifiées. Les nœuds peuvent également avoir des étiquettes supplémentaires.

        Important

        De nombreux composants de surveillance sont déployés en utilisant plusieurs pods sur différents nœuds du cluster afin de maintenir une haute disponibilité. Lorsque vous déplacez des composants de surveillance vers des nœuds étiquetés, assurez-vous que suffisamment de nœuds correspondants sont disponibles pour maintenir la résilience du composant. Si une seule étiquette est spécifiée, assurez-vous que suffisamment de nœuds contiennent cette étiquette pour distribuer tous les pods du composant sur des nœuds distincts. Vous pouvez également spécifier plusieurs étiquettes, chacune se rapportant à des nœuds individuels.

        Note

        Si les composants de surveillance restent dans l'état Pending après avoir configuré la contrainte nodeSelector, vérifiez dans les journaux du pod les erreurs relatives aux taches et aux tolérances.

        Par exemple, pour déplacer les composants de surveillance des projets définis par l'utilisateur vers des nœuds de travail spécifiques étiquetés nodename: worker1, nodename: worker2, et nodename: worker2, utilisez :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheusOperator:
              nodeSelector:
                nodename: worker1
            prometheus:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            thanosRuler:
              nodeSelector:
                nodename: worker1
                nodename: worker2

2. Enregistrez le fichier pour appliquer les modifications. Les composants concernés par la nouvelle configuration sont automatiquement déplacés vers les nouveaux nœuds.

   Note

   Les configurations appliquées à l'objet user-workload-monitoring-config ConfigMap ne sont pas activées à moins qu'un administrateur de cluster n'ait activé la surveillance pour les projets définis par l'utilisateur.

   Avertissement

   Lorsque des modifications sont enregistrées dans une carte de configuration de surveillance, les pods et autres ressources du projet concerné peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également être redémarrés.

Procédure

1. Modifiez l'objet ConfigMap:

   • To assign tolerations to a component that monitors core OpenShift Container Platform projects:

     1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. Spécifiez tolerations pour le composant :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>:
              tolerations:
                <toleration_specification>

        Remplacer <component> et <toleration_specification> en conséquence.

        Par exemple, oc adm taint nodes node1 key1=value1:NoSchedule ajoute une taint à node1 avec la clé key1 et la valeur value1. Cela empêche les composants de surveillance de déployer des pods sur node1 à moins qu'une tolérance ne soit configurée pour cette anomalie. L'exemple suivant configure le composant alertmanagerMain pour qu'il tolère l'altération de l'exemple :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              tolerations:
              - key: "key1"
                operator: "Equal"
                value: "value1"
                effect: "NoSchedule"

   • To assign tolerations to a component that monitors user-defined projects:

     1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. Spécifiez tolerations pour le composant :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              tolerations:
                <toleration_specification>

        Remplacer <component> et <toleration_specification> en conséquence.

        Par exemple, oc adm taint nodes node1 key1=value1:NoSchedule ajoute une taint à node1 avec la clé key1 et la valeur value1. Cela empêche les composants de surveillance de déployer des pods sur node1 à moins qu'une tolérance ne soit configurée pour cette anomalie. L'exemple suivant configure le composant thanosRuler pour qu'il tolère l'altération de l'exemple :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              tolerations:
              - key: "key1"
                operator: "Equal"
                value: "value1"
                effect: "NoSchedule"

2. Enregistrez le fichier pour appliquer les modifications. La nouvelle configuration de placement des composants est appliquée automatiquement.

   Note

   Les configurations appliquées à l'objet user-workload-monitoring-config ConfigMap ne sont pas activées à moins qu'un administrateur de cluster n'ait activé la surveillance pour les projets définis par l'utilisateur.

   Avertissement

   Lorsque des modifications sont enregistrées dans une carte de configuration de surveillance, les pods et autres ressources du projet concerné peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également être redémarrés.

Procédure

1. Modifiez l'objet cluster-monitoring-config ConfigMap dans l'espace de noms openshift-monitoring:

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. Ajouter une valeur pour enforcedBodySizeLimit à data/config.yaml/prometheusK8s afin de limiter la taille du corps qui peut être acceptée par raclage ciblé :

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |-
       prometheusK8s:
         enforcedBodySizeLimit: 40MB 1

   1

   Spécifier la taille maximale du corps des cibles de métriques scrappées. L'exemple suivant ( enforcedBodySizeLimit ) limite la taille non compressée de chaque cible scrappée à 40 mégaoctets. Les valeurs numériques valides utilisent le format de taille des données Prometheus : B (octets), KB (kilooctets), MB (mégaoctets), GB (gigaoctets), TB (téraoctets), PB (pétaoctets) et EB (exaoctets). La valeur par défaut est 0, ce qui signifie qu'il n'y a pas de limite. Vous pouvez également définir la valeur automatic pour calculer automatiquement la limite en fonction de la capacité de la grappe.

3. Enregistrez le fichier pour appliquer automatiquement les modifications.

   Avertissement

   Lorsque vous enregistrez les modifications apportées à une carte de configuration cluster-monitoring-config, les pods et autres ressources du projet openshift-monitoring peuvent être redéployés. Les processus de surveillance en cours d'exécution dans ce projet peuvent également redémarrer.

1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring:

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. Ajouter une section remoteWrite: sous data/config.yaml/prometheusK8s.

3. Ajoutez une URL de point final et des informations d'authentification dans cette section :

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       prometheusK8s:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com" 1
           <endpoint_authentication_credentials> 2

   1

   L'URL du point de terminaison d'écriture à distance.

   2

   La méthode d'authentification et les informations d'identification pour le point de terminaison. Les méthodes d'authentification actuellement prises en charge sont AWS Signature Version 4, l'authentification par HTTP et l'en-tête de requête Authorization, l'authentification de base, OAuth 2.0 et le client TLS. Voir Supported remote write authentication settings ci-dessous pour des exemples de configuration des méthodes d'authentification prises en charge.

4. Ajouter des valeurs de configuration après les informations d'authentification :

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       prometheusK8s:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com"
           <endpoint_authentication_credentials>
           <write_relabel_configs> 1

   1

   Les paramètres de configuration du relabel d'écriture.

   Pour <write_relabel_configs>, substituez une liste de configurations d'étiquetage en écriture pour les mesures que vous souhaitez envoyer au point de terminaison distant.

   L'exemple suivant montre comment transmettre une métrique unique appelée my_metric:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       prometheusK8s:
         remoteWrite:
         - url: "https://remote-write-endpoint.example.com"
           writeRelabelConfigs:
           - sourceLabels: [__name__]
             regex: 'my_metric'
             action: keep

   Voir la documentation Prometheus relabel_config pour plus d'informations sur les options de configuration de write relabel.

5. Enregistrez le fichier pour appliquer les modifications à l'objet ConfigMap. Les pods concernés par la nouvelle configuration redémarrent automatiquement.

   Note

   Les configurations appliquées à l'objet user-workload-monitoring-config ConfigMap ne sont pas activées à moins qu'un administrateur de cluster n'ait activé la surveillance pour les projets définis par l'utilisateur.

   Avertissement

   L'enregistrement des modifications apportées à un objet de surveillance ConfigMap peut entraîner le redéploiement des pods et d'autres ressources dans le projet concerné. L'enregistrement des modifications peut également redémarrer les processus de surveillance en cours dans ce projet.

Procédure

1. Modifiez l'objet ConfigMap:

   • To attach custom labels to all time series and alerts leaving the Prometheus instance that monitors core OpenShift Container Platform projects:

     1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. Définissez une carte des étiquettes que vous souhaitez ajouter pour chaque métrique sous data/config.yaml:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              externalLabels:
                <key>: <value> 1

        1

        Remplacer <key>: <value> par une carte de paires clé-valeur où <key> est un nom unique pour le nouveau label et <value> sa valeur.

        Avertissement

        N'utilisez pas prometheus ou prometheus_replica comme noms de clés, car ils sont réservés et seront écrasés.

        Par exemple, pour ajouter des métadonnées sur la région et l'environnement à toutes les séries temporelles et alertes, utilisez :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              externalLabels:
                region: eu
                environment: prod

   • To attach custom labels to all time series and alerts leaving the Prometheus instance that monitors user-defined projects:

     1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. Définissez une carte des étiquettes que vous souhaitez ajouter pour chaque métrique sous data/config.yaml:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              externalLabels:
                <key>: <value> 1

        1

        Remplacer <key>: <value> par une carte de paires clé-valeur où <key> est un nom unique pour le nouveau label et <value> sa valeur.

        Avertissement

        N'utilisez pas prometheus ou prometheus_replica comme noms de clés, car ils sont réservés et seront écrasés.

        Note

        Dans le projet openshift-user-workload-monitoring, Prometheus gère les mesures et Thanos Ruler les règles d'alerte et d'enregistrement. En remplaçant prometheus par externalLabels dans l'objet user-workload-monitoring-config ConfigMap , vous ne configurerez les étiquettes externes que pour les mesures et non pour les règles.

        Par exemple, pour ajouter des métadonnées sur la région et l'environnement à toutes les séries temporelles et alertes liées à des projets définis par l'utilisateur, utilisez :

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              externalLabels:
                region: eu
                environment: prod

2. Enregistrez le fichier pour appliquer les modifications. La nouvelle configuration est appliquée automatiquement.

   Note

   Les configurations appliquées à l'objet user-workload-monitoring-config ConfigMap ne sont pas activées à moins qu'un administrateur de cluster n'ait activé la surveillance pour les projets définis par l'utilisateur.

   Avertissement

   Lorsque des modifications sont enregistrées dans une carte de configuration de surveillance, les pods et autres ressources du projet concerné peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également être redémarrés.

Procédure

1. Modifiez l'objet cluster-monitoring-config ConfigMap dans l'espace de noms openshift-monitoring:

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. Ajoutez des valeurs pour les paramètres suivants sous data/config.yaml/prometheusK8s pour configurer les contraintes d'étalement de la topologie des pods :

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       prometheusK8s:
         topologySpreadConstraints:
         - maxSkew: 1 1
           topologyKey: monitoring 2
           whenUnsatisfiable: DoNotSchedule 3
           labelSelector:
             matchLabels: 4
               app.kubernetes.io/name: prometheus

   1

   Indiquez une valeur numérique pour maxSkew, qui définit le degré d'inégalité de la répartition des cosses. Ce champ est obligatoire et la valeur doit être supérieure à zéro. La valeur spécifiée a un effet différent selon la valeur spécifiée pour whenUnsatisfiable.

   2

   Spécifiez une clé d'étiquettes de nœuds pour topologyKey. Ce champ est obligatoire. Les nœuds qui ont une étiquette avec cette clé et des valeurs identiques sont considérés comme étant dans la même topologie. Le planificateur essaiera de placer un nombre équilibré de pods dans chaque domaine.

   3

   Indiquez une valeur pour whenUnsatisfiable. Ce champ est obligatoire. Les options disponibles sont DoNotSchedule et ScheduleAnyway. Indiquez DoNotSchedule si vous souhaitez que la valeur maxSkew définisse la différence maximale autorisée entre le nombre de modules correspondants dans la topologie cible et le minimum global. Indiquez ScheduleAnyway si vous souhaitez que le planificateur planifie toujours le module, mais qu'il accorde une priorité plus élevée aux nœuds susceptibles de réduire l'asymétrie.

   4

   Spécifiez une valeur pour matchLabels. Cette valeur est utilisée pour identifier l'ensemble des pods correspondants auxquels appliquer les contraintes.

3. Enregistrez le fichier pour appliquer automatiquement les modifications.

   Avertissement

   Lorsque vous enregistrez les modifications apportées à la carte de configuration cluster-monitoring-config, les pods et autres ressources du projet openshift-monitoring peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également redémarrer.

Procédure

1. Modifiez l'objet cluster-monitoring-config ConfigMap dans l'espace de noms openshift-monitoring:

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. Ajoutez des valeurs pour les paramètres suivants sous data/config.yaml/alertmanagermain pour configurer les contraintes d'étalement de la topologie des pods :

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       alertmanagerMain:
         topologySpreadConstraints:
         - maxSkew: 1 1
           topologyKey: monitoring 2
           whenUnsatisfiable: DoNotSchedule 3
           labelSelector:
             matchLabels: 4
               app.kubernetes.io/name: alertmanager

   1

   Indiquez une valeur numérique pour maxSkew, qui définit le degré d'inégalité de la répartition des cosses. Ce champ est obligatoire et la valeur doit être supérieure à zéro. La valeur spécifiée a un effet différent selon la valeur spécifiée pour whenUnsatisfiable.

   2

   Spécifiez une clé d'étiquettes de nœuds pour topologyKey. Ce champ est obligatoire. Les nœuds qui ont une étiquette avec cette clé et des valeurs identiques sont considérés comme étant dans la même topologie. Le planificateur essaiera de placer un nombre équilibré de pods dans chaque domaine.

   3

   Indiquez une valeur pour whenUnsatisfiable. Ce champ est obligatoire. Les options disponibles sont DoNotSchedule et ScheduleAnyway. Indiquez DoNotSchedule si vous souhaitez que la valeur maxSkew définisse la différence maximale autorisée entre le nombre de modules correspondants dans la topologie cible et le minimum global. Indiquez ScheduleAnyway si vous souhaitez que le planificateur planifie toujours le module, mais qu'il accorde une priorité plus élevée aux nœuds susceptibles de réduire l'asymétrie.

   4

   Spécifiez une valeur pour matchLabels. Cette valeur est utilisée pour identifier l'ensemble des pods correspondants auxquels appliquer les contraintes.

3. Enregistrez le fichier pour appliquer automatiquement les modifications.

   Avertissement

   Lorsque vous enregistrez les modifications apportées à la carte de configuration cluster-monitoring-config, les pods et autres ressources du projet openshift-monitoring peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également redémarrer.

Procédure

1. Modifiez la carte de configuration user-workload-monitoring-config dans l'espace de noms openshift-user-workload-monitoring:

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. Ajoutez des valeurs pour les paramètres suivants sous data/config.yaml/thanosRuler pour configurer les contraintes d'étalement de la topologie des pods :

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         topologySpreadConstraints:
         - maxSkew: 1 1
           topologyKey: monitoring 2
           whenUnsatisfiable: ScheduleAnyway 3
           labelSelector:
             matchLabels: 4
               app.kubernetes.io/name: thanos-ruler

   1

   Indiquez une valeur numérique pour maxSkew, qui définit le degré d'inégalité de la répartition des cosses. Ce champ est obligatoire et la valeur doit être supérieure à zéro. La valeur spécifiée a un effet différent selon la valeur spécifiée pour whenUnsatisfiable.

   2

   Spécifiez une clé d'étiquettes de nœuds pour topologyKey. Ce champ est obligatoire. Les nœuds qui ont une étiquette avec cette clé et des valeurs identiques sont considérés comme étant dans la même topologie. Le planificateur essaiera de placer un nombre équilibré de pods dans chaque domaine.

   3

   Indiquez une valeur pour whenUnsatisfiable. Ce champ est obligatoire. Les options disponibles sont DoNotSchedule et ScheduleAnyway. Indiquez DoNotSchedule si vous souhaitez que la valeur maxSkew définisse la différence maximale autorisée entre le nombre de modules correspondants dans la topologie cible et le minimum global. Indiquez ScheduleAnyway si vous souhaitez que le planificateur planifie toujours le module, mais qu'il accorde une priorité plus élevée aux nœuds susceptibles de réduire l'asymétrie.

   4

   Spécifiez une valeur pour matchLabels. Cette valeur est utilisée pour identifier l'ensemble des pods correspondants auxquels appliquer les contraintes.

3. Enregistrez le fichier pour appliquer automatiquement les modifications.

   Avertissement

   Lorsque vous enregistrez les modifications apportées à la carte de configuration user-workload-monitoring-config, les pods et autres ressources du projet openshift-user-workload-monitoring peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également redémarrer.

Procédure

1. Modifiez l'objet ConfigMap:

   • To set a log level for a component in the openshift-monitoring project:

     1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring:

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. Ajouter logLevel: <log_level> pour un composant sous data/config.yaml:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              logLevel: <log_level> 2

        1

        Le composant de la pile de surveillance pour lequel vous définissez un niveau de journalisation. Pour la surveillance de la plate-forme par défaut, les valeurs disponibles sont prometheusK8s, alertmanagerMain, prometheusOperator et thanosQuerier.

        2

        Le niveau de journalisation à définir pour le composant. Les valeurs disponibles sont error, warn, info, et debug. La valeur par défaut est info.

   • To set a log level for a component in the openshift-user-workload-monitoring project:

     1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring:

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. Ajouter logLevel: <log_level> pour un composant sous data/config.yaml:

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              logLevel: <log_level> 2

        1

        Le composant de la pile de surveillance pour lequel vous définissez un niveau de journalisation. Pour la surveillance de la charge de travail de l'utilisateur, les valeurs disponibles sont prometheus, prometheusOperator, et thanosRuler.

        2

        Le niveau de journalisation à définir pour le composant. Les valeurs disponibles sont error, warn, info, et debug. La valeur par défaut est info.

2. Enregistrez le fichier pour appliquer les modifications. Les pods du composant redémarrent automatiquement lorsque vous appliquez la modification du niveau de journalisation.

   Note

   Les configurations appliquées à l'objet user-workload-monitoring-config ConfigMap ne sont pas activées à moins qu'un administrateur de cluster n'ait activé la surveillance pour les projets définis par l'utilisateur.

   Avertissement

   Lorsque des modifications sont enregistrées dans une carte de configuration de surveillance, les pods et autres ressources du projet concerné peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également être redémarrés.

3. Confirmez que le niveau de journalisation a été appliqué en examinant la configuration du déploiement ou du pod dans le projet concerné. L'exemple suivant vérifie le niveau de journalisation dans le déploiement prometheus-operator du projet openshift-user-workload-monitoring:

   $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

   Exemple de sortie

           - --log-level=debug

4. Vérifiez que les pods du composant sont en cours d'exécution. L'exemple suivant répertorie l'état des modules dans le projet openshift-user-workload-monitoring:

   $ oc -n openshift-user-workload-monitoring get pods

   Note

   Si une valeur loglevel non reconnue est incluse dans l'objet ConfigMap, les pods du composant risquent de ne pas redémarrer avec succès.

1. Modifiez l'objet cluster-monitoring-config ConfigMap dans le projet openshift-monitoring:

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. Ajoutez une section thanosQuerier sous data/config.yaml et ajoutez des valeurs comme indiqué dans l'exemple suivant :

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       thanosQuerier:
         enableRequestLogging: <value> 1
         logLevel: <value> 2

   1

   Fixez la valeur à true pour activer la journalisation et à false pour la désactiver. La valeur par défaut est false.

   2

   Définissez la valeur sur debug, info, warn, ou error. Si aucune valeur n'existe pour logLevel, le niveau de journalisation est par défaut error.

3. Enregistrez le fichier pour appliquer les modifications.

   Avertissement

   Lorsque vous enregistrez les modifications apportées à une carte de configuration de surveillance, les pods et autres ressources du projet concerné peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également être redémarrés.

Vérification

1. Vérifiez que les pods Thanos Querier sont en cours d'exécution. L'exemple de commande suivant répertorie l'état des modules dans le projet openshift-monitoring:

   $ oc -n openshift-monitoring get pods

2. Exécutez une requête de test en utilisant les exemples de commandes suivants comme modèle :

   $ token=`oc create token prometheus-k8s -n openshift-monitoring`
   $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: Bearer $token" 'https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query?query=cluster_version'

3. Exécutez la commande suivante pour lire le journal des requêtes :

   oc -n openshift-monitoring logs <thanos_querier_pod_name> -c thanos-query

   Note

   Les pods thanos-querier étant des pods hautement disponibles (HA), il se peut que vous ne puissiez voir les journaux que dans un seul pod.

4. Après avoir examiné les informations de requête consignées, désactivez la consignation des requêtes en remplaçant la valeur enableRequestLogging par false dans la carte de configuration.

Procédure

1. Modifiez la carte de configuration cluster-monitoring-config dans le projet openshift-monitoring:

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. Ajouter enabled: false pour le composant alertmanagerMain sous data/config.yaml:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       alertmanagerMain:
         enabled: false

3. Enregistrez le fichier pour appliquer les modifications. L'instance de l'Alertmanager est automatiquement désactivée lorsque vous appliquez la modification.

Procédure

1. Modifier l'objet cluster-monitoring-config ConfigMap :

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. Ajouter enableUserWorkload: true sous data/config.yaml:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       enableUserWorkload: true 1

   1

   Lorsqu'il est défini sur true, le paramètre enableUserWorkload permet la surveillance de projets définis par l'utilisateur dans un cluster.

3. Enregistrez le fichier pour appliquer les modifications. La surveillance des projets définis par l'utilisateur est alors automatiquement activée.

   Avertissement

   Lorsque les modifications sont enregistrées dans l'objet cluster-monitoring-config ConfigMap , les pods et autres ressources du projet openshift-monitoring peuvent être redéployés. Les processus de surveillance en cours dans ce projet peuvent également être redémarrés.

4. Vérifiez que les pods prometheus-operator, prometheus-user-workload et thanos-ruler-user-workload sont en cours d'exécution dans le projet openshift-user-workload-monitoring. Le démarrage des pods peut prendre un certain temps :

   $ oc -n openshift-user-workload-monitoring get pod

   Exemple de sortie

   NAME                                   READY   STATUS        RESTARTS   AGE
   prometheus-operator-6f7b748d5b-t7nbg   2/2     Running       0          3h
   prometheus-user-workload-0             4/4     Running       1          3h
   prometheus-user-workload-1             4/4     Running       1          3h
   thanos-ruler-user-workload-0           3/3     Running       0          3h
   thanos-ruler-user-workload-1           3/3     Running       0          3h

Procédure

1. Extraire un jeton pour se connecter à Prometheus :

   $ SECRET=`oc get secret -n openshift-user-workload-monitoring | grep  prometheus-user-workload-token | head -n 1 | awk '{print $1 }'`

   $ TOKEN=`echo $(oc get secret $SECRET -n openshift-user-workload-monitoring -o json | jq -r '.data.token') | base64 -d`

2. Extrayez votre hôte de route :

   $ THANOS_QUERIER_HOST=`oc get route thanos-querier -n openshift-monitoring -o json | jq -r '.spec.host'`

3. Interrogez les métriques de vos propres services en ligne de commande. Par exemple :

   $ NAMESPACE=ns1

   $ curl -X GET -kG "https://$THANOS_QUERIER_HOST/api/v1/query?" --data-urlencode "query=up{namespace='$NAMESPACE'}" -H "Authorization: Bearer $TOKEN"

   Le résultat vous indiquera la durée pendant laquelle vos pods d'application ont été activés.

   Exemple de sortie

   {"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"up","endpoint":"web","instance":"10.129.0.46:8080","job":"prometheus-example-app","namespace":"ns1","pod":"prometheus-example-app-68d47c4fb6-jztp2","service":"prometheus-example-app"},"value":[1591881154.748,"1"]}]}}

Procédure

1. Ajouter l'étiquette à l'espace de noms du projet :

   $ oc label namespace my-project 'openshift.io/user-monitoring=false'

2. Pour réactiver la surveillance, retirez l'étiquette de l'espace de noms :

   $ oc label namespace my-project 'openshift.io/user-monitoring-'

   Note

   S'il existe des cibles de surveillance actives pour le projet, Prometheus peut prendre quelques minutes pour arrêter de les gratter après l'ajout de l'étiquette.

Procédure

1. Modifier l'objet cluster-monitoring-config ConfigMap :

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

   1. Définissez enableUserWorkload: à false sous data/config.yaml:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |
          enableUserWorkload: false

2. Enregistrez le fichier pour appliquer les modifications. La surveillance des projets définis par l'utilisateur est alors automatiquement désactivée.

3. Vérifiez que les pods prometheus-operator, prometheus-user-workload et thanos-ruler-user-workload sont terminés dans le projet openshift-user-workload-monitoring. Cela peut prendre un peu de temps :

   $ oc -n openshift-user-workload-monitoring get pod

   Exemple de sortie

   No resources found in openshift-user-workload-monitoring project.

Procédure

1. Modifier l'objet cluster-monitoring-config ConfigMap :

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. Ajouter enableUserAlertmanagerConfig: true dans la section alertmanagerMain sous data/config.yaml:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       alertmanagerMain:
         enableUserAlertmanagerConfig: true 1

   1

   Définissez la valeur enableUserAlertmanagerConfig sur true pour permettre aux utilisateurs de créer des configurations d'acheminement des alertes définies par l'utilisateur qui utilisent l'instance de la plate-forme principale de l'Alertmanager.

3. Enregistrez le fichier pour appliquer les modifications.

Procédure

1. Modifier l'objet user-workload-monitoring-config ConfigMap :

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. Ajouter enabled: true et enableAlertmanagerConfig: true dans la section alertmanager sous data/config.yaml:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       alertmanager:
         enabled: true 1
         enableAlertmanagerConfig: true 2

   1

   Fixez la valeur de enabled à true pour activer une instance dédiée de l'Alertmanager pour les projets définis par l'utilisateur dans un cluster. Fixez la valeur à false ou omettez la clé pour désactiver l'Alertmanager pour les projets définis par l'utilisateur. Si vous définissez cette valeur sur false ou si la clé est omise, les alertes définies par l'utilisateur sont acheminées vers l'instance Alertmanager de la plate-forme par défaut.

   2

   Définissez la valeur enableAlertmanagerConfig sur true pour permettre aux utilisateurs de définir leurs propres configurations de routage des alertes avec les objets AlertmanagerConfig.

3. Sauvegardez le fichier pour appliquer les changements. L'instance dédiée de l'Alertmanager pour les projets définis par l'utilisateur démarre automatiquement.

Procédure

1. Si vous n'avez pas obtenu la route API OpenShift Container Platform pour Thanos Querier, exécutez la commande suivante :

   $ oc get routes -n openshift-monitoring thanos-querier -o jsonpath='{.status.ingress[0].host}'

2. Récupérez une liste de métriques au format JSON à partir de la route API Thanos Querier en exécutant la commande suivante. Cette commande utilise oc pour s'authentifier avec un jeton de porteur.

   $ curl -k -H \N "Authorization : Bearer $(oc whoami -t)" https://<thanos_querier_route>/api/v1/metadata 1

   1

   Remplacez <thanos_querier_route> par la route de l'API OpenShift Container Platform pour Thanos Querier.

1. Ouvrez la console web d'OpenShift Container Platform et naviguez vers Observe → Targets.
2. Facultatif : Filtrez les cibles par statut et par source en sélectionnant des filtres dans la liste Filter.
3. Facultatif : Recherchez une cible par nom ou par étiquette en utilisant le champ Text ou Label à côté du champ de recherche.
4. Facultatif : Triez les cibles en cliquant sur un ou plusieurs des en-têtes de colonne Endpoint, Status, Namespace, Last Scrape, et Scrape Duration.

5. Cliquez sur l'URL d'une cible dans la colonne Endpoint pour accéder à sa page Target details. Cette page fournit des informations sur la cible, notamment :

   • L'URL du point de terminaison qui fait l'objet d'une recherche de métriques
   • Le statut actuel Up ou Down de la cible
   • Un lien vers l'espace de noms
   • Un lien vers les détails du ServiceMonitor
   • Étiquettes attachées à la cible
   • La date la plus récente à laquelle la cible a été scrappée pour les métriques

1. Ouvrez la console web OpenShift Container Platform et naviguez jusqu'à la page Observe → Alerting → Alerts.
2. Facultatif : Recherchez les alertes par nom en utilisant le champ Name dans la liste de recherche.
3. Facultatif : Filtrez les alertes par état, gravité et source en sélectionnant des filtres dans la liste Filter.
4. Facultatif : Triez les alertes en cliquant sur un ou plusieurs des en-têtes de colonne Name, Severity, State, et Source.

5. Sélectionnez le nom d'une alerte pour accéder à sa page Alert Details. La page comprend un graphique qui illustre les données chronologiques de l'alerte. Elle fournit également des informations sur l'alerte, notamment

   • Une description de l'alerte
   • Messages associés aux alertes
   • Étiquettes jointes au signalement
   • Un lien vers la règle d'alerte qui la régit
   • Silences pour l'alerte, s'il y en a

1. Naviguez jusqu'à la page Observe → Alerting → Silences.
2. Facultatif : Filtrez les silences par nom en utilisant le champ Search by name.
3. Facultatif : Filtrez les silences par État en sélectionnant des filtres dans la liste Filter. Par défaut, les filtres Active et Pending sont appliqués.
4. Facultatif : Triez les silences en cliquant sur un ou plusieurs des en-têtes de colonne Name, Firing Alerts, et State.

5. Sélectionnez le nom d'un silence pour accéder à sa page Silence Details. La page contient les informations suivantes :

   • Spécification d'alerte
   • Heure de début
   • Heure de fin
   • État de silence
   • Nombre et liste des avis de tir

1. Naviguez jusqu'à la page Observe → Alerting → Alerting Rules.
2. Facultatif : Filtrez les règles d'alerte par état, gravité et source en sélectionnant des filtres dans la liste Filter.
3. Facultatif : Triez les règles d'alerte en cliquant sur un ou plusieurs des en-têtes de colonne Name, Severity, Alert State, et Source.

4. Sélectionnez le nom d'une règle d'alerte pour accéder à sa page Alerting Rule Details. La page fournit les détails suivants sur la règle d'alerte :

   • Nom, gravité et description de la règle d'alerte
   • L'expression qui définit la condition de déclenchement de l'alerte
   • Durée pendant laquelle la condition doit être remplie pour qu'une alerte soit déclenchée
   • Un graphique pour chaque alerte régie par la règle d'alerte, indiquant la valeur avec laquelle l'alerte est déclenchée
   • Un tableau de toutes les alertes régies par la règle d'alerte

1. Naviguez jusqu'à la page Observe → <project_name> → Alerts.

2. Afficher les détails d'une alerte, d'un silence ou d'une règle d'alerte :

   • Alert Details peut être consultée en sélectionnant > à gauche du nom d'une alerte, puis en sélectionnant l'alerte dans la liste.

   • Silence Details peuvent être consultés en sélectionnant un silence dans la section Silenced By de la page Alert Details. La page Silence Details contient les informations suivantes :

     • Spécification d'alerte
     • Heure de début
     • Heure de fin
     • État de silence
     • Nombre et liste des avis de tir
   • Alerting Rule Details peut être consultée en sélectionnant View Alerting Rule dans le à droite d'une alerte sur la page Alerts.

1. Imprimer la configuration active de l'Alertmanager dans le fichier alertmanager.yaml:

   $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml

2. Modifiez la configuration sur alertmanager.yaml:

   global:
     resolve_timeout: 5m
   route:
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 12h
     receiver: default
     routes:
     - matchers:
       - "alertname=Watchdog"
       repeat_interval: 5m
       receiver: watchdog
     - matchers:
       - "service=<your_service>" 1
       routes:
       - matchers:
         - <your_matching_rules> 2
         receiver: <receiver> 3
   receivers:
   - name: default
   - name: watchdog
   - name: <receiver>
   #  <receiver_configuration>

   1

   service spécifie le service qui déclenche les alertes.

   2

   <your_matching_rules> spécifie les alertes cibles.

   3

   receiver spécifie le récepteur à utiliser pour l'alerte.

   Note

   Utilisez le nom de clé matchers pour indiquer les critères de correspondance qu'une alerte doit remplir pour correspondre au nœud. N'utilisez pas les noms de clés match ou match_re, qui sont tous deux obsolètes et dont la suppression est prévue dans une prochaine version.

   En outre, si vous définissez des règles d'inhibition, utilisez le nom de clé target_matchers pour indiquer les correspondants cibles et le nom de clé source_matchers pour indiquer les correspondants sources. N'utilisez pas les noms de clés target_match, target_match_re, source_match ou source_match_re, qui sont obsolètes et dont la suppression est prévue dans une prochaine version.

   L'exemple de configuration suivant de l'Alertmanager configure PagerDuty en tant que récepteur d'alertes :

   global:
     resolve_timeout: 5m
   route:
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 12h
     receiver: default
     routes:
     - matchers:
       - "alertname=Watchdog"
       repeat_interval: 5m
       receiver: watchdog
     - matchers: - "service=example-app" routes: - matchers: - "severity=critical" receiver: team-frontend-page
   receivers:
   - name: default
   - name: watchdog
   - name: team-frontend-page pagerduty_configs: - service_key: "your-key"

   Avec cette configuration, les alertes de gravité critical déclenchées par le service example-app sont envoyées à l'aide du récepteur team-frontend-page. En règle générale, ces types d'alertes sont envoyés à une personne ou à une équipe d'intervention critique.

3. Appliquer la nouvelle configuration dans le fichier :

   $ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-monitoring replace secret --filename=-

1. Naviguez jusqu'à la page Administration → Cluster Settings → Configuration → Alertmanager → YAML de la console web.
2. Modifier le fichier de configuration YAML.
3. Sélectionnez Save.

Procédure

1. Imprimer la configuration active de l'Alertmanager dans le fichier alertmanager.yaml:

   $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml"\N-) }}' | base64 --decode > alertmanager.yaml

2. Modifiez la configuration sur alertmanager.yaml:

   route:
     receiver: Default
     group_by:
     - name: Default
     routes:
     - matchers:
       - "service = prometheus-example-monitor" 1
       receiver: <receiver> 2
   receivers:
   - name: Default
   - name: <receiver>
   #  <receiver_configuration>

   1

   Spécifie les alertes qui correspondent à l'itinéraire. Cet exemple montre toutes les alertes qui ont l'étiquette service="prometheus-example-monitor".

   2

   Spécifie le récepteur à utiliser pour le groupe d'alertes.

3. Appliquer la nouvelle configuration dans le fichier :

   $ oc -n openshift-user-workload-monitoring create secret generic alertmanager-user-workload --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-user-workload-monitoring replace secret --filename=-

Procédure

1. In the Administrator perspective in the OpenShift Container Platform web console, navigate to Observe → Dashboards.
2. Choisissez un tableau de bord dans la liste Dashboard. Certains tableaux de bord, tels que les tableaux de bord etcd et Prometheus, produisent des sous-menus supplémentaires lorsqu'ils sont sélectionnés.

3. Optional: Select a time range for the graphs in the Time Range list.

   • Select a pre-defined time period.

   • Set a custom time range by selecting Custom time range in the Time Range list.

     1. Input or select the From and To dates and times.
     2. Click Save to save the custom time range.
4. Optional: Select a Refresh Interval.
5. Hover over each of the graphs within a dashboard to display detailed information about specific items.

Procédure

1. Dans la perspective développeur de la console web OpenShift Container Platform, naviguez vers Observe → Dashboard.
2. Sélectionnez un projet dans la liste déroulante Project:.

3. Sélectionnez un tableau de bord dans la liste déroulante Dashboard pour afficher les mesures filtrées.

   Note

   Tous les tableaux de bord produisent des sous-menus supplémentaires lorsqu'ils sont sélectionnés, à l'exception de Kubernetes / Compute Resources / Namespace (Pods).

4. Optional: Select a time range for the graphs in the Time Range list.

   • Select a pre-defined time period.

   • Set a custom time range by selecting Custom time range in the Time Range list.

     1. Input or select the From and To dates and times.
     2. Click Save to save the custom time range.
5. Optional: Select a Refresh Interval.
6. Hover over each of the graphs within a dashboard to display detailed information about specific items.

1. Ajouter le dépôt Helm :

   $ helm repo add rh-ecosystem-edge https://rh-ecosystem-edge.github.io/console-plugin-nvidia-gpu

   $ helm repo update

2. Installez la carte Helm dans l'espace de noms par défaut de l'opérateur NVIDIA GPU :

   $ helm install -n nvidia-gpu-operator console-plugin-nvidia-gpu rh-ecosystem-edge/console-plugin-nvidia-gpu

   Exemple de sortie

   NAME: console-plugin-nvidia-gpu
   LAST DEPLOYED: Tue Aug 23 15:37:35 2022
   NAMESPACE: nvidia-gpu-operator
   STATUS: deployed
   REVISION: 1
   NOTES:
   View the Console Plugin NVIDIA GPU deployed resources by running the following command:
   
   $ oc -n {{ .Release.Namespace }} get all -l app.kubernetes.io/name=console-plugin-nvidia-gpu
   
   Enable the plugin by running the following command:
   
   # Check if a plugins field is specified
   $ oc get consoles.operator.openshift.io cluster --output=jsonpath="{.spec.plugins}"
   
   # if not, then run the following command to enable the plugin
   $ oc patch consoles.operator.openshift.io cluster --patch '{ "spec": { "plugins": ["console-plugin-nvidia-gpu"] } }' --type=merge
   
   # if yes, then run the following command to enable the plugin
   $ oc patch consoles.operator.openshift.io cluster --patch '[{"op": "add", "path": "/spec/plugins/-", "value": "console-plugin-nvidia-gpu" }]' --type=json
   
   # add the required DCGM Exporter metrics ConfigMap to the existing NVIDIA operator ClusterPolicy CR:
   oc patch clusterpolicies.nvidia.com gpu-cluster-policy --patch '{ "spec": { "dcgmExporter": { "config": { "name": "console-plugin-nvidia-gpu" } } } }' --type=merge

   Le tableau de bord s'appuie principalement sur les métriques Prometheus exposées par l'exportateur NVIDIA DCGM, mais les métriques exposées par défaut ne sont pas suffisantes pour que le tableau de bord rende les jauges nécessaires. C'est pourquoi l'exportateur DGCM est configuré pour exposer un ensemble personnalisé de mesures, comme indiqué ici.

   apiVersion: v1
   data:
     dcgm-metrics.csv: |
       DCGM_FI_PROF_GR_ENGINE_ACTIVE, gauge, gpu utilization.
       DCGM_FI_DEV_MEM_COPY_UTIL, gauge, mem utilization.
       DCGM_FI_DEV_ENC_UTIL, gauge, enc utilization.
       DCGM_FI_DEV_DEC_UTIL, gauge, dec utilization.
       DCGM_FI_DEV_POWER_USAGE, gauge, power usage.
       DCGM_FI_DEV_POWER_MGMT_LIMIT_MAX, gauge, power mgmt limit.
       DCGM_FI_DEV_GPU_TEMP, gauge, gpu temp.
       DCGM_FI_DEV_SM_CLOCK, gauge, sm clock.
       DCGM_FI_DEV_MAX_SM_CLOCK, gauge, max sm clock.
       DCGM_FI_DEV_MEM_CLOCK, gauge, mem clock.
       DCGM_FI_DEV_MAX_MEM_CLOCK, gauge, max mem clock.
   kind: ConfigMap
   metadata:
     annotations:
       meta.helm.sh/release-name: console-plugin-nvidia-gpu
       meta.helm.sh/release-namespace: nvidia-gpu-operator
     creationTimestamp: "2022-10-26T19:46:41Z"
     labels:
       app.kubernetes.io/component: console-plugin-nvidia-gpu
       app.kubernetes.io/instance: console-plugin-nvidia-gpu
       app.kubernetes.io/managed-by: Helm
       app.kubernetes.io/name: console-plugin-nvidia-gpu
       app.kubernetes.io/part-of: console-plugin-nvidia-gpu
       app.kubernetes.io/version: latest
       helm.sh/chart: console-plugin-nvidia-gpu-0.2.3
     name: console-plugin-nvidia-gpu
     namespace: nvidia-gpu-operator
     resourceVersion: "19096623"
     uid: 96cdf700-dd27-437b-897d-5cbb1c255068

   Installez le ConfigMap et modifiez le CR de la politique de cluster de l'opérateur NVIDIA pour ajouter ce ConfigMap à la configuration de l'exportateur DCGM. L'installation du ConfigMap est effectuée par la nouvelle version du plugin de console NVIDIA GPU Helm Chart, mais l'édition du CR ClusterPolicy est effectuée par l'utilisateur.

3. Voir les ressources déployées :

   $ oc -n nvidia-gpu-operator get all -l app.kubernetes.io/name=console-plugin-nvidia-gpu

   Exemple de sortie

   NAME                                             READY   STATUS    RESTARTS   AGE
   pod/console-plugin-nvidia-gpu-7dc9cfb5df-ztksx   1/1     Running   0          2m6s
   
   NAME                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/console-plugin-nvidia-gpu   ClusterIP   172.30.240.138   <none>        9443/TCP   2m6s
   
   NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/console-plugin-nvidia-gpu   1/1     1            1           2m6s
   
   NAME                                                   DESIRED   CURRENT   READY   AGE
   replicaset.apps/console-plugin-nvidia-gpu-7dc9cfb5df   1         1         1       2m6s

Vérification

1. Vérifiez que l'opérateur d'interconnexion AMQ est disponible et que les pods requis sont en cours d'exécution :

   $ oc get pods -n amq-interconnect

   Exemple de sortie

   NAME                                    READY   STATUS    RESTARTS   AGE
   amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
   interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

2. Vérifiez que le pod de production d'événements bare-metal bare-metal-event-relay requis est en cours d'exécution dans l'espace de noms openshift-bare-metal-events:

   $ oc get pods -n openshift-bare-metal-events

   Exemple de sortie

   NAME                                                            READY   STATUS    RESTARTS   AGE
   hw-event-proxy-operator-controller-manager-74d5649b7c-dzgtl     2/2     Running   0          25s

Procédure

1. Récupérer le jeton du porteur :

   $ token=`oc whoami -t`

2. Interroger les métriques de la route /federate. L'exemple suivant interroge les métriques de up:

   $ curl -G -s -k -H "Authorization: Bearer $token" \
       'https:/<federation_host>/federate' \ 1
       --data-urlencode 'match[]=up'

   1

   Pour <federation_host>, remplacez l'URL de l'hôte pour la route de la fédération.

   Exemple de sortie

   # TYPE up untyped
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.143.148:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035322214
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.148.166:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035338597
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.173.16:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035343834
   ...

Procédure

1. Check that the corresponding labels match dans les configurations des services et des ressources ServiceMonitor.

   1. Obtenir le label défini dans le service. L'exemple suivant interroge le service prometheus-example-app dans le projet ns1:

      $ oc -n ns1 get service prometheus-example-app -o yaml

      Exemple de sortie

        labels:
          app: prometheus-example-app

   2. Vérifiez que l'étiquette matchLabels app dans la configuration de la ressource ServiceMonitor correspond à l'étiquette produite à l'étape précédente :

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      Exemple de sortie

      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app

      Note

      Vous pouvez vérifier les étiquettes de service et de ressource ServiceMonitor en tant que développeur disposant d'autorisations de visualisation pour le projet.

2. Inspect the logs for the Prometheus Operator dans le projet openshift-user-workload-monitoring.

   1. Liste les pods du projet openshift-user-workload-monitoring:

      $ oc -n openshift-user-workload-monitoring get pods

      Exemple de sortie

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

   2. Obtenez les journaux du conteneur prometheus-operator dans le pod prometheus-operator. Dans l'exemple suivant, le module s'appelle prometheus-operator-776fcbbd56-2nbfm:

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      En cas de problème avec le moniteur de service, les journaux peuvent contenir une erreur similaire à cet exemple :

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload

3. Review the target status for your endpoint sur la page Metrics targets dans l'interface de la console web de OpenShift Container Platform.

   1. Connectez-vous à la console web de OpenShift Container Platform et naviguez vers Observe → Targets dans la perspective Administrator.
   2. Localisez le point de terminaison des métriques dans la liste et vérifiez l'état de la cible dans la colonne Status.
   3. Si l'adresse Status est Down, cliquez sur l'URL du point de terminaison pour obtenir plus d'informations sur la page Target Details relative à cette cible de mesure.

4. Configure debug level logging for the Prometheus Operator dans le projet openshift-user-workload-monitoring.

   1. Modifiez l'objet user-workload-monitoring-config ConfigMap dans le projet openshift-user-workload-monitoring:

      $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

   2. Ajoutez logLevel: debug pour prometheusOperator sous data/config.yaml pour définir le niveau du journal à debug:

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |
          prometheusOperator:
            logLevel: debug

   3. Enregistrez le fichier pour appliquer les modifications.

      Note

      Le site prometheus-operator du projet openshift-user-workload-monitoring redémarre automatiquement lorsque vous appliquez la modification du niveau de journalisation.

   4. Confirmez que le niveau de journalisation debug a été appliqué au déploiement prometheus-operator dans le projet openshift-user-workload-monitoring:

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      Exemple de sortie

              - --log-level=debug

      La journalisation de niveau débogage montre tous les appels effectués par l'opérateur Prometheus.

   5. Vérifiez que le pod prometheus-operator fonctionne :

      $ oc -n openshift-user-workload-monitoring get pods

      Note

      Si une valeur Prometheus Operator loglevel non reconnue est incluse dans la carte de configuration, le pod prometheus-operator peut ne pas redémarrer avec succès.

   6. Examinez les journaux de débogage pour voir si l'opérateur Prometheus utilise la ressource ServiceMonitor. Examinez les journaux pour voir s'il y a d'autres erreurs connexes.

Procédure

1. Dans la perspective Administrator, naviguez vers Observe → Metrics.

2. Exécutez la requête Prometheus Query Language (PromQL) suivante dans le champ Expression. Cette requête renvoie les dix métriques qui ont le plus grand nombre d'échantillons de scrape :

   topk(10,count by (job)({__name__=~".+"}))

3. Étudier le nombre de valeurs d'étiquettes non liées attribuées à des mesures dont le nombre d'échantillons raclés est plus élevé que prévu.

   • If the metrics relate to a user-defined projectdans le cas d'une charge de travail, passez en revue les paires clé-valeur de métriques attribuées à votre charge de travail. Celles-ci sont mises en œuvre par les bibliothèques client Prometheus au niveau de l'application. Essayez de limiter le nombre d'attributs non liés référencés dans vos étiquettes.
   • If the metrics relate to a core OpenShift Container Platform projectcréez un dossier d'assistance Red Hat sur le portail client Red Hat.

4. Examinez l'état de la TSDB à l'aide de l'API HTTP Prometheus en exécutant les commandes suivantes en tant qu'administrateur de cluster :

   $ oc login -u <nom d'utilisateur> -p <mot de passe>

   $ host=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.spec.host})

   $ token=$(oc whoami -t)

   $ curl -H "Authorization: Bearer $token" -k "https://$host/api/v1/status/tsdb"

   Exemple de sortie

   "status": "success",