Panoramica
Questa guida fornisce linee guida su cosa monitorare e su come monitorare un deployment Apigee Hybrid. È destinato agli amministratori di cluster ibridi e agli amministratori dell'organizzazione.
Se non hai mai utilizzato Google Cloud Monitoring, consulta la documentazione di Google Cloud Monitoring per: Creare grafici con Esplora metriche e Come funziona gli avvisi.
I cluster ibridi Apigee forniscono metriche SLI (indicatore del livello del servizio) per aiutarti a comprendere le prestazioni di servizi di applicazioni e sistema 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 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. Per monitorare in modo efficace l'integrità e le prestazioni del cluster, occorre 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 elenca i valori che dovrebbero attivare gli avvisi. In realtà, è meno ovvio definire da Apigee: quali sono le prestazioni accettabili e quale sia l'utilizzo pericoloso di servizi e infrastrutture da parte di risorse. I valori delle soglie di avviso variano notevolmente a seconda di particolari pattern di traffico e accordi SLO/SLA.
L'ottimizzazione e la determinazione della soglia di avviso sono un processo in corso, in quanto può cambiare con il servizio e l'utilizzo dell'infrastruttura. Utilizza Avviso e Soglia critica per notifiche e avvisi.
- Stato integro: il valore è inferiore alla soglia di avviso.
- Precauzione: 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 possono creare con il valore MQL fornito di seguito o delle analisi di Apigee per identificare l'aspetto "normale" e regolare le soglie di avviso di conseguenza.
Il monitoraggio dei cluster ibridi può essere classificato in quattro diversi gruppi generali, ad esempio Traffico, Database, Piano di controllo Apigee e monitoraggio dell'infrastruttura. Nelle sezioni seguenti vengono descritti in dettaglio questi gruppi:
Traffico
Le metriche del proxy Apigee e SLI di destinazione forniscono conteggi e latenze di richieste/risposte per proxy API e target. La metrica SLI di latenza dei criteri di Apigee fornisce latenze di risposta ai criteri. Queste metriche SLI forniscono la copertura per il monitoraggio del traffico dell'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 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 eventuali picchi anomali nelle chiamate di richiesta per un determinato proxy. Qualsiasi picco anomalo imprevisto nel traffico delle API potrebbe rappresentare un rischio per la sicurezza di un bot o un attacco ai proxy API. Analogamente, un calo significativo del traffico complessivo relativo al cloud indica problemi con i client o con la connettività dei 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 anomali di tipo request_count picco/calo |
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 conteggio delle richieste di target di 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 sta ricevendo un tasso di richieste più alto, il pattern della percentuale di richieste ed eventuali picchi anomali 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 dell'avviso | Eventi come avvisi anomali di tipo request_count picco/calo |
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
Numero di risposte di errori del proxy
Caso d'uso: utilizza proxyv2/response_count per monitorare il tasso di risposta degli errori del proxy. Il grafico proxyv2/response_count mostra il tasso di richieste per il proxy API. Questo grafico è utile per capire quale proxy riceve un tasso di errori delle richieste più elevato o qualsiasi picco di errori anomali nelle chiamate di 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 "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 | Rapporto errori di risposta 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 la percentuale di errori della risposta del proxy 500 è 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 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 di errore del target dell'API. 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 anomali 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 !=~ 1.*| 2.*|3.*" |
Raggruppa per | method e tutte le etichette del tipo di risorsa TargetV2 |
Aggregatore | sum |
Considerazione dell'avviso | Il rapporto di errori di risposta proxy, ad esempio: Totale errori di risposta / Conteggio totale risposte.
|
Soglia di avviso | Dipende dallo SLO per l'installazione. Ad esempio, per la produzione, attiva una notifica di evento 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 del proxy
Caso d'uso: utilizza proxyv2/latencies_percentile per monitorare il percentile di latenza (p50, p90, p95 e p99) di tutte le risposte 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 di proxy API.
Tipi di risorse | ProxyV2 |
Metrica | proxyv2/latencies_percentile |
Filtra per | percentile = p99 |
Raggruppa per | method, percentile e tutte le etichette del tipo 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 proxy p99 latencies_percentile è di 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 di target del proxy API a una richiesta. Il grafico targetv2/latencies_percentile identifica la quantità di tempo totale che il target del proxy dell'API Apigee deve avere per rispondere a una richiesta. Questo valore non include l'overhead del proxy API Apigee.
Tipi di risorse | TargetV2 |
Metrica | targetv2/latenze_percentile |
Filtra per | percentile = p99 |
Raggruppa per | method, percentile e tutte le etichette del tipo di risorsa TargetV2 |
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 p99 latencies_percentile di destinazione è pari a 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 nel criterio dell'API Apigee rispetto alla latenza complessiva delle richieste proxy API del cliente.
Tipi di risorse | ProxyV2 |
Metrica | proxyv2/latencies_percentile |
Filtra per | percentile = p99 |
Raggruppa per | method, percentile e tutte le etichette del tipo 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 proxy p99 latencies_percentile è di 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, oltre all'utilizzo delle risorse Cassandra (volume di CPU, Mem e disco), la latenza delle richieste di lettura e scrittura del client deve essere monitorata per l'integrità del servizio Cassandra.
Tasso di richieste di lettura Cassandra
Caso d'uso: la metrica SLI Cassandra/clientrequest_rate (con scope=Read) fornisce informazioni sulla tariffa media delle 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 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 qualsiasi problema potenziale o cambiamento significativo nei pattern di query dei client, ad esempio un picco o un calo improvviso e imprevisto nella tasso di richieste di lettura. |
Soglia di avviso | Nessuna |
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 informazioni sulla tariffa media delle richieste di scrittura dei servizi Cassandra in un dato 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 qualsiasi problema potenziale o cambiamento significativo nei pattern di query dei clienti, ad esempio un picco o un calo improvviso e imprevisto nelle 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 Cassandra (al 99° percentile, 95° o 75° percentile). Queste metriche consentono di ottenere una visione complessiva delle prestazioni di Cassandra e possono indicare eventuali modifiche ai 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 una latenza del 99° percentile, in continuo aumento. |
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 della 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° 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 = 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 di evento se il valore di scrittura 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 == '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 di sincronizzazione Apigee forniscono i conteggi e le 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 regolarmente il polling del piano di controllo, scaricare i contratti e rendere le istanze disponibili per le istanze di runtime locali.
Tasso di richieste
Numero di 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 risorsa k8s_container |
Aggregatore | sum |
Considerazione dell'avviso | Utilizza questa opzione per le anomalie del traffico, ad esempio un avviso di picco o 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
Numero di 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 ibrido Apigee 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 dei tipi di risorsa k8s_container |
Raggruppa per | |
Aggregatore | sum |
Considerazione dell'avviso | Se si verificano errori nelle metriche upstream/response_count con codici di risposta diversi da 200 restituiti dal piano di controllo Apigee, è necessario un'ulteriore indagine su tali errori. |
Soglia di avviso | Dipende dallo SLO per i servizi Cassandra. Ad esempio, in produzione, attiva una notifica dell'evento se il sincronizzatore riscontra un errore response_code maggiore di un errore 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 suo utilizzo delle risorse. Per monitorare l'integrità e la disponibilità dell'infrastruttura del cluster di runtime Apigee, un amministratore del cluster può monitorare l'utilizzo comune delle risorse di container e pod, come CPU, Mem, disco e numero di riavvii del container. Segui la documentazione di GKE per ulteriori dettagli sulle metriche e sulle etichette disponibili.
La tabella seguente elenca alcuni dei servizi e dei container che puoi monitorare per ciascun servizio.
Nome servizio | Nome container |
---|---|
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 o si riavvia frequentemente. Il container di servizio specifico può essere filtrato in base alle etichette delle metriche per il monitoraggio del container di un servizio specifico.
Di seguito viene mostrato come utilizzare la metrica kubernetes.io/container/restart_count per il 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 tutte le etichette dei tipi di risorsa k8s_container |
Aggregatore | sum |
Considerazione dell'avviso | Se un container viene riavviato frequentemente, sono necessarie ulteriori indagini per determinare la causa principale. I motivi per cui un container può essere riavviato sono diversi, ad esempio OOMKilled ,
disco dati pieno e problemi di configurazione. |
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ù 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)] |