SupportConsoleDéveloppeursCommencer un essaiContact

7.11. Enquêter sur les problèmes de surveillance

OpenShift Container Platform inclut une pile de surveillance préconfigurée, préinstallée et auto-actualisée qui fournit une surveillance pour les composants de base de la plateforme. Dans OpenShift Container Platform 4.12, les administrateurs de clusters peuvent optionnellement activer la surveillance pour des projets définis par l'utilisateur.

Vous pouvez suivre ces procédures si vos propres mesures ne sont pas disponibles ou si Prometheus consomme beaucoup d'espace disque.

7.11.1. Déterminer pourquoi les mesures définies par l'utilisateur ne sont pas disponibles

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 que vous ne voyez pas les métriques correspondantes dans l'interface utilisateur des métriques.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).
  • Vous avez activé et configuré la surveillance des charges de travail définies par l'utilisateur.
  • Vous avez créé l'objet user-workload-monitoring-config ConfigMap .
  • Vous avez créé une ressource ServiceMonitor.

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.

Ressources supplémentaires

7.11.2. Déterminer pourquoi Prometheus consomme beaucoup d'espace disque

Les développeurs peuvent créer des étiquettes pour définir les attributs des métriques sous la forme de paires clé-valeur. Le nombre de paires clé-valeur potentielles correspond au nombre de valeurs possibles pour un attribut. Un attribut dont le nombre de valeurs potentielles est illimité est appelé attribut non lié. Par exemple, un attribut customer_id est non consolidé car il possède un nombre infini de valeurs possibles.

Chaque paire clé-valeur attribué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 temporelles créées. Cela peut avoir un impact sur les performances de Prometheus et consommer beaucoup d'espace disque.

Vous pouvez utiliser les mesures suivantes lorsque Prometheus consomme beaucoup de disque :

  • Check the number of scrape samples qui sont collectés.
  • Check the time series database (TSDB) status using the Prometheus HTTP API pour plus d'informations sur les étiquettes qui créent le plus de séries temporelles. Cette opération nécessite des privilèges d'administrateur de cluster.

  • Reduce the number of unique time series that are created en réduisant le nombre d'attributs non liés attribués aux mesures définies par l'utilisateur.

    Note

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

  • Enforce limits on the number of samples that can be scraped dans des projets définis par l'utilisateur. Cette opération nécessite des privilèges d'administrateur de cluster.

Conditions préalables

  • Vous avez accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.
  • Vous avez installé l'OpenShift CLI (oc).

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",

Ressources supplémentaires

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.

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

© 2024 Red Hat, Inc.