Panoramica
Questa guida fornisce linee guida su cosa monitorare e su come monitorare un deployment di Apigee Hybrid. È destinato agli amministratori di cluster ibride e agli amministratori dell'organizzazione.
Se non hai dimestichezza con il monitoraggio di Google Cloud, consulta la documentazione di Google Cloud Monitoring per informazioni su come creare grafici con Metrics Explorer e su come funzionano gli avvisi.
I cluster 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 risorse comuni utilizzati per tutte le metriche di Apigee Hybrid.
k8s_containerper le metriche a livello di sistema.Proxyper le metriche del proxy API Apigee.Targetper le metriche target dell'API Apigee
I tipi di risorse 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 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 evidenti e la documentazione fornita elencarebbe i valori che devono attivare gli avvisi. In realtà, è meno ovvio per Apigee definire cosa sia un rendimento accettabile e cosa sia un utilizzo pericoloso delle risorse di servizi e infrastrutture. I valori delle soglie di avviso variano notevolmente in base a particolari pattern di traffico e contratti SLO/SLA.
L'ottimizzazione e la determinazione della soglia di avviso sono un processo continuo in quanto possono variare in base all'utilizzo del servizio e dell'infrastruttura. Utilizza la soglia di avviso e critica per le notifiche e gli avvisi.
- Buono: il valore è inferiore alla soglia di avviso.
- Riguardante: 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 possono creare con l'MQL fornito di seguito o degli analytics di Apigee, per identificare il comportamento "normale" e regolare di conseguenza le soglie di avviso.
Il monitoraggio del cluster ibrido 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 della policy Apigee fornisce le latenze di risposta della policy. 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 tasso di richieste per i proxy. Questo grafico è utile per identificare il proxy che riceve una tasso di richieste più elevata, i pattern di 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 problema di sicurezza relativo a un bot o a 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 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/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 numero di richieste del target di runtime Apigee. Il grafico target/request_count mostra il tasso di richieste ricevuto dal target Apigee. Questo grafico può essere utile per vedere quale target riceve un tasso di richieste più elevato, il pattern del tasso di richieste e eventuali picchi anomali nelle chiamate di richiesta per un determinato target.
| Tipi di risorse | Destinazione |
| Metrica | target/request_count |
| Raggruppa per | method e tutte le etichette dei tipi di risorsa Target |
| 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/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
Conteggio delle risposte di errore del proxy
Caso d'uso: utilizza proxy/response_count per monitorare la percentuale di risposte con errori del proxy. Il grafico proxy/response_count mostra la tasso di richieste per il proxy API. Questo grafico è utile per capire quale proxy presenta un tasso di errori delle richieste più elevato o eventuali picchi di errori anomali nelle chiamate di richiesta per un determinato proxy.
| 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 degli avvisi | Il rapporto di errori di risposta del proxy: Errori di risposta totali / Numero di risposte totali.
|
| Soglia di avviso | Dipende dallo SLO per l'installazione. Le installazioni di produzione e non di produzione possono avere soglie diverse. Ad esempio: per la produzione, attiva una notifica di evento se il rapporto di errori 500 della risposta del proxy è pari al 5% per 5 minuti. |
Query MQL della dashboard di Cloud Monitoring:
fetch apigee.googleapis.com/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 MQL per l'operazione Google Cloud:
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 la tasso di richieste da 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 etichette dei tipi di risorsa Target |
| Aggregatore | sum |
| Considerazione degli avvisi | 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 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/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/latencies per monitorare le latenze di tutte le risposte del proxy API a una richiesta. Il grafico dei proxy/delle latenze può essere utile per identificare la latenza nel proxy API Apigee per la 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 target
Caso d'uso: utilizza target/latencies per monitorare le latenze di tutte le risposte del target del proxy API a una richiesta. Il grafico target/latenze identifica il tempo totale necessario al target del proxy API Apigee per rispondere a una richiesta. Questo valore non include il sovraccarico 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 del percentile di latenza p99 target è 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, insieme all'utilizzo delle risorse Cassandra (CPU, memoria e volume del disco), è necessario monitorare la latenza delle richieste di lettura e scrittura del client per il corretto funzionamento 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. Questa metrica consente di comprendere le tendenze del livello di attività delle richieste di lettura dei clienti.
| Tipi di risorse | k8s_container |
| Metrica | cassandra/clientrequest_rate |
| Filtra per | scope = Read e unit = OneMinuteRate |
| Raggruppa per | scope, unit e tutte le etichette dei tipi di risorsa k8s_container |
| Aggregatore | sum |
| Considerazione degli avvisi | Per eventuali problemi o modifiche significative nei pattern di query dei clienti, ad esempio un picco o un calo improvviso e imprevisto del tasso di richieste di lettura. |
| Soglia di avviso | Nessuno |
Query MQL della dashboard di Cloud Monitoring:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Read' && metric.unit == 'OneMinuteRate')
| group_by 1m,
[value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
[value_clientrequest_latency_mean_aggregate:
aggregate(value_clientrequest_latency_mean)]
|
|
Frequenza delle richieste di scrittura di Cassandra
Caso d'uso: la metrica SLI cassandra/clientrequest_rate (con ambito=Write) fornisce informazioni sulla frequenza media delle richieste di scrittura dei servizi Cassandra in un determinato momento. Questa metrica consente di comprendere le tendenze a livello di attività delle richieste di scrittura dei clienti.
| Tipi di risorse | k8s_container |
| Metrica | cassandra/clientrequest_rate |
| Filtra per | scope = Read e unit = OneMinuteRate |
| Raggruppa per | scope, unit e tutte le etichette dei tipi di risorsa k8s_container |
| Aggregatore | sum |
| Considerazione degli avvisi | Per eventuali problemi o cambiamenti significativi nei pattern di query dei clienti, ad esempio un picco o un calo improvviso e imprevisto delle richieste di scrittura che richiedono ulteriori accertamenti. |
| Soglia di avviso | Nessuna |
Query MQL della dashboard di Cloud Monitoring:
fetch k8s_container
| metric 'apigee.googleapis.com/cassandra/clientrequest_latency'
| filter (metric.scope == 'Write' && metric.unit == 'OneMinuteRate')
| group_by 1m,
[value_clientrequest_latency_mean: mean(value.clientrequest_latency)]
| every 1m
| group_by [metric.scope, metric.unit],
[value_clientrequest_latency_mean_aggregate:
aggregate(value_clientrequest_latency_mean)]
|
|
Latenza delle richieste di lettura di Cassandra
Caso d'uso: la metrica SLI cassandra/clientrequest_latency (con ambito=Lettura) fornisce la latenza delle richieste di lettura dei servizi Cassandra (al 99° percentile, al 95° percentile o al 75° percentile). Queste metriche consentono di avere una visione complessiva del rendimento di Cassandra e possono indicare eventuali cambiamenti nei pattern di utilizzo o un problema che si manifesta nel tempo.
| Tipi di risorse | k8s_container |
| Metrica | cassandra/clientrequest_latency |
| Filtra per | scope = Read e unit = 99thPercentile |
| Raggruppa per | scope, unit e tutte le etichette dei tipi di risorsa k8s_container |
| Aggregatore | sum |
| Considerazione degli avvisi | 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 ambito=Write) fornisce la latenza delle richieste di scrittura dei servizi Cassandra (al 99° percentile, al 95° percentile o al 75° percentile). Queste metriche consentono di avere una visione complessiva del rendimento di Cassandra e possono indicare eventuali cambiamenti nei pattern di utilizzo o un problema che si manifesta nel tempo.
| Tipi di risorse | k8s_container |
| Metrica | cassandra/clientrequest_latency |
| Filtra per | scope = 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)]
|
|
Control plane Apigee
Le metriche SLI del servizio Apigee Synchronizer forniscono conteggi di richieste e risposte e la latenza tra il piano di controllo di Apigee e il piano di runtime ibrido. Le istanze di sincronizzazione in esecuzione nel piano di runtime devono eseguire regolarmente il polling del piano di controllo, scaricare i contratti e metterli a disposizione delle istanze di runtime locali.
Tasso di richieste
Numero di richieste in upstream
Caso d'uso: le metriche upstream/request_count indicano il numero di richieste effettuate dal servizio Synchronizer al piano di controllo Apigee.
| Tipi di risorse | k8s_container |
| Metrica | upstream/request_count |
| Filtra per | container_name = apigee-synchronizer e type = CONTRACT |
| Raggruppa per | method, type, container_name e tutte le etichette del tipo di risorsa k8s_container |
| Aggregatore | sum |
| Considerazione degli avvisi | Utilizza questa metrica per le anomalie del traffico, ad esempio un picco o un avviso di calo anomalo di request_count. |
| Soglia di avviso | Nessuna |
Query MQL della dashboard di Cloud Monitoring:
fetch k8s_container | metric 'apigee.googleapis.com/upstream/request_count' | filter (resource.container_name == 'apigee-synchronizer') && (metric.type == 'CONTRACT') | align rate(1m) | every 1m | group_by [metric.method, metric.type, resource.container_name], [value_request_count_aggregate: aggregate(value.request_count)] |
|
Percentuale di errori
Conteggio delle risposte upstream
Caso d'uso: la metrica SLI upstream/response_count fornisce il numero di risposte ricevute dai servizi di sincronizzazione dal piano di controllo Apigee. Questo diagramma può essere utile per identificare eventuali problemi di connettività o configurazione tra il piano di runtime di Apigee Hybrid e il piano di controllo.
| Tipi di risorse | k8s_container |
| Metrica | upstream/request_count |
| Filtra per | method, response_type, container_name e tutte le etichette per il tipo di risorsa k8s_container |
| Raggruppa per | |
| Aggregatore | sum |
| Considerazione degli avvisi | Se sono presenti errori nelle metriche upstream/response_count con codici di risposta diversi da 200 restituiti dal piano di controllo Apigee, è necessario effettuare ulteriori accertamenti su questi errori. |
| Soglia di avviso | Dipende dallo SLO per i servizi Cassandra. Ad esempio: in produzione, attiva una notifica di evento se Synchronizer riscontra più di un errore response_code ogni tre minuti. |
Query MQL della dashboard di Cloud Monitoring:
fetch k8s_container | metric 'apigee.googleapis.com/upstream/response_count' | filter (resource.container_name == 'apigee-synchronizer') && (metric.response_code != '200' && metric.type == 'CONTRACT') | align rate(1m) | every 1m | group_by [metric.method, metric.response_code, metric.type, resource.container_name], [value_response_count_aggregate: aggregate(value.response_count)] |
|
Infrastruttura
GKE e altre piattaforme Kubernetes forniscono metriche SLI a livello di sistema. Le etichette delle metriche SLI possono essere filtrate e raggruppate per monitorare un 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 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 contenitori che puoi monitorare per ciascun servizio.
| Nome servizio | Nome contenitore |
|---|---|
| Cassandra | apigee-cassandra |
| Processore di messaggi(MP) | apigee-runtime |
| Synchronizer | apigee-synchronizer |
| Telemetria | apigee-prometheus-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 il numero di riavvii di un container. Questo grafico può essere utile per identificare se un contenitore si arresta in modo anomalo/si riavvia di frequente. 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 l'utilizzo della metrica kubernetes.io/container/restart_count per il contenitore 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 contenitore si riavvia di frequente, è necessario effettuare ulteriori accertamenti per individuare la causa principale. Esistono diversi motivi per cui un contenitore può riavviarsi, ad esempio OOMKilled,
disco dati pieno e problemi di configurazione, per citarne alcuni. |
| Soglia di avviso | Dipende dallo SLO per l'installazione. Ad esempio: per la produzione, attiva una notifica di evento se un contenitore si riavvia più di 5 volte 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)] |
|