Linee guida per il monitoraggio del cluster

Panoramica

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

Se non hai familiarità con il monitoraggio di Google Cloud, consulta la documentazione di Google Cloud Monitoring per: Creare grafici con Metrics Explorer e Come funzionano gli avvisi.

I cluster Apigee Hybrid forniscono metriche SLI (Service Level Indicator) per aiutarti a capire le prestazioni dei servizi di applicazioni e di sistema in un determinato 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 target API Apigee

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

Soglia di avviso: in un mondo perfetto, le soglie di avviso sarebbero ovvie e la documentazione fornita elenco dei valori che dovrebbero attivare gli avvisi. In realtà, per Apigee è meno ovvio definire quali sono le prestazioni accettabili e qual è l'utilizzo pericoloso delle risorse di servizi e infrastrutture. I valori soglia degli avvisi variano notevolmente a seconda dei particolari pattern di traffico e degli accordi SLO/SLA.

L'ottimizzazione e la determinazione di una soglia di avviso sono un processo continuo, in quanto possono variare in base all'utilizzo del servizio e dell'infrastruttura. Utilizza le soglie di avviso e critiche per le notifiche e gli avvisi.

  • Sano: il valore è inferiore alla soglia di avviso.
  • Preoccupante: valore superiore alla soglia di avviso, ma inferiore alla soglia critica.
  • Critico: valore > soglia critica.

I clienti devono utilizzare gli strumenti forniti per determinare la soglia ottimale, che si tratti delle dashboard di Cloud Monitoring che i clienti possono creare con MQL fornito di seguito o delle analisi di Apigee, per identificare l'aspetto della "normalità" e poi regolare di conseguenza le soglie degli avvisi.

Il monitoraggio dei cluster ibridi può essere suddiviso in quattro diversi gruppi generali, ad esempio traffico, database, piano di controllo Apigee e infrastruttura monitoraggio. Le sezioni seguenti descrivono questi gruppi nel dettaglio:

Traffico

Le metriche SLI di proxy e target Apigee forniscono conteggi di richieste/risposte e latenze per proxy e target API. La metrica SLI Latenza policy Apigee fornisce le latenze di risposta delle policy. Queste metriche SLI forniscono copertura per il monitoraggio del traffico API Apigee.

Tasso di richieste

Numero di 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 riceve una tasso di richieste più elevata, i pattern tasso di richieste e qualsiasi picco anomalo nelle chiamate di richiesta per un determinato proxy. Qualsiasi picco anomalo imprevisto nel traffico API potrebbe essere un problema di sicurezza relativo a un bot o a un attacco ai proxy API. Analogamente, un calo significativo del traffico complessivo potrebbe indicare problemi con i client o la connettività dei componenti upstream di Apigee.

Tipi di risorse ProxyV2
Metrica proxyv2/request_count
Raggruppa per method e tutte le etichette del tipo 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 conteggio delle richieste di destinazione di Apigee Runtime. Il grafico targetv2/request_count mostra la tasso di richieste ricevute dal target Apigee. Questo grafico può essere utile per vedere quale target riceve una tasso di richieste più elevata, il pattern della frequenza di richieste e qualsiasi picco anomalo nelle chiamate di richieste per un determinato target.

Tipi di risorse TargetV2
Metrica targetv2/request_count
Raggruppa per method e tutte le etichette del tipo 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 il tasso di risposta di errore del proxy. Il grafico proxyv2/response_count mostra la tasso di richieste per il proxy API. Questo grafico è utile per capire quale proxy sta ottenendo un tasso di errori di richiesta più elevato o qualsiasi picco di errori anomalo nelle chiamate di richiesta 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 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 tra errori di risposta del proxy: errori di risposta totali / numero totale di risposte.
  • Errori totali di risposta = Somma di proxyv2/response_count con filtro response_code != 200
  • Numero totale di risposte = Somma di proxyv2/response_count
Soglia di avviso Dipende dallo SLO per l'installazione. Le installazioni di produzione e non di produzione potrebbero avere soglie diverse. Ad esempio: per la produzione, attiva una notifica di evento se il rapporto di errori 500 di risposta del 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 per il criterio di avviso dell'operazione 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 di errore del target

Caso d'uso: utilizza targetv2/response_count per monitorare il tasso di risposta di errore di API Target. Il grafico targetv2/response_count mostra la tasso di richieste dall'API Target. Questo grafico può essere utile per identificare il target che riceve una tasso di richieste più elevata o eventuali picchi anomali di errori nelle chiamate di richiesta.

Tipi di risorse TargetV2
Metrica targetv2/response_count
Filtra per response_code != 200

Utilizza un'espressione regolare per escludere tutti i response_code 2xx e 3xx, ad esempio:

"response_code !=~ 1.*| 2.*|3.*"
Raggruppa per method e tutte le etichette del tipo di risorsa TargetV2
Aggregatore sum
Considerazione degli avvisi Il rapporto tra errori di risposta del proxy, ad esempio: Errori di risposta totali / Numero totale di risposte.
  • Errori totali di risposta = Somma di targetv2/response_count con filtro response_code != 200
  • Numero totale di risposte = Somma di targetv2/response_count
Soglia di avviso Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento se il rapporto di errori 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 delle 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. Il grafico proxyv2/latencies_percentile può essere utile per identificare la latenza nel proxy API Apigee rispetto alla latenza complessiva delle richieste del proxy API.

Tipi di risorse ProxyV2
Metrica proxyv2/latencies_percentile
Filtra per percentile = p99
Raggruppa per Metodo, percentile e tutte le etichette del tipo di risorsa ProxyV2
Aggregatore p99 (99° percentile)
Considerazione degli avvisi Valore elevato di latencies_percentile P99.
Soglia di avviso Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica evento se il valore di 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 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 di destinazione del proxy API a una richiesta. Il grafico targetv2/latencies_percentile identifica il tempo totale impiegato dal 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 metodo, percentile e tutte le etichette del tipo di risorsa TargetV2
Aggregatore p99 (99° percentile)
Considerazione degli avvisi Valore elevato di latencies_percentile P99.
Soglia di avviso Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica evento se il valore di target 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 delle latenze dei criteri

Caso d'uso: utilizza il monitor 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 API Apigee rispetto alla latenza complessiva delle richieste del proxy API del cliente.

Tipi di risorse ProxyV2
Metrica proxyv2/latencies_percentile
Filtra per percentile = p99
Raggruppa per Metodo, percentile e tutte le etichette del tipo di risorsa ProxyV2
Aggregatore p99 (99° percentile)
Considerazione degli avvisi Valore elevato di latencies_percentile P99.
Soglia di avviso Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica evento se il valore di 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 ha più metriche SLI di Cassandra. Queste metriche SLI possono fornire un monitoraggio completo per il servizio Apigee Cassandra. Come minimo, insieme all'utilizzo delle risorse Cassandra (CPU, memoria e volume del disco), la latenza delle richieste di lettura e scrittura del client deve essere monitorata per lo stato del servizio Cassandra.

Tasso di richieste di lettura di Cassandra

Caso d'uso: la metrica SLI cassandra/clientrequest_rate (con scope=Read) fornisce informazioni sulla velocità media delle richieste di lettura dei servizi Cassandra in un determinato momento. Questa metrica aiuta a 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 del tipo di risorsa k8s_container
Aggregatore sum
Considerazione degli avvisi Per eventuali problemi o variazioni significative nei pattern di query dei client, ad esempio un picco o un calo improvviso e inatteso della 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)]

Tasso di richieste di scrittura di Cassandra

Caso d'uso: la metrica SLI cassandra/clientrequest_rate (con scope=Write) fornisce informazioni sulla velocità media delle richieste di scrittura dei servizi Cassandra in un determinato momento. Questa metrica aiuta a comprendere le tendenze del 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 del tipo di risorsa k8s_container
Aggregatore sum
Considerazione degli avvisi Per eventuali problemi o cambiamenti significativi nei pattern di query dei client, ad esempio un picco o un calo improvviso e inatteso 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 delle richieste di lettura di Cassandra

Caso d'uso: la metrica SLI cassandra/clientrequest_latency (con scope=Read) fornisce la latenza delle richieste di lettura dei servizi Cassandra (al 99°, 95° o 75° percentile). Queste metriche aiutano a fornire una visione generale 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 del tipo di risorsa k8s_container
Aggregatore sum
Considerazione degli avvisi Se l'indicatore SLI della latenza delle richieste di lettura mostra costantemente una tendenza al rialzo della latenza al 99° percentile.
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 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°, 95° o 75° percentile). Queste metriche aiutano a fornire una visione generale delle prestazioni di Cassandra e possono indicare eventuali cambiamenti nei modelli 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 del tipo di risorsa k8s_container
Aggregatore sum
Considerazione degli avvisi Se l'indicatore SLI di latenza delle richieste di scrittura mostra costantemente una tendenza al rialzo della latenza al 99° percentile.
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)]

Control plane Apigee

Le metriche SLI del servizio Apigee Synchronizer forniscono conteggi e latenze di richieste e risposte tra il piano di controllo Apigee e il piano di runtime ibrido. Le istanze del sincronizzatore in esecuzione nel piano di runtime devono eseguire il polling del piano di controllo regolarmente, scaricare i contratti e renderli disponibili 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 del tipo di risorsa k8s_container
Aggregatore sum
Considerazione degli avvisi Utilizza questa opzione per anomalie del traffico, ad esempio un picco anomalo di request_count o un avviso di calo.
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 ricevute dai servizi di sincronizzazione dal piano di controllo Apigee. Questo grafico può essere utile per identificare eventuali problemi di connettività o configurazione tra il piano di runtime Apigee Hybrid e il piano di controllo.

Tipi di risorse k8s_container
Metrica upstream/request_count
Filtra per method, response_type, container_name e tutte le etichette del tipo di risorsa k8s_container
Raggruppa per
Aggregatore sum
Considerazione degli avvisi Se si verificano errori nelle metriche upstream/response_count con codici di risposta diversi da 200 restituiti dal control plane Apigee, è necessario approfondire questi errori.
Soglia di avviso Dipende dal tuo SLO per i servizi Cassandra. Ad esempio: in produzione, attiva una notifica di evento se Synchronizer rileva 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 delle risorse comuni di container e pod, ad esempio CPU, memoria, disco e conteggi dei riavvii dei container. Per ulteriori dettagli sulle metriche e sulle etichette disponibili, consulta la documentazione di GKE.

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

Nome servizio Nome contenitore
Cassandra apigee-cassandra
Message Processor(MP) apigee-runtime
Synchronizer apigee-synchronizer
Telemetry 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 riavvii di un container. Questo grafico può essere utile per identificare se un container si arresta in modo anomalo/si riavvia di frequente. Il contenitore di servizio specifico può essere filtrato in base alle etichette delle metriche per il monitoraggio del contenitore di un servizio specifico.

Di seguito viene mostrato l'utilizzo della metrica kubernetes.io/container/restart_count per il container Cassandra. Puoi utilizzare questa metrica per qualsiasi contenitore 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 del tipo di risorsa k8s_container
Aggregatore sum
Considerazione degli avvisi Se un contenitore viene riavviato di frequente, è necessario approfondire la causa principale. Un container può riavviarsi per diversi motivi, ad esempio OOMKilled, disco di 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 viene riavviato più di 5 volte in 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)]