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 funzionano gli avvisi.
I cluster Apigee Hybrid forniscono metriche SLI (indicatore di livello del servizio) per aiutarti a comprendere il rendimento dei servizi di sistema e delle applicazioni 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 Tipi di risorse utilizzati per tutte le metriche Apigee Hybrid.
k8s_containerper le metriche a livello di sistema.Proxyper le metriche del proxy API Apigee.Targetper 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 cluster_name,
Possibilità di utilizzare le etichette pod_name e container_name, oltre alle
le etichette delle metriche. Per monitorare efficacemente l'integrità e le prestazioni del cluster, è consigliabile utilizzare una combinazione di etichette di tipo di risorsa ed etichette di metriche.
Soglia di avviso: in un mondo perfetto, le soglie di avviso sarebbero ovvie e il valore fornito documentazione elenca 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 schemi di traffico e contratti SLO/SLA.
L’ottimizzazione e la determinazione della soglia di avviso sono un processo continuo in quanto può cambiare l'uso del servizio e dell'infrastruttura. Utilizza la soglia di avviso e critica per le notifiche e gli avvisi.
- Buono: 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. Le sezioni seguenti descrivono questi gruppi in dettaglio:
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 delle API Apigee.
Tasso di richieste
Conteggio delle richieste proxy
Caso d'uso: utilizza proxy/request_count per monitorare il numero di richieste proxy. Il grafico proxy/request_count mostra la frequenza di richiesta 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 | Proxy |
| Metrica | proxy/request_count |
| Raggruppa per | method e tutte le etichette dei tipi di risorsa Proxy |
| Aggregatore | sum |
| Considerazione dell'avviso | 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/Proxy | metric 'apigee.googleapis.com/proxy/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 target/request_count per monitorare il target di runtime Apigee conteggio delle richieste. Il grafico target/request_count mostra il tasso di richieste ricevute da Apigee target. 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 | Destinazione |
| Metrica | target/request_count |
| Raggruppa per | method e tutte le opzioni Target etichette dei tipi di risorse |
| Aggregatore | sum |
| Considerazione dell'avviso | 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/Target | metric 'apigee.googleapis.com/target/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 proxy/response_count per monitorare la risposta di errore del proxy. di conversione. Il grafico proxy/response_count mostra il tasso di richieste per 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 | Proxy |
| Metrica | proxy/response_count |
| Filtra per | response_code != 200
|
| Raggruppa per | method, response_code, fault_code,
fault_source, apigee_fault,
e tutte le etichette dei tipi di risorsa Proxy. |
| 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. 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 del proxy è del 5% per 5 minuti. |
Query MQL della dashboard di Cloud Monitoring:
fetch apigee.googleapis.com/Proxy | metric 'apigee.googleapis.com/proxy/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/Proxy::apigee.googleapis.com/proxy/response_count
| {
filter (metric.response_code == 500)
;
ident
}
| group_by drop[metric.response_code ], sliding(5m), .sum
| ratio
| scale '%'
| every (30s)
| condition val() > 5'%'
|
|
Numero di risposte di errore target
Caso d'uso: utilizza target/response_count per monitorare il tasso di risposta dell'errore API Target. Il grafico target/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 | Destinazione |
| Metrica | target/response_count |
| Filtra per | response_code != 200
|
| Raggruppa per | method e tutte le opzioni Target etichette dei tipi di risorse |
| Aggregatore | sum |
| Considerazione dell'avviso | Il rapporto di errori di risposta del proxy, ad esempio: Errori di risposta totali/Numero di risposte totali.
|
| 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/Target | metric 'apigee.googleapis.com/target/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
Latenze del proxy
Caso d'uso: utilizza proxy/latenze per monitorare le latenze di tutte le risposte proxy API a una richiesta. Il grafico relativo a proxy/latenze può essere utile per identificare la latenza nel proxy API Apigee rispetto alla latenza complessiva della richiesta del proxy API.
| Tipi di risorse | Proxy |
| Metrica | proxy/latencies |
| Raggruppa per | method e tutte le etichette dei tipi di risorsa Proxy |
| Aggregatore | p99 (99° percentile) |
| Considerazione degli avvisi | Valore elevato del percentile di latenza P99. |
| Soglia di avviso | Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento se il valore del percentile di latenza p99 del proxy è 5 secondi per 5 minuti. |
Query MQL della dashboard di Cloud Monitoring:
fetch apigee.googleapis.com/Proxy
| metric 'apigee.googleapis.com/proxy/latencies'
| align delta(1m)
| every 1m
| group_by [metric.method],
[value_latencies_percentile: percentile(value.latencies, 99)]
|
|
Latenze di destinazione
Caso d'uso: utilizza il target/latencies per monitorare le latenze di tutte le risposte di targeting del proxy API a una richiesta. La Il grafico target/latenze identifica la quantità di tempo totale per il proxy API Apigee per rispondere a una richiesta. Questo valore non include l'overhead del proxy API Apigee.
| Tipi di risorse | Destinazione |
| Metrica | target/latencies |
| Raggruppa per | method, percentile e tutte le etichette dei tipi di risorsa Target |
| Aggregatore | p99 (99° percentile) |
| Considerazione degli avvisi | Valore elevato del percentile di latenza P99. |
| Soglia di avviso | Dipende dallo SLO per l'installazione. Ad esempio, per la produzione, attiva una notifica di evento. Se il valore il percentile di latenza p99 target è di 5 secondi per 5 minuti. |
Query MQL della dashboard di Cloud Monitoring:
fetch apigee.googleapis.com/Target
| metric 'apigee.googleapis.com/target/latencies'
| align delta(1m)
| every 1m
| group_by [metric.method],
[value_latencies_percentile: percentile(value.latencies, 99)]
|
|
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 di 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. Questo aiuta a comprendere il comportamento dei clienti tendenze del livello di attività delle richieste di lettura.
| 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 scope=Write) fornisce insight sulla tariffa media delle richieste di scrittura nei 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 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 scope=Read) fornisce Latenza delle richieste di lettura dei servizi Cassandra (al 99° percentile, 95° percentile o 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 tutte le etichette dei tipi di risorsa k8s_container |
| 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 clientrequest_latency letto 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° percentile, 95° percentile o 75° ). Queste metriche consentono di avere una visione complessiva delle prestazioni di Cassandra e possono indicare eventuali cambiamenti nei pattern di utilizzo o problemi che si manifestano 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 degli avvisi | Se l'SLI della latenza delle richieste di scrittura 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 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 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 degli avvisi | Da utilizzare per le anomalie del traffico, ad esempio un picco anomalo di request_count o avviso di caduta di emergenza. |
| 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 i servizi di sincronizzazione ricevuti 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 tutte le etichette per il tipo di risorsa k8s_container |
| Raggruppa per | |
| Aggregatore | sum |
| Considerazione dell'avviso | In caso di errori nelle metriche upstream/response_count con codici di risposta non 200 dal piano di controllo Apigee, per cui sono state necessarie ulteriori indagini errori. |
| Soglia di avviso | Dipende dallo SLO per i servizi Cassandra. Ad esempio: in produzione, attiva una notifica di evento. se il sincronizzatore riscontra un errore maggiore di un 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 l'integrità e la disponibilità dell'infrastruttura del cluster Apigee Runtime, un amministratore del cluster può monitorare l'utilizzo delle risorse comuni dei container e dei pod, come CPU, memoria, disco e conteggi di riavvio dei container. Per ulteriori dettagli sulle metriche e sulle etichette disponibili, consulta la documentazione di GKE.
La tabella seguente elenca 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-appapigee-prometheus-proxyapigee-prometheus-aggapigee-stackdriver-exporter |
Container / pod
Conteggio riavvii
Caso d'uso: la metrica SLI di sistema kubernetes.io/container/restart_count fornisce di volte in cui un container è stato riavviato. Questo grafico può essere utile per capire se un container si arresta in modo anomalo o si riavvia spesso. Il contenitore del servizio specifico può essere escluso in base alle etichette delle metriche per il monitoraggio dei contenitori 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 uno qualsiasi dei contenitori 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 per il tipo di risorsa k8s_container |
| Aggregatore | sum |
| Considerazione degli avvisi | Se un container si riavvia frequentemente, sono necessarie ulteriori indagini per il root
causa. 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 container si riavvia più spesso 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)] |
|