Linee guida per il monitoraggio del cluster

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 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 ibridi Apigee forniscono metriche SLI (indicatore del livello del servizio) per aiutarti a comprendere in che modo di sistema e applicazioni siano in esecuzione 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 Tipi di risorse utilizzati per tutte le metriche Apigee Hybrid.

• k8s_container per le metriche a livello di sistema.
• Proxy per le metriche del proxy API Apigee.
• Target 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. È necessario utilizzare una combinazione di etichette Resource Type ed etichette delle metriche per per monitorare in modo efficace l'integrità e le prestazioni del cluster.

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 modelli di traffico e agli accordi 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.

• Stato integro: 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 del cluster ibrido può essere classificato in quattro diversi gruppi generali, ad esempio Traffico, database, piano di controllo Apigee e infrastruttura il monitoraggio. Nelle sezioni seguenti vengono descritti in dettaglio questi gruppi:

Traffico

Le metriche Apigee Proxy e SLI di destinazione forniscono conteggi e latenze di richieste/risposte per le API Proxy e target. 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 dell'API Apigee.

Tasso di richieste

Conteggio delle richieste proxy

Caso d'uso: utilizza proxy/request_count per monitorare il conteggio delle 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 del traffico complessivo nel cloud indica problemi con i client o la connettività da Apigee a upstream componenti.

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 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.

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 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.

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)]

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'%'

Conteggio delle 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.

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.

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 l'overhead del proxy API Apigee.

    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. Questa metrica consente di comprendere le tendenze del livello di attività delle richieste di lettura dei clienti.

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 con la comprensione dei clienti di scrittura delle tendenze dei livelli di attività delle richieste.

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 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.

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.

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 di sincronizzazione al piano di controllo Apigee.

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 Piano di controllo.

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 il cluster di runtime Apigee integrità e disponibilità dell'infrastruttura, un amministratore del cluster può monitorare container e pod comuni dell'uso delle risorse, ad esempio numero di riavvii di CPU, Mem, disco e 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.

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 capire se un container si arresta in modo anomalo o si riavvia spesso. Il container di servizio specifico può essere filtrato in base alle metriche per il monitoraggio dei container 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 qualsiasi contenitore della tabella precedente.

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)]