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 efficacemente l'abbonamento Pub/Sub, ti consigliamo di esaminare prima il punteggio integrità latenza di pubblicazione (subscription/delivery_latency_health_score) per verificare quali fattori possono contribuire a una latenza inaspettata o aumentata.
L'età del messaggio senza ACK più vecchio continua ad aumentare
oldest_unacked_message_age è una metrica fondamentale per il monitoraggio dell'integrità delle iscrizioni Pub/Sub. Misura l'età, in secondi, del messaggio meno recente nel backlog di una sottoscrizione che non è stato ancora confermato da un sottoscrittore. Questa metrica offre informazioni preziose su potenziali ritardi o colli di bottiglia nell'elaborazione.
Il monitoraggio della coda 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 stanno rimanendo indietro. Questa pratica consente un intervento precoce per risolvere potenziali problemi relativi al calo delle prestazioni.
Alcuni dei problemi comuni del 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 stanno tenendo il passo con il volume dei messaggi. In questo caso, concentrati sui componenti degli abbonati:
Integrità del client: analizza l'utilizzo delle risorse sulle macchine che ospitano i client degli abbonati, ad esempio 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 ed esamina i log degli errori. Bug o inefficienze nel codice degli abbonati 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 latenze elevate.
Limitazioni delle quote: 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, controlla le quote delle risorse di Compute Engine o GKE per evitare potenziali colli di bottiglia.
L'abbonato ha confermato negativamente i messaggi
Quando un sottoscrittore non conferma un messaggio (nack), indica a Pub/Sub che non è stato possibile elaborare il messaggio. Pub/Sub tenta quindi di recapitare lo stesso messaggio. I nack ripetuti per un messaggio generano duplicati e potenzialmente un ritardo elevato nella consegna del messaggio.
Tieni presente che il nack di un messaggio non garantisce che il successivo pull recuperi un messaggio diverso. Il criterio di reinvio di Pub/Sub potrebbe continuare a recapitare i messaggi non incapsulati 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 ritiro esponenziale, per eseguire il ritiro dei singoli messaggi che potrebbero essere elaborati in un secondo momento, ma che richiedono un po' più di tempo prima del nuovo invio.
Se devi saltare intenzionalmente determinati messaggi, l'approccio consigliato è di inviare l'acknowledgement, anche se non li elaborerai. In questo modo vengono rimossi dall'abbonamento, si evitano reimportazioni non necessarie e si riduce il consumo di risorse. Se non confermi i messaggi, intenzionalmente o meno, si creano problemi di backlog e recapiti duplicati.
Latenza di pubblicazione elevata
La latenza di recapito in Pub/Sub è il tempo necessario a un messaggio di un publisher per raggiungere un sottoscrittore. Alcune possibili cause di una latenza di invio elevata sono descritte nelle sezioni successive.
Iscritti insufficienti
Per i client che utilizzano StreamingPull, per ottenere una latenza costantemente bassa, mantieni aperte più connessioni StreamingPull al tuo abbonamento. Senza connessioni degli abbonati attive, Pub/Sub non può consegnare i messaggi tempestivamente. Un singolo stream potrebbe essere un punto di rottura singolo, 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 stream sufficienti 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 attesa per il tuo abbonamento. Le richieste infrequenti potrebbero accumulare messaggi nella coda e aumentare la latenza. Questo approccio contribuisce a ridurre al minimo le lacune nella connettività e a migliorare la latenza di caricamento.
La libreria client di alto livello è consigliata nei casi in cui sono richieste velocità effettive elevate e latenza ridotta 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 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à importanti, ma richiedono un coordinamento aggiuntivo all'interno di Pub/Sub per garantire la consegna corretta. 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 errori. Se l'ordinamento è abilitato, i messaggi con una chiave di ordinamento non possono essere recapitati finché non viene inviato l'ACK per quelli precedenti con la stessa chiave di ordinamento.
Valuta se l'ordinamento dei messaggi o la consegna esattamente una volta sono assolutamente essenziali per la tua applicazione. Se la latenza ridotta è la tua priorità principale, 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 lato client.
Se noti un aumento della latenza di recapito, puoi controllare le dimensioni dei messaggi utilizzando la metrica topic/message_sizes, raggruppando per topic_id. Correla eventuali picchi di 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 il fattore che contribuisce al 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. Questo comportamento si verifica perché Pub/Sub distribuisce i messaggi tra i consumatori attivi per motivi di efficienza. A volte, un singolo consumatore potrebbe ricevere meno messaggi del previsto o un sottoinsieme di messaggi diverso da quello di altri consumatori.
Tieni presente che i messaggi potrebbero essere già in sospeso per i clienti e che un backlog di messaggi non confermati non significa necessariamente che li riceverai nella prossima richiesta pull. Tieni presente che un consumatore potrebbe essere un utente che utilizza il pull nella console Google Cloud o in Google Cloud CLI oppure che esegue un abbonato personalizzato localmente per controllare i messaggi.
Per i client pull unari, potresti notare che alcune richieste di pull non restituiscono messaggi. Come discusso nella sezione Non sono stati sottoscritti abbastanza abbonamenti, è consigliabile mantenere più richieste pull in attesa, poiché alcune richieste potrebbero restituire meno del numero massimo di messaggi configurati o addirittura zero messaggi.
Se sospetti uno di questi comportamenti, controlla se sono presenti più consumatori contemporaneamente collegati all'abbonamento e ispezionali.
Filtra 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 relative al backlog.
Utilizzare l'opzione returnImmediately
Se il client utilizza il pull unario, controlla se il campo returnImmediately è impostato su true. Si tratta di un campo deprecato che indica al servizio Pub/Sub di rispondere immediatamente alla richiesta pull anche se non restituisce messaggi. Ciò può comportare il ritorno di richieste pull con 0 messaggi anche quando è presente un backlog.
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 conseguenza, i messaggi vengono recapitati di nuovo, creando l'impressione di duplicati. Puoi misurare la frequenza con cui gli abbonati non rispettano la scadenza per l'acknowledgment 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 per la scadenza massima dell'estensione che puoi configurare.
- Se stai creando la tua libreria client, utilizza il metodo
modifyAckDeadlineper estendere la scadenza per l'acknowledgment.
Se i messaggi vengono estratti dall'abbonato più velocemente di quanto possano essere elaborati e confermati, alcuni potrebbero scadere e richiedere l'estensione della scadenza. Tuttavia, se l'abbonato continua a non riuscire a completare la procedura, le estensioni ripetute della scadenza alla fine non vanno a buon fine. Nel peggiore dei casi, questo può portare a un numero eccessivo di iscritti duplicati, aggravando il backlog. I duplicati in scadenza generano nuovi duplicati.
Per evitare di sovraccaricare l'abbonato, riduci il numero di messaggi che l'abbonato estrae contemporaneamente. In questo modo, l'abbonato ha meno messaggi da elaborare entro la scadenza. Meno messaggi scadono e meno messaggi vengono recapitati di nuovo.
Per ridurre il numero di messaggi che l'abbonato estrae contemporaneamente, devi ridurre il numero massimo di messaggi in attesa impostato nella configurazione del controllo flusso dell'abbonato. Non esiste un valore universale, quindi devi modificare il limite massimo di messaggi in attesa in base alla tua 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 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ò avviene per preservare l'ordine della sequenza. Tuttavia, non esiste alcuna garanzia rigorosa che i messaggi dipendenti vengano inviati solo dopo l'hacking riuscito dei messaggi precedenti nella sequenza.
L'abbonato sta ignorando i messaggi
Vedi L'abbonato sta ignorando i messaggi.
Risoluzione dei problemi relativi a un abbonamento StreamingPull
Relazione tra la metrica della latenza della richiesta e la latenza di invio 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 caricamento end-to-end.
Anziché utilizzare la metrica della latenza della richiesta, utilizza il punteggio di integrità della latenza di pubblicazione per verificare quali fattori contribuiscono all'aumento della latenza di pubblicazione end-to-end.
Le connessioni StreamingPull si chiudono con uno stato non OK
Gli stream StreamingPull si chiudono sempre con uno stato non OK. A differenza di uno stato di errore per le RPC univoche, questo stato per StreamingPull è solo un'indicazione che lo stream è disconnesso. Le richieste non generano errori. 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 piuttosto sulla metrica Risposta StreamingPull
subscription/streaming_pull_response_count,
raggruppata per response_code o response_class.
Cerca questi errori:
Gli errori di precondizione non riuscita possono verificarsi se nel backlog delle iscrizioni sono presenti messaggi criptati con una chiave Cloud KMS disattivata. Per riprendere il recupero, ripristina l'accesso alla chiave.
Gli errori di disponibilità possono verificarsi quando Pub/Sub non è in grado di elaborare una richiesta. Molto probabilmente si tratta di una condizione transitoria e la libreria del client ritenta le richieste. Non è necessario alcun intervento da parte tua se utilizzi una libreria client.
Gli errori di mancata corrispondenza possono verificarsi quando l'abbonamento viene eliminato o se non è mai stato creato. L'ultimo caso si verifica se hai fornito un percorso di abbonamento non valido.