Migrazione a Cloud Operations per GKE

Esistono due opzioni per il monitoraggio e il logging del supporto in Google Kubernetes Engine (GKE):

• Logging e Monitoring legacy: per la documentazione, consulta le pagine Monitoraggio legacy e Logging legacy.

• Cloud Operations for GKE: per la documentazione, consulta Cloud Operations for GKE.

Questa pagina spiega le differenze tra queste due opzioni e ciò che devi modificare per eseguire la migrazione da Logging e Monitoring legacy a Cloud Operations for GKE.

Avviso: dopo il 31 marzo 2021, la registrazione e il monitoraggio legacy non saranno più supportati. Dopo questa data, la migrazione dei cluster che utilizzano Logging e Monitoring legacy viene eseguita automaticamente e gradualmente in Cloud Operations for GKE. Tuttavia, il supporto di Logging e Monitoring legacy e del supporto di Cloud Operations for GKE non sono compatibili. Per completare l'aggiornamento di Cloud Operations for GKE, devi modificare le configurazioni di Monitoring e Logging, incluse, a titolo esemplificativo, criteri di avviso, grafici, filtri di gruppo, query di log, sink di log, esclusioni di log e metriche basate su log.

Nota: questo argomento si applica solo ai cluster GKE Standard. Logging e Monitoring legacy non sono disponibili per i cluster Autopilot.

Quando devo eseguire la migrazione?

Puoi eseguire la migrazione delle configurazioni esistenti di Cloud Monitoring e Cloud Logging dalla versione legacy di Logging e Monitoring a Cloud Operations for GKE in qualsiasi momento. Tuttavia, tieni presente che Logging e Monitoring legacy non sono supportati in GKE versione 1.20.

Nota: la modifica della versione di GKE del cluster non influisce sul supporto configurato per il monitoraggio e il logging. Consulta Quale supporto utilizza il monitoraggio e il logging del mio cluster? per determinare il supporto attuale per il tuo cluster.

La tabella riportata di seguito riassume le opzioni di monitoraggio e logging disponibili in ogni versione di release di GKE:

Versione GKE	Logging e Monitoring legacy	Cloud Operations for GKE
1,14	Disponibile	predefinita
1,15	Disponibile	predefinita
1,16	Disponibile	predefinita
1,17	Disponibile	predefinita
1,18	Disponibile	predefinita
1,19	Disponibile	predefinita
1,20	Non disponibile	predefinita

Per informazioni sul ritiro di Logging e Monitoring legacy, consulta la guida Supporto per il ritiro di GKE.

Quali sono i vantaggi dell'utilizzo di Cloud Operations for GKE?

Cloud Operations for GKE offre importanti vantaggi, tra cui:

• Monitoraggio dell'infrastruttura migliorato. La dashboard di GKE include più metriche pronte all'uso nel livello gratuito, con un aumento da 17 metriche legacy a 44 nuove metriche.

• Più tipi di risorse per differenziare meglio le risorse Kubernetes, più metadati per filtrare e raggruppare le metriche.

• Supporto del monitoraggio orientato ai servizi con SLO Monitoring per GKE.

• Modelli di risorse coerenti tra Cloud Logging e Cloud Monitoring.

• Miglioramenti delle prestazioni per tutte le nuove metriche di GKE.

Cosa cambierà?

Cloud Operations for GKE utilizza un modello di risorse diverso rispetto a Logging e Monitoring legacy per organizzare metriche, log e metadati. Ecco alcune modifiche specifiche per i tuoi cluster che utilizzano Cloud Operations for GKE:

• Modifica alla navigazione: la dashboard di Cloud Monitoring si chiama GKE. Questa dashboard non viene visualizzata se non hai cluster che utilizzano Cloud Operations for GKE.

• Modifiche ai nomi dei tipi di risorse monitorate: ad esempio, i nodi Kubernetes sono elencati nel tipo di risorsa monitorata k8s_node , che è un nodo Kubernetes, anziché gce_instance (istanza VM di Compute Engine).

• Modifiche ai nomi delle metriche Kubernetes: in Cloud Operations for GKE, i nomi dei tipi di metrica iniziano ora con il prefisso kubernetes.io/ anziché container.googleapis.com/.

• Modifiche ai metadati loglog: le voci di log di Cloud Operations for GKE hanno cambiato i nomi di alcuni campi resource.label e labels. Ad esempio, il valore del campo resource.labels.namespace_id è cambiato in resource.labels.namespace_name, mentre il valore non è cambiato.

• Modifiche relative a loglog: i nomi dei log di Cloud Operations for GKE utilizzano stdout o stderr, mentre Logging e Monitoring legacy utilizzano una gamma più ampia di nomi, tra cui il nome del container. Il nome del container è ancora disponibile in Cloud Operations for GKE come etichetta delle risorse in resource.labels.container_name.

La tabella riportata di seguito riassume le modifiche precedenti:

Cambia	(Precedente) Logging e monitoraggio legacy	(Novità) Cloud Operations for GKE
Menu Dashboard	Dashboard > Cluster GKE	Dashboard > GKE
Prefissi delle metriche	container.googleapis.com	kubernetes.io
Metriche tipi di risorse	gke_container gce_instance (nessuno)	k8s_container k8s_node k8s_pod
Tipi di risorse di log	container gke_cluster gce_instance gke_nodepool	k8s_container k8s_cluster gke_cluster (solo log di controllo) k8s_node k8s_pod

Modifiche al tipo di risorsa

Cloud Operations for GKE ha nuovi nomi di tipi di risorse, nuovi nomi di visualizzazione dei tipi di risorse e nuovi nomi per le etichette che identificano risorse specifiche. Queste modifiche sono elencate nella tabella seguente.

Modifiche al tipo di risorsa

(Precedente) Tipo di risorsa legacy di Logging e Monitoring	(Nuovo) Tipo di risorsa Cloud Operations for GKE
Note a tabella: ^1 nel nuovo tipo di risorsa utilizzato solo per il monitoraggio, instance_id diventa node_name in metadata.system_labels. ^2 zone si riferisce alla località di questo container o istanza. location si riferisce alla località del nodo master del cluster. ^3 metadata.system_labels.node_name non è disponibile nei tipi di risorse k8s_container utilizzati per il logging. Non puoi eseguire la ricerca dei log in base al nome del nodo. ^4 Il tipo di risorsa gce_instance può rappresentare i nodi Kubernetes e le istanze VM non Kubernetes. Quando esegui l'upgrade a Cloud Operations for GKE, gli utilizzi relativi ai nodi vengono modificati per utilizzare il nuovo tipo di risorsa k8s_node, inclusi i log a livello di nodo con i seguenti nomi: kubelet, docker, kube-proxy, startupscript e node-problem-detector. ^5 I nodi k8s_pod e k8s_cluster potrebbero includere log non presenti nel supporto di Logging e Monitoring legacy.
Solo monitoraggio: gke_container (container GKE) Etichette:   cluster_name   container_name   instance_id^1   namespace_id   pod_id   project_id   zone^2 Solo logging: container (container GKE) Etichette:   cluster_name   container_name   instance_id^1   namespace_id   pod_id   project_id   zone^2	Monitoraggio e logging: k8s_container (container Kubernetes) Etichette:   cluster_name   container_name   metadata.system_labels.node_name^3   namespace_name   pod_name   project_id   location^2
Solo logging:: gce_instance (istanza VM di Compute Engine)^4 Etichette:   cluster_name   instance_id   project_id   zone^2	Monitoraggio e logging k8s_node^4 (nodo Kubernetes) Etichette:   cluster_name   node_name   project_id   location^2
(nessuno)	Monitoraggio e logging: k8s_pod^5 (pod Kubernetes) Etichette:   cluster_name   namespace_name   pod_name   project_id   location^2
Solo logging gke_cluster (GKE_cluster) Etichette:   cluster_name   project_id   location	Monitoraggio e logging: k8s_cluster^5 (cluster Kubernetes) Etichette:   cluster_name   project_id   location

Cosa devo fare?

Questa sezione contiene informazioni più specifiche sui cambiamenti dei modelli di risorse in Cloud Operations for GKE e sul loro impatto sulle configurazioni di monitoraggio e logging esistenti.

Devi eseguire i seguenti passaggi per eseguire la migrazione del cluster a Cloud Operations for GKE:

1. Identifica le configurazioni di logging e monitoraggio: identifica le configurazioni di logging e monitoraggio che potrebbero utilizzare valori modificati tra Logging e Monitoring legacy e Cloud Operations for GKE.

2. Aggiorna le configurazioni di logging e monitoring: aggiorna le configurazioni di logging e monitoraggio per riflettere le modifiche presenti in Cloud Operations for GKE.

3. Aggiorna la configurazione del cluster GKE: aggiorna il tuo cluster GKE per utilizzare l'impostazione Cloud Operations for GKE.

Poiché i modelli delle risorse e i nomi dei log sono cambiati tra le versioni legacy di Logging e Monitoring e quelle di Cloud Operations for GKE, è necessario aggiornare anche tutte le configurazioni di Logging o Monitoring che fanno riferimento alle modifiche nei modelli di risorse. La migrazione potrebbe richiedere l'aggiornamento delle configurazioni di Logging e Monitoring, tra cui a titolo esemplificativo:

• dashboard personalizzate
• grafici
• Filtri di gruppo
• criteri di avviso
• sink di log
• esclusioni di log
• metriche basate su log in Cloud Logging e Cloud Monitoring

Nota: dopo aver eseguito la migrazione di un cluster a Cloud Operations for GKE, assicurati di trovare i dati di monitoraggio e logging utilizzando solo i nuovi nomi dei tipi di risorse. Potresti comunque vedere i tipi di risorse legacy, ma contengono solo i dati di monitoraggio e logging precedenti all'aggiornamento dei cluster.

Identificazione dei cluster mediante Logging e Monitoring legacy

Utilizza la dashboard Cluster GKE di Cloud Monitoring per identificare i cluster all'interno di un progetto che utilizzano ancora Logging e Monitoring legacy:

1. Fai clic sulla dashboard di Cloud Monitoring GKE Cluster.
2. Assicurati che l'opzione "Ambito delle metriche" selezionato includa il progetto Google Cloud che vuoi esaminare per i cluster che eseguono Logging e Monitoring legacy.

3. Visualizza l'elenco dei cluster nella dashboard. Nella dashboard vengono visualizzati solo i cluster che utilizzano il logging e il monitoraggio legacy.

   Ad esempio, nel seguente screenshot ci sono 4 cluster che utilizzano Logging e Monitoring legacy.

   

Migrazione delle risorse di monitoraggio

Se utilizzi il logging e il monitoraggio legacy con un cluster GKE la cui versione del piano di controllo è la 1.15 o successiva, le metriche del cluster sono disponibili sia nei modelli di risorse legacy di Monitoring che in Cloud Operations for GKE. Ciò significa che, anche prima di eseguire la migrazione dei cluster a Cloud Operations for GKE, i tuoi cluster iniziano a generare metriche utilizzando il nuovo modello dei dati senza costi aggiuntivi.

A partire da gennaio 2021, le dashboard e gli avvisi personalizzati verranno aggiornati automaticamente per fare riferimento alle nuove metriche del modello di risorse. Se vuoi eseguire la migrazione delle tue configurazioni Cloud Monitoring (grafici in dashboard personalizzate, avvisi e gruppi), devi aggiornare ogni configurazione in modo che rifletta il nuovo modello di risorse.

Devi inoltre eseguire la migrazione delle configurazioni se la mantieni in Terraform o in un altro gestore di deployment e sincronizzi automaticamente le modifiche.

Identificazione delle configurazioni per il vecchio modello dei dati

Per identificare le configurazioni di Cloud Monitoring che devi aggiornare nell'ambito della migrazione a Cloud Operations for GKE, consulta la dashboard Kubernetes Migration Status:

1. Nella console Google Cloud, vai a Monitoring:

   Vai a Monitoring

2. Nel riquadro di navigazione di Monitoring, fai clic su Impostazioni, quindi seleziona la scheda Stato migrazione Kubernetes.

La seguente dashboard di esempio mostra che è necessario aggiornare 1 criterio di avviso:

Aggiornamento delle configurazioni di Cloud Monitoring

Se il cluster utilizza GKE versione 1.15 o successiva e la versione legacy di Monitoring, pubblica la creatività in entrambi i modelli di dati. In questo caso, hai due opzioni per eseguire la migrazione delle configurazioni.

• Clona le configurazioni e aggiorna i cloni. Con questa opzione puoi creare una copia delle dashboard, dei criteri di avviso e dei gruppi esistenti ed eseguire la migrazione delle copie nel nuovo modello di risorse. In questo modo, puoi continuare a utilizzare Monitoring per il tuo cluster utilizzando il vecchio modello di dati e il nuovo modello di dati contemporaneamente. Ad esempio, con questa opzione, avrai due dashboard: quella originale che continua a utilizzare il modello di risorse originale e un clone di una dashboard originale che utilizza il nuovo modello di risorse.

• Esegui l'upgrade delle configurazioni interessate. Questa opzione passa immediatamente al nuovo modello di dati in Cloud Monitoring.

Le sezioni seguenti forniscono istruzioni per eseguire la migrazione delle configurazioni per dashboard, criteri di avviso e gruppi.

Punto chiave: se vuoi verificare che una configurazione funzioni come previsto utilizzando le metriche di Cloud Operations for GKE, clona e confronta prima le configurazioni precedenti con quelle nuove. Tuttavia, se hai già confermato che la configurazione funziona come previsto utilizzando le metriche di Cloud Operations for GKE o se prevedi di farlo dopo l'upgrade della configurazione attiva, esegui l'upgrade ora.

Una considerazione per decidere quale opzione scegliere è la quantità di cronologia di monitoraggio che vuoi avere a disposizione. Attualmente Cloud Monitoring offre 6 settimane di dati storici per i tuoi cluster. Dopo l'upgrade del cluster GKE che inizia a scrivere due volte i modelli di dati, il vecchio modello presenta ancora le metriche storiche per il cluster, mentre il nuovo modello di dati include solo metriche che iniziano al momento dell'upgrade.

Se non hai bisogno dei dati storici, puoi eseguire l'upgrade delle configurazioni in loco al nuovo modello di dati in qualsiasi momento. Se i dati storici sono importanti, puoi clonare le configurazioni e aggiornare i cloni per utilizzare i nuovi tipi di modello di risorse.

In alternativa, puoi attendere 6 settimane dopo che il cluster inizia la doppia scrittura in entrambi i modelli di dati. Dopo sei settimane, entrambi i modelli di dati hanno gli stessi dati storici, quindi puoi eseguire l'upgrade delle configurazioni in corso e passare al nuovo modello di dati.

Aggiornamento delle dashboard

Per visualizzare le dashboard, completa i seguenti passaggi:

1. Nella console Google Cloud, vai a Monitoring:

   Vai a Monitoring

2. Seleziona Dashboard.

Per clonare una dashboard e aggiornarla, procedi nel seguente modo:

1. Trova la dashboard da clonare.

2. Fai clic su Copia dashboard () e inserisci un nome per la dashboard clonata.

3. Aggiorna le configurazioni della nuova dashboard in base alle tue esigenze.

Per aggiornare le definizioni del grafico nella dashboard:

1. Fai clic su Altre opzioni del grafico (⋮) del grafico da modificare.

2. Seleziona Modifica per aprire il riquadro Modifica grafico.

3. Modifica il tipo di risorsa e il nome della metrica da tradurre nel nuovo modello di dati. Se necessario, puoi anche aggiornare i campi Filtro e Raggruppa per.

Aggiornamento dei criteri di avviso

Per visualizzare i criteri di avviso, completa i seguenti passaggi:

1. Nella console Google Cloud, vai a Monitoring:

   Vai a Monitoring

2. Seleziona Avvisi.

Per clonare e aggiornare un criterio di avviso, completa i seguenti passaggi:

1. Seleziona il criterio da clonare dalla tabella Criteri.

2. Fai clic su Copia per avviare il flusso di creazione della copia del criterio di avviso.

3. Modifica le condizioni che fanno riferimento al modello dati precedente per aggiornare il tipo di risorsa e il nome della metrica.

   L'ultimo passaggio del flusso ti consente di inserire un nome per il criterio clonato.

Per modificare un criterio di avviso impostato, completa i seguenti passaggi:

1. Seleziona il criterio da modificare nella tabella Criteri.

2. Fai clic su Modifica per aggiornare la norma.

3. Aggiorna le condizioni che fanno riferimento al modello dati precedente.

Aggiornamento dei gruppi

Non è possibile clonare un gruppo tramite la console Google Cloud, quindi se vuoi duplicare un gruppo devi crearne uno nuovo con lo stesso filtro.

Un filtro di gruppo può fare riferimento al vecchio modello dei dati in diversi modi.

• Tipo di risorsa: un gruppo potrebbe definire un filtro resource.type="gke_container". Poiché il tipo gke_container può essere utilizzato per fare riferimento a diversi tipi di entità GKE, devi aggiornare il filtro al tipo di risorsa che intendi effettivamente associare: k8s_container, k8s_pod o k8s_node. Se vuoi trovare una corrispondenza per più tipi, definisci un filtro con più clausole combinate con l'operatore OR.

• Etichetta cloud_account: un gruppo potrebbe definire un filtro resource.metadata.cloud_account="<var>CLOUD_ACCOUNT_ID</<var>". Nell'ambito di un ritiro separato, il campo di metadati cloud_account non è più disponibile. Prendi in considerazione l'utilizzo dell'etichetta resource.labels.project_id.

• Etichetta region: un gruppo potrebbe definire un filtro resource.metadata.region="<var>REGION_NAME</<var>". Il campo di metadati region non è più disponibile nel nuovo modello dati. Se vuoi abbinare le entità GKE in base alla posizione geografica, ti consigliamo di utilizzare l'etichetta resource.labels.location.

Mappatura delle metriche tra i modelli di dati

Questa sezione descrive come mappare le metriche dal vecchio modello dei dati a quelle nel nuovo modello. Il modello di dati precedente ha pubblicato 17 metriche diverse, elencate nelle tabelle seguenti. Alcune di queste metriche sono state pubblicate su più tipi di entità GKE, il che si traduce in oltre 17 mappature per la traduzione di tutte le metriche.

Quando mappi le metriche, ricorda quanto segue:

• Il prefisso per le metriche precedenti è container.googleapis.com/. Il prefisso per le nuove metriche è kubernetes.io/.

• L'unico tipo di risorsa nel modello di dati precedente è gke_container. A seconda della modalità con cui hai definito le etichette delle risorse, questo tipo di risorsa potrebbe fare riferimento a container GKE, pod, daemon di sistema e macchine, che corrispondono ai nodi GKE.

• Puoi eseguire query sull'API Monitoring utilizzando combinazioni di pod_id e container_name che non corrispondono a quelle elencate nella seguente tabella. I dati restituiti da queste query non sono definiti e non viene fornita alcuna mappatura da questi stati non definiti.

  Tipo di entità GKE	Filtro
  Container	pod_id != '' e container_name != '' (pod_id non è la stringa vuota e container_name non è la stringa vuota)
  Pod	pod_id != '' e container_name == '' (pod_id non è la stringa vuota e container_name è la stringa vuota)
  Daemon di sistema	pod_id == '' e container_name != 'machine' (pod_id è la stringa vuota e container_name è una di docker-daemon, kubelets o pods)
  Macchina	pod_id == '' e container_name == 'machine' (pod_id è la stringa vuota e container_name è la stringa machine)

Le tabelle elencano tre tipi di mappature:

• Mappatura diretta tra il vecchio e il nuovo modello di dati.

• Mappature che richiedono la configurazione.

• Mappature di metriche precedenti che non hanno un equivalente diretto nel nuovo modello.

Mappatura diretta

Le seguenti metriche traducono direttamente tra il modello di dati precedente e quello nuovo.

Nome metrica precedente	Tipo di entità GKE precedente	Nuovo nome metrica	Nuovo tipo di risorsa GKE	Note
container/accelerator/ duty_cycle	Container	container/accelerator/ duty_cycle	container_k8s
container/accelerator/ memory_total)	Container	container/accelerator/ memory_total)	container_k8s
container/accelerator/ memory_used	Container	container/accelerator/ memory_used	container_k8s
container/accelerator/ richiesta	Container	container/accelerator/ richiesta	container_k8s
container/cpu/ prenotati_core	Container	container/cpu/ limit_cores	container_k8s	Vedi Mappature che richiedono la configurazione per la mappatura quando la risorsa è pod
container/cpu/ usage_time	Container	container/cpu/ core_usage_time	container_k8s	Vedi Mappature che richiedono la configurazione per la mappatura quando la risorsa è pod
container/cpu/ usage_time	Daemon di sistema	node_daemon/cpu/ core_usage_time	nodo_k8s	Nel modello di dati precedente, gke_container.container_name è uno di docker-daemon, kubelets o pods. Questi valori del filtro corrispondono a quelli nel nuovo campo del modello di dati metric.component.
container/cpu/ utilizzo	Container	container/cpu/ limit_utilization	container_k8s
container/disk/ byte_totale	Pod	pod/volume/ byte_totale	pod k8s	L'elemento gke_container.device_name (Volume:config-volume) è tradotto in k8s_pod.volume_name (config-volume) rimuovendo il Volume: che era stato anteposto.
container/disk/bytes_used	Pod	pod/volume/ byte_utilizzati	pod k8s	L'elemento gke_container.device_name (Volume:config-volume) è tradotto in k8s_pod.volume_name (config-volume) rimuovendo il Volume: che era stato anteposto.
container/memory/ byte_total	Container	container/memory/ limit_byte	container_k8s
container/memory/ byte_used	Container	container/memory/ used_byte	container_k8s
container/memory/ byte_used	Daemon di sistema	node_daemon/memory/ used_bytes	nodo_k8s	Nel modello di dati precedente, gke_container.container_name è uno di docker-daemon, kubelets o pods. Questi valori del filtro corrispondono a quelli nel nuovo campo del modello di dati metric.component.
container/disk/ inodes_free	Macchina	node/ephemeral_storage/ inodes_free	nodo_k8s	Il modello di dati precedente ha il campo instance_id, un ID numero casuale. Il nuovo modello dei dati ha node_name, un nome leggibile.
container/disk/ inodi_totale	Macchina	node/ephemeral_storage/ inodes_total	nodo_k8s	Il modello di dati precedente ha il campo instance_id, un ID numero casuale. Il nuovo modello dei dati ha node_name, un nome leggibile.
container/pid_limit	Macchina	node/pid_limit	nodo_k8s	Il modello di dati precedente ha il campo instance_id, un ID numero casuale. Il nuovo modello dei dati ha node_name, un nome leggibile.
container/pid_used	Macchina	node/pid_used	nodo_k8s	Il modello di dati precedente ha il campo instance_id, un ID numero casuale. Il nuovo modello dei dati ha node_name, un nome leggibile.

Mappature che richiedono la configurazione

Le seguenti metriche traducono dal vecchio modello dei dati al nuovo modello dei dati, con qualche manipolazione di base.

Nome metrica precedente	Tipo di entità GKE precedente	Nuovo nome metrica	Nuovo tipo di risorsa GKE	Note
container/cpu/ prenotati_core	Pod	SOMMA container/cpu/limit_cores raggruppa per pod_name	container_k8s	Il modello dei dati precedente ha un campo pod_id, un UUID. Il nuovo modello dei dati ha pod_name, un nome leggibile.
container/cpu/ usage_time	Pod	SOMMA container/cpu/core_usage_time GROUP BY pod_name	container_k8s	Il modello dei dati precedente ha un campo pod_id, un UUID. Il nuovo modello dei dati ha un pod_name, un nome leggibile.
container/disk/ byte_totale	Container	node/ephemeral_storage/ total_bytes	container_k8s	gke_container.device_name è uno di / o logs. Ciascuno di questi valori è uguale al nuovo valore.
container/disk/ byte_used	Container	container/ephemeral_storage/ used_byte	container_k8s	gke_container.device_name è uno di / o logs. Questi due valori devono essere sommati per ottenere il nuovo valore. Nel nuovo modello dati, non puoi ottenere i valori / e logs separatamente.
container/memory/ byte_total	Pod	SOMMA container/memory/limit_bytes raggruppa per pod_name	container_k8s	Il modello dei dati precedente ha un campo pod_id, un UUID. Il nuovo modello dei dati ha pod_name, un nome leggibile.
container/memory/ byte_used	Pod	SOMMA container/memory/used_bytes raggruppa per pod_name	container_k8s	Il modello dei dati precedente ha un campo pod_id, un UUID. Il nuovo modello dei dati ha pod_name, un nome leggibile.

Mappature che non hanno un equivalente diretto nel nuovo modello

Le seguenti metriche non hanno un equivalente nel nuovo modello dati.

Utilizzo CPU per il pod

Nel modello di dati precedente, questa metrica, basata sul limite di CPU per ciascun container, rappresenta una media ponderata dell'utilizzo della CPU in tutti i container di un pod.

Nel nuovo modello dei dati, questo valore non esiste e deve essere calcolato in base al lato client in base al limite e all'utilizzo di ciascun container.

Tempo di attività

Nel vecchio modello dei dati, questa metrica è una metrica cumulativa che rappresenta la frazione di tempo in cui un container è disponibile in unità ms/s. Per un container sempre disponibile, il valore è di circa 1000 ms/s.

Nel nuovo modello dei dati, questa metrica è una metrica relativa alle ore e indica la durata di ogni parte del sistema senza interruzioni.

Modifiche al gruppo di risorse

Se definisci i gruppi di risorse e utilizzi uno dei tipi di risorse legacy di Logging e Monitoring visualizzati nella tabella Modifiche dei tipi di risorse precedente, modifica questi tipi come tipi di risorse Cloud Operations for GKE corrispondenti. Se il gruppo di risorse include grafici personalizzati, potresti doverli modificare.

Nota: verifica che i gruppi aggiornati contengano lo stesso numero di risorse dell'upgrade prima dell'upgrade. Un numero insufficiente di risorse potrebbe indicare che hai perso alcune modifiche.

Migrazione delle risorse di logging

Per eseguire la migrazione delle risorse di logging, completa i passaggi nelle sezioni seguenti.

Modifiche ai contenuti delle voci di log

Quando esegui l'aggiornamento a Cloud Operations for GKE, potresti notare che alcune informazioni nelle voci di log sono state spostate in campi con nomi diversi. Queste informazioni possono essere visualizzate nelle query sui log utilizzate in metriche basate su log, sink di log ed esclusioni dei log.

Nella tabella seguente, Modifiche alle voci di log, sono elencati i nuovi campi e le nuove etichette. Ecco un breve riepilogo:

• Controlla il campo logName nei filtri. Le voci di log di Cloud Operations for GKE utilizzano stdout o stderr nei nomi di log, mentre Logging e Monitoring legacy utilizzavano una gamma più ampia di nomi, tra cui il nome del container. Il nome del container è ancora disponibile come etichetta della risorsa.
• Verifica il campo labels nelle voci di log. Questo campo potrebbe contenere informazioni che in precedenza erano presenti nei campi delle voci di log metadata.
• Verifica il campo resource.labels nelle voci di log. I nuovi tipi di risorse hanno valori etichette aggiuntivi.

Modifiche alla voce di log

(Precedente) Voci di log Logging e Monitoring legacy	(Novità) Voci di log di Cloud Operations for GKE
Note a tabella: ^1 Le etichette delle risorse identificano risorse specifiche che generano metriche, come cluster e nodi specifici. ^2 Il campo labels viene visualizzato nelle nuove voci di log che fanno parte di Cloud Operations for GKE e occasionalmente in alcune voci di log legacy e di Monitoring. Nella Suite operativa di Google Cloud per GKE, viene utilizzato per archiviare alcune informazioni precedentemente nei campi delle voci di log metadata.
Risorse per le voci di log resource.labels (etichette delle risorse^1)	Risorse per le voci di log resource.labels (etichette delle risorse^1)
Metadati delle voci di log labels (etichette di voci di log^2) etichette (esempi)   compute.googleapis.com/resource_name:     "fluentd-gcp-v3.2.0-d4d9p"   container.googleapis.com/namespace_name:     "kube-system"   container.googleapis.com/pod_name:     "fluentd-gcp-scaler-8b674f786-d4pq2"   container.googleapis.com/stream:     "stdout"	Metadati delle voci di log labels etichette (esempi)   k8s-pod/app:     "currencyservice"   k8s-pod/pod-template-hash:     "5a67f17c"

Log di esempio:

Modifiche al tipo di risorsa del container:

Il testo in rosso mostra le differenze tra i modelli di risorse Logging e Monitoring legacy e Cloud Operations for GKE.

Modello di risorsa	Log di esempio
Logging e Monitoring legacy	{ "insertId": "fji4tsf1a8o5h", "jsonPayload": { "pid": 1, "name": "currencyservice-server", "v": 1, "message": "conversion request successful", "hostname": "currencyservice-6995d74b95-zjkmj" }, "resource": { "type": "container", "labels": { "project_id": "my-test-project", "cluster_name": "my-test-cluster", "pod_id": "currencyservice-6995d74b95-zjkmj", "zone": "us-central1-c", "container_name": "server", "namespace_id": "default", "instance_id": "1234567890" } }, "timestamp": "2020-10-02T19:02:47.575434759Z", "severity": "INFO", "labels": { "container.googleapis.com/pod_name": "currencyservice-6995d74b95-zjkmj", "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk", "container.googleapis.com/stream": "stdout", "container.googleapis.com/namespace_name": "default" }, "logName": "projects/my-test-project/logs/server", "receiveTimestamp": "2020-10-02T19:02:50.972304596Z" }
Cloud Operations for GKE	{ "insertId": "mye361s5zfcl55amj", "jsonPayload": { "v": 1, "name": "currencyservice-server", "pid": 1, "hostname": "currencyservice-5b69f47d-wg4zl", "message": "conversion request successful" }, "resource": { "type": "k8s_container", "labels": { "container_name": "server", "project_id": "my-test-project", "pod_name": "currencyservice-5b69f47d-wg4zl", "namespace_name": "onlineboutique", "location": "us-central1-c", "cluster_name": "my-prod-cluster" } }, "timestamp": "2020-10-02T18:41:55.359669767Z", "severity": "INFO", "labels": { "k8s-pod/app": "currencyservice", "k8s-pod/pod-template-hash": "5b69f47d", "compute.googleapis.com/resource_name": "gke-legacy-cluster-default-pool-c534acb8-hvxk" }, "logName": "projects/my-test-project/logs/stdout", "receiveTimestamp": "2020-10-02T18:41:57.930654427Z" }

Modifiche al tipo di risorsa cluster:

Il testo in rosso mostra le differenze tra i modelli di risorse Logging e Monitoring legacy e Cloud Operations for GKE.

Modello di risorsa	Log di esempio
Logging e Monitoring legacy	{ "insertId": "962szqg9uiyalt", "jsonPayload": { "type": "Normal", "involvedObject": { "apiVersion": "policy/v1beta1", "uid": "a1bc2345-12ab-12ab-1234-123456a123456", "resourceVersion": "50968", "kind": "PodDisruptionBudget", "namespace": "knative-serving", "name": "activator-pdb" }, "apiVersion": "v1", "reason": "NoPods", "source": { "component": "controllermanager" }, "message": "No matching pods found", "kind": "Event", "metadata": { "selfLink": "/api/v1/namespaces/knative-serving/events/activator-pdb.163a42fcb707c1fe", "namespace": "knative-serving", "name": "activator-pdb.163a42fcb707c1fe", "uid": "a1bc2345-12ab-12ab-1234-123456a123456", "creationTimestamp": "2020-10-02T19:17:50Z", "resourceVersion": "1917" } }, "resource": { "type": "gke_cluster", "labels": { "project_id": "my-test-project", "location": "us-central1-c", "cluster_name": "my-prod-cluster" } }, "timestamp": "2020-10-02T21:33:20Z", "severity": "INFO", "logName": "projects/my-test-project/logs/events", "receiveTimestamp": "2020-10-02T21:33:25.510671123Z" }
Cloud Operations for GKE	{ "insertId": "1qzipokg6ydoesp", "jsonPayload": { "involvedObject": { "uid": "a1bc2345-12ab-12ab-1234-123456a123456", "name": "istio-telemetry", "apiVersion": "autoscaling/v2beta2", "resourceVersion": "90505937", "kind": "HorizontalPodAutoscaler", "namespace": "istio-system" }, "source": { "component": "horizontal-pod-autoscaler" }, "kind": "Event", "type": "Warning", "message": "missing request for cpu", "metadata": { "resourceVersion": "3071416", "creationTimestamp": "2020-08-22T14:18:59Z", "name": "istio-telemetry.162d9ce2894d6642", "selfLink": "/api/v1/namespaces/istio-system/events/istio-telemetry.162d9ce2894d6642", "namespace": "istio-system", "uid": "a1bc2345-12ab-12ab-1234-123456a123456" }, "apiVersion": "v1", "reason": "FailedGetResourceMetric" }, "resource": { "type": "k8s_cluster", "labels": { "project_id": "my-test-project" "location": "us-central1-a", "cluster_name": "my-prod-cluster1", } }, "timestamp": "2020-10-02T21:39:07Z", "severity": "WARNING", "logName": "projects/my-test-project/logs/events", "receiveTimestamp": "2020-10-02T21:39:12.182820672Z" }

Modifiche al tipo di risorsa del nodo:

Il testo in rosso mostra le differenze tra i modelli di risorse Logging e Monitoring legacy e Cloud Operations for GKE.

Modello di risorsa	Log di esempio
Logging e Monitoring legacy	{ "insertId": "16qdegyg9t3n2u5", "jsonPayload": { "SYSLOG_IDENTIFIER": "kubelet", [...] "PRIORITY": "6", "_COMM": "kubelet", "_GID": "0", "_MACHINE_ID": "9565f7c82afd94ca22612c765ceb1042", "_SYSTEMD_UNIT": "kubelet.service", "_EXE": "/home/kubernetes/bin/kubelet" }, "resource": { "type": "gce_instance", "labels": { "instance_id": "1234567890", "zone": "us-central1-a", "project_id": "my-test-project" } }, "timestamp": "2020-10-02T21:43:14.390150Z", "labels": { "compute.googleapis.com/resource_name": "gke-legacy-monitoring-default-pool-b58ff790-29rr" }, "logName": "projects/my-test-project/logs/kubelet", "receiveTimestamp": "2020-10-02T21:43:20.433270911Z" }
Cloud Operations for GKE	{ "insertId": "kkbgd6e5tmkpmvjji", "jsonPayload": { "SYSLOG_IDENTIFIER": "kubelet", [...] "_CAP_EFFECTIVE": "3fffffffff", "_HOSTNAME": "gke-standard-cluster-1-default-pool-f3929440-f4dy", "PRIORITY": "6", "_COMM": "kubelet", "_TRANSPORT": "stdout", "_GID": "0", "MESSAGE": "E1002 21:43:14.870346 1294 pod_workers.go:190] Error syncing pod 99ba1919-d633-11ea-a5ea-42010a800113 (\"stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\"), skipping: failed to \"StartContainer\" for \"metadata-agent\" with CrashLoopBackOff: \"Back-off 5m0s restarting failed container=metadata-agent pod=stackdriver-metadata-agent-cluster-level-65655bdbbf-v5vjv_kube-system(99ba1919-d633-11ea-a5ea-42010a800113)\"" }, "resource": { "type": "k8s_node", "labels": { "cluster_name": "my-prod-cluster-1", "location": "us-central1-a", "node_name": "gke-standard-cluster-1-default-pool-f3929440-f4dy" "project_id": "my-test-project", } }, "timestamp": "2020-10-02T21:43:14.870426Z", "logName": "projects/my-test-project/logs/kubelet", "receiveTimestamp": "2020-10-02T21:43:20.788933199Z" }

Aggiornamenti della configurazione di Logging

Questa sezione descrive le modifiche che potresti dover apportare alla configurazione di Cloud Logging nell'ambito di una migrazione a Cloud Operations for GKE. Devi inoltre eseguire la migrazione delle configurazioni se mantieni la configurazione in Terraform o in un altro gestore di deployment e sincronizzi automaticamente le modifiche.

Logging delle query

Se utilizzi le query per trovare e filtrare i log in Cloud Logging e utilizzi uno dei tipi di risorse legacy di Logging e Monitoring visualizzati nella tabella Modifiche ai tipi di risorse precedenti, imposta questi tipi sui tipi corrispondenti di Cloud Operations for GKE.

Ad esempio, in Logging e Monitoring legacy, esegui una query per i log dei container utilizzando il tipo di risorsa container, mentre in Cloud Operations for GKE utilizzi il tipo di risorsa k8s_container per l'esecuzione di query sui log dei container.

  resource.type="k8s_container"

Come ulteriore esempio, in Logging e Monitoring legacy puoi eseguire query su nomi di log specifici per i container utilizzando il nome del container, mentre in Cloud Operations for GKE utilizzi i nomi di log stdout e stderr per eseguire query sui log di container.

  resource.type="k8s_container"
  log_name="projects/YOUR_PROJECT_NAME/logs/stdout"
  resource.labels.container_name="CONTAINER_NAME"

Metriche basate su log

Se definisci le tue metriche basate su log e utilizzi le metriche o i tipi di risorse legacy di Logging e Monitoring mostrati nelle precedenti tabelle Modifiche ai nomi delle metriche o Modifiche ai tipi di risorse, modifica tali metriche e tipi di risorse in quelle Cloud Operations for GKE corrispondenti.

Nota: se non visualizzi alcun esempio delle metriche basate su log dopo l'aggiornamento a Cloud Operations for GKE, è possibile che tu stia ancora utilizzando le metriche o i tipi di risorse legacy di Logging e Monitoring.

Puoi utilizzare il seguente comando dell'interfaccia a riga di comando gcloud per trovare le metriche basate su log:

  gcloud logging metrics list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging metrics list --filter='filter~resource.labels.namespace_id'

  gcloud logging metrics list --filter='filter~resource.labels.pod_id'

  gcloud logging metrics list --filter='filter~resource.labels.zone'

Puoi utilizzare il seguente comando dell'interfaccia a riga di comando gcloud per aggiornare le metriche basate sui log.

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging metrics update YOUR_LOGS_BASED_METRIC_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

In alternativa, puoi aggiornare le metriche basate su log nella console Google Cloud.

Esportazioni dei log

Se esporti uno qualsiasi dei log e se l'esportazione utilizza i tipi di risorse legacy di Logging e Monitoring visualizzati nella tabella Modifiche dei tipi di risorse precedente, modifica l'esportazione per utilizzare i tipi di risorse Cloud Operations for GKE corrispondenti. Le voci di log di Cloud Operations for GKE utilizzano i nomi di log stdout o stderr, mentre Logging e Monitoring legacy utilizzano il nome del container.

Esistono due importanti considerazioni per la modifica del nome di log:

1. Modifiche all'esportazione di posizioni e tabelle dei file di destinazione: i valori dei nomi di log in Cloud Operations for GKE includono stdout o stderr invece del nome del container. Il nome del container è ancora disponibile come etichetta della risorsa. L'elaborazione del nome log nelle esportazioni o nelle query di Cloud Storage tramite le tabelle BigQuery deve essere modificata per utilizzare i nomi dei log stdout e stderr.
2. Valori loglog: vengono utilizzati per determinare la struttura del file esportato in Cloud Storage e la struttura della tabella in BigQuery. L'utilizzo dei file e delle tabelle BigQuery di Cloud Storage deve essere adeguato per tenere conto della struttura delle cartelle in Cloud Storage e delle strutture delle tabelle in BigQuery.

Nota: prima di eseguire l'aggiornamento a Cloud Operations for GKE, prendi nota del numero approssimativo di voci di log che stai esportando dal tuo progetto G C P, in modo da verificare che tu riceva ancora un numero appropriato.

Puoi utilizzare i seguenti comandi dell'Google Cloud CLI per trovare i sink di logging interessati:

  gcloud logging sinks list --filter='filter~resource.type=\"container\" OR filter~resource.type=container'

  gcloud logging sinks list --filter='filter~resource.labels.namespace_id'

  gcloud logging sinks list --filter='filter~resource.labels.pod_id'

  gcloud logging sinks list --filter='filter~resource.labels.zone'

Puoi utilizzare il seguente comando dell'interfaccia a riga di comando gcloud per aggiornare i sink di logging.

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.type=\"container\" OR resource.type=\"k8s_container\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.namespace_id=\"YOUR_NAMESPACE\" OR resource.labels.namespace_name=\"YOUR_NAMESPACE\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.pod_id=\"YOUR_POD_NAME\" OR resource.labels.pod_name=\"YOUR_NAME\"'

  gcloud logging sinks update YOUR_SINK_NAME --log-filter='resource.labels.zone=\"YOUR_ZONE\" OR resource.labels.location=\"YOUR_ZONE\"'

In alternativa, puoi aggiornare le metriche basate su log nella console Google Cloud.

Esclusioni dei log

Se escludi alcuni dei tuoi log e se i filtri di esclusione utilizzano i tipi di risorse legacy di Logging e Monitoring visualizzati nella tabella Modifiche dei tipi di risorse precedente, modifica i filtri di esclusione per utilizzare i tipi di risorse Cloud Operations for GKE corrispondenti.

Per informazioni su come visualizzare le esclusioni dei log, consulta la guida Visualizzazione dei filtri di esclusione.

Nota: prima di eseguire l'aggiornamento a Cloud Operations for GKE, prendi nota del numero approssimativo di voci di log che stai escludendo dal progetto G C P, in modo da verificare che tu riceva ancora un numero appropriato.

Modifiche alla posizione del log

In Cloud Logging, i tuoi log vengono archiviati con il tipo di risorsa che li ha generati. Poiché questi tipi sono cambiati in Cloud Operations for GKE, assicurati di cercare i log nei nuovi tipi di risorse, come Kubernetes Container e non nei tipi legacy di logging e monitoraggio, come GKE Container.

Aggiorna la configurazione del cluster

Dopo aver eseguito la migrazione di qualsiasi logging e monitoraggio delle risorse per utilizzare il formato dei dati di Cloud Operations for GKE, l'ultimo passaggio è aggiornare il cluster GKE in modo da utilizzare Cloud Operations for GKE.

Per aggiornare la configurazione di logging e monitoraggio del cluster GKE, segui questi passaggi:

CONSOLE

1. Vai alla pagina Cluster di GKE per il tuo progetto. Viene visualizzato il seguente pulsante:

   Vai ai cluster Kubernetes

2. Fai clic sul cluster che vuoi aggiornare per utilizzare Cloud Operations for GKE.

3. Nella riga Cloud Operations for GKE, fai clic sull'icona Modifica.

4. Nella finestra di dialogo visualizzata, verifica che sia selezionata l'opzione Abilita Operazioni Cloud per GKE.

5. Nel menu a discesa della finestra di dialogo, seleziona i log e le metriche da raccogliere. L'impostazione predefinita (consigliata) per Cloud Operations for GKE è il monitoraggio e il logging di sistemi e carichi di lavoro. Se selezioni in questo menu a discesa qualsiasi valore diverso da "legacy Logging and Monitoring", il cluster verrà aggiornato per iniziare a utilizzare Cloud Operations for GKE anziché Logging e Monitoring legacy.

6. Fai clic su Salva modifiche.

GCLOUD

1. Esegui questo comando:

   gcloud container clusters update [CLUSTER_NAME] \
     --zone=[ZONE] \
     --project=[PROJECT_ID] \
     --logging=SYSTEM,WORKLOAD \
     --monitoring=SYSTEM
   

Passaggi successivi

• Per ulteriori informazioni sulla nuova dashboard di Cloud Operations for GKE, consulta Osservazione del sistema.
• Per informazioni sulla visualizzazione dei log, vedi Visualizzazione dei log GKE.