Questo documento fornisce alcuni suggerimenti comuni per la risoluzione dei problemi relativi alle sottoscrizioni pull di Pub/Sub. Scopri di più sulle sottoscrizioni pull nella Guida per sottoscrittori pull.
Per monitorare in modo efficace la sottoscrizione Pub/Sub, ti consigliamo di esaminare prima il punteggio di integrità della latenza di consegna (subscription/delivery_latency_health_score) per verificare quali fattori possono contribuire a una latenza imprevista o maggiore.
L'età del messaggio senza ACK più vecchio continua ad aumentare
Il oldest_unacked_message_age è una metrica fondamentale per monitorare l'integrità delle sottoscrizioni Pub/Sub. Misura l'età, in secondi, del messaggio meno recente nel backlog di una sottoscrizione che non è ancora stato confermato (ACK) da un sottoscrittore. Questa metrica offre informazioni preziose su potenziali ritardi o colli di bottiglia nell'elaborazione.
Il monitoraggio del backlog dei messaggi garantisce un'elaborazione tempestiva ed efficiente dei messaggi. Monitorando l'età del messaggio senza ACK meno recente, puoi identificare in modo proattivo le situazioni in cui i consumatori sono in ritardo. Questa pratica consente un intervento precoce per risolvere potenziali problemi relativi al peggioramento del rendimento.
Di seguito sono riportati alcuni problemi comuni relativi al backlog che puoi esaminare:
Problemi di configurazione del client
Se le metriche oldest_unacked_message_age e num_undelivered_messages aumentano contemporaneamente, potrebbe significare che i sottoscrittori non riescono a tenere il passo con il volume dei messaggi. In questa situazione, concentra la tua indagine sui componenti del sottoscrittore:
Integrità del client: analizza l'utilizzo delle risorse sulle macchine che ospitano i client sottoscrittori, come CPU, memoria e larghezza di banda di rete. Cerca i punti di pressione che potrebbero ostacolare l'efficienza dell'elaborazione.
Codice client: esamina le modifiche recenti al codice e i log degli errori. Bug o inefficienze nel codice del sottoscrittore possono influire in modo significativo sulle velocità di elaborazione dei messaggi. Tieni presente che potrebbero esserci problemi in messaggi specifici. Ad esempio, più messaggi potrebbero dover accedere contemporaneamente alla stessa riga di un database. Questo comportamento può causare conflitti e latenza elevata.
Limitazioni delle quote: verifica di non aver superato le quote o le limitazioni di Pub/Sub imposte dal tuo servizio di hosting. Se i sottoscrittori sono ospitati in Google Cloud, esamina le quote delle risorse di Compute Engine o GKE per evitare potenziali colli di bottiglia.
Il sottoscrittore ha confermato negativamente i messaggi
Quando un sottoscrittore conferma negativamente (NACK) un messaggio, indica a Pub/Sub che il messaggio non è stato elaborato correttamente. Pub/Sub tenta quindi di riconsegnare lo stesso messaggio. I NACK ripetuti per un messaggio comportano la creazione di duplicati e potenzialmente un ritardo elevato nella consegna dei messaggi.
Tieni presente che l'invio di un NACK per un messaggio non garantisce che il pull successivo recuperi un messaggio diverso. Il criterio di riconsegna di Pub/Sub potrebbe continuare a riconsegnare i messaggi con NACK prima di quelli nuovi. Pertanto, non fare affidamento sui NACK come metodo per filtrare o saltare messaggi specifici. Imposta invece un criterio di ripetizione, preferibilmente un backoff esponenziale, per eseguire il backoff dei singoli messaggi che probabilmente saranno elaborabili in un secondo momento, ma che richiedono un po' più di tempo prima della riconsegna.
Se devi saltare intenzionalmente determinati messaggi, l'approccio consigliato è quello di confermarli, anche se non li elaborerai. In questo modo, vengono rimossi dalla sottoscrizione, si evitano riconsegne non necessarie e si riduce il consumo di risorse. Se i messaggi non vengono confermati, intenzionalmente o meno, si verificano problemi di backlog e consegne duplicate.
Latenza di consegna elevata
La latenza di consegna in Pub/Sub è il tempo necessario affinché un messaggio di un publisher raggiunga un sottoscrittore. Nelle sezioni successive vengono descritte alcune possibili cause di una latenza di consegna elevata.
Numero insufficiente di sottoscrittori
Per i client che utilizzano StreamingPull, per ottenere una latenza costantemente bassa, mantieni più connessioni StreamingPull aperte alla sottoscrizione. Senza connessioni sottoscrittori attive, Pub/Sub non può consegnare i messaggi tempestivamente. Un singolo stream potrebbe essere un singolo punto di errore, aumentando il rischio di ritardi. La metrica subscription/open_streaming_pulls fornisce visibilità sul numero di connessioni di streaming attive. Utilizzala per assicurarti di avere sempre stream sufficienti per gestire i messaggi in entrata.
Per i client che utilizzano il pull unario, per ottenere una latenza costantemente bassa, mantieni più richieste di pull in sospeso alla sottoscrizione. Le richieste poco frequenti potrebbero potenzialmente accumulare messaggi nel backlog e aumentare la latenza. Questo approccio aiuta a ridurre al minimo le interruzioni della connettività e a migliorare la latenza di consegna.
La libreria client di alto livello è consigliata nei casi in cui sono necessari throughput elevato e latenza bassa con un sovraccarico operativo e un costo di elaborazione minimi. Per impostazione predefinita, la libreria client di alto livello utilizza l'API StreamingPull, in quanto tende a essere una scelta migliore per ridurre al minimo la latenza. Le librerie client di alto livello contengono funzioni e classi predefinite che gestiscono le chiamate API sottostanti per l'autenticazione, l'ottimizzazione del throughput e della latenza, la formattazione dei messaggi e altre funzionalità.
Problemi di configurazione del client
Consulta la sezione Problemi di configurazione del client.
Backlog elevato
Tieni presente che un backlog di messaggi senza ACK in una sottoscrizione Pub/Sub aumenta intrinsecamente la latenza end-to-end perché i messaggi non vengono elaborati immediatamente dai sottoscrittori.
Chiavi di ordinamento e consegna "exactly-once"
Le chiavi di ordinamento e la consegna "exactly-once" sono funzionalità utili, ma richiedono una coordinazione aggiuntiva all'interno di Pub/Sub per garantire la consegna corretta. Questa coordinazione può ridurre la disponibilità e aumentare la latenza. Sebbene la differenza sia minima nello stato stazionario, eventuali passaggi di coordinamento necessari potrebbero comportare aumenti temporanei della latenza o un aumento della percentuale di errori. Se l'ordinamento è abilitato, i messaggi con una chiave di ordinamento non possono essere consegnati finché quelli precedenti con la stessa chiave di ordinamento non vengono confermati.
Valuta se l'ordinamento dei messaggi o la consegna "exactly-once" sono assolutamente essenziali per la tua applicazione. Se la priorità è la latenza bassa, ridurre al minimo l'utilizzo di queste funzionalità potrebbe contribuire a ridurre i ritardi nell'elaborazione dei messaggi.
Aumento delle dimensioni dei messaggi
Un aumento improvviso delle dimensioni dei messaggi potrebbe potenzialmente aumentare il tempo di trasferimento tra Pub/Sub e il client e rallentare il tempo di elaborazione dei messaggi sul lato client.
Se noti un aumento della latenza di consegna, puoi controllare le dimensioni dei messaggi utilizzando la topic/message_sizes metrica, raggruppando per topic_id. Correlare eventuali picchi nelle dimensioni dei messaggi con i problemi di rendimento osservati.
Messaggi mancanti
Se sospetti che i messaggi non vengano consegnati correttamente al tuo sottoscrittore, uno dei seguenti motivi potrebbe essere il fattore che contribuisce a questo problema.
Distribuzione dei messaggi nelle sottoscrizioni Pub/Sub con più consumatori
In Pub/Sub, i messaggi potrebbero essere distribuiti in modo non uniforme tra i consumatori della stessa sottoscrizione. Pub/Sub esegue il bilanciamento del carico dei messaggi su tutti i client attivi, ma l'obiettivo principale è massimizzare il throughput complessivo di elaborazione dei messaggi e ridurre al minimo il backlog, anziché garantire una distribuzione perfettamente uniforme. Il sistema indirizza dinamicamente più messaggi ai consumatori che dimostrano una capacità maggiore, ovvero quelli che confermano rapidamente i messaggi e non sono vincolati dalle impostazioni di controllo del flusso. I consumatori che elaborano i messaggi a velocità diverse o che operano in condizioni diverse (ad es. disponibilità delle risorse, latenza di rete) gestiranno probabilmente volumi di messaggi diversi. In genere, i consumatori più veloci e reattivi riceveranno ed elaboreranno una quota maggiore del carico di messaggi.
Questo metodo di distribuzione tra più consumatori significa che l'ordine in cui i messaggi vengono ricevuti ed elaborati può variare. Di conseguenza, a meno che l'ordinamento dei messaggi non sia abilitato per la sottoscrizione e i publisher non includano le chiavi di ordinamento, non è garantito che i messaggi vengano elaborati dai consumatori nell'ordine in cui sono stati pubblicati.
Tieni presente che i messaggi potrebbero essere già in sospeso per i client e che un backlog di messaggi non confermati non significa necessariamente che riceverai questi messaggi nella prossima richiesta di pull. Tieni presente che un consumatore potrebbe essere una persona che utilizza il pull nella Google Cloud console o in Google Cloud CLI oppure che esegue un sottoscrittore personalizzato in locale per controllare i messaggi.
Per i client pull unari, potresti notare che alcune richieste di pull restituiscono zero messaggi. Come discusso nella sezione Numero insufficiente di sottoscrittori, ti consigliamo di mantenere più richieste di pull in sospeso, in quanto alcune richieste potrebbero restituire un numero di messaggi inferiore al numero massimo configurato o anche zero messaggi, anche se esiste un backlog. Questo perché altri consumatori potrebbero avere lease sui messaggi disponibili.
Se un consumatore non conferma un messaggio entro la scadenza di conferma o se lo conferma negativamente (NACK), Pub/Sub tenterà di riconsegnarlo. Questo tentativo di riconsegna può essere effettuato a qualsiasi consumatore attivo nella sottoscrizione, non necessariamente a quello che lo ha ricevuto inizialmente. Pertanto, un ID messaggio specifico potrebbe essere consegnato e la sua elaborazione tentata da più consumatori diversi connessi alla sottoscrizione durante il suo ciclo di vita finché uno di essi non lo conferma correttamente.
Se sospetti comportamenti di distribuzione dei messaggi imprevisti, verifica se sono presenti più consumatori collegati contemporaneamente alla sottoscrizione ed esamina le metriche e le configurazioni di rendimento individuali.
Filtro sulla sottoscrizione
Verifica se alla sottoscrizione è associato un filtro. In caso affermativo, riceverai solo i messaggi che corrispondono al filtro. Il servizio Pub/Sub riconosce automaticamente i messaggi che non corrispondono al filtro. Considera l'impatto dei filtri sulle metriche del backlog.
Utilizzo dell'opzione returnImmediately
Se il client utilizza il pull unario, verifica se il returnImmediately campo è impostato su true. Questo è un campo ritirato che indica al servizio Pub/Sub di rispondere immediatamente alla richiesta di pull anche se restituisce zero messaggi. Di conseguenza, le richieste di pull potrebbero restituire 0 messaggi anche se esiste un backlog.
Problemi di configurazione del client
Se utilizzi la libreria client Java e inizializzi il sottoscrittore
con un canale gRPC personalizzato utilizzando il
setChannelProvider()
metodo, devi assicurarti che l'impostazione maxInboundMessageSize sia di almeno
20 MB (corrispondente al valore
predefinito della libreria)
quando crei TransportChannelProvider. Quando questo valore è inferiore a 10 MB, i messaggi di dimensioni superiori a maxInboundMessageSize non vengono ricevuti correttamente. Alcuni metodi comuni per configurare questa impostazione sono
InstantiatingGrpcChannelProvider.Builder.setMaxInboundMessageSize()
e
ManagedChannelBuilder.maxInboundMessageSize().
Gestire i duplicati
La duplicazione dei messaggi in Pub/Sub si verifica spesso quando i sottoscrittori non riescono a confermare i messaggi entro la scadenza di conferma. Di conseguenza, i messaggi vengono riconsegnati, creando l'impressione di duplicati. Puoi misurare la frequenza con cui i sottoscrittori non rispettano la scadenza di conferma utilizzando la metrica subscription/expired_ack_deadlines_count. Scopri di più su come monitorare la scadenza della scadenza di conferma.
Per ridurre la frequenza di duplicazione, estendi le scadenze dei messaggi.
- Le librerie client gestiscono automaticamente l'estensione della scadenza, ma esistono limiti predefiniti alla scadenza massima di estensione che puoi configurare.
- Se stai creando la tua libreria client, utilizza il
modifyAckDeadlinemetodo per estendere la scadenza di conferma.
Se i messaggi vengono recuperati nel sottoscrittore più velocemente di quanto possano essere elaborati e confermati, alcuni messaggi potrebbero scadere e richiedere estensioni della scadenza. Tuttavia, se il sottoscrittore rimane sovraccarico, le estensioni ripetute della scadenza alla fine non vanno a buon fine. Nel peggiore dei casi, questo può portare a un sovraccarico di duplicati nel sottoscrittore, esacerbando il backlog. I duplicati in scadenza generano quindi nuovi duplicati.
Per evitare di sovraccaricare il sottoscrittore, riduci il numero di messaggi che il sottoscrittore recupera alla volta. In questo modo, il sottoscrittore ha meno messaggi da elaborare entro la scadenza. Meno messaggi scadono e meno messaggi vengono riconsegnati.
Per ridurre il numero di messaggi che il sottoscrittore recupera alla volta, devi ridurre l'impostazione del numero massimo di messaggi in sospeso nella configurazione del controllo del flusso del sottoscrittore. Non esiste un valore universale, quindi devi modificare il limite massimo di messaggi in sospeso in base al throughput e alla capacità del sottoscrittore. Tieni presente che ogni applicazione elabora i messaggi in modo diverso e impiega una quantità di tempo diversa per confermare un messaggio.
Forzare i nuovi tentativi
Per forzare Pub/Sub a riprovare a inviare un messaggio, invia una richiesta nack. Se non utilizzi le librerie client di alto livello, invia una richiesta modifyAckDeadline con ackDeadlineSeconds impostato su 0.
Chiavi di ordinamento
Quando Pub/Sub riconsegna un messaggio con una chiave di ordinamento, riconsegna anche tutti i messaggi successivi con la stessa chiave di ordinamento, anche se sono stati confermati in precedenza. Questa operazione viene eseguita per mantenere l'ordine della sequenza. Tuttavia, non esiste una garanzia rigorosa che i messaggi dipendenti vengano inviati solo dopo la conferma corretta dei messaggi precedenti nella sequenza.
Il sottoscrittore sta inviando NACK per i messaggi
Consulta la sezione Il sottoscrittore sta inviando NACK per i messaggi.
Risolvere i problemi relativi a una sottoscrizione StreamingPull
Relazione tra la metrica della latenza delle richieste e la latenza di consegna end-to-end
Per StreamingPull, la metrica serviceruntime.googleapis.com/api/request_latencies rappresenta il tempo per cui lo stream è aperto. La metrica non è utile per determinare la latenza di consegna end-to-end.
Anziché utilizzare la metrica della latenza delle richieste, utilizza il punteggio di integrità della latenza di consegna per verificare quali fattori contribuiscono a un aumento della latenza di consegna end-to-end.
Le connessioni StreamingPull si chiudono con uno stato diverso da OK
Gli stream StreamingPull si chiudono sempre con uno stato diverso da OK. A differenza di uno stato di errore per gli RPC unari, questo stato per StreamingPull indica solo che lo stream è disconnesso. Le richieste non vanno a buon fine. Pertanto, anche se l'API StreamingPull potrebbe avere una percentuale di errori sorprendente del 100%, questo comportamento è previsto.
Poiché gli stream StreamingPull si chiudono sempre con un errore, non è utile esaminare le metriche di terminazione degli stream durante la diagnosi degli errori. Concentrati invece su
la metrica di risposta StreamingPull
subscription/streaming_pull_response_count,
raggruppata per response_code o response_class.
Cerca questi errori:
Gli errori Failed precondition (Condizione preliminare non soddisfatta) possono verificarsi se nel backlog della sottoscrizione sono presenti messaggi criptati con una chiave Cloud KMS disattivata. Per riprendere il pull, ripristina l'accesso alla chiave.
Gli errori Unavailable (Non disponibile) possono verificarsi quando Pub/Sub non è in grado di elaborare una richiesta. Si tratta molto probabilmente di una condizione temporanea e la libreria client riprova a inviare le richieste. Se utilizzi una libreria client, non è necessario alcun intervento da parte tua.
Gli errori Not found (Non trovato) possono verificarsi quando la sottoscrizione viene eliminata o se non è mai esistita. Quest'ultimo caso si verifica se hai fornito un percorso di sottoscrizione non valido.