Questo documento fornisce alcuni suggerimenti comuni per la risoluzione dei problemi relativi alle sottoscrizioni pull Pub/Sub. Scopri di più sulle sottoscrizioni al pull nella Guida per abbonato pull.
Per monitorare in modo efficace l'abbonamento Pub/Sub, ti consigliamo di esaminare innanzitutto il punteggio integrità latenza di pubblicazione (subscription/delivery_latency_health_score) per verificare quali fattori possono contribuire a una latenza imprevista o aumentata.
L'età del messaggio senza ACK più vecchio continua ad aumentare
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 tempestivo per risolvere potenziali problemi relativi al peggioramento delle prestazioni.
Alcuni dei problemi comuni di backlog che puoi esaminare includono:
Problemi di configurazione del client
Quando le metriche oldest_unacked_message_age e num_undelivered_messages aumentano contemporaneamente, potrebbe significare che gli abbonati non riescono a tenere il passo con il volume dei messaggi. In questo caso, concentra l'indagine sui componenti degli abbonati:
Stato del client: analizza l'utilizzo delle risorse sulle macchine che ospitano i client abbonati, come CPU, memoria e larghezza di banda di rete. Cerca punti di pressione che potrebbero ostacolare l'efficienza di elaborazione.
Codice client: rivedi le modifiche recenti al codice ed esamina i log degli errori. Bug o inefficienze nel codice dell'abbonato possono influire notevolmente sulle percentuali 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 contese e latenza elevata.
Limitazioni di quota: verifica di non aver superato le quote o le limitazioni di Pub/Sub imposte dal tuo servizio di hosting. Se gli abbonati sono ospitati in Google Cloud, rivedi le quote delle risorse di Compute Engine o GKE per evitare potenziali colli di bottiglia.
L'abbonato ha risposto negativamente ai messaggi
Quando un abbonato invia un riconoscimento negativo (NACK) di 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 del messaggio.
Tieni presente che l'invio di un NACK per un messaggio non garantisce che il pull successivo recuperi un messaggio diverso. Il criterio di ripetizione di Pub/Sub potrebbe continuare a ripetere la distribuzione dei messaggi con NACK prima di quelli nuovi. Pertanto, non fare affidamento sugli NACK come metodo di filtro o per ignorare messaggi specifici. Imposta invece un criterio di ripetizione, preferibilmente un backoff esponenziale, per ritardare l'elaborazione dei singoli messaggi che probabilmente saranno elaborabili in un secondo momento, ma che richiedono un po' di tempo in più prima della nuova consegna.
Se devi ignorare intenzionalmente determinati messaggi, l'approccio consigliato è di confermarli, anche se non li elaborerai. In questo modo, vengono rimossi dall'abbonamento, si evitano riinvii non necessari e si riduce il consumo di risorse. Lasciare i messaggi non confermati, intenzionalmente o meno, crea problemi di backlog e consegne duplicate.
Latenza di pubblicazione elevata
La latenza di consegna in Pub/Sub è il tempo necessario a un messaggio di un publisher per raggiungere un sottoscrittore. Alcune possibili cause di una latenza di pubblicazione elevata sono descritte nelle sezioni successive.
Numero insufficiente di iscritti
Per i client che utilizzano StreamingPull, per ottenere una latenza costantemente bassa, mantieni aperte più connessioni StreamingPull al tuo abbonamento. Senza connessioni attive degli abbonati, Pub/Sub non può recapitare i messaggi tempestivamente. Un singolo flusso potrebbe essere un single point of failure, aumentando il rischio di ritardi. La metrica subscription/open_streaming_pulls fornisce visibilità sul numero di connessioni di streaming attive. Utilizzalo per assicurarti di avere sempre un numero sufficiente di stream per gestire i messaggi in arrivo.
Per i client che utilizzano il pull unario, per ottenere una latenza costantemente bassa, mantieni più richieste di pull in sospeso per l'abbonamento. Le richieste poco frequenti potrebbero potenzialmente accumulare messaggi nel backlog e aumentare la latenza. Questo approccio contribuisce a ridurre al minimo le interruzioni della connettività e a migliorare la latenza di distribuzione.
La libreria client di alto livello è consigliata per i casi in cui sono richieste velocità effettiva elevata e bassa latenza con sovraccarico operativo e costi 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 della velocità effettiva 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 non confermati in un abbonamento Pub/Sub aumenta intrinsecamente la latenza end-to-end perché i messaggi non vengono elaborati immediatamente dagli abbonati.
Chiavi di ordinamento e consegna "exactly-once"
Le chiavi di ordinamento e la consegna exactly-once sono funzionalità utili, ma richiedono un coordinamento aggiuntivo all'interno di Pub/Sub per garantire la corretta consegna. Questo coordinamento può ridurre la disponibilità e aumentare la latenza. Sebbene la differenza sia minima in stato stazionario, eventuali passaggi di coordinamento necessari potrebbero comportare aumenti temporanei della latenza o un aumento del tasso di errore. Se l'ordinamento è abilitato, i messaggi con una chiave di ordinamento non possono essere recapitati finché quelli precedenti con la stessa chiave di ordinamento non vengono confermati.
Valuta se l'ordinamento dei messaggi o la consegna esatta sono assolutamente essenziali per la tua applicazione. Se la bassa latenza è la tua priorità assoluta, ridurre al minimo l'utilizzo di queste funzionalità potrebbe contribuire a ridurre i ritardi nell'elaborazione dei messaggi.
Aumento delle dimensioni del messaggio
Un aumento improvviso delle dimensioni del messaggio potrebbe potenzialmente aumentare il tempo di trasferimento tra Pub/Sub e il client e rallentare il tempo di elaborazione dei messaggi lato client.
Se noti un aumento della latenza di pubblicazione, puoi controllare le dimensioni dei messaggi utilizzando la metrica topic/message_sizes, raggruppando per topic_id. Correlare eventuali picchi nelle dimensioni dei messaggi con i problemi di prestazioni osservati.
Messaggi mancanti
Se sospetti che i messaggi non vengano recapitati correttamente al tuo abbonato, uno dei seguenti motivi potrebbe essere la causa.
Distribuzione dei messaggi nelle sottoscrizioni Pub/Sub con più consumer
In Pub/Sub, i messaggi potrebbero essere distribuiti in modo non uniforme tra i consumatori. Questo comportamento si verifica perché Pub/Sub distribuisce i messaggi tra i consumatori attivi per efficienza. A volte, un singolo consumatore potrebbe ricevere meno messaggi del previsto o un sottoinsieme diverso di messaggi rispetto ad altri consumatori.
Tieni presente che i messaggi potrebbero essere già in sospeso per i clienti e che un backlog di messaggi non riconosciuti non significa necessariamente che li riceverai nella prossima richiesta di pull. Tieni presente che un consumer può essere una persona che utilizza pull nella console Google Cloud o in Google Cloud CLI oppure che esegue un abbonato personalizzato in locale per controllare i messaggi.
Per i client Pull unari, potresti notare che alcune richieste di pull restituiscono zero messaggi. Come descritto nella sezione Non ci sono abbonati sufficienti, è consigliabile mantenere più richieste pull in sospeso, poiché alcune richieste potrebbero restituire un numero di messaggi inferiore al numero massimo configurato o anche zero messaggi.
Se sospetti uno di questi comportamenti, verifica se ci sono più consumatori collegati contemporaneamente all'abbonamento ed esaminali.
Filtrare in base all'abbonamento
Controlla se all'abbonamento è associato un filtro. In questo caso, riceverai solo i messaggi che corrispondono al filtro. Il servizio Pub/Sub riconosce automaticamente i messaggi che non corrispondono al filtro. Considera in che modo i filtri influiscono sulle metriche del backlog.
Utilizzare l'opzione returnImmediately
Se il client utilizza Pull unario, controlla se il campo returnImmediately è impostato su true. Si tratta di un campo ritirato che indica al servizio Pub/Sub di rispondere immediatamente alla richiesta pull anche se non restituisce messaggi. Di conseguenza, le richieste pull vengono restituite con 0 messaggi anche in presenza di un backlog.
Gestire i duplicati
La duplicazione dei messaggi in Pub/Sub si verifica spesso quando i sottoscrittori non riescono a confermare la ricezione dei messaggi entro la scadenza. In questo modo, i messaggi vengono ridistribuiti, creando l'impressione di duplicati. Puoi misurare la frequenza con cui gli abbonati non rispettano la scadenza di conferma utilizzando la metrica subscription/expired_ack_deadlines_count. Scopri di più su come monitorare la scadenza della conferma.
Per ridurre il tasso di duplicazione, estendi le scadenze dei messaggi.
- Le librerie client gestiscono automaticamente l'estensione della scadenza, ma esistono limiti predefiniti alla scadenza massima dell'estensione che puoi configurare.
- Se stai creando la tua libreria client, utilizza il metodo
modifyAckDeadlineper 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 l'abbonato continua a essere sopraffatto, le estensioni ripetute della scadenza alla fine non vanno a buon fine. Nel peggiore dei casi, questo può portare a un numero eccessivo di duplicati per un abbonato, esacerbando il backlog. I duplicati scadono e vengono generati nuovi duplicati.
Per evitare di sovraccaricare l'abbonato, riduci il numero di messaggi che recupera contemporaneamente. In questo modo, l'abbonato ha meno messaggi da elaborare entro la scadenza. Meno messaggi scadono e meno messaggi vengono inviati di nuovo.
Per ridurre il numero di messaggi recuperati dal sottoscrittore 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 alla velocità effettiva e alla capacità degli abbonati. Tieni presente che ogni applicazione elabora i messaggi in modo diverso e impiega un tempo diverso per confermare la ricezione di 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 un 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. Ciò consente di preservare l'ordine della sequenza. Tuttavia, non esiste una garanzia rigida che i messaggi dipendenti vengano inviati solo dopo l'ack riuscito dei messaggi precedenti nella sequenza.
Il sottoscrittore sta inviando NACK ai messaggi
Vedi L'abbonato non riceve i messaggi.
Risoluzione dei problemi relativi a un abbonamento 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 integrità latenza di pubblicazione per verificare quali fattori contribuiscono a una maggiore latenza di pubblicazione end-to-end.
Chiusura delle connessioni StreamingPull con uno stato non corretto
I flussi StreamingPull si chiudono sempre con uno stato non corretto. A differenza di uno stato di errore per le RPC unarie, questo stato per StreamingPull indica solo che lo stream è disconnesso. Le richieste non hanno esito negativo. Pertanto, anche se l'API StreamingPull potrebbe avere un tasso di errore sorprendente del 100%, questo comportamento è intenzionale.
Poiché gli stream StreamingPull si chiudono sempre con un errore, non è utile
esaminare le metriche di interruzione dello stream durante la diagnosi degli errori. Concentrati invece sulla metrica
Risposta StreamingPull
subscription/streaming_pull_response_count,
raggruppata per response_code o response_class.
Cerca questi errori:
Gli errori Failed precondition 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 di indisponibilità 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. Non è necessario alcun intervento da parte tua se utilizzi una libreria client.
Gli errori di tipo Not found possono verificarsi quando l'abbonamento viene eliminato o se non è mai esistito. Il secondo caso si verifica se hai fornito un percorso di abbonamento non valido.