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 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_container per le metriche a livello di sistema.
  • Proxy per le metriche del proxy API Apigee.
  • Target 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 di 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.

  • In buono stato: il valore è inferiore alla soglia di avviso.
  • Preoccupante: valore maggiore della 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 PromQL 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 in dettaglio questi gruppi:

Traffico

Le metriche SLI di proxy e target Apigee forniscono conteggi e latenze di richieste/risposte 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

Conteggio richieste proxy

Caso d'uso: utilizza proxy/request_count per monitorare il conteggio delle richieste proxy. Il grafico proxy/request_count mostra la tasso di richieste per i proxy. Questo grafico è utile per identificare quale proxy riceve unatasso di richiestee più elevata, i patterntasso di richiestee 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 considerevole del traffico complessivo del cloud indica problemi con i client o la connettività dei componenti upstream di Apigee.

Tipi di risorse Proxy
Metrica proxy/request_count
Raggruppa per method e tutte le etichette del tipo 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 PromQL della dashboard di Cloud Monitoring: 
sum by (method) (
 rate({"apigee.googleapis.com/proxy/request_count", monitored_resource="apigee.googleapis.com/Proxy"}[1m])
)

Conteggio richieste target

Caso d'uso: utilizza target/request_count per monitorare il conteggio delle richieste di destinazione del runtime Apigee. Il grafico target/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 eventuali picchi anomali nelle chiamate di richieste per un determinato target.

Tipi di risorse Destinazione
Metrica target/request_count
Raggruppa per method e tutte le etichette del tipo 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 PromQL della dashboard di Cloud Monitoring: 
sum by (method, type, endpoint) (
 rate({"apigee.googleapis.com/target/request_count", monitored_resource="apigee.googleapis.com/Target"}[1m])
)

Tasso di errori

Conteggio delle risposte di errore del proxy

Caso d'uso: utilizza proxy/response_count per monitorare il tasso di risposta di errore 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 di richiesta più elevato o eventuali picchi anomali di errori 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 del tipo di risorsa Proxy
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 proxy/response_count con filtro response_code != 200
  • Numero totale di risposte = Somma di proxy/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 PromQL della dashboard di Cloud Monitoring: 
sum by (method, response_code, fault_code, fault_source, apigee_fault) (
 rate({"apigee.googleapis.com/proxy/response_count", monitored_resource="apigee.googleapis.com/Proxy", response_code!="200"}[1m])
)
Esempio di PromQL per i criteri di avviso per l'operazione Google Cloud: 
100 * (
 sum by (method, org, apigee_fault, location, resource_container, env, proxy_name, fault_code, fault_source) ({"apigee.googleapis.com/proxy/response_count", monitored_resource="apigee.googleapis.com/Proxy", response_code="500"})
/
 sum by (method, org, apigee_fault, location, resource_container, env, proxy_name, fault_code, fault_source) ({"apigee.googleapis.com/proxy/response_count", monitored_resource="apigee.googleapis.com/Proxy"})
) > 5

Conteggio risposte di errore target

Caso d'uso: utilizza target/response_count per monitorare il tasso di risposta di errore del target API. Il grafico target/response_count mostra la tasso di richieste dal target API. 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 Destinazione
Metrica target/response_count
Filtra per response_code != 200
Raggruppa per method e tutte le etichette del tipo di risorsa Target
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 nelle risposte = Somma di target/response_count con filtro response_code != 200
  • Numero totale di risposte = Somma di target/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 PromQL della dashboard di Cloud Monitoring: 
sum by (method, type, endpoint, response_code) (
 rate({"apigee.googleapis.com/target/response_count", monitored_resource="apigee.googleapis.com/Target", response_code!="200"}[1m])
)

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 proxy/latenze può essere utile per identificare la latenza nel proxy API Apigee rispetto alla latenza complessiva delle richieste del proxy API.

Tipi di risorse Proxy
Metrica proxy/latencies
Raggruppa per method e tutte le etichette del tipo 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 è di 5 secondi per 5 minuti.
Query PromQL della dashboard di Cloud Monitoring: 
histogram_quantile(
 0.99,
 sum by (le, method) (
   rate({"apigee.googleapis.com/proxy/latencies/bucket", monitored_resource="apigee.googleapis.com/Proxy"}[1m])
 )
)

Latenze target

Caso d'uso: utilizza target/latencies per monitorare le latenze di tutte le risposte di destinazione del proxy API a una richiesta. Il grafico target/latenze 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 Destinazione
Metrica target/latencies
Raggruppa per Metodo, percentile e tutte le etichette del tipo 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 evento se il valore del percentile di latenza p99 target è di 5 secondi per 5 minuti.
Query PromQL della dashboard di Cloud Monitoring: 
histogram_quantile(
  0.99,
  sum by (le, method) (
    rate({"apigee.googleapis.com/target/latencies/bucket", monitored_resource="apigee.googleapis.com/Target"}[1m])
  )
)

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 PromQL della dashboard di Cloud Monitoring: 
sum by (scope, unit) (
 avg_over_time({"apigee.googleapis.com/cassandra/clientrequest_latency",
   monitored_resource="k8s_container",
   scope="Read",
   unit="OneMinuteRate"
 }[1m])
)

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 PromQL della dashboard di Cloud Monitoring: 
sum by (scope, unit) (
 avg_over_time({"apigee.googleapis.com/cassandra/clientrequest_latency",
   monitored_resource="k8s_container",
   scope="Write",
   unit="OneMinuteRate"
 }[1m])
)

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 complessiva delle prestazioni di Cassandra e possono indicare eventuali modifiche nei pattern di utilizzo o un problema che si manifesta nel tempo.

Tipi di risorse k8s_container
Metrica cassandra/clientrequest_latency
Filtra per scope = Read e unit = 99thPercentile
Raggruppa per scope, unit e tutte le etichette 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 PromQL della dashboard di Cloud Monitoring: 
sum by (scope, unit) (
 avg_over_time({"apigee.googleapis.com/cassandra/clientrequest_latency",
   monitored_resource="k8s_container",
   scope="Read",
   unit="99thPercentile"
 }[1m])
)

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 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 del tipo di risorsa k8s_container
Aggregatore sum
Considerazione degli avvisi Se l'indicatore SLI della 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 clientrequest_latency di scrittura del 99° percentile è 5 secondi per 3 minuti
Query PromQL della dashboard di Cloud Monitoring: 
sum by (scope, unit) (
 avg_over_time({"apigee.googleapis.com/cassandra/clientrequest_latency",
   monitored_resource="k8s_container",
   scope="Write",
   unit="99thPercentile"
 }[1m])
)

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 delle 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 Utilizza questo valore per anomalie del traffico, ad esempio un picco o un calo anomalo di request_count.
Soglia di avviso Nessuna
Query PromQL della dashboard di Cloud Monitoring: 
sum by (method, type, container_name) (
 rate({"apigee.googleapis.com/upstream/request_count",
   monitored_resource="k8s_container",
   container_name="apigee-synchronizer",
   type="CONTRACT"
 }[1m])
)

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 riscontra più di un errore response_code ogni tre minuti.
Query PromQL della dashboard di Cloud Monitoring: 
sum by (method, response_code, type, container_name) (
 rate({"apigee.googleapis.com/upstream/response_count",
   monitored_resource="k8s_container",
   container_name="apigee-synchronizer",
   response_code!="200"
   type="CONTRACT"
 }[1m])
)

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 contenitori che puoi monitorare per ciascun servizio.

Nome servizio Nome contenitore
Cassandra apigee-cassandra
Message Processor(MP) apigee-runtime
Synchronizer 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 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 PromQL della dashboard di Cloud Monitoring: 
sum by (cluster_name, namespace_name, pod_name, container_name) (
 rate({"kubernetes.io/container/restart_count",
   monitored_resource="k8s_container",
   container_name=~".*cassandra.*",
   namespace_name="apigee"
 }[1m])
)