- v1.12 (più recente)
- Versione 1.11
- Versione 1.10
- Elenco delle versioni supportate
- Versione 1.9
- Versione 1.8
- Versione 1.7
- Versione 1.6
- Versione 1.5
- Versione 1.4
- Versione 1.3
- Versione 1.2
- Versione 1.1
Versioni supportate:
Versioni non supportate:
Panoramica
Questa guida fornisce linee guida su cosa monitorare e come monitorare un deployment ibrido Apigee. È destinata agli amministratori di cluster ibridi e degli amministratori dell'organizzazione.
Se non hai mai utilizzato Google Cloud Monitoring, consulta la documentazione di Google Cloud Monitoring relativa a: Creare grafici con Metrics Explorer e Come funzionano gli avvisi.
I cluster ibridi di Apigee forniscono metriche SLI (indicatore del livello del servizio) per aiutarti a comprendere le prestazioni dei servizi di applicazioni e sistema in un determinato momento. Puoi visualizzare un elenco completo delle metriche disponibili.
Google Cloud Monitoring utilizza Tipo di risorsa per identificare ogni metrica SLI. Esistono tre tipi di risorse comuni utilizzati per tutte le metriche ibride di Apigee.
k8s_container
per le metriche a livello di sistema.ProxyV2
per le metriche del proxy API Apigee.TargetV2
per le metriche target 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
disponibili, oltre
alle etichette delle metriche. È consigliabile utilizzare una combinazione di etichette del tipo di risorsa ed etichette delle metriche 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 elencherebbe i valori che dovrebbero attivare gli avvisi. In realtà, per Apigee non è facile definire quali siano prestazioni accettabili e cosa sia un utilizzo pericoloso di risorse di servizi e infrastrutture. I valori delle soglie di avviso variano notevolmente a seconda di determinati pattern di traffico e accordi SLO/SLA.
L'ottimizzazione e la determinazione di una soglia di avviso sono un processo continuo in quanto può variare con l'utilizzo del servizio e dell'infrastruttura. Utilizza la soglia Avviso e Critica per notifiche e avvisi.
- Integro: il valore è inferiore alla soglia di avviso.
- Problema: valore superiore alla soglia di avviso, ma inferiore alla soglia critica.
- Critica: Valore > Soglia critica.
I clienti dovrebbero utilizzare gli strumenti forniti per determinare la soglia ottimale, che si tratti delle dashboard di Cloud Monitoring che i clienti possono creare con l'MQL fornito di seguito o dell'analisi di Apigee, per identificare il comportamento "normale" e quindi ottimizzare le soglie di avviso di conseguenza.
Il monitoraggio del cluster ibrido può essere classificato in quattro diversi gruppi generali, ad esempio Traffico, Database, piano di controllo Apigee e monitoraggio dell'infrastruttura. Le sezioni seguenti descrivono dettagliatamente questi gruppi:
Traffico
Le metriche Apigee e SLI di destinazione forniscono i conteggi di richieste/risposta e latenze per proxy e destinazioni API. La metrica SLI di latenza dei criteri Apigee fornisce latenze di risposta dei criteri. Queste metriche SLI forniscono la copertura per il monitoraggio del traffico dell'API Apigee.
Tasso di richieste
Conteggio richieste proxy
Caso d'uso: utilizza proxyv2/request_count per monitorare il conteggio delle richieste proxy. Il grafico proxyv2/request_count mostra la tasso di richieste per i proxy. Questo grafico è utile per identificare quale proxy sta ricevendo un tasso di richieste più elevato, i pattern di frequenza delle richieste e eventuali picchi anomali nelle chiamate alle richieste per un determinato proxy. Eventuali picchi anomali imprevisti nel traffico delle API potrebbero rappresentare un problema di sicurezza per un bot o un attacco ai proxy API. Allo stesso modo, un calo significativo del cloud di traffico complessivo indica problemi con i client o con la connettività dai componenti upstream di Apigee.
Tipi di risorse | ProxyV2 |
Metrica | proxyv2/request_count |
Raggruppa per | method e tutte le etichette dei tipi di risorsa ProxyV2 |
Aggregatore | sum |
Considerazione dell'avviso | Eventi come avvisi request_count di picco/calo anomali |
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)] |
Conteggio richieste target
Caso d'uso: utilizza targetv2/request_count per monitorare il numero di richieste di destinazione del runtime Apigee. Il grafico targetv2/request_count mostra il tasso di richieste ricevute dal target Apigee. Questo grafico può essere utile per vedere quale target riceve un tasso di richieste più elevato, un pattern di frequenza delle richieste e eventuali picchi anomali nelle chiamate alle richieste per un determinato target.
Tipi di risorse | TargetV2 |
Metrica | targetv2/request_count |
Raggruppa per | method e tutte le etichette dei tipi di risorse TargetV2 |
Aggregatore | sum |
Considerazione dell'avviso | Eventi come avvisi request_count di picco/calo anomali |
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 percentuale di risposte di errori del proxy. Il grafico proxyv2/response_count mostra il tasso di richieste per il proxy API. Questo grafico è utile per capire quale proxy sta registrando una percentuale di errori nelle richieste più elevata o un picco di errori anomali nelle chiamate delle richieste per un determinato proxy.
Tipi di risorse | ProxyV2 |
Metrica | proxyv2/response_count |
Filtra per | response_code != 200
Utilizza un'espressione regolare per escludere tutti i valori "response_code !=~ 1.*| 2.*|3.*" |
Raggruppa per | method, response_code , fault_code ,
fault_source , apigee_fault
e tutte le etichette dei tipi di risorsa
ProxyV2 |
Aggregatore | sum |
Considerazione dell'avviso | Il rapporto di errori delle risposte del proxy: Totale errori di risposta / Numero totale di risposte.
|
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 errore 500 della risposta proxy è del 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 MQL del criterio di avviso relativo alle operazioni di Google Cloud:
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 con errori target
Caso d'uso: utilizza targetv2/response_count per monitorare il tasso di risposta di errore del target API. Il grafico targetv2/response_count mostra la tasso di richieste dal target API. Questo grafico può essere utile per identificare la destinazione che riceve un tasso di richieste più elevato o eventuali picchi di errori anomali nelle chiamate alle richieste.
Tipi di risorse | TargetV2 |
Metrica | targetv2/response_count |
Filtra per | response_code != 200
Utilizza un'espressione regolare per escludere tutti i valori "response_code !=~ 1.*| 2.*|3.*" |
Raggruppa per | method e tutte le etichette dei tipi di risorse TargetV2 |
Aggregatore | sum |
Considerazione dell'avviso | Il rapporto di errori delle risposte del proxy, ad esempio Errori totali di risposta / Conteggio totale delle risposte.
|
Soglia di avviso | Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di eventi se il rapporto 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 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. Il grafico proxyv2/latencies_percentile può essere utile per identificare la latenza nel proxy dell'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 risorse ProxyV2 |
Aggregatore | p99 (99° percentile) |
Considerazione dell'avviso | Valore elevato di latencies_percentile P99. |
Soglia di avviso | Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento, se il valore del proxy p99 latencies_percentile è 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 latenze target
Caso d'uso: utilizza targetv2/latencies_percentile per monitorare il percentile di latenza (p50, p90, p95 e p99) di tutte le risposte della destinazione proxy API a una richiesta. Il grafico targetv2/latencies_percentile identifica il tempo totale necessario al target del 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 tutte le etichette dei tipi di risorse TargetV2 |
Aggregatore | p99 (99° percentile) |
Considerazione dell'avviso | Valore elevato di latencies_percentile P99. |
Soglia di avviso | Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento, se il valore di p99 latencies_percentile è 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 latenze dei criteri
Caso d'uso: utilizza policyv2/latencies_percentile per monitorare il percentile di latenza di elaborazione (p50, p90, p95 e p99) di tutti i criteri Apigee. Il grafico policyv2/latencies_percentile può essere utile per identificare la latenza nei criteri dell'API Apigee per la latenza complessiva della richiesta proxy API del cliente.
Tipi di risorse | ProxyV2 |
Metrica | proxyv2/latencies_percentile |
Filtra per | percentile = p99 |
Raggruppa per | method, percentile e tutte le etichette dei tipi di risorse ProxyV2 |
Aggregatore | p99 (99° percentile) |
Considerazione dell'avviso | Valore elevato di latencies_percentile P99. |
Soglia di avviso | Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento, se il valore del proxy p99 latencies_percentile è 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 Apigee Cassandra dispone di più metriche SLI Cassandra. Queste metriche SLI possono fornire un monitoraggio completo per il servizio Apigee Cassandra. Come minimo, insieme all'utilizzo delle risorse Cassandra (CPU, Mem e volume del disco), la latenza della richiesta di lettura e scrittura del client deve essere monitorata per l'integrità del servizio Cassandra.
Percentuale di richieste di lettura per Cassandra
Caso d'uso: la metrica SLI cassandra/clientrequest_rate (con scope=Read) fornisce insight sulla percentuale media di richieste di lettura dei servizi Cassandra in un determinato momento. Questa metrica consente di comprendere le tendenze a livello di attività delle richieste di lettura dei client.
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 potenziali o cambiamenti significativi nei pattern di query dei client, ad esempio un picco o un calo improvviso e imprevisto della tasso di richieste di lettura. |
Soglia di avviso | Nessun valore |
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)] |
Tasso di richieste di scrittura Cassandra
Caso d'uso: la metrica SLI cassandra/clientrequest_rate (con scope=Write) fornisce insight sulla percentuale media di richieste di scrittura dei servizi Cassandra in un determinato momento. Questa metrica consente di comprendere le tendenze a livello di attività di scrittura 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 potenziali o cambiamenti significativi nei pattern di query dei client, ad esempio un picco o un calo improvviso e imprevisto delle richieste di scrittura che richiedono ulteriori indagini. |
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 della richiesta di lettura Cassandra
Caso d'uso: la metrica SLI cassandra/clientrequest_latency (con scope=Read) fornisce la latenza delle richieste di lettura dei servizi Casssandra (al 99° percentile, 95° percentile o 75° percentile). Queste metriche consentono di ottenere una visione complessiva delle prestazioni di Cassandra e possono indicare eventuali modifiche 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 tutte le etichette dei tipi di risorsa k8s_container |
Aggregatore | sum |
Considerazione dell'avviso | Se lo SLI di latenza delle richieste di lettura mostra in modo coerente la latenza del 99° percentile in costante aumento. |
Soglia di avviso | Dipende dal tuo SLO per i servizi Cassandra. Ad esempio: in produzione, attiva una notifica di evento se il valore clientrequest_latency di lettura del 99° percentile è 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 richiesta di scrittura 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° percentile). Queste metriche consentono di avere una visione complessiva delle prestazioni di Cassandra e possono indicare eventuali modifiche 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 costantemente una latenza del 99° percentile in costante aumento. |
Soglia di avviso | Dipende dal tuo SLO per i servizi Cassandra. Ad esempio: in produzione, attiva una notifica di evento se il valore di scrittura clientrequest_latency del 99° percentile è 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 == '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 SLI del servizio Apigee Sincronizzar forniscono i conteggi e le latenze delle richieste e delle risposte tra il piano di controllo Apigee e il piano di runtime ibrido. Le istanze del sincronizzatore in esecuzione sul piano di runtime devono eseguire il polling regolare del piano di controllo, scaricare i contratti e rendere lo stesso disponibile alle istanze di runtime locali.
Tasso di richieste
Conteggio richieste upstream
Caso d'uso: le metriche upstream/request_count indicano il numero di richieste effettuate dal servizio di sincronizzazione 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 dei tipi di risorse k8s_container |
Aggregatore | sum |
Considerazione dell'avviso | Utilizza questa opzione per le anomalie del traffico, ad esempio un avviso di picco o calo di request_count anomalo. |
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 risposte upstream
Caso d'uso: la metrica SLI upstream/response_count fornisce il numero di risposte che i servizi di sincronizzazione hanno ricevuto dal piano di controllo Apigee. Questo grafico può essere utile per identificare eventuali problemi di connettività o configurazione tra il piano di runtime ibrido e il piano di controllo di Apigee.
Tipi di risorse | k8s_container |
Metrica | upstream/request_count |
Filtra per | method, response_type, container_name e tutte le etichette dei tipi di risorse k8s_container |
Raggruppa per | |
Aggregatore | sum |
Considerazione dell'avviso | In caso di errori nelle metriche upstream/response_count con codici di risposta non 200 restituiti dal piano di controllo Apigee, sono state necessarie ulteriori indagini per tali errori. |
Soglia di avviso | Dipende dal tuo SLO per i servizi Cassandra. Ad esempio, in produzione, attiva una notifica di evento se il sincronizzatore 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 container specifico e il relativo utilizzo delle risorse. Per monitorare l'integrità e la disponibilità dell'infrastruttura del cluster Apigee Runtime, un amministratore del cluster può monitorare l'utilizzo comune delle risorse di container e pod, come il numero di riavvii di CPU, Mem, dischi e container. Segui la documentazione di GKE per ulteriori dettagli sulle metriche e sulle etichette disponibili.
Nella tabella seguente sono elencati alcuni dei servizi e dei container che puoi monitorare per ciascun servizio.
Nome servizio | Nome contenitore |
---|---|
Cassandra | apigee-cassandra |
Processore di messaggi(MP) | apigee-runtime |
Sincronizzatore | 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 container si arresta in modo anomalo/si riavvia frequentemente. Il container di servizi specifico può essere filtrato in base alle etichette delle metriche per il monitoraggio dei container di un servizio specifico.
Di seguito è riportato l'utilizzo della metrica kubernetes.io/container/restart_count per il container Cassandra. Puoi utilizzare questa metrica per qualsiasi container nella 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 tutte le etichette dei tipi di risorse k8s_container |
Aggregatore | sum |
Considerazione dell'avviso | Se un container si riavvia frequentemente, sono necessarie ulteriori indagini per la causa principale. Esistono diversi motivi per cui un container può riavviarsi, ad esempio OOMKilled ,
il 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 container si riavvia più spesso 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)] |