Risolvere i problemi delle dashboard di monitoraggio

Questa pagina mostra come risolvere i problemi relativi alle dashboard di monitoraggio per Google Kubernetes Engine (GKE).

Per impostazione predefinita, Monitoring è abilitato quando crei un cluster. Se non vedi le dashboard GKE quando visualizzi le dashboard Google Cloud fornite in Monitoring, Monitoring non è abilitato per i cluster nel progetto Google Cloud selezionato. Abilita il monitoraggio per visualizzare queste dashboard.

Nella mia dashboard non sono presenti risorse Kubernetes

Se non vedi risorse Kubernetes nella tua dashboard GKE, controlla quanto segue:

Progetto Google Cloud selezionato

Verifica di aver selezionato il progetto Google Cloud corretto dall'elenco a discesa nella barra dei menu della console Google Cloud per selezionarlo. Devi selezionare il progetto di cui vuoi visualizzare i dati.

Attività dei cluster

Se hai appena creato il cluster, attendi qualche minuto affinché venga completato con i dati. Per maggiori dettagli, consulta Configurare il logging e il monitoraggio per GKE.

Intervallo di tempo

L'intervallo di tempo selezionato potrebbe essere troppo limitato. Puoi utilizzare il menu Tempo nella barra degli strumenti della dashboard per selezionare altri intervalli di tempo o definire un intervallo Personalizzato.

Autorizzazioni per visualizzare la dashboard

Se visualizzi uno dei seguenti messaggi di errore di cui è stata negata l'autorizzazione quando visualizzi i dettagli del deployment di un servizio o le metriche di un progetto Google Cloud, devi aggiornare il ruolo Identity and Access Management in modo da includere roles/monitoring.viewer o 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

Per maggiori dettagli, vai a Ruoli predefiniti.

Autorizzazioni dell'account di servizio del cluster e del nodo per scrivere dati in Monitoring e Logging

Se vedi tassi di errore elevati nella pagina API e servizi abilitati della console Google Cloud, è possibile che nel tuo account di servizio manchino i seguenti ruoli:

  • roles/logging.logWriter: nella console Google Cloud, questo ruolo è denominato Writer log. Per ulteriori informazioni sui ruoli di Logging, consulta la guida controllo dell'accesso Logging.

  • roles/monitoring.metricWriter: nella console Google Cloud, questo ruolo è denominato Monitoring Metric Writer. Per ulteriori informazioni sui ruoli in Monitoring, consulta la guida al controllo dell'accesso di Monitoring.

  • roles/stackdriver.resourceMetadata.writer: nella console Google Cloud, questo ruolo è denominato Stackdriver Resource Metadata Writer. Questo ruolo consente l'accesso in sola scrittura ai metadati delle risorse e fornisce esattamente le autorizzazioni necessarie agli agenti per inviare i metadati. Per ulteriori informazioni sui ruoli di Monitoring, consulta la guida per controllo dell'accesso Monitoring.

Per elencare i tuoi account di servizio, nella console Google Cloud vai a IAM e amministrazione e seleziona Account di servizio.

Impossibile visualizzare i log

Se non vedi i tuoi log nelle dashboard, verifica quanto segue:

L'agente è in esecuzione e in stato integro

GKE 1.17 e versioni successive utilizza Fluent Bit per acquisire i log. Fluent Bit è l'agente Logging che viene eseguito sui nodi Kubernetes. Per verificare se l'agente viene eseguito correttamente:

  1. Verifica se l'agente è in fase di riavvio eseguendo questo comando:

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

    Se non vengono eseguiti riavvii, l'output è simile al seguente:

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

  2. Controlla le condizioni dello stato del pod eseguendo questo comando:

    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"

    Se il deployment è integro, l'output è simile al seguente:

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

  3. Controlla lo stato del pod, che può aiutare a determinare se il deployment è integro eseguendo questo comando:

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

    Se il deployment è integro, l'output è simile al seguente:

    NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentbit-gke   2         2         2       2            2           kubernetes.io/os=linux   5d19h

    In questo output di esempio, lo stato desiderato corrisponde a quello attuale.

Se l'agente è in esecuzione ed è integro in questi scenari, e continui a non vedere tutti i tuoi log, è possibile che sia sovraccarico e i log vengano eliminati.

Agente sovraccarico e log in fase di eliminazione

Se non vedi tutti i log, è possibile che il volume dei log del nodo stia sovraccaricando l'agente. La configurazione predefinita dell'agente Logging in GKE è ottimizzata per la frequenza di 100 kiB al secondo per ciascun nodo e l'agente potrebbe iniziare a eliminare i log se il volume supera questo limite.

Per rilevare se stai raggiungendo questo limite, cerca uno dei seguenti indicatori:

  • Visualizza la metrica kubernetes.io/container/cpu/core_usage_time con il filtro container_name=fluentbit-gke per vedere se l'utilizzo della CPU dell'agente Logging è prossimo o al 100%.

  • Visualizza la metrica logging.googleapis.com/byte_count raggruppata per metadata.system_labels.node_name per vedere se uno o più nodi raggiunge i 100 kiB al secondo.

Se noti una di queste condizioni, puoi ridurre il volume dei log dei nodi aggiungendo altri nodi al cluster. Se tutto il volume dei log proviene da un singolo pod, devi ridurre il volume di quel pod.

Se vuoi modificare i parametri di ottimizzazione dell'agente Logging, guarda il tutorial della community per eseguire il deployment di una configurazione dell'agente Logging personalizzata.

Per maggiori informazioni su come indagare e risolvere i problemi relativi al logging di GKE, consulta Risoluzione dei problemi relativi al logging in GKE.

L'incidente non corrisponde a una risorsa GKE?

Se disponi di una condizione del criterio di avviso che aggrega metriche in diverse risorse GKE, potresti dover modificare la condizione del criterio in modo da includere più etichette della gerarchia GKE per associare gli incidenti a entità specifiche.

Ad esempio, potresti avere due cluster GKE, uno per la produzione e uno per la gestione temporanea, ciascuno con la propria copia del servizio lilbuddy-2. Quando la condizione del criterio di avviso aggrega una metrica nei container di entrambi i cluster, la dashboard di GKE Monitoring non è in grado di associare questo incidente in modo univoco al servizio di produzione o al servizio di gestione temporanea.

Per risolvere questa situazione, imposta come target del criterio di avviso un servizio specifico aggiungendo namespace, cluster e location al campo Raggruppa per del criterio. Nella scheda dell'evento relativo all'avviso, fai clic sul link Aggiorna criterio di avviso per aprire la pagina Modifica criterio di avviso relativa al criterio di avviso pertinente. Da qui, puoi aggiornare il criterio di avviso con le informazioni aggiuntive in modo che la dashboard possa trovare la risorsa associata.

Dopo aver aggiornato il criterio di avviso, la dashboard di Monitoring GKE è in grado di associare tutti gli incidenti futuri a un servizio unico in un determinato cluster, fornendoti ulteriori informazioni per diagnosticare il problema.

A seconda del tuo caso d'uso, potresti voler filtrare in base ad alcune di queste etichette oltre ad aggiungerle al campo Raggruppa per. Ad esempio, se vuoi ricevere avvisi solo per il cluster di produzione, puoi filtrare in base a cluster_name.