Risolvere i problemi relativi ai log mancanti in GKE

I problemi con la pipeline di logging in Google Kubernetes Engine (GKE) possono impedire la visualizzazione dei log del cluster in Cloud Logging, ostacolando i tuoi sforzi di monitoraggio e debug.

Utilizza questo documento per scoprire come verificare configurazioni e autorizzazioni, risolvere problemi di risorse e prestazioni, analizzare filtri e comportamento delle applicazioni e risolvere problemi di piattaforma o servizio che interessano i log.

Queste informazioni sono importanti per gli amministratori e gli operatori della piattaforma che mantengono l'osservabilità del cluster e per chiunque utilizzi Cloud Logging per risolvere i problemi delle operazioni GKE. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE.

Per saperne di più su come utilizzare i log per risolvere i problemi relativi ai carichi di lavoro e ai cluster, consulta Eseguire l'analisi storica con Cloud Logging.

Trova la soluzione in base al sintomo

Se hai identificato un sintomo specifico correlato ai log mancanti, utilizza la seguente tabella per trovare consigli per la risoluzione dei problemi:

Categoria Sintomo o osservazione Possibile causa Passaggi per la risoluzione dei problemi
Configurazione Non sono visibili log di nessun cluster nel progetto. L'API Cloud Logging è disattivata per il progetto. Verifica lo stato dell'API Cloud Logging
Mancano i log di un cluster specifico o mancano solo determinati tipi di log. Il logging a livello di cluster è disabilitato per i tipi di log richiesti. Verifica la configurazione del logging del cluster
I log non sono presenti nei nodi di un node pool specifico. I nodi del pool di nodi non dispongono dell'ambito di accesso richiesto. Verifica gli ambiti di accesso del node pool
Nei log dell'agente di logging vengono visualizzati errori di autorizzazione (401 o 403). Il account di servizio del nodo non dispone dell'autorizzazione richiesta. Verifica le autorizzazioni del account di servizio del nodo
Risorse e rendimento I log mancano a intermittenza o vengono visualizzati errori RESOURCE_EXHAUSTED. Il progetto sta superando la quota di scrittura dell'API Cloud Logging. Esaminare l'utilizzo della quota dell'API Cloud Logging
Mancano alcuni log di un nodo specifico, spesso durante periodi di traffico o carico elevato. Il nodo supera i limiti di velocità effettiva dell'agente Logging o non dispone di risorse (CPU o memoria) per elaborare i log. Esaminare il throughput dei nodi e l'utilizzo delle risorse
Filtri e comportamento delle applicazioni Mancano costantemente log specifici che corrispondono a un determinato pattern. Un filtro di esclusione dei log in Cloud Logging elimina involontariamente i log. Esaminare i filtri di esclusione dei log
I log di un contenitore vengono ritardati in modo significativo o vengono visualizzati solo dopo l'uscita dal contenitore. L'output dell'applicazione è completamente memorizzato nel buffer, spesso a causa del piping stdout. Analizzare il buffering e i ritardi dei log dei container
I log previsti non vengono visualizzati nei risultati di ricerca. I filtri delle query in Esplora log potrebbero essere troppo restrittivi. Esaminare le query di Esplora log
Non sono visibili log da un pod di applicazione specifico, ma sono presenti altri log del cluster. L'applicazione all'interno del container non scrive in stdout o stderr. Analizzare il comportamento di logging specifico dell'applicazione
Piattaforma e servizio I log precedenti a una determinata data non vengono visualizzati. I log hanno superato il periodo di conservazione e sono stati eliminati da Cloud Logging. Esaminare i periodi di conservazione dei log
Perdita o ritardi diffusi dei log in tutti i progetti o cluster. Problema del servizio Cloud Logging o ritardo nell'importazione. Investiga i problemi e i ritardi del servizio Cloud Logging
I problemi di logging coincidono con le limitazioni della versione del cluster. Versione di GKE non supportata. Esaminare la versione del cluster

Utilizzare strumenti di diagnostica automatizzati

Le sezioni seguenti descrivono gli strumenti che possono ispezionare automaticamente il cluster per individuare errori di configurazione comuni e aiutarti a esaminare problemi complessi.

Eseguire il debug dei problemi di logging di GKE con gcpdiag

Se mancano log o i log del cluster GKE sono incompleti, utilizza lo strumento gcpdiag per la risoluzione dei problemi.

gcpdiag è uno strumento open source. Non è un prodotto Google Cloud supportato ufficialmente. Puoi utilizzare lo strumento gcpdiag per identificare e risolvere Google Cloud i problemi del progetto. Per maggiori informazioni, consulta il progetto gcpdiag su GitHub.

Quando i log del cluster GKE sono mancanti o incompleti, esamina le potenziali cause concentrandoti sulle seguenti impostazioni di configurazione principali:

  • Logging a livello di progetto:assicura che il progetto Google Cloud che ospita il cluster GKE abbia l'API Cloud Logging abilitata.
  • Logging a livello di cluster:verifica che il logging sia abilitato esplicitamente nella configurazione del cluster GKE.
  • Autorizzazioni del pool di nodi:conferma che i nodi all'interno dei pool di nodi del cluster hanno l'ambito Cloud Logging Write abilitato, consentendo loro di inviare dati di log.
  • Autorizzazioni del service account:verifica che il service account utilizzato dai node pool disponga delle autorizzazioni IAM necessarie per interagire con Cloud Logging. In particolare, in genere è richiesto il ruolo roles/logging.logWriter.
  • Quote di scrittura dell'API Cloud Logging:verifica che le quote di scrittura dell'API Cloud Logging non siano state superate nel periodo di tempo specificato.

ConsoleGoogle Cloud

  1. Completa e copia il seguente comando. 
    2. gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION
  2. Apri la console Google Cloud e attiva Cloud Shell.
    3. Apri Cloud Console
  3. Incolla il comando copiato.
  4. Esegui il comando gcpdiag, che scarica l'immagine Docker gcpdiag e poi esegue controlli diagnostici. Se applicabile, segui le istruzioni di output per correggere i controlli non riusciti.

Docker

Puoi eseguire gcpdiag utilizzando un wrapper che avvia gcpdiag in un container Docker. Docker o Podman devono essere installati.

  1. Copia ed esegui il seguente comando sulla workstation locale. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. Esegui il comando gcpdiag. 
    ./gcpdiag runbook gke/logs \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=LOCATION

Visualizza i parametri disponibili per questo runbook.

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del progetto che contiene la risorsa.
  • CLUSTER_NAME: il nome del cluster GKE.
  • LOCATION: la regione o la zona di Compute Engine (ad esempio, us-central1 o us-central1-a) per il cluster.

Flag utili:

Per un elenco e una descrizione di tutti i flag dello strumento gcpdiag, consulta le istruzioni per l'utilizzo di gcpdiag.

Utilizzare le indagini di Gemini Cloud Assist

Valuta la possibilità di utilizzare le indagini di Gemini Cloud Assist per ottenere ulteriori informazioni sui log e risolvere i problemi. Per saperne di più sui diversi modi per avviare un'indagine utilizzando Esplora log, consulta Risolvere i problemi relativi alle indagini di Gemini Cloud Assist nella documentazione di Gemini.

Verifica la configurazione e le autorizzazioni di logging

Impostazioni errate sono un motivo comune per la mancanza di log GKE. Utilizza le sezioni seguenti per verificare la configurazione di Cloud Logging.

Verifica lo stato dell'API Cloud Logging

Affinché i log vengano raccolti da qualsiasi cluster del tuo progetto, l'API Cloud Logging deve essere attiva.

Sintomi:

In Cloud Logging non sono visibili log di risorse GKE nel tuo progetto.

Causa:

L'API Cloud Logging è disabilitata per il progetto Google Cloud , impedendo all'agente di logging sui nodi di inviare i log.

Risoluzione:

Per verificare che l'API Cloud Logging sia abilitata e abilitarla se necessario, seleziona una delle seguenti opzioni:

Console

  1. Nella console Google Cloud , vai alla pagina API e servizi abilitati.

    Vai ad API e servizi abilitati

  2. Nel campo Filtro, digita Cloud Logging API e premi Invio.

  3. Se l'API è abilitata, la vedrai elencata. Se l'API non è elencata, abilitala:

    1. Fai clic su Abilita API e servizi.
    2. Nel campo Cerca, digita Cloud Logging API e premi Invio.
    3. Fai clic sul risultato API Cloud Logging.
    4. Fai clic su Attiva.

gcloud

  1. Controlla se l'API è abilitata:

    gcloud services list --enabled --filter="NAME=logging.googleapis.com"

    L'output dovrebbe essere simile all'esempio seguente:

    NAME: logging.googleapis.com
TITLE: Cloud Logging API

  2. Se l'API non è elencata nei servizi abilitati, abilitala:

    gcloud services enable logging.googleapis.com \
    --project=PROJECT_ID

    Sostituisci PROJECT_ID con l'ID progetto Google Cloud.

Verifica la configurazione della registrazione dei log del cluster

GKE ti consente di configurare i tipi di log (ad esempio SYSTEM o WORKLOAD) raccolti da un cluster.

Sintomi:

In Cloud Logging non vengono visualizzati log di un cluster GKE specifico o mancano solo determinati tipi di log (ad esempio SYSTEM).

Causa:

Il logging a livello di cluster è disabilitato per i tipi di log richiesti. Se utilizzi un cluster Autopilot, questo non è la causa dei problemi di logging. Questa impostazione è configurabile per i cluster Standard, ma è sempre abilitata per impostazione predefinita sui cluster Autopilot e non può essere disabilitata.

Risoluzione:

Per controllare e aggiornare la configurazione di logging del cluster, seleziona una delle seguenti opzioni:

Console

  1. Nella console Google Cloud , vai alla pagina Cluster Kubernetes.

    Vai ai cluster Kubernetes

  2. Fai clic sul nome del cluster che vuoi esaminare.

  3. Fai clic sulla scheda Dettagli e vai alla sezione Funzionalità.

  4. Nella riga Logging, controlla quali tipi di log, ad esempio Sistema o Carichi di lavoro, sono attivati.

  5. Se i tipi di log che vuoi raccogliere sono disattivati o errati, fai clic su Modifica logging.

  6. Nell'elenco Componenti, seleziona le caselle di controllo per i tipi di log che vuoi raccogliere e fai clic su Ok. Per saperne di più sui tipi di log disponibili, consulta Informazioni sui log di GKE.

  7. Fai clic su Salva modifiche.

gcloud

  1. Per controllare la configurazione della registrazione, descrivi il cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(name,loggingConfig.componentConfig.enableComponents)"

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.
    • PROJECT_ID: il tuo ID progetto Google Cloud .

    Se la registrazione è abilitata, l'output è simile al seguente:

    example-cluster    SYSTEM_COMPONENTS;WORKLOADS

    Se l'output è NONE, la registrazione è disattivata.

  2. Se i tipi di log che ti interessano sono disattivati o errati, aggiorna la configurazione della registrazione:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --logging=LOGGING_TYPE

    Sostituisci LOGGING_TYPE con SYSTEM, WORKLOAD o entrambi. Per raccogliere i log, SYSTEM deve essere abilitato. I log WORKLOAD non possono essere raccolti singolarmente. Per saperne di più sui tipi di log disponibili, consulta Informazioni sui log GKE.

Verifica gli ambiti di accesso del pool di nodi

I nodi di un cluster GKE utilizzano gli ambiti di accesso OAuth per ottenere l'autorizzazione a interagire con le API Google Cloud , incluso Cloud Logging.

Sintomi:

I log non sono presenti nei nodi di un pool di nodi specifico.

Causa:

I nodi nel pool di nodi non dispongono dell'ambito di accesso OAuth necessario. Per consentire ai nodi di scrivere i log in Cloud Logging, è necessario uno dei seguenti ambiti:

  • https://www.googleapis.com/auth/logging.write: concede l'autorizzazione a scrivere log. Questo è l'ambito minimo richiesto.
  • https://www.googleapis.com/auth/logging.admin: concede l'accesso completo all'API Cloud Logging, che include le autorizzazioni di logging.write.
  • https://www.googleapis.com/auth/cloud-platform: concede l'accesso completo a tutte le API Google Cloud attivate, incluse le autorizzazioni di logging.write.

Risoluzione:

Per verificare le autorizzazioni e concedere i ruoli richiesti se mancanti, seleziona una delle seguenti opzioni:

Console

  1. Verifica gli ambiti di accesso del pool di nodi:

    1. Nella console Google Cloud , vai alla pagina Cluster Kubernetes.

      Vai ai cluster Kubernetes

    2. Per aprire la pagina dei dettagli del cluster, fai clic sul nome del cluster che vuoi esaminare.

    3. Fai clic sulla scheda Nodi.

    4. Nella sezione Pool di nodi, fai clic sul nome del pool di nodi che vuoi esaminare.

    5. Vai alla sezione Sicurezza.

    6. Controlla gli ambiti elencati nel campo Ambiti di accesso. Assicurati che sia presente almeno uno degli ambiti richiesti:

      • API Stackdriver Logging - Sola scrittura
      • API Stackdriver Logging - Full
      • Cloud Platform - Enabled

      Se gli ambiti richiesti non sono presenti, ricrea il pool di nodi. Non puoi modificare gli ambiti di accesso in un pool di nodi esistente.

  2. Se necessario, crea un nuovo pool di nodi con l'ambito richiesto:

    1. Torna alla pagina dei dettagli del cluster che vuoi modificare.
    2. Fai clic sulla scheda Nodi.
    3. Fai clic su Crea node pool gestito dall'utente.
    4. Compila la sezione Dettagli del pool di nodi.
    5. Nel riquadro di navigazione a sinistra, fai clic su Sicurezza.
    6. Nella sezione Ambiti di accesso, seleziona i ruoli che vuoi aggiungere:
      • Per aggiungere ambiti specifici, seleziona Imposta l'accesso per ogni API.
      • Per consentire l'accesso completo, seleziona Consenti l'accesso completo a tutte le API Cloud.
    7. Configura le altre sezioni in base alle esigenze.
    8. Fai clic su Crea.

  3. Esegui la migrazione dei tuoi carichi di lavoro al nuovo node pool. Dopo aver eseguito la migrazione dei workload al nuovo pool di nodi, le tue applicazioni vengono eseguite su nodi che dispongono degli ambiti necessari per inviare i log a Cloud Logging.

  4. Elimina il vecchio pool di nodi:

    1. Torna alla pagina dei dettagli del cluster e seleziona la scheda Nodi.
    2. Nella sezione Pool di nodi, individua il vecchio pool di nodi.
    3. Accanto al pool di nodi, fai clic su Elimina .
    4. Quando ti viene chiesto, conferma l'eliminazione digitando il nome pool di nodi e fai clic su Elimina.

gcloud

  1. Verifica gli ambiti di accesso del pool di nodi:

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePools[].name,nodePools[].config.oauthScopes)"

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.
    • PROJECT_ID: il tuo ID progetto Google Cloud .

    Esamina l'output per ogni pool di nodi. Assicurati che sia elencato almeno uno degli ambiti richiesti (https://www.googleapis.com/auth/logging.write, https://www.googleapis.com/auth/cloud-platform o https://www.googleapis.com/auth/logging.admin). Se gli ambiti richiesti non sono presenti, ricrea il pool di nodi. Non puoi modificare gli ambiti di accesso in unpool di nodil esistente.

  2. Se necessario, crea un nuovo pool di nodi con l'ambito richiesto:

    gcloud container node-pools create NEW_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --scopes=https://www.googleapis.com/auth/logging.write,OTHER_SCOPES

    Sostituisci quanto segue:

    • NEW_NODE_POOL_NAME: un nome per il nuovo pool di nodi.
    • OTHER_SCOPES: un elenco separato da virgole di altri ambiti richiesti dai nodi. Se non hai bisogno di altri ambiti, ometti questo segnaposto e la virgola precedente.

  3. Esegui la migrazione dei tuoi carichi di lavoro al nuovo node pool. Dopo aver eseguito la migrazione dei workload al nuovo pool di nodi, le tue applicazioni vengono eseguite su nodi che dispongono degli ambiti necessari per inviare i log a Cloud Logging.

  4. Elimina il vecchio pool di nodi:

    gcloud container node-pools delete OLD_NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID

Verifica le autorizzazioni del account di servizio del nodo

I nodi utilizzano un account di servizio per l'autenticazione con i servizi e questo account richiede autorizzazioni IAM specifiche per scrivere i log. Google Cloud

Sintomi:

  • Nei nodi mancano i log.
  • L'ispezione dei log dell'agente di logging (ad esempio Fluent Bit) potrebbe mostrare errori relativi alle autorizzazioni, ad esempio codici 401 o 403 durante il tentativo di scrittura in Cloud Logging.
  • Potresti visualizzare una notifica Grant Critical Permissions to Node Service Account per il cluster nella console Google Cloud .

Causa:

Il account di servizio utilizzato dai nodi del pool di nodi non dispone delle autorizzazioni IAM necessarie per scrivere i log in Cloud Logging. I nodi richiedono un account di servizio con il ruolo logging.logWriter, che include l'autorizzazione logging.logEntries.create.

Inoltre, per GKE versione 1.33 o successive, l'agente di servizio del nodo predefinito di GKE (service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com) deve disporre almeno del ruolo Agente di servizio del nodo predefinito di Kubernetes (roles/container.defaultNodeServiceAgent). Questo ruolo consente a GKE di gestire le risorse e le operazioni dei nodi, inclusi i componenti di logging.

Risoluzione:

Per verificare le autorizzazioni e concedere i ruoli richiesti se mancano, procedi nel seguente modo:

  • Verifica l'autorizzazione del account di servizio del nodo.
  • Verifica che il service agent GKE disponga del ruolo richiesto.

Verifica l'autorizzazione del account di servizio del nodo

L'account di servizio del nodo è l'account utilizzato dal nodo per l'autenticazione e l'invio dei log. Per identificare questo account di servizio e verificare che disponga dell'autorizzazione roles/logging.logWriter richiesta:

  1. Per identificare il account di servizio utilizzato dal pool di nodi, seleziona una delle seguenti opzioni:

    Console

    1. Nella console Google Cloud , vai alla pagina Cluster Kubernetes.

      Vai ai cluster Kubernetes

    2. Nell'elenco dei cluster, fai clic sul nome del cluster che vuoi esaminare.

    3. A seconda della modalità operativa del cluster, esegui una delle seguenti operazioni:

      • Per i cluster standard:

        1. Fai clic sulla scheda Nodi.
        2. Nella tabella Pool di nodi, fai clic sul nome di un pool di nodi. Viene visualizzata la pagina dei dettagli del pool di nodi.
        3. Nella sezione Sicurezza, trova il campo Service account.

      • Per i cluster Autopilot, procedi nel seguente modo:

        1. Vai alla scheda Dettagli.
        2. Nella sezione Sicurezza, trova il campo Service account.

      Se il valore nel campo Service account è default, i tuoi nodi utilizzano il account di servizio predefinito di Compute Engine. Se il valore in questo campo non è default, i tuoi nodi utilizzano un account di servizio personalizzato. Per concedere il ruolo richiesto a un account di servizio personalizzato, consulta Utilizzare i service account IAM con privilegio minimo minimi.

    gcloud

    Esegui questo comando, a seconda del tipo di cluster che utilizzi:

    Cluster standard 

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(config.serviceAccount)"

    Sostituisci quanto segue:

    • NODE_POOL_NAME: il nome del pool di nodil.
    • CLUSTER_NAME: il nome del tuo cluster Standard.
    • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.
    • PROJECT_ID: il tuo Google Cloud ID progetto.

    Se l'output è default, il pool di nodi utilizza il account di servizio predefinito di Compute Engine. Se il valore non è default, i nodi utilizzano un account di servizio personalizzato. Per concedere il ruolo richiesto a un account di servizio personalizzato, consulta Utilizzare i service account IAM con privilegio minimo minimi.

    Cluster Autopilot 

    gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --project=PROJECT_ID \
    --format="value(nodePoolDefaults.nodeConfigDefaults.serviceAccount)"

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster Autopilot.
    • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.
    • PROJECT_ID: l'ID progetto Google Cloud .

    Se l'output è default, il pool di nodi utilizza il account di servizio predefinito di Compute Engine. Se il valore non è default, i nodi utilizzano un account di servizio personalizzato. Per concedere il ruolo richiesto a un account di servizio personalizzato, consulta Utilizzare i service account IAM con privilegio minimo minimi.

    Per script più dettagliati per identificare le autorizzazioni mancanti, vedi Identifica tutti i service account dei nodi con autorizzazioni mancanti.

  2. GKE esegue automaticamente la scansione delle autorizzazioni mancanti e fornisce suggerimenti. Per utilizzare i suggerimenti per verificare le autorizzazioni mancanti, seleziona una delle seguenti opzioni:

    Console

    1. Nella pagina Cluster Kubernetes, individua la colonna Notifiche.
    2. Controlla la colonna Notifiche per il suggerimento Concedi autorizzazioni critiche. Questo suggerimento indica che il controllo NODE_SA_MISSING_PERMISSIONS non è riuscito.
    3. Se il consiglio è presente, fai clic. Si apre un riquadro dei dettagli che spiega le autorizzazioni mancanti e fornisce i passaggi per risolvere il problema.

    gcloud

    1. Elenca i suggerimenti per le autorizzazioni mancanti del account di servizio:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analizza l'output del comando:

      • Se il comando restituisce un elenco vuoto, il sistema di raccomandazione non ha trovato consigli attivi per NODE_SA_MISSING_PERMISSIONS. I service account che ha controllato sembrano disporre delle autorizzazioni richieste.

      • Se il comando restituisce uno o più blocchi YAML, il consigliere ha identificato un problema di autorizzazione. Esamina l'output per i seguenti campi chiave:

        • description: fornisce un riepilogo del problema, ad esempio specificando che al tuoaccount di serviziot nodo manca il ruolo roles/logging.logWriter o che all'agente di servizio GKE manca il ruolo roles/container.defaultNodeServiceAgent.
        • resource: specifica il cluster interessato.
        • content.operations: contiene la risoluzione consigliata. Questa sezione fornisce il comando gcloud projects add-iam-policy-binding esatto necessario per concedere il ruolo specifico mancante.

    Potrebbero essere necessarie fino a 24 ore prima che il sistema di raccomandazione rifletta le modifiche recenti.

  3. Se vuoi verificare immediatamente le autorizzazioni, per controllare le autorizzazioni e assegnare il ruolo, seleziona una delle seguenti opzioni:

    Console

    1. Nella console Google Cloud , vai alla pagina IAM.

      Vai a IAM

    2. Trova il account di servizio utilizzato dal pool di nodi.

    3. Nella colonna Ruolo, verifica se il account di servizio ha il ruolo Writer log (roles/logging.logWriter).

    4. Se l'autorizzazione non è presente, aggiungila:

      1. Fai clic su Modifica entità.
      2. Fai clic su Aggiungi un altro ruolo.
      3. Nel campo di ricerca, inserisci Logs Writer.
      4. Seleziona la casella di controllo Logs Writer e fai clic su Applica.
      5. Fai clic su Salva.

    gcloud

    1. Controlla i ruoli attuali per il account di servizio del nodo:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"

    2. Se non è presente, concedi il ruolo logging.logWriter:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role="roles/logging.logWriter"

Verifica le autorizzazioni del service agent GKE

Se i log continuano a mancare e utilizzi la versione 1.33 o successive, verifica che l'agente gestito da Google utilizzato da GKE per gestire i componenti dei nodi disponga dell'autorizzazione richiesta:

  1. Per identificare l'indirizzo email dell'agente di servizio, recupera il numero di progetto:

    gcloud projects describe PROJECT_ID --format="value(projectNumber)"

    Sostituisci PROJECT_ID con l'ID progetto. Prendi nota dell'output.

    L'indirizzo email del service agent GKE è: service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com

  2. Per utilizzare i suggerimenti per verificare le autorizzazioni mancanti, seleziona una delle seguenti opzioni:

    Console

    1. Nella pagina Cluster Kubernetes, trova la colonna Notifiche.
    2. Controlla la colonna relativa al suggerimento Concedi autorizzazioni critiche.
    3. Se il consiglio è presente, fai clic. Si apre un riquadro dei dettagli che spiega le autorizzazioni mancanti e fornisce i passaggi per risolvere il problema.

    gcloud

    1. Elenca i suggerimenti per le autorizzazioni mancanti del account di servizio:

      gcloud recommender recommendations list \
    --recommender=google.container.DiagnosisRecommender \
    --location LOCATION \
    --project PROJECT_ID \
    --format yaml \
    --filter="recommenderSubtype:NODE_SA_MISSING_PERMISSIONS"

    2. Analizza l'output del comando. Esamina l'output per una descrizione che specifica che all'agente di servizio GKE (gcp-sa-gkenode) manca il ruolo roles/container.defaultNodeServiceAgent.

  3. Per controllare immediatamente le autorizzazioni e concedere il ruolo, seleziona una delle seguenti opzioni:

    Console

    1. Nella console Google Cloud , vai alla pagina IAM.

      Vai a IAM

    2. Nel campo Filtro, digita l'indirizzo email dell'agente di servizio GKE e premi Invio.

    3. Nell'elenco filtrato, verifica che l'agente di servizio disponga almeno del ruolo Agente di servizio nodo predefinito di Kubernetes (roles/container.defaultNodeServiceAgent).

    4. Se il ruolo non è presente, concedilo:

      1. Fai clic su Modifica entità accanto all'agente di servizio.
      2. Fai clic su Aggiungi ruoli.
      3. Nel campo di ricerca, inserisci Kubernetes Default Node Service Agent e seleziona il ruolo.
      4. Fai clic su Salva.

    gcloud

    1. Verifica se il ruolo roles/container.defaultNodeServiceAgent è associato all'agente di servizio:

      gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \
    --format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com"

      Nell'output, cerca roles/container.defaultNodeServiceAgent.

    2. Se il ruolo non è presente, concedi il ruolo Agente di servizio del nodo predefinito di Kubernetes:

      gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-gkenode.iam.gserviceaccount.com" \
    --role="roles/container.defaultNodeServiceAgent"

Risolvi i problemi relativi alle risorse e alle prestazioni

Se i log mancano in modo intermittente o vengono eliminati dai nodi con traffico elevato, la causa potrebbe non essere una configurazione errata, ma un problema di prestazioni. Utilizza le sezioni seguenti per verificare se il tuo progetto supera le quote API o se l'elevato volume di log sta sovraccaricando gli agenti su nodi specifici.

Esaminare l'utilizzo della quota dell'API Cloud Logging

Per proteggere il servizio, Cloud Logging applica una quota di scrittura a tutti i progetti, limitando il volume totale di log che Cloud Logging può inserire al minuto.

Sintomi:

  • I log sono mancanti in modo intermittente o completo.
  • Nei log dell'agente di logging o del nodo vengono visualizzati errori RESOURCE_EXHAUSTED relativi a logging.googleapis.com.

Causa:

Il progetto sta superando la quota di richieste di scrittura dell'API Cloud Logging. Questo problema impedisce all'agente di logging di inviare i log.

Risoluzione:

Per controllare l'utilizzo della quota e richiedere un aumento:

  1. Nella console Google Cloud , vai alla pagina Quote.

    Vai a Quote

  2. Nel campo Filtro, digita Cloud Logging API e premi Invio.

  3. Nell'elenco filtrato, trova la quota per Byte di scrittura dei log al minuto per regione per la regione in cui si trova il cluster.

  4. Controlla i valori nella colonna Percentuale di utilizzo corrente. Se l'utilizzo è pari o vicino al limite, è probabile che tu abbia superato la quota.

  5. Per richiedere un aumento, fai clic su Modifica quota e segui le istruzioni. Per saperne di più, consulta Visualizza e gestisci le quote.

Per ridurre l'utilizzo, valuta la possibilità di escludere i log o ridurre la verbosità dei log dalle applicazioni. Puoi anche configurare criteri di avviso per ricevere una notifica prima di raggiungere il limite.

Esaminare la velocità effettiva dei nodi e l'utilizzo delle risorse

L'agente di logging GKE su ogni nodo ha un proprio limite di velocità effettiva, che può essere superato.

Sintomi:

I log di nodi specifici mancano o vengono ritardati in modo intermittente, in particolare durante i periodi di elevata attività del cluster o di utilizzo intenso delle risorse dei nodi.

Causa:

L'agente di logging GKE ha un limite di velocità effettiva predefinito (circa 100 KBps per nodo). Se le applicazioni su un nodo generano log più velocemente di questo limite, l'agente potrebbe eliminare i log, anche se la quota API complessiva del progetto non viene superata. Puoi monitorare la velocità effettiva di logging dei nodi utilizzando la metrica kubernetes.io/node/logs/input_bytes in Metrics Explorer.

I log potrebbero mancare anche se il nodo è sottoposto a un forte carico di CPU o memoria, lasciando risorse insufficienti per l'agente per elaborare i log.

Risoluzione:

Per ridurre la velocità effettiva, seleziona una delle seguenti opzioni:

Cluster standard

Prova le seguenti soluzioni:

  • Abilita logging ad alta velocità effettiva: questa funzionalità aumenta la capacità per nodo. Per saperne di più, vedi Regolare la velocità effettiva dell'agente Logging Cloud Logging.

  • Riduci il volume di log: analizza i pattern di logging delle applicazioni. Ridurre la registrazione non necessaria o eccessivamente dettagliata.

  • Esegui il deployment di un agente di logging personalizzato: puoi eseguire il deployment e gestire il tuo DaemonSet Fluent Bit personalizzato, ma sei responsabile della sua configurazione e manutenzione.

  • Controlla l'utilizzo delle risorse dei nodi: anche se il volume dei log rientra nei limiti, assicurati che i nodi non siano sottoposti a un carico eccessivo di CPU o memoria. Risorse dei nodi insufficienti possono ostacolare la capacità dell'agente di logging di elaborare e inviare i log. Puoi controllare metriche come kubernetes.io/node/cpu/core_usage_time e kubernetes.io/node/memory/used_bytes in Esplora metriche.

Cluster Autopilot

Prova le seguenti soluzioni:

  • Riduci il volume dei log: analizza i pattern di logging delle applicazioni. Ridurre la registrazione non necessaria o eccessivamente dettagliata. Se possibile, assicurati che i log siano strutturati, perché questi tipi di log possono contribuire a un'elaborazione efficiente. Escludi i log non essenziali.

  • Ottimizza le prestazioni delle applicazioni: poiché le risorse dei nodi vengono gestite nei cluster Autopilot, assicurati che le tue applicazioni non consumino eccessivamente CPU o memoria, il che potrebbe influire indirettamente sulle prestazioni dei componenti dei nodi come l'agente di logging. Anche se non gestisci direttamente i nodi, l'efficienza dell'applicazione influisce sull'integrità complessiva dei nodi.

Risolvere i problemi relativi al filtraggio e all'applicazione

Quando l'applicazione genera correttamente i log, ma questi non vengono visualizzati in Cloud Logging, il problema è spesso causato dal filtro o dal comportamento di logging dell'applicazione. Le sezioni seguenti esplorano problemi come i filtri di esclusione dei log, il buffering a livello di container, le query di ricerca restrittive e le applicazioni che non scrivono in stdout o stderr.

Esamina i filtri di esclusione dei log

Esplora log mostra solo i log che corrispondono a tutti i filtri nella query e all'intervallo di tempo selezionato.

Sintomi:

Log specifici che corrispondono a determinati criteri non sono presenti in Cloud Logging, ma sono presenti altri log delle stesse origini.

Causa:

I filtri di esclusione dei log sono definiti nei sink di Cloud Logging (spesso il sink _Default). Queste regole eliminano automaticamente i log che corrispondono a criteri specifici, anche se sono stati inviati correttamente dal nodo.

Risoluzione:

Per esaminare e modificare i filtri di esclusione, seleziona una delle seguenti opzioni:

Console

  1. Nella console Google Cloud , vai alla pagina Router dei log.

    Vai al router dei log

  2. Identifica il filtro problematico:

    1. Per ogni sink (tranne il sink _Required, che non può avere filtri di esclusione), fai clic su Altre azioni e seleziona Visualizza dettagli sink.
    2. Esamina le query nella sezione Filtri di esclusione. Confronta la logica del filtro con gli attributi dei log mancanti (ad esempio, tipo di risorsa, etichette o parole chiave).
    3. Copia la query del filtro di esclusione.

    4. Vai alla pagina Esplora log.

      Vai a Esplora log

    5. Incolla la query del filtro di esclusione nel riquadro della query e fai clic su Esegui query.

    6. Esamina i risultati. I log visualizzati sono quelli che il filtro escluderebbe. Se i log mancanti vengono visualizzati in questi risultati, è probabile che la causa sia questo filtro.

  3. Disattiva o modifica il filtro:

    1. Torna alla pagina Router dei log.
    2. Fai clic su Altre azioni per il sink con il filtro sospetto e seleziona Modifica sink.
    3. Individua la sezione Scegli i log da escludere dal sink e trova il filtro di esclusione.
    4. Puoi fare clic su Disattiva per disattivare il filtro oppure modificare la query per renderla più specifica.
    5. Fai clic su Aggiorna sink. Le modifiche si applicano ai nuovi log.

gcloud

  1. Elenca tutti i sink nel progetto:

    gcloud logging sinks list --project=PROJECT_ID

  2. Visualizza i filtri di esclusione di ogni sink:

    gcloud logging sinks describe SINK_NAME --project=PROJECT_ID

    Nell'output, rivedi la sezione exclusions. Confronta la logica del filtro con gli attributi dei log mancanti (ad esempio, tipo di risorsa, etichette o parole chiave).

  3. Per modificare le esclusioni, aggiorna la configurazione del sink:

    1. Esporta la configurazione del sink in un file locale (ad esempio, sink-config.yaml):

      gcloud logging sinks describe SINK_NAME \
    --format=yaml > sink-config.yaml

    2. Apri il file sink-config.yaml in un editor di testo.

    3. Trova la sezione exclusions: e rimuovi o modifica il filtro problematico.

    4. Aggiorna il sink modificato:

      gcloud logging sinks update SINK_NAME sink-config.yaml \
    --project=PROJECT_ID

      Per ulteriori informazioni su questo comando, consulta la documentazione di gcloud logging sinks update.

Esamina il buffering e i ritardi dei log dei container

Applicazioni e sistemi operativi spesso utilizzano il buffering per scrivere i dati in blocchi anziché riga per riga, il che può migliorare le prestazioni.

Sintomi:

  • I log di container specifici vengono visualizzati in Cloud Logging solo dopo l'uscita del container o con un ritardo significativo nella visualizzazione dei log.
  • A volte i log sono incompleti.

Causa:

Questo problema è spesso causato dal buffering dei log. Sebbene l'output standard (stdout) sia in genere memorizzato nel buffer di riga quando è connesso a un terminale, questo comportamento cambia quando l'output viene reindirizzato. Se i log o gli script di avvio di un'applicazione all'interno di un container inviano stdout ad altri comandi (ad esempio my-app | grep ...), l'output potrebbe essere completamente memorizzato nel buffer. Di conseguenza, i log vengono conservati fino a quando il buffer non è pieno o la pipe non si chiude. Questo comportamento può causare ritardi o perdita di dati se il contenitore termina in modo imprevisto. Anche il buffering interno dell'applicazione può causare ritardi.

Risoluzione:

Per risolvere il problema, prova le seguenti soluzioni:

  • Evita il piping stdout: se possibile, modifica i punti di ingresso del contenitore o i comandi dell'applicazione per scrivere i log direttamente in stdout o stderr senza eseguire il piping tramite altri comandi come grep o sed all'interno del contenitore.
  • Assicurati che sia presente un buffer di linea:
    • Se il piping è inevitabile, utilizza strumenti che supportano il buffering delle righe. Ad esempio, utilizza grep --line-buffered.
    • Per le applicazioni personalizzate, assicurati che i log vengano svuotati di frequente, idealmente dopo ogni riga, quando vengono scritti in stdout. Molte librerie di logging hanno impostazioni per controllare il buffering.

  • Testa il comportamento di buffering: esegui il deployment del seguente manifest del pod e osserva gli effetti nei log utilizzando il comando kubectl logs -f buffered-pod. Sperimenta commentando e decommentando i diversi array command nel manifest buffered-container:

    # buffered.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: run-script
data:
run.sh: |
    #!/bin/bash
    echo "Starting..."
    for i in $(seq 3600); do
    echo "Log ${i}"
    sleep 1
    done
    echo "Exiting."
---
apiVersion: v1
kind: Pod
metadata:
name: buffered-pod
spec:
containers:
    - name: buffered-container
    image: ubuntu  # Or any other image with bash

    # Case 1: Direct execution - line buffered by default to TTY
    # Logs appear immediately.
    command: ['/bin/bash', '-c', '/mnt/run.sh']

    # Case 2: Piped to grep - fully buffered by default
    # Logs might be delayed or appear in chunks.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep Log']

    # Case 3: Piped to grep with --line-buffered
    # Logs appear immediately.
    # command: ['/bin/bash', '-c', '/mnt/run.sh | grep --line-buffered Log']

    volumeMounts:
        - name: scripts
        mountPath: /mnt
volumes:
    - name: scripts
    configMap:
        name: run-script
        defaultMode: 0777
restartPolicy: Never

Esaminare le query di Esplora log

Se hai la certezza che i log vengano raccolti, ma non riesci a trovarli, il problema potrebbe riguardare la query di ricerca o l'intervallo di tempo.

Sintomi:

I log previsti non vengono visualizzati nei risultati di ricerca, anche se sai che l'applicazione li genera.

Causa:

La query in Esplora log potrebbe avere filtri (ad esempio su spazi dei nomi, etichette, tipi di risorse o testo) che escludono inavvertitamente i log che stai cercando.

Risoluzione:

  1. Nella console Google Cloud , vai alla pagina Esplora log.

    Vai a Esplora log

  2. Fai clic su Scegli intervallo di tempo. Anche se pensi di sapere quando si sono verificati i log, prova un intervallo molto più ampio per escludere problemi di sincronizzazione.

  3. Semplifica la query:

    1. Cancella tutti i filtri.

    2. Prova a filtrare solo per il tuo cluster:

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"

      Sostituisci quanto segue:

      • CLUSTER_NAME: il nome del tuo cluster.
      • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.

    3. Fai clic su Esegui query.

  4. Se la query generica funziona, reinserisci i filtri originali uno alla volta:

    • Tipo di risorsa: assicurati di utilizzare il tipo di risorsa corretto. Ad esempio, stai filtrando in base a k8s_container quando dovresti filtrare in base a k8s_node?
    • Etichette: controlla l'ortografia di resource.labels, ad esempio namespace_name, container_name o etichette personalizzate.
    • Gravità: assicurati che il livello di gravità (ad esempio, severity=ERROR) non sia troppo restrittivo.
    • Payload di testo: controlla la presenza di errori ortografici e stringhe eccessivamente restrittive nei termini di ricerca. Ad esempio, utilizza : per "contiene" anziché = per una corrispondenza esatta (jsonPayload.message:"error" anziché jsonPayload.message="error").

  5. Verifica che i filtri tengano conto della distinzione tra maiuscole e minuscole (il testo in genere non fa distinzione tra maiuscole e minuscole, ma le etichette potrebbero non farlo), assicurati che i valori non contengano caratteri nascosti o spazi aggiuntivi e controlla se i termini con caratteri speciali devono essere racchiusi tra virgolette.

  6. Controlla la cronologia. I cali improvvisi quando aggiungi un filtro possono aiutarti a identificare la parte problematica della query.

Per ulteriori suggerimenti sulle query di logging efficaci, consulta Trovare rapidamente le voci di log nella documentazione di Cloud Logging.

Se non riesci ancora a trovare i log dopo aver perfezionato la query, il problema potrebbe non essere la query, ma un problema descritto in altre sezioni di questo documento.

Esaminare il comportamento di logging specifico dell'applicazione

L'agente di logging GKE raccoglie solo i log scritti nei flussi stdout e stderr.

Sintomi:

In Cloud Logging non sono visibili log per un pod o un container specifico, anche se sono presenti altri log del cluster.

Causa:

L'applicazione non scrive su stdout o stderr. Potrebbe essere configurato in modo errato per scrivere i log in un file all'interno del container, dove l'agente di logging non può raccoglierli.

L'applicazione potrebbe anche combinare testo JSON e non JSON nel suo output. Il parser dell'agente di logging prevede un formato coerente (JSON o testo) da un singolo flusso. Se un'applicazione configurata per la registrazione JSON restituisce una riga di testo normale, può interrompere l'analizzatore, causando l'eliminazione o l'importazione errata dei log.

Risoluzione:

  1. Determina il nome del pod e lo spazio dei nomi dell'applicazione di cui mancano i log:

    kubectl get pods -n NAMESPACE_NAME

  2. Controlla i log dei container:

    • Se il pod ha un singolo container, esegui il seguente comando:

      kubectl logs POD_NAME \
    -n NAMESPACE_NAME

      Sostituisci quanto segue:

      • POD_NAME: il nome del pod.
      • NAMESPACE_NAME: lo spazio dei nomi del pod.

    • Se il pod ha più container, specifica il nome del container:

      kubectl logs POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Sostituisci CONTAINER_NAME con il nome del container all'interno del pod.

    • Per seguire i log in tempo reale, esegui questo comando:

      kubectl logs -f POD_NAME \
    -c CONTAINER_NAME \
    -n NAMESPACE_NAME

      Sostituisci quanto segue:

      • POD_NAME: il nome del pod.
      • CONTAINER_NAME: il nome del container all'interno del pod.
      • NAMESPACE_NAME: lo spazio dei nomi del pod.

  3. Analizza l'output:

    • Se il comando kubectl logs non produce output o se l'output comando non contiene i log previsti, il problema riguarda l'applicazione stessa. Il comando kubectl logs legge direttamente dagli stream stdout e stderr acquisiti dal runtime del container. Se i log non sono qui, l'agente di logging di GKE non può vederli.

      Modifica il codice o la configurazione dell'applicazione per interrompere la scrittura in un file e registra invece tutti i messaggi direttamente in stdout (per i log regolari) e stderr (per i log degli errori).

    • Se vedi un mix di stringhe JSON e righe di testo normale, questo output indica un problema di formato misto. Configura l'applicazione in modo che scriva solo oggetti JSON validi su una sola riga in stdout e stderr.

    • Se il comando kubectl logs mostra i log previsti, il problema si verifica probabilmente più avanti nella pipeline di logging (ad esempio, agent, autorizzazioni o servizio Cloud Logging).

Risolvere i problemi relativi a piattaforme e servizi

Le sezioni seguenti ti aiutano a esaminare i problemi esterni alla tua configurazione immediata, come le norme di conservazione dei log, l'integrità di Cloud Logging o le versioni di GKE non supportate.

Esaminare i periodi di conservazione dei log

I log vengono archiviati nei bucket e ogni bucket ha un periodo di conservazione che definisce per quanto tempo vengono conservati i log prima di essere eliminati automaticamente.

Sintomi:

I log precedenti a una determinata data non sono presenti.

Causa:

I log che stai cercando sono precedenti al periodo di conservazione del bucket di log a cui sono stati indirizzati.

Risoluzione:

Per identificare e aggiornare il periodo di conservazione, seleziona una delle seguenti opzioni:

Console

  1. Identifica il bucket a cui vengono indirizzati i log GKE:

    1. Nella console Google Cloud , vai alla pagina Router dei log.

      Vai al router dei log

    2. Controlla la colonna Destinazione, che mostra dove vengono indirizzati i log.

      La destinazione è simile alla seguente:

      logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

      Tieni presente PROJECT_ID, LOCATION e BUCKET_ID.

      I log vengono spesso indirizzati al bucket _Default, ma potrebbero anche essere indirizzati ad altri bucket se hai configurato sink personalizzati.

  2. Controlla il periodo di conservazione del bucket di log:

    1. Nella console Google Cloud , vai alla pagina Archiviazione log.

      Vai ad Archiviazione dei log

    2. Trova i bucket corrispondenti a BUCKET_ID, LOCATION e PROJECT_ID dalla destinazione del sink.

    3. Per ogni bucket pertinente, visualizza la colonna Periodo di conservazione.

    4. Se i log che vuoi visualizzare sono precedenti al periodo di conservazione, Cloud Logging li ha eliminati. Se hai bisogno di un periodo di conservazione più lungo, procedi nel seguente modo:

      1. Per il bucket di cui vuoi estendere il periodo di conservazione, fai clic su Altre azioni.
      2. Seleziona Modifica bucket e aggiorna il periodo di conservazione. Tieni presente le potenziali implicazioni sui costi.

gcloud

  1. Identifica il bucket a cui vengono indirizzati i log GKE:

    gcloud logging sinks list --project=PROJECT_ID

    Rivedi l'output. Il campo destination per ogni sink mostra dove vengono indirizzati i log. Il formato di destinazione per un bucket di log è:

    logging.googleapis.com/projects/PROJECT_ID/locations/LOCATION/buckets/BUCKET_ID

    Tieni presente PROJECT_ID, LOCATION e BUCKET_ID.

    I log vengono spesso indirizzati al bucket _Default.

  2. Controlla il periodo di conservazione del bucket di log:

    gcloud logging buckets describe BUCKET_ID \
    --location=LOCATION \
    --project=PROJECT_ID

    Nell'output, cerca il campo retentionDays. Se i log che ti servono sono precedenti al valore elencato per retentionDays, Cloud Logging li ha eliminati.

  3. Se hai bisogno di un periodo di conservazione più lungo, aggiornalo:

    gcloud logging buckets update BUCKET_ID \
    --location=LOCATION \
    --retention-days=RETENTION_DAYS \
    --project=PROJECT_ID

    Sostituisci quanto segue:

    • BUCKET_ID: l'ID del bucket di log.
    • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il bucket.
    • RETENTION_DAYS: il numero di giorni per cui conservare i log. Tieni presente le potenziali implicazioni sui costi dell'aumento del periodo di conservazione.
    • PROJECT_ID: il tuo ID progetto Google Cloud .

Indagare sui problemi del servizio Cloud Logging e sui ritardi di importazione

A volte, la pipeline di logging stessa potrebbe riscontrare problemi, a causa di un'interruzione a livello di servizio o di un ritardo temporaneo e su larga scala nell'importazione.

Sintomi:

  • Perdita di log diffusa o intermittente in più progetti o cluster.
  • La visualizzazione dei log in Esplora log è notevolmente ritardata.

Causa:

  • Interruzione del servizio Cloud Logging: un'interruzione rara a livello di servizio può impedire l'importazione dei log, causando ritardi diffusi o la perdita totale dei log.
  • Volume elevato di log: anche senza un'interruzione ufficiale, un volume elevato di log dal tuo progetto o dalla tua regione può sovraccaricare temporaneamente il servizio di importazione, causando ritardi nella visualizzazione dei log.

Risoluzione:

  • Controlla lo stato dei servizi Google Cloud visitando la Google Cloud dashboard Service Health. Cerca eventuali incidenti aperti relativi a Cloud Logging o GKE.

  • Tieni conto dei potenziali ritardi nell'importazione. Se i log non sono immediatamente visibili e non sono presenti incident attivi, attendi un po' di tempo per l'importazione, soprattutto se il volume dei log è elevato. Ricontrolla tra qualche minuto.

Esaminare la versione del cluster

GKE rilascia regolarmente nuove versioni che includono correzioni di bug e miglioramenti delle prestazioni per i componenti, incluso l'agente di logging.

Sintomi:

I problemi di logging coincidono con le limitazioni della versione del cluster.

Causa:

Il cluster potrebbe eseguire una versione di GKE precedente o non supportata che presenta problemi noti dell'agente di logging o non dispone di determinate funzionalità di logging.

Risoluzione:

Per risolvere il problema, segui questi passaggi:

  1. Controlla la versione del cluster:

    gcloud container clusters describe CLUSTER_NAME \
    --location LOCATION \
    --format="value(currentMasterVersion)"

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.

  2. Per assicurarti che sia una versione supportata, confrontala con la programmazione delle release di GKE.

  3. Se il cluster utilizza una versione non supportata, esegui l'upgrade del cluster.

Passaggi successivi