Résoudre les problèmes liés aux tableaux de bord de surveillance

Autopilot Standard

Cette page explique comment résoudre les problèmes liés aux tableaux de bord de surveillance pour Google Kubernetes Engine (GKE).

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.

Par défaut, Monitoring est activé lorsque vous créez un cluster. Si vous ne voyez pas les tableaux de bord GKE lorsque vous consultez les tableaux de bord Google Cloud fournis dans Monitoring, Monitoring n'est pas activé pour les clusters du projet Google Cloud sélectionné. Activez la surveillance pour afficher ces tableaux de bord.

Aucune ressource Kubernetes ne s'affiche dans mon tableau de bord

Si vous ne voyez aucune ressource Kubernetes dans votre tableau de bord GKE, vérifiez les points suivants :

Projet Google Cloud sélectionné

Vérifiez que vous avez sélectionné le projet Google Cloud approprié dans la liste déroulante de la barre de menu de la console Google Cloud pour sélectionner un projet. Vous devez choisir le projet pour lequel vous souhaitez afficher les données.

Activité des clusters

Si vous venez de créer le cluster, attendez quelques minutes que les données arrivent. Pour en savoir plus, consultez Configurer la journalisation et la surveillance pour GKE.

Période

La période sélectionnée est peut-être trop restrictive. Vous pouvez sélectionner d'autres périodes ou définir une période personnalisée dans le menu Temps de la barre d'outils du tableau de bord.

Autorisations pour afficher le tableau de bord

Si l'un des messages d'erreur suivants indiquant un refus d'autorisation s'affiche lorsque vous consultez les informations de déploiement d'un service ou les métriques d'un projet Google Cloud, vous devez mettre à jour votre rôle IAM pour y ajouter roles/monitoring.viewer ou roles/viewer :

You do not have sufficient permissions to view this page
You don't have permissions to perform the action on the selected resources

Pour plus de détails, consultez la section Rôles prédéfinis.

Autorisations du compte de service pour les clusters et les nœuds permettant d'écrire des données dans Monitoring et Logging

Si vous constatez des taux d'erreur élevés sur la page API et services activés de la console Google Cloud, il se peut que votre compte de service ne dispose pas des rôles suivants :

roles/logging.logWriter : dans Google Cloud Console, ce rôle est appelé Rédacteur de journaux. Pour en savoir plus sur les rôles Logging, consultez le guide du contrôle des accès de Logging.
roles/monitoring.metricWriter : dans Google Cloud Console, ce rôle est appelé Rédacteur de métriques Monitoring. Pour en savoir plus sur les rôles Monitoring, consultez le guide du contrôle des accès de Monitoring.
roles/stackdriver.resourceMetadata.writer : dans Google Cloud Console, ce rôle est appelé Rédacteur de métadonnées de ressource Stackdriver. Il accorde un accès en écriture seule aux métadonnées de ressource et fournit exactement les autorisations nécessaires aux agents qui envoient des métadonnées. Pour en savoir plus sur les rôles Monitoring, consultez le guide du contrôle des accès de Monitoring.

Pour répertorier vos comptes de service, accédez à IAM et administration dans la console Google Cloud, puis sélectionnez Comptes de service.

Impossible d'afficher les journaux

Si vos journaux ne s'affichent pas dans les tableaux de bord, vérifiez les points suivants :

Agent en cours d'exécution et opérationnel

Les versions 1.17 et ultérieures de GKE utilisent Fluent Bit pour capturer les journaux. Fluent Bit est l'agent Logging qui s'exécute sur les nœuds Kubernetes. Pour vérifier si l'agent s'exécute correctement, procédez comme suit :

Vérifiez si l'agent redémarre en exécutant la commande suivante :

kubectl get pods -l k8s-app=fluentbit-gke -n kube-system

S'il n'y a pas de redémarrage, le résultat ressemble à ce qui suit :

NAME                  READY   STATUS    RESTARTS   AGE
fluentbit-gke-6zr6g   2/2     Running   0          44d
fluentbit-gke-dzh9l   2/2     Running   0          44d

Vérifiez les conditions d'état du pod en exécutant la commande suivante :

JSONPATH='{range .items[*]};{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status},{end}{end};'  \
 && kubectl get pods -l k8s-app=fluentbit-gke -n kube-system -o jsonpath="$JSONPATH" | tr ";" "\n"

Si le déploiement est opérationnel, le résultat ressemble à ce qui suit :

fluentbit-gke-nj4qs:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,
fluentbit-gke-xtcvt:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,

Vérifiez l'état du pod, qui peut vous aider à déterminer si le déploiement est opérationnel, en exécutant la commande suivante :
```
kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-system
```
Si le déploiement est opérationnel, le résultat ressemble à ce qui suit :
```
NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentbit-gke   2         2         2       2            2           kubernetes.io/os=linux   5d19h
```
Dans cet exemple de résultat, l'état souhaité correspond à l'état actuel.

Si l'agent est en cours d'exécution et opérationnel dans ces scénarios, et que vous ne voyez toujours pas tous vos journaux, il peut être surchargé et supprimer des journaux.

Agent surchargé au point de supprimer des journaux

Certains journaux peuvent ne pas apparaître si l'agent est surchargé par le volume de journaux des nœuds. La configuration par défaut de l'agent Logging dans GKE est réglée pour un débit de 100 kio par seconde pour chaque nœud. Au-delà de cette limite, l'agent peut commencer à perdre des journaux.

Pour déterminer si cette limite est atteinte, recherchez la présence des indicateurs de surcharge suivants :

Affichez la métrique kubernetes.io/container/cpu/core_usage_time avec le filtre container_name=fluentbit-gke et regardez si l'utilisation du processeur de l'agent Logging est proche de ou égale à 100 %.
Affichez la métrique logging.googleapis.com/byte_count regroupée par metadata.system_labels.node_name et regardez si un nœud atteint 100 kio par seconde.

Si l'un de ces indicateurs est présent, vous pouvez réduire le volume de journaux de vos nœuds en ajoutant des nœuds au cluster. Si l'intégralité du volume des journaux provient d'un seul pod, vous devez réduire le volume sur ce pod-là.

Pour plus d'informations sur l'analyse et la résolution des problèmes liés à la journalisation GKE, consultez la page Dépannage de la journalisation dans GKE.

Incident non associé à une ressource GKE

Si vous disposez d'une condition de règle d'alerte qui agrège des métriques sur des ressources GKE distinctes, vous devrez peut-être la modifier afin d'inclure davantage de libellés de hiérarchie GKE pour associer des incidents à des entités spécifiques.

Par exemple, vous pouvez disposer de deux clusters GKE, un en production et un en préproduction, possédant chacun sa propre copie du service lilbuddy-2. Lorsque la condition de règle d'alerte agrège une métrique en rapport avec les conteneurs des deux clusters, le tableau de bord Monitoring de GKE ne peut pas associer cet incident de manière unique au service de production ou au service de préproduction.

Pour résoudre ce problème, ciblez la règle d'alerte sur un service spécifique en ajoutant namespace, cluster et location dans le champ Grouper par de la règle. Sur la carte d'événement de l'alerte, cliquez sur le lien Mettre à jour la règle d'alerte pour ouvrir la page Modifier la règle d'alerte pour la règle d'alerte concernée. Vous pouvez ensuite mettre à jour la règle d'alerte avec des informations supplémentaires afin que le tableau de bord puisse localiser la ressource associée.

Une fois la règle d'alerte mise à jour, le tableau de bord Monitoring de GKE est en mesure d'associer tous les futurs incidents à un service unique dans un cluster spécifique, ce qui vous donne des informations supplémentaires pour diagnostiquer le problème.

Selon votre cas d'utilisation, vous devrez peut-être filtrer certains de ces libellés, en plus de les ajouter au champ Grouper par. Par exemple, si vous souhaitez n'afficher que les alertes relatives à votre cluster de production, vous pouvez filtrer selon cluster_name.

Étapes suivantes