Risolvere i problemi relativi alle dashboard di monitoraggio

Se non riesci a visualizzare le dashboard di monitoraggio di Google Kubernetes Engine (GKE) in Cloud Monitoring o se sembra che manchino dati, potresti non essere in grado di osservare e rispondere ai problemi nei cluster e nei workload.

Utilizza questo documento per diagnosticare e risolvere i problemi relativi alle dashboard di monitoraggio di GKE. Trova indicazioni su come verificare se Cloud Monitoring è abilitato, controllare Cloud de Confiance le impostazioni della console e dell'account e risolvere i problemi relativi ai log e alle policy di avviso per le risorse GKE.

Queste informazioni sono importanti per gli amministratori e gli operatori della piattaforma e per gli sviluppatori di applicazioni che utilizzano le dashboard di Cloud Monitoring per comprendere l'integrità e le prestazioni dei cluster GKE e delle applicazioni. Per saperne di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Cloud de Confiance by S3NS , consulta Ruoli utente e attività comuni di GKE.

Per saperne di più su come utilizzare queste dashboard per risolvere i problemi dei tuoi cluster e workload, consulta Valuta l'integrità di cluster e workload nella console Cloud de Confiance .

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

Nella mia dashboard non sono presenti risorse Kubernetes

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

Progetto Cloud de Confiance selezionato

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

Attività dei cluster

Se hai appena creato il cluster, attendi qualche minuto affinché i dati vengano compilati. Per maggiori dettagli, consulta Configurazione di logging e monitoraggio per GKE.

Intervallo di tempo

L'intervallo di tempo selezionato potrebbe essere troppo ristretto. Puoi utilizzare il menu Ora 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 autorizzazione negata quando visualizzi i dettagli del deployment di un servizio o le metriche di un Cloud de Confiance progetto, devi aggiornare il tuo 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 del account di servizio del cluster e del nodo per scrivere dati in Monitoring e Logging

Se visualizzi tassi di errore elevati nella pagina API e servizi abilitati della console Cloud de Confiance , il tuo account di servizio potrebbe non disporre dei seguenti ruoli:

  • roles/logging.logWriter: nella console Cloud de Confiance , questo ruolo è denominato Logs Writer. Per saperne di più sui ruoli Logging, consulta la guida al controllo dell'accesso Logging.

  • roles/monitoring.metricWriter: nella console Cloud de Confiance , questo ruolo è denominato Monitoring Metric Writer. Per saperne di più sui ruoli di Monitoring, consulta la guida al controllo dell'accesso di Monitoring.

  • roles/stackdriver.resourceMetadata.writer: nella console Cloud de Confiance , 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 metadati. Per saperne di più sui ruoli Monitoring, consulta la guida controllo dell'accessodi Monitoring.

Per elencare i service account, nella console Cloud de Confiance vai a IAM e amministrazione, quindi seleziona Service account.

Impossibile visualizzare i log

Se non vedi i log nelle dashboard, controlla quanto segue:

L'agente è in esecuzione e integro

GKE 1.17 e versioni successive utilizzano Fluent Bit per acquisire i log. Fluent Bit è l'agente Logging eseguito sui nodi Kubernetes. Per verificare che l'agente sia in esecuzione correttamente, segui questi passaggi:

  1. Controlla se l'agente si sta riavviando eseguendo questo comando:

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

    Se non sono presenti 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 di 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ò aiutarti 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 e funziona correttamente in questi scenari e continui a non visualizzare tutti i log, è possibile che l'agente sia sovraccarico e stia eliminando i log.

Agente sovraccarico e eliminazione dei log

Uno dei possibili motivi per cui non vedi tutti i log è che il volume dei log del nodo sta sovraccaricando l'agente. La configurazione predefinita dell'agente Logging in GKE è ottimizzata per una velocità di 100 KiB al secondo per ogni nodo e l'agente potrebbe iniziare a eliminare i log se il volume supera questo limite.

Per rilevare se potresti aver raggiunto 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 verificare se l'utilizzo della CPU dell'agente Logging è vicino o pari al 100%.

  • Visualizza la metrica logging.googleapis.com/byte_count raggruppata per metadata.system_labels.node_name per verificare se un nodo raggiunge 100 KiB al secondo.

Se riscontri 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 da quel pod.

Per saperne di più su come esaminare e risolvere i problemi relativi al logging di GKE, consulta Risoluzione dei problemi di logging in GKE.

L'incidente non corrisponde a una risorsa GKE?

Se hai una condizione criterio di avviso che aggrega le metriche tra risorse GKE distinte, potresti dover modificare la condizione della policy per 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 tra i container in 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 staging.

Per risolvere questo problema, indirizza la criterio di avviso a un servizio specifico aggiungendo namespace, cluster e location al campo Raggruppa per della policy. Nella scheda evento per l'avviso, fai clic sul link Aggiorna policy di avviso per aprire la pagina Modifica policy di avviso per la policy 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 monitoraggio GKE è in grado di associare tutti i futuri incidenti a un servizio univoco in un determinato cluster, fornendoti ulteriori informazioni per diagnosticare il problema.

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