Linee guida per il monitoraggio del cluster

Stai visualizzando la versione 1.10 di Documentazione di Apigee hybrid. Per ulteriori informazioni, vedi Versioni supportate.

Version 1.10 

   Versioni supportate:

• v1.13 (più recente)                        
• v1.12                         
• v1.11                         
• Elenco delle versioni supportate

Versioni non supportate:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Panoramica

Questa guida fornisce linee guida su cosa monitorare e su come monitorare un deployment di Apigee Hybrid. È destinato agli amministratori di cluster ibride e agli amministratori dell'organizzazione.

Se non hai dimestichezza con il monitoraggio di Google Cloud, consulta la documentazione di Google Cloud Monitoring per informazioni su come creare grafici con Metrics Explorer e su come funzionano gli avvisi.

I cluster ibridi Apigee forniscono metriche SLI (indicatore del livello del servizio) per aiutarti a comprendere in che modo di sistema e applicazioni siano in esecuzione in un dato momento. Puoi visualizzare un elenco completo delle metriche disponibili.

Google Cloud Monitoring utilizza il tipo di risorsa per identificare ogni metrica SLI. Esistono tre tipi di risorse comuni utilizzati per tutte le metriche di Apigee Hybrid.

• k8s_container per le metriche a livello di sistema.
• ProxyV2 per le metriche del proxy API Apigee.
• TargetV2 per le metriche di destinazione dell'API Apigee

I tipi di risorsa hanno etichette comuni che si applicano a tutte le metriche associate. Ad esempio, tutte le metriche con tipo di risorsa k8s_container hanno le etichette cluster_name, pod_name e container_name, oltre alle etichette delle metriche. È necessario utilizzare una combinazione di etichette Resource Type ed etichette delle metriche per per monitorare in modo efficace l'integrità e le prestazioni del cluster.

Soglia di avviso: in un mondo perfetto, le soglie di avviso sarebbero evidenti e la documentazione fornita elencarebbe i valori che devono attivare gli avvisi. In realtà, è meno ovvio per Apigee definire cosa sia un rendimento accettabile e cosa sia un utilizzo pericoloso delle risorse di servizi e infrastrutture. I valori delle soglie di avviso variano notevolmente in base a particolari modelli di traffico e agli accordi SLO/SLA.

L'ottimizzazione e la determinazione della soglia di avviso sono un processo continuo, in quanto possono variare in base all'utilizzo del servizio e dell'infrastruttura. Utilizza Avviso e Soglia critica per le notifiche e avvisi di sicurezza.

• Stato integro: il valore è inferiore alla soglia di avviso.
• Concerto: valore maggiore della soglia di avviso, ma è minore di la soglia critica.
• Critica: Valore > Soglia critica.

I clienti dovrebbero usare gli strumenti forniti per determinare la soglia ottimale, che si tratti dashboard di Cloud Monitoring che i clienti possono creare con l'MQL fornito di seguito oppure l'analisi di Apigee, per identificare ciò che "normale" e poi ottimizza le soglie di avviso di conseguenza.

Il monitoraggio dei cluster ibride può essere classificato in quattro diversi gruppi generali, ad esempio monitoraggio del traffico, del database, del piano di controllo Apigee e dell'infrastruttura. Nelle sezioni seguenti vengono descritti in dettaglio questi gruppi:

Nota: il monitoraggio del traffico API è lo stesso per i cluster Apigee-X e Hybrid. Gli utenti di Apigee-X hanno accesso alle metriche SLI del traffico API, come Proxy, Target e Policy, nel progetto Google Cloud dell'organizzazione e possono utilizzare queste metriche SLI per il monitoraggio e gli avvisi.

Suggerimento: in genere, il "Tasso di richieste" le dashboard sono utili autonomamente visualizzazione del modello di traffico. Aggiunta di una soglia di avviso solo per lo SLI del tasso di richieste le metriche possono essere difficili, a meno che il modello di traffico/volume non sia predeterminato. Tuttavia, un il grafico del tasso di richieste può fornire informazioni utili su picchi di traffico anomali insoliti o cali durante il debug di qualsiasi problema relativo al traffico (lettura, scrittura, codice di risposta e così via).

Traffico

Le metriche SLI di proxy e target di Apigee forniscono conteggi di richieste/risposte e latenze per i proxy e i target API. La metrica SLI di latenza del criterio Apigee fornisce le latenze di risposta dei criteri. Queste metriche SLI forniscono la copertura per il monitoraggio del traffico dell'API Apigee.

Tasso di richieste

Conteggio delle richieste proxy

Caso d'uso: utilizza proxyv2/request_count per monitorare il conteggio delle richieste del proxy. La Il grafico proxyv2/request_count mostra il tasso di richieste per i proxy. Questo grafico è utile per identificare il proxy che riceve un tasso di richieste, i pattern del tasso di richieste e picco anomalo nelle chiamate di richiesta per un determinato proxy. Qualsiasi picco anomalo imprevisto nell'API il traffico potrebbe essere un problema di sicurezza per un bot o un attacco ai proxy API. Analogamente, un calo significativo del traffico cloud complessivo indica problemi con i client o la connettività dei componenti Apigee upstream.

Tipi di risorse	ProxyV2
Metrica	proxyv2/request_count
Raggruppa per	method e tutte le etichette dei tipi di risorsa ProxyV2
Aggregatore	sum
Considerazione degli avvisi	Eventi come gli avvisi relativi a picchi/cali anomali di request_count
Soglia di avviso	Nessuna
Query MQL della dashboard di Cloud Monitoring: fetch apigee.googleapis.com/ProxyV2 | metric 'apigee.googleapis.com/proxyv2/request_count' | align rate(1m) | every 1m | group_by [metric.method], [value_request_count_aggregate: aggregate(value.request_count)]

Numero di richieste target

Caso d'uso: utilizza targetv2/request_count per monitorare il numero di richieste del target di runtime Apigee. Il grafico targetv2/request_count mostra la frequenza delle richieste ricevute dal target Apigee. Questo grafico può essere utile per vedere quale target riceve un tasso di richieste più elevato, pattern di frequenza e qualsiasi picco anomalo nelle chiamate di richiesta per un particolare target.

Tipi di risorse	TargetV2
Metrica	targetv2/request_count
Raggruppa per	method e tutte le etichette dei tipi di risorsa TargetV2
Aggregatore	sum
Considerazione degli avvisi	Eventi come gli avvisi relativi a picchi/cali anomali di request_count
Soglia di avviso	Nessuna
Query MQL della dashboard di Cloud Monitoring: fetch apigee.googleapis.com/TargetV2 | metric 'apigee.googleapis.com/targetv2/request_count' | align rate(1m) | every 1m | group_by [metric.method, metric.type, metric.endpoint], [value_request_count_aggregate: aggregate(value.request_count)]

Tasso di errori

Conteggio delle risposte di errore del proxy

Caso d'uso: utilizza proxyv2/response_count per monitorare la risposta di errore del proxy di conversione. Il grafico proxyv2/response_count mostra la frequenza di richiesta per il proxy API. Questo grafico è utile per capire quale proxy riceve un tasso di errore delle richieste più elevato o qualsiasi errore anomalo di richieste per un proxy specifico.

Tipi di risorse	ProxyV2
Metrica	proxyv2/response_count
Filtra per	response_code != 200 Utilizza una regex per escludere tutti i codici response_code 2xx e 3xx, ad esempio: "response_code !=~ 1.*| 2.*|3.*"
Raggruppa per	method, response_code, fault_code, fault_source, apigee_fault, e tutte le etichette dei tipi di risorse ProxyV2
Aggregatore	sum
Considerazione degli avvisi	Il rapporto di errori di risposta del proxy: Errori di risposta totali/Numero di risposte totali. Totale errori di risposta = somma di proxyv2/response_count con codice response_code del filtro != 200 Numero di risposte totali = somma di proxyv2/response_count
Soglia di avviso	Dipende dallo SLO per l'installazione. Le installazioni di produzione e non di produzione possono avere soglie diverse. Ad esempio: per la produzione, attiva una notifica di evento se il rapporto di errori 500 della risposta del proxy è pari al 5% per 5 minuti.
Query MQL della dashboard di Cloud Monitoring: fetch apigee.googleapis.com/ProxyV2 | metric 'apigee.googleapis.com/proxyv2/response_count' | filter (metric.response_code != '200') | align rate(1m) | every 1m | group_by [metric.method, metric.response_code, metric.fault_code, metric.fault_source, metric.apigee_fault], [value_response_count_aggregate: aggregate(value.response_count)]
Esempio di criterio di avviso relativo alle operazioni di Google Cloud MQL: fetch apigee.googleapis.com/ProxyV2::apigee.googleapis.com/proxyv2/response_count | { filter (metric.response_code == '500') ; ident } | group_by drop[metric.response_code ], sliding(5m), .sum | ratio | scale '%' | every (30s) | condition val() > 5'%'

Conteggio delle risposte di errore target

Caso d'uso: utilizza targetv2/response_count per monitorare il tasso di risposta dell'API Target per errori. Il grafico targetv2/response_count mostra il tasso di richieste dal target API. Questo grafico può essere utile per identificare il target che riceve un tasso di richieste più elevato o eventuali picchi di errori anormali nelle chiamate di richiesta.

Tipi di risorse	TargetV2
Metrica	targetv2/response_count
Filtra per	response_code != 200 Utilizza una regex per escludere tutti i codici response_code 2xx e 3xx, ad esempio: "response_code !=~ 1.*| 2.*|3.*"
Raggruppa per	method e tutte le etichette dei tipi di risorsa TargetV2
Aggregatore	sum
Considerazione dell'avviso	Il rapporto di errori di risposta proxy, ad esempio: Totale errori di risposta / Conteggio totale risposte. Totale errori di risposta = Somma di targetv2/response_count con il filtro response_code != 200 Conteggio totale delle risposte = Somma di targetv2/response_count
Soglia di avviso	Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva un evento. Notifica, Se il tasso di errore di risposta target è del 5% per 3 minuti.
Query MQL della dashboard di Cloud Monitoring: fetch apigee.googleapis.com/TargetV2 | metric 'apigee.googleapis.com/targetv2/response_count' | filter (metric.response_code != '200') | align rate(1m) | every 1m | group_by [metric.method, metric.type, metric.endpoint, metric.response_code], [value_response_count_aggregate: aggregate(value.response_count)]

Latenze

Percentile latenze del proxy

Caso d'uso: utilizza proxyv2/latencies_percentile per monitorare il percentile di latenza (p50, p90, p95 e p99) di tutte le risposte del proxy API a una richiesta. La Il grafico proxyv2/latencies_percentile può essere utile per identificare la latenza nel proxy API Apigee per la latenza complessiva delle richieste di proxy API.

Tipi di risorse	ProxyV2
Metrica	proxyv2/latencies_percentile
Filtra per	percentile = p99
Raggruppa per	method, percentile e tutti i valori ProxyV2 etichette dei tipi di risorse
Aggregatore	p99 (99° percentile)
Considerazione dell'avviso	Valore elevato di p99 latencies_percentile.
Soglia di avviso	Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento se il valore di latencies_percentile del proxy p99 è 5 secondi per 5 minuti.
Query MQL della dashboard di Cloud Monitoring: fetch apigee.googleapis.com/ProxyV2 | metric 'apigee.googleapis.com/proxyv2/latencies_percentile' | filter (metric.percentile == 'p99') | group_by 1m, [value_latencies_percentile_mean: mean(value.latencies_percentile)] | every 1m | group_by [metric.method, metric.percentile], [value_latencies_percentile_mean_percentile: percentile(value_latencies_percentile_mean, 99)]

Percentile delle latenze target

Caso d'uso: utilizza targetv2/latencies_percentile per monitorare il percentile di latenza (p50, p90, p95 e p99) di tutte le risposte del target del proxy API a una richiesta. Il grafico targetv2/latencies_percentile identifica il tempo totale necessario al target proxy API Apigee per rispondere a una richiesta. Questo valore non include l'overhead del proxy API Apigee.

Tipi di risorse	TargetV2
Metrica	targetv2/latencies_percentile
Filtra per	percentile = p99
Raggruppa per	method, percentile e tutti i valori TargetV2 etichette dei tipi di risorse
Aggregatore	p99 (99° percentile)
Considerazione dell'avviso	Valore elevato di p99 latencies_percentile.
Soglia di avviso	Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento se il valore di latencies_percentile target p99 è 5 secondi per 5 minuti.
Query MQL della dashboard di Cloud Monitoring: fetch apigee.googleapis.com/ProxyV2 | metric 'apigee.googleapis.com/proxyv2/latencies_percentile' | filter (metric.percentile == 'p99') | group_by 1m, [value_latencies_percentile_mean: mean(value.latencies_percentile)] | every 1m | group_by [metric.method, metric.percentile], [value_latencies_percentile_mean_percentile: percentile(value_latencies_percentile_mean, 99)]

Percentile delle latenze dei criteri

Caso d'uso: utilizza policyv2/latencies_percentile per monitorare la latenza di elaborazione percentile (p50, p90, p95 e p99) di tutti i criteri Apigee. La Il grafico policyv2/latencies_percentile può essere utile per identificare la latenza nell'API Apigee per la latenza complessiva delle richieste proxy API.

Tipi di risorse	ProxyV2
Metrica	proxyv2/latencies_percentile
Filtra per	percentile = p99
Raggruppa per	method, percentile e tutte le etichette dei tipi di risorsa ProxyV2
Aggregatore	p99 (99° percentile)
Considerazione dell'avviso	Valore elevato di p99 latencies_percentile.
Soglia di avviso	Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento se il valore di latencies_percentile del proxy p99 è 5 secondi per 5 minuti.
Query MQL della dashboard di Cloud Monitoring: fetch apigee.googleapis.com/ProxyV2 | metric 'apigee.googleapis.com/policyv2/latencies_percentile' | filter (metric.percentile == 'p99') | group_by 1m, [value_latencies_percentile_mean: mean(value.latencies_percentile)] | every 1m | group_by [metric.policy_name, metric.percentile], [value_latencies_percentile_mean_aggregate: aggregate(value_latencies_percentile_mean)]

Database

Cassandra

Il servizio di database Cassandra di Apigee dispone di più metriche SLI di Cassandra. Queste metriche SLI possono fornire un monitoraggio completo del servizio Apigee Cassandra. Come minimo, oltre all'utilizzo delle risorse Cassandra (volume di CPU, Mem e disco), le attività di lettura e scrittura per monitorare l'integrità del servizio Cassandra.

Tasso di richieste di lettura Cassandra

Caso d'uso: la metrica SLI cassandra/clientrequest_rate (con ambito=Lettura) fornisce informazioni sulla frequenza media delle richieste di lettura dei servizi Cassandra in un determinato momento. Questa metrica consente di comprendere le tendenze del livello di attività delle richieste di lettura dei clienti.

Tipi di risorse	k8s_container
Metrica	cassandra/clientrequest_rate
Filtra per	scope = Read e unit = OneMinuteRate
Raggruppa per	scope, unit e tutte le etichette dei tipi di risorsa k8s_container
Aggregatore	sum
Considerazione dell'avviso	Per eventuali problemi o modifiche significative ai pattern di query dei clienti; ad esempio un picco o un calo improvviso e imprevisto nella tasso di richieste di lettura.
Soglia di avviso	Nessuno
Query MQL della dashboard di Cloud Monitoring: fetch k8s_container | metric 'apigee.googleapis.com/cassandra/clientrequest_latency' | filter (metric.scope == 'Read' && metric.unit == 'OneMinuteRate') | group_by 1m, [value_clientrequest_latency_mean: mean(value.clientrequest_latency)] | every 1m | group_by [metric.scope, metric.unit], [value_clientrequest_latency_mean_aggregate: aggregate(value_clientrequest_latency_mean)]

Frequenza delle richieste di scrittura di Cassandra

Caso d'uso: la metrica SLI cassandra/clientrequest_rate (con ambito=Write) fornisce informazioni sulla frequenza media delle richieste di scrittura dei servizi Cassandra in un determinato momento. Questa metrica consente di comprendere le tendenze a livello di attività delle richieste di scrittura dei clienti.

Tipi di risorse	k8s_container
Metrica	cassandra/clientrequest_rate
Filtra per	scope = Read e unit = OneMinuteRate
Raggruppa per	scope, unit e tutte le etichette dei tipi di risorsa k8s_container
Aggregatore	sum
Considerazione dell'avviso	Per eventuali problemi o cambiamenti significativi nei pattern di query dei clienti, ad esempio un picco o un calo improvviso e imprevisto delle richieste di scrittura che richiedono ulteriori accertamenti.
Soglia di avviso	Nessuna
Query MQL della dashboard di Cloud Monitoring: fetch k8s_container | metric 'apigee.googleapis.com/cassandra/clientrequest_latency' | filter (metric.scope == 'Write' && metric.unit == 'OneMinuteRate') | group_by 1m, [value_clientrequest_latency_mean: mean(value.clientrequest_latency)] | every 1m | group_by [metric.scope, metric.unit], [value_clientrequest_latency_mean_aggregate: aggregate(value_clientrequest_latency_mean)]

Latenza delle richieste di lettura di Cassandra

Caso d'uso: la metrica SLI cassandra/clientrequest_latency (con ambito = Lettura) fornisce la latenza delle richieste di lettura dei servizi Cassandra (al 99° percentile, al 95° percentile o al 75° percentile). Queste metriche consentono di avere una visione complessiva del rendimento di Cassandra e possono indicare eventuali cambiamenti nei pattern di utilizzo o un problema che si manifesta nel tempo.

Tipi di risorse	k8s_container
Metrica	cassandra/clientrequest_latency
Filtra per	scope = Read e unit = 99thPercentile
Raggruppa per	scope, unit e tutti i valori k8s_container etichette dei tipi di risorse
Aggregatore	sum
Considerazione dell'avviso	Se l'SLI della latenza delle richieste di lettura mostra costantemente una tendenza verso l'aumento della latenza al 99° percentile.
Soglia di avviso	Dipende dallo SLO per i servizi Cassandra. Ad esempio: in produzione, attiva una notifica di evento. se il valore di lettura clientrequest_latency di 99thPercentile è di 5 secondi per 3 minuti
Query MQL della dashboard di Cloud Monitoring: fetch k8s_container | metric 'apigee.googleapis.com/cassandra/clientrequest_latency' | filter (metric.scope == 'Read' && metric.unit == '99thPercentile') | group_by 1m, [value_clientrequest_latency_mean: mean(value.clientrequest_latency)] | every 1m | group_by [metric.scope, metric.unit], [value_clientrequest_latency_mean_aggregate: aggregate(value_clientrequest_latency_mean)]

Latenza delle richieste di scrittura di Cassandra

Caso d'uso: la metrica SLI cassandra/clientrequest_latency (con scope=Write) fornisce la latenza delle richieste di scrittura dei servizi Cassandra (al 99° percentile, 95° percentile o 75° ). Queste metriche consentono di avere una visione complessiva del rendimento di Cassandra e possono indicare eventuali cambiamenti nei pattern di utilizzo o un problema che si manifesta nel tempo.

Tipi di risorse	k8s_container
Metrica	cassandra/clientrequest_latency
Filtra per	scope = Write e unit = 99thPercentile
Raggruppa per	scope, unit e tutte le etichette dei tipi di risorsa k8s_container
Aggregatore	sum
Considerazione dell'avviso	Se lo SLI di latenza delle richieste di scrittura mostra in modo coerente una latenza del 99° percentile, con una tendenza continua verso l'alto.
Soglia di avviso	Dipende dallo SLO per i servizi Cassandra. Ad esempio: in produzione, attiva una notifica evento se il valore clientrequest_latency di 99thPercentile è 5 secondi per 3 minuti
Query MQL della dashboard di Cloud Monitoring: fetch k8s_container | metric 'apigee.googleapis.com/cassandra/clientrequest_latency' | filter (metric.scope == 'Write' && metric.unit == '99thPercentile') | group_by 1m, [value_clientrequest_latency_mean: mean(value.clientrequest_latency)] | every 1m | group_by [metric.scope, metric.unit], [value_clientrequest_latency_mean_aggregate: aggregate(value_clientrequest_latency_mean)]

Piano di controllo Apigee

Le metriche dello SLI del servizio Apigee Sincronizzar forniscono conteggi e latenze di richieste e risposte tra il piano di controllo Apigee e il piano di runtime ibrido. Le istanze di sincronizzazione in esecuzione nel piano di runtime devono eseguire regolarmente il polling del piano di controllo, scaricare i contratti e metterli a disposizione delle istanze di runtime locali.

Tasso di richieste

Numero di richieste in upstream

Caso d'uso: le metriche upstream/request_count indicano il numero di richieste effettuate dal servizio Synchronizer al piano di controllo Apigee.

Tipi di risorse	k8s_container
Metrica	upstream/request_count
Filtra per	container_name = apigee-synchronizer e type = CONTRACT
Raggruppa per	method, type, container_name e tutte le etichette del tipo di risorsa k8s_container
Aggregatore	sum
Considerazione dell'avviso	Utilizza questa metrica per le anomalie del traffico, ad esempio un picco o un avviso di calo anomalo di request_count.
Soglia di avviso	Nessuna
Query MQL della dashboard di Cloud Monitoring: fetch k8s_container | metric 'apigee.googleapis.com/upstream/request_count' | filter (resource.container_name == 'apigee-synchronizer') && (metric.type == 'CONTRACT') | align rate(1m) | every 1m | group_by [metric.method, metric.type, resource.container_name], [value_request_count_aggregate: aggregate(value.request_count)]

Percentuale di errori

Conteggio delle risposte upstream

Caso d'uso: la metrica SLI upstream/response_count fornisce il numero di risposte ricevute dai servizi di sincronizzazione dal piano di controllo Apigee. Questo diagramma può essere utile per identificare eventuali problemi di connettività o configurazione tra il piano di runtime di Apigee Hybrid e il piano di controllo.

Tipi di risorse	k8s_container
Metrica	upstream/request_count
Filtra per	method, response_type, container_name e tutti Tipo di risorsa k8s_container etichette
Raggruppa per
Aggregatore	sum
Considerazione degli avvisi	Se sono presenti errori nelle metriche upstream/response_count con codici di risposta diversi da 200 restituiti dal piano di controllo Apigee, è necessario effettuare ulteriori accertamenti su questi errori.
Soglia di avviso	Dipende dallo SLO per i servizi Cassandra. Ad esempio, in produzione, attiva una notifica di evento se Synchronizer riscontra più di un errore response_code ogni tre minuti.
Query MQL della dashboard di Cloud Monitoring: fetch k8s_container | metric 'apigee.googleapis.com/upstream/response_count' | filter (resource.container_name == 'apigee-synchronizer') && (metric.response_code != '200' && metric.type == 'CONTRACT') | align rate(1m) | every 1m | group_by [metric.method, metric.response_code, metric.type, resource.container_name], [value_response_count_aggregate: aggregate(value.response_count)]

Infrastruttura

GKE e altre piattaforme Kubernetes forniscono metriche SLI a livello di sistema. Le etichette delle metriche SLI possono essere filtrate e raggruppate per monitorare un contenitore specifico e il relativo utilizzo delle risorse. per monitorare il cluster di runtime Apigee integrità e disponibilità dell'infrastruttura, un amministratore del cluster può monitorare container e pod comuni dell'uso delle risorse, ad esempio numero di riavvii di CPU, Mem, disco e container. Per ulteriori dettagli sulle metriche e sulle etichette disponibili, consulta la documentazione di GKE.

La tabella seguente elenca alcuni dei servizi e dei contenitori che puoi monitorare per ciascun servizio.

Nome servizio	Nome contenitore
Cassandra	apigee-cassandra
Processore di messaggi (MP)	apigee-runtime
Synchronizer	apigee-synchronizer
Telemetria	apigee-prometheus-app apigee-prometheus-proxy apigee-prometheus-agg apigee-stackdriver-exporter

Container / pod

Conteggio riavvii

Caso d'uso: la metrica SLI di sistema kubernetes.io/container/restart_count fornisce il numero di volte in cui un container è stato riavviato. Questo grafico può essere utile per identificare se un contenitore si arresta in modo anomalo/si riavvia di frequente. Il container di servizio specifico può essere filtrato in base alle metriche per il monitoraggio dei container di un servizio specifico.

Di seguito viene mostrato come utilizzare la metrica kubernetes.io/container/restart_count per Container Cassandra. Puoi utilizzare questa metrica per qualsiasi contenitore della tabella precedente.

Tipi di risorse	k8s_container
Metrica	kubernetes.io/container/restart_count
Filtra per	namespace_name = apigee e container_name =~ .*cassandra.*
Raggruppa per	cluster_name, namespace_name, pod_name, container_name e tutti Tipo di risorsa k8s_container etichette
Aggregatore	sum
Considerazione dell'avviso	Se un contenitore si riavvia di frequente, è necessario effettuare ulteriori accertamenti per individuare la causa principale. Esistono diversi motivi per cui un contenitore può riavviarsi, ad esempio OOMKilled, disco dati pieno e problemi di configurazione, per citarne alcuni.
Soglia di avviso	Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento se un contenitore si riavvia più di 5 volte entro 30 minuti.
Query MQL della dashboard di Cloud Monitoring: fetch k8s_container | metric 'kubernetes.io/container/restart_count' | filter (resource.container_name =~ '.*cassandra.*' && resource.namespace_name == 'apigee') | align rate(1m) | every 1m | group_by [resource.cluster_name, resource.namespace_name, resource.pod_name, resource.container_name], [value_restart_count_aggregate: aggregate(value.restart_count)]