Questa pagina mostra come risolvere i problemi relativi alle dashboard di monitoraggio per Google Kubernetes Engine (GKE).
Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.Le dashboard GKE non sono elencate in Cloud Monitoring
Per impostazione predefinita, il monitoraggio è abilitato quando crei un cluster. Se non vedi le dashboard di GKE visualizzare le dashboard di Google Cloud fornite in Monitoring non è abilitato per 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 tua dashboard GKE, quindi controlla quanto segue:
Progetto Google Cloud selezionato
Verifica di aver selezionato il progetto Google Cloud corretto dalla nella barra dei menu della console Google Cloud per selezionare un progetto. Devi seleziona il progetto di cui vuoi vedere i dati.
Attività dei cluster
Se hai appena creato il cluster, attendi qualche minuto affinché venga compilato con i dati. Vedi Configurazione del logging e del monitoraggio per GKE per maggiori dettagli.
Intervallo di tempo
L'intervallo di tempo selezionato potrebbe essere troppo limitato. Puoi utilizzare il menu Ora in 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 durante la visualizzazione i dettagli del deployment di un servizio o le metriche di un progetto Google Cloud, devi aggiornare il tuo ruolo Identity and Access Management in modo da includere roles/monitoring.viewer oppure 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 in nella console Google Cloud, nel tuo account di servizio potrebbe mancare ruoli:
roles/logging.logWriter
: nella console Google Cloud, questo ruolo è denominato Writer log: Per ulteriori informazioni sui ruoli di Logging, consulta consulta la guida al controllo dell'accesso a Logging.roles/monitoring.metricWriter
: nella console Google Cloud, questo ruolo è denominato Writer metriche Monitoring. Per ulteriori informazioni Per i ruoli di Monitoring, consulta la sezione sull'accesso in Monitoring per il controllo.roles/stackdriver.resourceMetadata.writer
: nella console Google Cloud, il nome di questo ruolo è Stackdriver Resource Metadata Writer. Questo ruolo consente accesso in sola scrittura ai metadati delle risorse e fornisce esattamente autorizzazioni necessarie agli agenti per inviare metadati. Per ulteriori informazioni per i ruoli di Monitoring, consulta Guida al controllo dell'accesso al monitoraggio.
Per elencare gli account di servizio, nella console Google Cloud vai a IAM e amministratore, quindi seleziona Account di servizio.
Impossibile visualizzare i log
Se non vedi i log nelle dashboard, controlla quanto segue:
L'agente è in esecuzione e in stato integro
GKE 1.17 e versioni successive utilizzano bit Fluent per acquisire i log. Fluent Bit è l'agente Logging che viene eseguito sui nodi Kubernetes. Per verificare che l'agente funzioni correttamente, segui questi passaggi:
Verifica se l'agente si sta riavviando eseguendo questo comando:
kubectl get pods -l k8s-app=fluentbit-gke -n kube-system
Se non vengono riavviati, 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
Controlla le condizioni dello stato dei 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,
Controllare 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 allo stato attuale.
Se l'agente è in esecuzione e in stato integro in questi scenari, ma ancora non vedi tutti dei log, l'agente potrebbe essere sovraccarico e cancellare i log.
L'agente ha sovraccarico e eliminazione dei log
È possibile che non tutti i log siano visualizzati perché un volume troppo elevato sta sovraccaricando l'agente. L'agente Logging predefinito in GKE è ottimizzata per la 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 una delle seguenti opzioni indicatori:
Visualizza la metrica
kubernetes.io/container/cpu/core_usage_time
con il filtrocontainer_name=fluentbit-gke
per vedere se l'utilizzo della CPU dell'agente è vicino o al 100%.Visualizza la metrica
logging.googleapis.com/byte_count
raggruppata permetadata.system_labels.node_name
per vedere se un nodo raggiunge i 100 kiB per 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 un singolo pod, dovrai ridurre il volume da quel pod.
Per ulteriori informazioni sull'analisi e la risoluzione del logging di GKE vedi Risoluzione dei problemi di logging in GKE.
L'incidente non corrisponde a una risorsa GKE?
Se è presente una condizione del criterio di avviso che aggrega le metriche in risorse GKE, potresti dover modificare per includere altre etichette della gerarchia GKE da associare incidenti con entità specifiche.
Ad esempio, potresti avere due cluster GKE, uno
produzione e una per la gestione temporanea, ognuno con la propria copia del servizio
lilbuddy-2
. Quando la condizione del criterio di avviso aggrega una metrica
di container in entrambi i cluster,
La dashboard di monitoraggio non è in grado di associare questo incidente
in modo univoco con il servizio di produzione o di gestione temporanea.
Per risolvere la situazione, indirizza il criterio di avviso a 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 per il criterio di avviso pertinente. Da
puoi aggiornare il criterio di avviso con le informazioni aggiuntive,
la dashboard possa trovare la risorsa associata.
Dopo aver aggiornato il criterio di avviso, il cluster GKE La dashboard di monitoraggio può associare tutti gli incidenti futuri con un servizio univoco in un particolare cluster, per ottenere informazioni aggiuntive per diagnosticare il problema.
A seconda del caso d'uso, potresti voler filtrare alcune di queste etichette in
oltre ad aggiungerli al campo Raggruppa per. Ad esempio, se vuoi solo
per il tuo cluster di produzione, puoi applicare un filtro in base a cluster_name
.