Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

8.9. Enquête sur les questions de surveillance

Le service OpenShift Red Hat sur AWS inclut une pile de surveillance préconfigurée, préinstallée et auto-mise à jour qui fournit la surveillance des composants de la plate-forme de base. Dans Red Hat OpenShift Service sur AWS 4, les administrateurs de clusters peuvent optionnellement activer la surveillance des projets définis par l’utilisateur.

B) Utilisez ces procédures si les problèmes suivants se posent:

  • Les métriques sont indisponibles.
  • « Prometheus consomme beaucoup d’espace disque.
  • L’alerte KubePersistentVolumeFillingUp tire pour Prometheus.

Les ressources ServiceMonitor vous permettent de déterminer comment utiliser les métriques exposées par un service dans des projets définis par l’utilisateur. Suivez les étapes décrites dans cette procédure si vous avez créé une ressource ServiceMonitor mais ne pouvez pas voir les mesures correspondantes dans l’interface utilisateur de Metrics.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.
  • La surveillance est activée et configurée pour les projets définis par l’utilisateur.
  • Création d’une ressource ServiceMonitor.

Procédure

  1. Assurez-vous que les étiquettes correspondantes correspondent aux configurations de ressources ServiceMonitor et ServiceMonitor.

    1. D’obtenir l’étiquette définie 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
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

        labels:
    app: prometheus-example-app
      Copy to Clipboard Toggle word wrap

    2. Assurez-vous que la définition de matchLabels dans la configuration de la ressource ServiceMonitor correspond à la sortie de l’étiquette à l’étape précédente. L’exemple suivant interroge le moniteur de service prometheus-example-monitor dans le projet ns1: 

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      apiVersion: v1
kind: ServiceMonitor
metadata:
  name: prometheus-example-monitor
  namespace: ns1
spec:
  endpoints:
  - interval: 30s
    port: web
    scheme: http
  selector:
    matchLabels:
      app: prometheus-example-app
      Copy to Clipboard Toggle word wrap

      Note

      En tant que développeur, vous pouvez vérifier les étiquettes de service et de ressources ServiceMonitor avec les autorisations pour le projet.

  2. Inspecter les logs de l’opérateur Prometheus dans le cadre du projet de surveillance de la charge de travail ouverte de l’utilisateur.

    1. Énumérez les pods dans le projet openshift-user-workload-monitoring: 

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap

      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
      Copy to Clipboard Toggle word wrap

    2. D’obtenir les billes à partir du conteneur protéréheus-operator dans la pod de promesseheus-operator. Dans l’exemple suivant, le pod est appelé prometheus-operator-776fcbbd56-2nbfm: 

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator
      Copy to Clipboard Toggle word wrap

      En cas de problème avec le moniteur de service, les journaux peuvent inclure 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
      Copy to Clipboard Toggle word wrap

  3. Consultez l’état cible de votre point de terminaison sur la page cible Metrics dans le service OpenShift Red Hat sur l’interface utilisateur de la console Web AWS.

    1. Connectez-vous au service Red Hat OpenShift sur la console web AWS et accédez à Observer Targets dans la perspective de l’administrateur.
    2. Localisez le point de terminaison des métriques dans la liste, et examinez l’état de la cible dans la colonne État.
    3. Dans le cas où l’état est en panne, cliquez sur l’URL du point de terminaison pour afficher plus d’informations sur la page Détails de la cible pour cette cible de mesures.

  4. Configurez la journalisation du niveau de débogage pour l’opérateur Prometheus dans le projet openshift-user-workload-monitoring.

    1. Éditer l’objet ConfigMap de l’utilisateur-workload-monitoring-config 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. Ajouter logLevel: débogage pour proteheusOperator sous data/config.yaml pour définir le niveau de journal à déboguer: 

      apiVersion: v1
kind: ConfigMap
metadata:
  name: user-workload-monitoring-config
  namespace: openshift-user-workload-monitoring
data:
  config.yaml: |
    prometheusOperator:
      logLevel: debug
# ...
      Copy to Clipboard Toggle word wrap
    3. Enregistrez le fichier pour appliquer les modifications. Le pod de promesse-opérateur affecté est automatiquement redéployé.

    4. Confirmez que le niveau de journal de débogage a été appliqué au déploiement protéréheus-operator dans le projet openshift-user-workload-monitoring: 

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

              - --log-level=debug
      Copy to Clipboard Toggle word wrap

      L’enregistrement de niveau de débogage affichera tous les appels effectués par l’opérateur Prometheus.

    5. Assurez-vous que le pod protéréheus-operator est en cours d’exécution: 

      $ oc -n openshift-user-workload-monitoring get pods
      Copy to Clipboard Toggle word wrap
      Note

      Lorsqu’une valeur de niveau de journal Prometheus Operator non reconnue est incluse dans la carte de configuration, le pod prometheus-operator pourrait ne pas redémarrer avec succès.

    6. Consultez les journaux de débogage pour voir si l’opérateur Prometheus utilise la ressource ServiceMonitor. Examinez les journaux pour d’autres erreurs connexes.

Les développeurs peuvent créer des étiquettes pour définir des attributs pour les métriques sous la forme de paires clé-valeur. Le nombre de paires de valeurs clés potentielles correspond au nombre de valeurs possibles pour un attribut. L’attribut qui a un nombre illimité de valeurs potentielles s’appelle un attribut non lié. A titre d’exemple, un attribut customer_id est non lié parce qu’il a un nombre infini de valeurs possibles.

Chaque paire clé-valeur assignée a une série chronologique unique. L’utilisation de nombreux attributs non liés dans les étiquettes peut entraîner une augmentation exponentielle du nombre de séries chronologiques créées. Cela peut avoir un impact sur les performances de Prometheus et peut consommer beaucoup d’espace disque.

Lorsque Prometheus consomme beaucoup de disque, vous pouvez utiliser les mesures suivantes:

  • Consultez l’état de la base de données des séries chronologiques (TSDB) à l’aide de l’API HTTP Prometheus pour plus d’informations sur les étiquettes qui créent le plus de données de séries chronologiques. Cela nécessite des privilèges d’administrateur de cluster.
  • Consultez le nombre d’échantillons d’éraflures qui sont collectés.

  • Diminuer le nombre de séries chronologiques uniques qui sont créées en réduisant le nombre d’attributs non liés qui sont attribués à des métriques définies par l’utilisateur.

    Note

    L’utilisation d’attributs liés à un ensemble limité de valeurs possibles réduit le nombre de combinaisons de paires clé-valeur potentielles.

  • Appliquer des limites sur le nombre d’échantillons pouvant être grattés sur des projets définis par l’utilisateur. Cela nécessite des privilèges d’administrateur de cluster.

Conditions préalables

  • En tant qu’utilisateur, vous avez accès au cluster avec le rôle d’administrateur dédié.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Dans la perspective de l’administrateur, accédez à Observer Metrics.

  2. Entrez une requête Prometheus Query Language (PromQL) dans le champ Expression. Les requêtes d’exemple suivantes aident à identifier les métriques de haute cardinalité qui pourraient entraîner une consommation élevée d’espace disque:

    • En exécutant la requête suivante, vous pouvez identifier les dix emplois qui ont le plus grand nombre d’échantillons de raclette: 

      topk(10, max by(namespace, job) (topk by(namespace, job) (1, scrape_samples_post_metric_relabeling)))
      Copy to Clipboard Toggle word wrap

    • En exécutant la requête suivante, vous pouvez identifier les séries chronologiques en identifiant les dix emplois qui ont créé le plus de données de séries chronologiques au cours de la dernière heure: 

      topk(10, sum by(namespace, job) (sum_over_time(scrape_series_added[1h])))
      Copy to Clipboard Toggle word wrap

  3. Étudier le nombre de valeurs d’étiquettes non liées attribuées aux mesures dont le nombre d’échantillons de griffes est plus élevé que prévu:

    • Lorsque les métriques se rapportent à un projet défini par l’utilisateur, examinez les paires clés-valeur attribuées à votre charge de travail. Ceux-ci sont mis en œuvre par l’intermédiaire des bibliothèques clientes Prometheus au niveau de l’application. Essayez de limiter le nombre d’attributs non liés référencés dans vos étiquettes.
    • Lorsque les métriques se rapportent à un service de base Red Hat OpenShift sur le projet AWS, créez un cas de support Red Hat sur le portail client Red Hat.

  4. Examinez le statut TSDB à l’aide de l’API HTTP Prometheus en suivant ces étapes lorsqu’il est connecté en tant qu’administrateur dédié:

    1. Accédez à l’URL de route de l’API Prometheus en exécutant la commande suivante: 

      $ HOST=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.status.ingress[].host})
      Copy to Clipboard Toggle word wrap

    2. Extraire un jeton d’authentification en exécutant la commande suivante: 

      $ TOKEN=$(oc whoami -t)
      Copy to Clipboard Toggle word wrap

    3. Interrogez le statut TSDB pour Prometheus en exécutant la commande suivante: 

      $ curl -H "Authorization: Bearer $TOKEN" -k "https://$HOST/api/v1/status/tsdb"
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      "status": "success","data":{"headStats":{"numSeries":507473,
"numLabelPairs":19832,"chunkCount":946298,"minTime":1712253600010,
"maxTime":1712257935346},"seriesCountByMetricName":
[{"name":"etcd_request_duration_seconds_bucket","value":51840},
{"name":"apiserver_request_sli_duration_seconds_bucket","value":47718},
...
      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