Eseguire analisi storiche con Cloud Logging

Quando un pod non funziona o un servizio non funziona come previsto in Google Kubernetes Engine (GKE), è fondamentale comprendere la sequenza di eventi che hanno portato al problema. L'ispezione dello stato attuale non è sempre sufficiente per trovare la causa principale, il che rende i dati di log storici preziosi.

Utilizza questa pagina per scoprire come utilizzare Cloud Logging per analizzare i guasti passati (ad esempio perché un pod non è stato avviato o chi ha eliminato un deployment critico) eseguendo query e analizzando i log di GKE.

Queste informazioni sono importanti per gli amministratori e gli operatori della piattaforma che devono eseguire l'analisi della causa principale dei problemi a livello di cluster, controllare le modifiche e comprendere le tendenze del comportamento del sistema. È anche essenziale per gli sviluppatori di applicazioni per il debug degli errori specifici dell'applicazione, il tracciamento dei percorsi delle richieste e la comprensione del comportamento del codice nell'ambiente GKE nel tempo. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Cloud de Confiance by S3NS contenuti, consulta Ruoli e attività comuni degli utenti GKE.

Comprendere i tipi di log chiave per la risoluzione dei problemi

Per aiutarti a risolvere i problemi, Cloud Logging raccoglie e aggrega automaticamente diversi tipi di log chiave dai cluster GKE, dalle app containerizzate e da altri Cloud de Confiance servizi:

  • Log dei nodi e del runtime (kubelet, containerd): i log dei servizi dei nodi sottostanti. Poiché kubelet gestisce il ciclo di vita di tutti i pod sul nodo, i suoi log sono essenziali per la risoluzione dei problemi come gli avvii dei container, gli eventi di memoria insufficiente (OOM), gli errori di probe e gli errori di montaggio dei volumi. Questi log sono fondamentali anche per la diagnosi dei problemi a livello di nodo, ad esempio un nodo con stato NotReady.

    Poiché containerd gestisce il ciclo di vita dei container, incluso il pull delle immagini, i suoi log sono fondamentali per la risoluzione dei problemi che si verificano prima che kubelet possa avviare il container. I log di containerd ti aiutano a diagnosticare i problemi a livello di nodo in GKE, perché documentano le attività specifiche e i potenziali errori del runtime del container.

  • Log delle app (stdout, stderr): i flussi di output standard e di errore dei processi containerizzati. Questi log sono essenziali per il debug di problemi specifici dell'app, come arresti anomali, errori o comportamenti imprevisti.

  • Audit log: questi log rispondono alla domanda "Chi ha fatto cosa, dove e quando?" per il tuo cluster. Tengono traccia delle azioni amministrative e delle chiamate API effettuate al server API Kubernetes, il che è utile per diagnosticare i problemi causati da modifiche alla configurazione o accessi non autorizzati.

Scenari comuni di risoluzione dei problemi

Dopo aver identificato un problema, puoi eseguire query su questi log per scoprire cosa è successo. Per iniziare, la revisione dei log può aiutarti a risolvere questi problemi:

  • Se un nodo ha lo stato NotReady, esamina i log dei nodi. I log kubelet e containerd spesso rivelano la causa sottostante, ad esempio problemi di rete o vincoli di risorse.
  • Se il provisioning di un nuovo nodo non riesce e non viene aggiunto al cluster, esamina i log della porta seriale del nodo. serial port logs. Questi log acquisiscono l'attività della fase iniziale di avvio e di avvio di kubelet prima che gli agenti Logging del nodo siano completamente attivi.
  • Se un pod non è stato avviato in passato, esamina i log delle app per quel pod per verificare la presenza di arresti anomali. Se i log sono vuoti o il pod non può essere pianificato, controlla gli audit log per gli eventi pertinenti o i log dei nodi sul nodo di destinazione per trovare indizi sulla pressione delle risorse o sugli errori di pull delle immagini.
  • Se un deployment critico è stato eliminato e nessuno sa perché, esegui una query sugli audit log Attività di amministrazione. Questi log possono aiutarti a identificare l'utente o l'account di servizio che ha emesso la chiamata API di eliminazione, fornendo un punto di partenza chiaro per la tua indagine.

Come accedere ai log

Utilizza Esplora log per eseguire query, visualizzare e analizzare i log di GKE nella Cloud de Confiance console. Esplora log offre potenti opzioni di filtro che ti aiutano a isolare il problema.

Per accedere a Esplora log e utilizzarlo, segui questi passaggi:

  1. Nella Cloud de Confiance console, vai alla pagina Esplora log.

    Vai a Esplora log

  2. Nel riquadro Query, inserisci una query. Utilizza il linguaggio di query di Logging per scrivere query mirate. Ecco alcuni filtri comuni per iniziare:

    Tipo di filtro Descrizione Valore di esempio
    resource.type Il tipo di risorsa Kubernetes. k8s_cluster, k8s_node, k8s_pod, k8s_container
    log_id Il flusso di log della risorsa. stdout, stderr
    resource.labels.RESOURCE_TYPE.name Filtra le risorse con un nome specifico.
    Sostituisci RESOURCE_TYPE con il nome della risorsa su cui vuoi eseguire la query. Ad esempio, namespace o pod.    		 example-namespace-name, example-pod-name
    severity Il livello di gravità del log. DEFAULT, INFO, WARNING, ERROR, CRITICAL
    jsonPayload.message=~ Una ricerca con espressione regolare per il testo all'interno del messaggio di log. scale.down.error.failed.to.delete.node.min.size.reached

    Ad esempio, per risolvere i problemi di un pod specifico, potresti voler isolare i relativi log degli errori. Per visualizzare solo i log con gravità ERROR per quel pod, utilizza la seguente query:

    resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
resource.labels.namespace_name="NAMESPACE_NAME"
severity=ERROR

    Sostituisci quanto segue:

    • POD_NAME: il nome del pod che presenta problemi.
    • NAMESPACE_NAME: lo spazio dei nomi in cui si trova il pod. Se non sai qual è lo spazio dei nomi, esamina la colonna Namespace nell'output del comando kubectl get pods.

    Per altri esempi, consulta Query correlate a Kubernetes nella documentazione di Google Cloud Observability.

  3. Fai clic su Esegui query.

  4. Per visualizzare il messaggio di log completo, inclusi il payload JSON, i metadati e il timestamp, fai clic sulla voce di log.

Per ulteriori informazioni sui log di GKE, consulta Informazioni sui log di GKE.

Passaggi successivi