Questa pagina mostra come risolvere i problemi relativi alle dashboard di monitoraggio per Google Kubernetes Engine (GKE).
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.Le dashboard GKE non sono elencate in Cloud Monitoring
Per impostazione predefinita, il monitoraggio è attivo quando crei un cluster. Se non vedi le dashboard GKE quando visualizzi le dashboard Google Cloud fornite in Monitoring, significa che il monitoraggio non è abilitato per i cluster nel progetto Google Cloud selezionato. Abilita il monitoraggio per visualizzare queste dashboard.
Nessuna risorsa Kubernetes nella mia dashboard
Se non vedi risorse Kubernetes nella dashboard di 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 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é venga completato con i dati. Per maggiori dettagli, consulta Configurazione del logging e del 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 relativi al rifiuto dell'autorizzazione quando visualizzi i dettagli di implementazione di un servizio o le metriche di un Google Cloud 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 pageYou don't have permissions to perform the action on the selected resources
Per maggiori dettagli, vai a Ruoli predefiniti.
Autorizzazioni degli account di servizio del cluster e del nodo per scrivere dati in Monitoring e Logging
Se noti tassi di errore elevati nella pagina API e servizi abilitati della console Google Cloud, è possibile che al tuo account di servizio manchino i seguenti ruoli:
roles/logging.logWriter: nella console Google Cloud, questo ruolo è denominato Scrittore di 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 Scrittore di metriche di monitoraggio. Per ulteriori informazioni sui ruoli di monitoraggio, consulta la guida al monitoraggio del controllo degli accessi.roles/stackdriver.resourceMetadata.writer: nella console Google Cloud, questo ruolo è denominato Stackdriver Resource Metadata Writer. Questo ruolo consente accesso in sola scrittura ai metadati della risorsa e fornisce esattamente le autorizzazioni necessarie agli agenti per inviare metadati. Per ulteriori informazioni sui ruoli di monitoraggio, consulta la guida controllo dell'accesso degli accessi.
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 log nelle dashboard, controlla quanto segue:
L'agente è in esecuzione e funziona correttamente
GKE 1.17 e versioni successive utilizzano Fluent Bit per acquisire i log. Fluent Bit è l'agente Logging che viene eseguito sui nodi Kubernetes. Per verificare se l'agente è in esecuzione correttamente, svolgi i seguenti passaggi:
Controlla se l'agente si sta riavviando eseguendo il seguente comando:
kubectl get pods -l k8s-app=fluentbit-gke -n kube-systemSe 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 44dControlla le condizioni dello stato del pod eseguendo il seguente 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,Controlla lo stato del pod, che può aiutarti a determinare se il deployment è in stato di salute, eseguendo il seguente comando:
kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-systemSe 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 5d19hIn questo esempio di output, lo stato desiderato corrisponde a quello attuale.
Se l'agente è in esecuzione e funziona correttamente in questi scenari e continui a non vedere tutti i log, è possibile che l'agente sia sovraccaricato e stia perdendo i log.
Agente sovraccaricato e perdita di log
Un possibile motivo per cui non vedi tutti i log è che il volume dei log del nodo sta sovraccaricando l'agente. La configurazione predefinita dell'agente di logging in GKE è ottimizzata per una frequenza 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 raggiungere questo limite, cerca uno dei seguenti indicatori:
Visualizza la metrica
kubernetes.io/container/cpu/core_usage_timecon il filtrocontainer_name=fluentbit-gkeper verificare se l'utilizzo della CPU dell'agente di logging è vicino o al 100%.Visualizza la metrica
logging.googleapis.com/byte_countraggruppata permetadata.system_labels.node_nameper vedere se un nodo raggiunge 100 KiB per secondo.
Se si verifica 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.
Per ulteriori informazioni 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 del criterio di avviso che aggrega le metriche in risorse GKE distinte, potrebbe essere necessario modificare la condizione del criterio per includere altre 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 l'implementazione, ciascuno con una propria copia del serviziolilbuddy-2. Quando la condizione del criterio di avviso aggrega una metrica tra i contenitori di entrambi i cluster, la dashboard di monitoraggio GKE non è in grado di associare questo incidente in modo univoco al servizio di produzione o al servizio di staging.
Per risolvere la situazione, scegli come target del criterio di avviso un servizio specifico aggiungendo namespace, cluster e location al campo Raggruppa per del criterio. Nella scheda dell'evento per l'avviso, fai clic sul link Aggiorna criterio di avviso per aprire la pagina Modifica criterio di avviso per il 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 monitoraggio GKE è in grado di associare tutti gli incidenti futuri a un servizio univoco in un determinato cluster, fornendoti ulteriori informazioni per diagnosticare il problema.
A seconda del caso d'uso, potresti voler filtrare in base ad alcune di queste etichette, oltre ad aggiungerle al campo Raggruppa per. Ad esempio, se vuoi solo gli avvisi per il tuo cluster di produzione, puoi filtrare in base a cluster_name.