Questo documento fornisce alcuni suggerimenti comuni per la risoluzione dei problemi relativi alle sottoscrizioni pull Pub/Sub. Scopri di più sulle sottoscrizioni pull nella guida per i sottoscrittori pull.
Per monitorare in modo efficace la tua sottoscrizione 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 è stato ancora 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 dei messaggi tempestiva ed efficiente. Monitorando l'età del messaggio senza ACK meno recente, puoi identificare in modo proattivo le situazioni in cui i consumer sono in ritardo. Questa pratica consente un intervento tempestivo per risolvere potenziali problemi relativi a un peggioramento delle prestazioni.
Alcuni dei problemi comuni relativi agli arretrati 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 iscritti non riescono a stare al passo con il volume dei messaggi. In questo caso, concentra l'indagine sui componenti del sottoscrittore:
Integrità del client: analizza l'utilizzo delle risorse sulle macchine che ospitano i client degli abbonati, 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 ed esamina i log degli errori. Bug o inefficienze nel codice del sottoscrittore possono influire in modo significativo sulle frequenze 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 invia una conferma negativa (nack) per un messaggio, segnala a Pub/Sub che il messaggio non è stato elaborato correttamente. Pub/Sub tenta quindi di inviare nuovamente lo stesso messaggio. Le conferme negative (NACK) ripetute per un messaggio generano 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. La policy di nuovo invio di Pub/Sub potrebbe continuare a inviare nuovamente i messaggi nack prima di quelli nuovi. Pertanto, non fare affidamento sui nack come metodo per filtrare o saltare messaggi specifici. Imposta invece una policy di ripetizione, preferibilmente un backoff esponenziale, per ritardare i singoli messaggi che probabilmente potranno 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 è confermarli, anche se non li elaborerai. In questo modo, i messaggi vengono rimossi dalla sottoscrizione, si evitano nuovi invii 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 distribuzione in Pub/Sub è il tempo necessario affinché un messaggio di un publisher raggiunga un sottoscrittore. Alcune possibili cause di una latenza di pubblicazione elevata sono descritte nelle sezioni successive.
Numero di iscritti insufficiente
Per i client che utilizzano StreamingPull, per ottenere una latenza costantemente bassa, mantieni più connessioni StreamingPull aperte alla tua sottoscrizione. Senza connessioni di sottoscrittori attive, Pub/Sub non può recapitare i messaggi tempestivamente. Un singolo stream 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. Utilizza questa opzione 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 la tua sottoscrizione. Le richieste non frequenti potrebbero 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 pubblicazione.
La libreria client di alto livello è consigliata per i casi in cui sono richiesti un throughput elevato e una bassa latenza con un overhead operativo e un costo di elaborazione minimi. Per impostazione predefinita, la libreria client di alto livello utilizza l'API StreamingPull, poiché 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 non confermati 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 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 nello stato stabile, 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é non viene inviato un ACK per i messaggi precedenti con la stessa chiave di ordinamento.
Valuta se l'ordinamento dei messaggi o la consegna exactly-once 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 dei messaggi
Un aumento improvviso delle dimensioni dei messaggi potrebbe aumentare il tempo di trasferimento tra Pub/Sub e il tuo client e rallentare il tempo di elaborazione dei messaggi sul lato client.
Se noti un aumento della latenza di distribuzione, 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 sottoscrittore, il motivo potrebbe essere uno dei seguenti.
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 della stessa sottoscrizione. Pub/Sub bilancia il carico dei messaggi tra tutti i client attivi, ma l'obiettivo principale è massimizzare il throughput complessivo dell'elaborazione dei messaggi e ridurre al minimo il backlog, anziché garantire una distribuzione perfettamente uniforme. Il sistema indirizza dinamicamente più messaggi ai consumer che dimostrano una maggiore capacità, ovvero quelli che confermano rapidamente i messaggi e non sono limitati dalle impostazioni di controllo del flusso. I consumer che elaborano i messaggi a velocità diverse o che operano in condizioni diverse (ad esempio, disponibilità delle risorse, latenza di rete) probabilmente gestiranno volumi di messaggi diversi. In genere, i consumer più veloci e reattivi ricevono ed elaborano una quota maggiore del carico di messaggi.
Questo metodo di distribuzione tra più consumer 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 chiavi di ordinamento, non è garantito che i messaggi vengano elaborati dai consumer nell'ordine in cui sono stati pubblicati.
Tieni presente che i messaggi potrebbero essere già in sospeso per i client e un backlog di messaggi non confermati non significa necessariamente che riceverai questi messaggi nella prossima richiesta di pull. Tieni presente che un consumer potrebbe essere un utente che utilizza la funzionalità di pull nella console Google Cloud o in Google Cloud CLI oppure che esegue un sottoscrittore personalizzato localmente per controllare i messaggi.
Per i client di pull unario, potresti notare che alcune richieste di pull non restituiscono messaggi. Come discusso nella sezione Numero di sottoscrittori insufficiente, è consigliabile mantenere più richieste di pull in sospeso, poiché alcune richieste potrebbero restituire un numero di messaggi inferiore al numero massimo configurato o addirittura zero messaggi, anche se esiste un backlog. Questo perché altri consumer potrebbero avere lease sui messaggi disponibili.
Se un consumer non conferma un messaggio entro la scadenza di conferma o se invia una conferma negativa (NACK) per il messaggio, Pub/Sub tenterà di inviarlo nuovamente. Questo tentativo di nuovo invio può essere effettuato a qualsiasi consumer attivo nell'abbonamento, non necessariamente a quello che lo ha ricevuto inizialmente. Pertanto, un determinato ID messaggio potrebbe essere recapitato a più consumer diversi connessi alla sottoscrizione nel corso della sua durata e la sua elaborazione potrebbe essere tentata da più consumer diversi, finché uno di questi non lo conferma correttamente.
Se sospetti comportamenti imprevisti nella distribuzione dei messaggi, verifica se sono presenti più consumer collegati contemporaneamente alla sottoscrizione e controlla le singole metriche sul rendimento e le configurazioni.
Filtra in base alla sottoscrizione
Controlla se alla sottoscrizione è 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 l'impatto dei filtri sulle metriche di backlog.
Utilizzo dell'opzione returnImmediately
Se il client utilizza il pull unario, controlla se il campo returnImmediately è impostato su true. Questo è un campo deprecato che indica al servizio Pub/Sub di rispondere immediatamente alla richiesta di pull, anche se non restituisce messaggi. Ciò può comportare la restituzione di richieste di pull con 0 messaggi anche in presenza di un backlog.
Problemi di configurazione del client
Se utilizzi la libreria client Java e inizializzi il sottoscrittore con un canale gRPC personalizzato utilizzando il metodo setChannelProvider(), devi assicurarti che l'impostazione maxInboundMessageSize sia di almeno 20 MB (corrispondente al valore predefinito della libreria ) quando crei il tuo TransportChannelProvider. Quando questo valore è inferiore a 10 MB, i messaggi di dimensioni superiori a maxInboundMessageSize non verranno ricevuti correttamente. Alcuni metodi comuni per configurare questa impostazione sono
InstantiatingGrpcChannelProvider.Builder.setMaxInboundMessageSize()
e
ManagedChannelBuilder.maxInboundMessageSize().
Gestire i duplicati
Un sottoscrittore potrebbe ricevere messaggi duplicati nei seguenti casi:
Ricaricamento. Un client ha inviato un acknowledgment negativo per un messaggio o la scadenza dell'acknowledgment è scaduta. Si tratta di un comportamento normale.
Consegna duplicata. Un messaggio viene inviato nuovamente dopo una conferma riuscita o prima della scadenza della conferma. Le sottoscrizioni con la consegna "exactly-once" abilitata non ricevono consegne duplicate.
Messaggi duplicati dal publisher. Il publisher invia un messaggio due volte a causa della logica dell'applicazione del publisher. Il servizio Pub/Sub li tratta come messaggi Pub/Sub distinti e assegna loro ID messaggio univoci.
Se gli ID messaggio sono gli stessi, significa che Pub/Sub ha inviato o recapitato nuovamente il messaggio. Se gli ID messaggio sono diversi, significa che la duplicazione è avvenuta a monte, presso il publisher.
Scadenze di conferma scadute
La duplicazione dei messaggi in Pub/Sub si verifica spesso quando i sottoscrittori non riescono a confermare la ricezione dei messaggi entro la scadenza di conferma. Ciò comporta il nuovo invio dei messaggi, 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 del termine di 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 di conferma.
Se i messaggi vengono estratti 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, ciò può portare a un sovraccarico di duplicati per il sottoscrittore, aggravando l'arretrato. I duplicati in scadenza generano quindi nuovi duplicati.
Per evitare di sovraccaricare il sottoscrittore, riduci il numero di messaggi che il sottoscrittore estrae alla volta. In questo modo, il sottoscrittore ha meno messaggi da elaborare entro la scadenza. Scadono meno messaggi e ne vengono inviati di nuovo meno.
Per ridurre il numero di messaggi che il sottoscrittore estrae alla volta, devi ridurre l'impostazione del numero massimo di messaggi in sospeso nella configurazione del controllo di flusso del sottoscrittore. Non esiste un valore valido per tutti, quindi devi regolare il limite massimo di messaggi in attesa 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 confermare un messaggio.
Forzatura dei 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 precedentemente confermati. In questo modo viene preservato l'ordine della sequenza. Tuttavia, non esiste una garanzia rigorosa che i messaggi dipendenti vengano inviati solo dopo l'avvenuta conferma di ricezione dei messaggi precedenti nella sequenza.
Il sottoscrittore sta inviando nack per i messaggi
Consulta la sezione Il sottoscrittore sta inviando nack per i messaggi.
Operazioni di ricerca
Quando esegui un'operazione di ricerca su un timestamp o uno snapshot, Pub/Sub riconsegna i messaggi pubblicati dopo il timestamp o inclusi nello snapshot. Questo nuovo invio è un comportamento previsto e si verifica anche se la consegna "exactly-once" è abilitata nella sottoscrizione. Per saperne di più, consulta Cerca con consegna "exactly-once".
Deduplicazione downstream
I sottoscrittori e altri sistemi downstream potrebbero deduplicare i messaggi. Ad esempio, Dataflow supporta la consegna "exactly-once". Se vedi messaggi duplicati visualizzati in modo imprevisto a valle, la causa potrebbe essere nel sottoscrittore anziché in Pub/Sub.
Risoluzione dei problemi di una sottoscrizione StreamingPull
Relazione tra la metrica di latenza delle richieste e la latenza di distribuzione end-to-end
Per StreamingPull, la metrica serviceruntime.googleapis.com/api/request_latencies rappresenta il tempo di apertura dello stream. La metrica non è utile per determinare la latenza di pubblicazione end-to-end.
Anziché utilizzare la metrica della latenza della richiesta, utilizza il punteggio integrità latenza di pubblicazione per verificare quali fattori contribuiscono a un aumento della latenza di pubblicazione end-to-end.
Chiusura delle connessioni StreamingPull 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 unarie, questo stato per StreamingPull è solo un'indicazione 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 terminazione dello stream durante la diagnosi degli errori. Concentrati invece sulla metrica di risposta StreamingPull subscription/streaming_pull_response_count, raggruppata per response_code o response_class.
Cerca questi errori:
Gli errori Precondizione non riuscita possono verificarsi se nel backlog della sottoscrizione sono presenti messaggi criptati con una chiave Cloud KMS disabilitata. Per riprendere l'estrazione, ripristina l'accesso alla chiave.
Gli errori di non disponibilità 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 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.