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à dei messaggi senza ACK meno recente 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 del backlog dei messaggi garantisce un'elaborazione dei messaggi tempestiva ed efficiente. Monitorando l'età del messaggio senza ACK meno recente, puoi identificare in modo proattivo le situazioni in cui i consumatori sono indietro. In questo modo è possibile intervenire tempestivamente per risolvere problemi potenziali legati a un peggioramento delle prestazioni.
Alcuni dei problemi comuni di arretrato 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 del sottoscrittore possono influire notevolmente 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ò generare conflitti e latenza elevata.
Limitazioni della quota: verifica di non aver superato le quote o le limitazioni Pub/Sub imposte dal 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 riconosce (nack) negativamente un messaggio, segnala 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 l'aggiunta di un messaggio non garantisce che il pull successivo recuperi un messaggio diverso. Il criterio di riconsegna di Pub/Sub potrebbe continuare a recapitare i messaggi nascosti 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 verificano problemi di backlog e duplicazioni dei recapiti.
Latenza di distribuzione elevata
La latenza di consegna in Pub/Sub è il tempo impiegato da 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 sempre una bassa latenza, mantieni più connessioni StreamingPull aperte per la tua sottoscrizione. 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 in streaming attive. Usa questa impostazione per assicurarti di disporre sempre di un numero sufficiente di stream per gestire i messaggi in arrivo.
Per i client che utilizzano il pull unario, per ottenere sempre una bassa latenza, mantieni più richieste di pull in sospeso verso la tua sottoscrizione. 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 bassa latenza con un sovraccarico operativo e un costo di elaborazione minimi. Per impostazione predefinita, la libreria client di alto livello utilizza l'API StreamingPull, che 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
Vedi Problemi di configurazione del client.
Backlog alto
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.
Ordine delle chiavi 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 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 esattamente una volta sono assolutamente essenziali per la tua applicazione. Se la tua priorità principale è una bassa latenza, ridurre al minimo l'uso di queste funzionalità potrebbe aiutare a ridurre i ritardi nell'elaborazione dei messaggi.
Aumento delle dimensioni dei messaggi
Un improvviso aumento delle dimensioni dei messaggi potrebbe 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 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ù consumer
In Pub/Sub, i messaggi potrebbero essere distribuiti in modo non uniforme tra i consumer. 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 consumer potrebbe essere qualcuno che utilizza il pull nella console Google Cloud o in Google Cloud CLI oppure esegue in locale un sottoscrittore personalizzato per controllare i messaggi.
Per i client pull unari, potresti notare che alcune richieste di pull non restituiscono messaggi. Come discusso nella sezione relativa al numero insufficiente di sottoscrittori, consigliamo di mantenere più richieste di pull in sospeso poiché alcune richieste potrebbero restituire un numero inferiore al numero massimo di messaggi configurato o addirittura zero messaggi.
Se sospetti uno di questi comportamenti, verifica se ci sono più consumatori contemporaneamente collegati all'abbonamento e controllali.
Filtra in base all'abbonamento
Verifica 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, verifica che il campo returnImmediately sia 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 possono confermare i messaggi entro la scadenza di conferma. In questo modo i messaggi vengono recapitati nuovamente, creando l'impressione di duplicati. Puoi misurare la frequenza con cui gli abbonati non rispettano la scadenza per l'acknowledgement utilizzando la metrica subscription/expired_ack_deadlines_count. Scopri di più su come monitorare la scadenza della conferma.
Per ridurre la percentuale 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 di conferma.
Se il pull dei messaggi nel sottoscrittore viene eseguito più velocemente di quanto sia possibile elaborare e accettare il messaggio, alcuni potrebbero scadere e richiedere estensioni di 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 iscritti duplicati, aggravando il backlog. Duplicati in scadenza, quindi genera nuovi duplicati.
Per evitare di sovraccaricare il sottoscrittore, riduci il numero di messaggi di cui il sottoscrittore esegue il pull alla volta. 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 regolare il limite massimo di messaggi in sospeso in base alla velocità effettiva e alla capacità del sottoscrittore. Tieni presente che ogni applicazione elabora i messaggi in modo diverso e impiega un tempo diverso per l'acknowledgement di un messaggio.
Forzare i nuovi tentativi
Per forzare Pub/Sub a riprovare 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. Ciò avviene per preservare l'ordine della sequenza. Tuttavia, non esistono regole garantisce che i messaggi dipendenti vengano inviati solo dopo l'applicazione 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 pubblicazione 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 distribuzione end-to-end.
Anziché utilizzare la metrica della latenza delle richieste, utilizza il punteggio di integrità della latenza di pubblicazione per verificare quali fattori stanno contribuendo a un aumento della latenza di distribuzione 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 presentano errori. Pertanto, anche se L'API StreamingPull potrebbe avere un tasso di errore sorprendente del 100%, questo comportamento la progettazione.
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 sono presenti messaggi nella backlog di abbonamenti criptati con una chiave Cloud KMS disabilitata. A riprendere il pull e ripristinare l'accesso alla chiave.
Gli errori di non disponibilità possono verificarsi quando Pub/Sub non è in grado di elaborare una richiesta. Molto probabilmente si tratta di una condizione temporanea e il client nella libreria fa un nuovo tentativo con le richieste. Non è necessario alcun intervento da parte tua se utilizzi una libreria client.
Gli errori Non trovato possono verificarsi quando l'abbonamento viene eliminato o se non viene mai esistevano in primo luogo. L'ultimo caso si verifica se hai fornito un percorso di abbonamento non valido.