Sebbene Memorystore for Redis fornisca metriche lato server in tempo reale per monitorare la velocità effettiva, l'utilizzo della CPU e la memoria utilizzata, questi dati da soli potrebbero non spiegare perché l'applicazione client riscontra una latenza elevata all'interno di sistemi distribuiti complessi.
Le metriche lato client risolvono questo problema fornendo trasparenza sull'intero ciclo richiesta-risposta. Misurano un comando dal momento in cui l'applicazione lo avvia fino a quando l'applicazione elabora la risposta. Acquisendo questi punti dati, puoi determinare con precisione se la latenza ha origine dalla logica dell'applicazione, dal percorso di rete o dal server Redis.
Prima di iniziare
Assicurati che l'applicazione client utilizzi un account di servizio e che siano assegnati i seguenti ruoli Identity and Access Management (IAM):
roles/cloudtrace.agent(agente Cloud Trace)roles/monitoring.metricWriter(Monitoring Metric Writer)
Per ulteriori informazioni sulla concessione dei ruoli, consulta la guida rapida Concedi un ruolo IAM utilizzando la Google Cloud console.
Abilita l'API Cloud Monitoring
Per esportare le metriche lato client in Monitoring, l'applicazione richiede l'abilitazione dell'API Monitoring. L'esportazione e la visualizzazione di queste metriche in Monitoring ti consentono di individuare la causa principale dei colli di bottiglia per determinare l'origine della latenza.
Per abilitare l'API Monitoring:
Nella Google Cloud console, vai alla pagina API e servizi.
Seleziona il progetto in cui hai creato l'istanza Memorystore for Redis.
Fai clic su Abilita API e servizi.
Cerca
monitoring.Nei risultati di ricerca, fai clic su API Cloud Monitoring.
Se viene visualizzato il messaggio API abilitata, l'API è già abilitata. In caso contrario, fai clic su Abilita.
Abilita l'Cloud Trace API
Per visualizzare le tracce distribuite in Trace, devi abilitare l'API Trace. Puoi quindi utilizzare Trace Explorer per visualizzare queste tracce, diagnosticare i colli di bottiglia e isolare l'origine della latenza nella tua applicazione.
Per abilitare l'API Trace:
Nella Google Cloud console, vai alla pagina API e servizi.
Seleziona il progetto in cui hai creato l'istanza Memorystore for Redis.
Fai clic su Abilita API e servizi.
Cerca
trace.Nei risultati di ricerca, fai clic su API Cloud Trace.
Se viene visualizzato il messaggio API abilitata, l'API è già abilitata. In caso contrario, fai clic su Abilita.
Abilita le metriche lato client
Per abilitare le metriche lato client, aggiungi l'OpenTelemetry OpenTelemetry, l'esportatore Cloud Monitoring e l'esportatore Cloud Trace al codice dell'applicazione. L'instrumentazione OpenTelemetry, che viene eseguita direttamente all'interno della libreria client Redis dell'applicazione, acquisisce le metriche. In questo modo, l'applicazione può registrare i punti dati di latenza ed esportarli in Monitoring e Trace per la visualizzazione.
Per abilitare le metriche lato client, puoi utilizzare Go, Java, Node.js, o Python. Le informazioni sull'abilitazione delle metriche per ogni lingua sono riportate nelle schede seguenti.
Vai
Per installare le dipendenze richieste di OpenTelemetry ed Google Cloud esportatore, esegui i seguenti comandi nel terminale:
go get github.com/gomodule/redigo/redis@latest go get go.opentelemetry.io/otel go get go.opentelemetry.io/otel/sdk/trace go get go.opentelemetry.io/otel/sdk/metric go get github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/trace go get github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/metric
Per abilitare le metriche lato client, crea un file
main.goe aggiungi il seguente codice:Esegui l'applicazione per almeno un minuto per dare all'esportatore il tempo sufficiente per raggruppare e inviare le metriche pubblicate a Monitoring.
Java
Per installare le dipendenze richieste di OpenTelemetry e Google Cloud esportatore dependencies, aggiungi il seguente codice al file
pom.xmldell'applicazione:Per abilitare le metriche lato client, crea un file
RedisTelemetryApp.javae aggiungi il seguente codice:Esegui l'applicazione per almeno un minuto per dare all'esportatore il tempo sufficiente per raggruppare e inviare le metriche pubblicate a Monitoring.
Node.js
Per installare le dipendenze richieste di OpenTelemetry ed Google Cloud esportatore, esegui i seguenti comandi nel terminale:
npm install redis@^4.6.0 @opentelemetry/api@^1.9.0 @opentelemetry/sdk-trace-node@^2.1.0 @opentelemetry/sdk-trace-base@^2.1.0 @opentelemetry/sdk-metrics@^2.1.0 @opentelemetry/instrumentation@^0.205.0 @opentelemetry/instrumentation-redis@^0.67.0 @google-cloud/opentelemetry-cloud-trace-exporter@^3.0.0 @google-cloud/opentelemetry-cloud-monitoring-exporter@^0.21.0 @opentelemetry/resources@^2.1.0
Per abilitare le metriche lato client, crea un file
server.jse aggiungi il seguente codice:Esegui l'applicazione per almeno un minuto per dare all'esportatore il tempo sufficiente per raggruppare e inviare le metriche pubblicate a Monitoring.
Python
Per installare le dipendenze richieste di OpenTelemetry ed Google Cloud esportatore, esegui i seguenti comandi nel terminale:
pip install redis==7.0.1 opentelemetry-api==1.39.1 opentelemetry-sdk==1.39.1 opentelemetry-instrumentation-redis==0.60b1 opentelemetry-exporter-gcp-trace==1.11.0 opentelemetry-exporter-gcp-monitoring==1.11.0a0
Per abilitare le metriche lato client, crea un file
main.pye aggiungi il seguente codice all'applicazione:Esegui l'applicazione per almeno un minuto per dare all'esportatore il tempo sufficiente per raggruppare e inviare le metriche pubblicate a Monitoring.
Visualizza le metriche in Monitoring
Dopo aver abilitato le metriche lato client ed eseguito l'applicazione per almeno un minuto per dare all'esportatore il tempo sufficiente per raggruppare e inviare le metriche a Monitoring, utilizza Monitoring per visualizzare le metriche, raggrupparle per operazione o istanza e applicare gli aggregatori per monitorare le prestazioni dell'applicazione.
Per visualizzare le metriche in Monitoring:
Nella Google Cloud console, vai alla pagina Esplora metriche.
Selezionare il tuo Google Cloud progetto.
Fai clic su Seleziona una metrica.
Cerca
workload.googleapis.com/redis.Seleziona una metrica lato client. Raggruppa i dati per
operationeinstance, se necessario, e scegli un aggregatore. Per esplorare altre opzioni, consulta Seleziona le metriche durante l'utilizzo di Esplora metriche.
Visualizza le tracce distribuite in Trace
Dopo che l'applicazione inizia a esportare i dati, puoi utilizzare Trace per visualizzare l'intero ciclo richiesta-risposta dei comandi Redis. La visualizzazione delle tracce distribuite in Trace ti consente di diagnosticare i colli di bottiglia in modo da poter isolare rapidamente l'origine esatta della latenza nella tua applicazione.
Per visualizzare le tracce distribuite in Trace:
Nella Google Cloud console, vai alla pagina Esplora tracce.
Seleziona una traccia recente rappresentata da un punto nel grafico a dispersione.
Esamina la visualizzazione a cascata per isolare l'origine della latenza identificando i seguenti colli di bottiglia:
Durata totale della richiesta: la barra di primo livello (principale) mostra il tempo totale di attesa per il completamento dell'operazione.
Latenza di rete e del server (RTT): le barre secondarie (ad esempio quelle con etichetta
GEToSET) mostrano il tempo impiegato dal comando per attraversare la rete ed essere eseguito sul server Memorystore for Redis.Blocco della connessione client: se è presente un ampio spazio orizzontale vuoto prima dell'inizio dell'intervallo secondario Redis, il thread dell'applicazione è bloccato in attesa di una connessione TCP disponibile dal pool di connessioni.
Blocco dell'analisi dell'applicazione: se è presente un ampio spazio orizzontale vuoto dopo la fine dell'intervallo secondario Redis, l'applicazione ha difficoltà ad analizzare o elaborare il payload restituito. Questo accade spesso con le stringhe JSON di più megabyte.
Nuovi tentativi: se vedi più intervalli secondari brevi per lo stesso comando che si verificano in sequenza all'interno della stessa traccia principale, il client potrebbe riscontrare una perdita di pacchetti di rete e deve attivare il ciclo di nuovi tentativi con backoff esponenziale.
Risoluzione dei problemi
Questa sezione elenca i problemi di prestazioni comuni che puoi identificare utilizzando le metriche lato client, spiega le cause principali e fornisce indicazioni per la risoluzione dei problemi.
| Problema | Causa | Risoluzione dei problemi |
|---|---|---|
L'applicazione riscontra un picco di latenza improvviso, ma Memorystore for Redis sembra completamente integro.
|
Il collo di bottiglia si trova esclusivamente all'interno dell'applicazione. I
thread tentano di eseguire i comandi Redis, ma il pool di connessioni è completamente
esaurito. L'elevata redis_client_blocking_latency rappresenta
il tempo impiegato dal codice in attesa di un socket TCP disponibile prima che il
comando venga inviato alla rete. |
Per gestire il traffico simultaneo più elevato, aumenta i
limiti delle dimensioni del pool di connessioni nella configurazione del client Redis (ad esempio,
MaxActive per Go, MaxTotal per Java o
max_connections per Node.js e Python). |
La richiesta viene completata, ma l'endpoint richiede molto più tempo del previsto. Non ci sono problemi associati all'integrità della rete o del server.
|
Memorystore for Redis esegue il comando e la rete trasferisce rapidamente il
payload (RTT basso). Tuttavia, il payload restituito è di grandi dimensioni (ad
esempio, una stringa JSON di 15 MB). L'applicazione riscontra un'elevata
redis_application_blocking_latency perché l'applicazione
consuma risorse eccessive durante l'allocazione della memoria e la deserializzazione di quella
stringa di grandi dimensioni in un oggetto. |
Ottimizza il modello dei dati. Non archiviare blob JSON di grandi dimensioni in singole chiavi.
Suddividi i dati utilizzando gli hash Redis (HSET) e utilizza
HGET o HMGET per recuperare solo i campi specifici
di cui hai bisogno.
|
La latenza dell'applicazione rivolta agli utenti aumenta, ma le metriche Redis indicano una bassa latenza del server e i checkout del pool di connessioni tipici.
|
Poiché redis_client_rtt acquisisce solo l'RTT delle
richieste riuscite, non riflette la durata del timeout di un pacchetto non riuscito. Quando l'applicazione riscontra interruzioni temporanee dei pacchetti o ripristini TCP, la logica di nuovi tentativi del client instrumentato incrementa
redis_retry_count e attiva il ciclo di backoff esponenziale.
Questo introduce un tempo di sospensione tra i tentativi (ad esempio,
100ms, 200ms, o 400ms). L'utente
riscontra una latenza totale elevata, ma la causa principale sottostante è una perdita di pacchetti di rete, che attiva ritardi di sospensione lato client. |
Controlla i log dei flussi VPC per verificare la presenza di pacchetti eliminati, limitazione della larghezza di banda,
o anomalie di routing tra regioni. Se riscontri timeout aggressivi,
assicurati che i timeout di connessione client (socket_timeout o
connect_timeout) siano maggiori dell'RTT previsto per tenere conto
del jitter di rete temporaneo. |
Tutto si ferma e tutti i livelli della pipeline di telemetria segnalano una latenza elevata.
|
Redis è a thread singolo. Quando esegui un comando di complessità temporale O(N)
, ad esempio KEYS *, SMEMBERS
su un set di grandi dimensioni o HGETALL su un hash con milioni di
campi, il motore Redis si mette in pausa per soddisfare la richiesta. Mentre il comando
è in esecuzione, ogni altra richiesta dell'applicazione viene messa in coda, causando un picco di latenza
a livello di sistema. Poiché la redis_client_rtt personalizzata corrisponde alla latenza del server (commands/usec_per_call), il server che esegue il comando è il collo di bottiglia. |
Apri Trace ed esamina i comandi Redis negli intervalli lenti per identificare la query che causa il blocco. Sostituisci i comandi di blocco con quelli non bloccanti nel codice. Per scorrere i set di dati di grandi dimensioni in modo incrementale senza bloccare il
thread del server, utilizza |
L'applicazione segnala una latenza di base elevata e coerente per tutti i comandi Redis, anche quando il traffico è basso.
|
Il server Redis esegue i comandi istantaneamente, ma l'applicazione e l'istanza vengono implementate in regioni diverse (ad esempio, us-central1 e us-east1). Ogni pacchetto di rete deve attraversare l'infrastruttura cloud fisica di Google Cloud tra questi data center geografici. Ciò comporta una penalità di latenza tra regioni obbligatoria alla velocità della luce per ogni andata e ritorno. |
Per ridurre la latenza, implementa l'applicazione in modo che risieda nella stessa regione e zona dell'istanza. Per visualizzare la regione dell'applicazione e l'istanza, utilizza la Google Cloud console. |
Passaggi successivi
- Scopri di più sulle metriche lato client.
- Scopri di più sulle metriche lato client disponibili per Memorystore for Redis.