Chapitre 16. Dépannage des problèmes de surveillance
16.1. Déterminer pourquoi les mesures définies par l'utilisateur ne sont pas disponibles Copier lienLien copié sur presse-papiers!
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-configConfigMap. -
Vous avez créé une ressource
ServiceMonitor.
Procédure
Check that the corresponding labels match dans les configurations des services et des ressources
ServiceMonitor.Obtenir le label défini dans le service. L'exemple suivant interroge le service
prometheus-example-appdans le projetns1:oc -n ns1 get service prometheus-example-app -o yaml
$ oc -n ns1 get service prometheus-example-app -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
labels: app: prometheus-example-applabels: app: prometheus-example-appCopy to Clipboard Copied! Toggle word wrap Toggle overflow Vérifiez que l'étiquette
matchLabelsappdans la configuration de la ressourceServiceMonitorcorrespond à l'étiquette produite à l'étape précédente :oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml
$ oc -n ns1 get servicemonitor prometheus-example-monitor -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
spec: endpoints: - interval: 30s port: web scheme: http selector: matchLabels: app: prometheus-example-appspec: endpoints: - interval: 30s port: web scheme: http selector: matchLabels: app: prometheus-example-appCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteVous pouvez vérifier les étiquettes de service et de ressource
ServiceMonitoren tant que développeur disposant d'autorisations de visualisation pour le projet.
Inspect the logs for the Prometheus Operator dans le projet
openshift-user-workload-monitoring.Liste les pods du projet
openshift-user-workload-monitoring:oc -n openshift-user-workload-monitoring get pods
$ oc -n openshift-user-workload-monitoring get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 132mCopy to Clipboard Copied! Toggle word wrap Toggle overflow Obtenez les journaux du conteneur
prometheus-operatordans le podprometheus-operator. Dans l'exemple suivant, le module s'appelleprometheus-operator-776fcbbd56-2nbfm:oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator
$ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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-workloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Review the target status for your endpoint sur la page Metrics targets dans l'interface de la console web de OpenShift Container Platform.
-
Connectez-vous à la console web de OpenShift Container Platform et naviguez vers Observe
Targets dans la perspective Administrator. - Localisez le point de terminaison des métriques dans la liste et vérifiez l'état de la cible dans la colonne Status.
- 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.
-
Connectez-vous à la console web de OpenShift Container Platform et naviguez vers Observe
Configure debug level logging for the Prometheus Operator dans le projet
openshift-user-workload-monitoring.Modifiez l'objet
user-workload-monitoring-configConfigMapdans le projetopenshift-user-workload-monitoring:oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-configCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ajoutez
logLevel: debugpourprometheusOperatorsousdata/config.yamlpour 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: debugapiVersion: v1 kind: ConfigMap metadata: name: user-workload-monitoring-config namespace: openshift-user-workload-monitoring data: config.yaml: | prometheusOperator: logLevel: debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enregistrez le fichier pour appliquer les modifications.
NoteLe site
prometheus-operatordu projetopenshift-user-workload-monitoringredémarre automatiquement lorsque vous appliquez la modification du niveau de journalisation.Confirmez que le niveau de journalisation
debuga été appliqué au déploiementprometheus-operatordans le projetopenshift-user-workload-monitoring:oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml | grep "log-level"
$ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml | grep "log-level"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Exemple de sortie
- --log-level=debug
- --log-level=debugCopy to Clipboard Copied! Toggle word wrap Toggle overflow La journalisation de niveau débogage montre tous les appels effectués par l'opérateur Prometheus.
Vérifiez que le pod
prometheus-operatorfonctionne :oc -n openshift-user-workload-monitoring get pods
$ oc -n openshift-user-workload-monitoring get podsCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteSi une valeur Prometheus Operator
loglevelnon reconnue est incluse dans la carte de configuration, le podprometheus-operatorpeut ne pas redémarrer avec succès.-
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.