Questo documento fornisce alcuni suggerimenti comuni per la risoluzione dei problemi relativi alle sottoscrizioni al pull Pub/Sub. Per ulteriori informazioni sulle sottoscrizioni pull, consulta la guida per gli abbonati 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 aumentata.
L'età dei messaggi senza ACK meno recente 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 (con 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 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 entrambe le metriche oldest_unacked_message_age e num_undelivered_messages aumentano contemporaneamente, è possibile che i sottoscrittori non stiano tenendo il passo con il volume dei messaggi. In questa situazione, concentrati sugli aspetti relativi agli iscritti:
Integrità client: analizza l'utilizzo delle risorse sulle macchine che ospitano client sottoscrittori, come CPU, memoria e larghezza di banda della rete. Cerca i punti di pressione che potrebbero compromettere 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 in un database. Questo comportamento può generare conflitti e latenza elevata.
Limitazioni delle quote: verifica di non aver superato le quote o le limitazioni Pub/Sub imposte dal servizio di hosting. Se gli abbonati sono ospitati su Google Cloud, esamina le quote delle risorse di Compute Engine o GKE per evitare potenziali colli di bottiglia.
Il sottoscrittore ha confermato i messaggi in modo negativo
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. Ripetuti nack di un messaggio generano duplicati e potenzialmente un elevato ritardo 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 per i nuovi tentativi, preferibilmente un backoff esponenziale, come metodo per fare leva sui singoli messaggi che potrebbero essere elaborati in un secondo momento, ma che richiedono un po' più di tempo prima che vengano recapitati.
Se devi ignorare intenzionalmente determinati messaggi, l'approccio consigliato è confermarli, anche se non li elaborerai. In questo modo le richieste vengono rimosse dalla sottoscrizione, vengono evitati i ricaricamenti non necessari e si riduce il consumo di risorse. Se i messaggi non vengono confermati, intenzionalmente o meno, si creano problemi di backlog e duplicati dei caricamenti.
Latenza di distribuzione elevata
La latenza di consegna in Pub/Sub è il tempo impiegato da un messaggio di un publisher per raggiungere un sottoscrittore. Nelle sezioni successive sono descritte alcune delle possibili cause di un'elevata latenza di distribuzione.
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 attive del sottoscrittore, Pub/Sub non può recapitare i messaggi tempestivamente. Un singolo flusso potrebbe costituire un single point of failure, 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 avere costantemente 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. Eventuali richieste poco frequenti potrebbero accumulare messaggi nel backlog e aumentare la latenza. Questo approccio aiuta a ridurre al minimo le lacune nella connettività e a migliorare la latenza di distribuzione.
La libreria client di alto livello è consigliata per i casi in cui hai bisogno di una velocità effettiva elevata e di bassa latenza con costi di elaborazione e overhead operativo minimi. Per impostazione predefinita, la libreria client di alto livello utilizza l'API StreamingPull, che tende a essere la 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 senza ACK in una sottoscrizione Pub/Sub aumenta intrinsecamente la latenza end-to-end perché i messaggi non vengono elaborati immediatamente dai sottoscrittori.
Ordine delle chiavi e consegna "exactly-once"
Ordinare le chiavi e consegnare "exactly-once" sono funzionalità preziose, ma richiedono un ulteriore coordinamento all'interno di Pub/Sub per garantire una 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 un aumento temporaneo 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 "exactly-once" 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 sottoscrittore, il fattore determinante 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. Questo comportamento si verifica perché Pub/Sub distribuisce i messaggi tra i consumer attivi per maggiore efficienza. A volte, un singolo consumer potrebbe ricevere meno messaggi del previsto o un sottoinsieme di messaggi diverso rispetto ad altri consumer.
Tieni presente che i messaggi potrebbero essere già in sospeso per i client e un backlog di messaggi non confermati non significa necessariamente che li riceverai nella prossima richiesta di 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 osservare che alcune richieste di pull restituiscono zero 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 associati 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. Valuta come i filtri influiscono sulle metriche di backlog.
Utilizzo dell'opzione returnImmediately
Se il client utilizza il pull unario, verifica che il campo returnImmediately sia impostato su true. Si tratta di un campo obsoleto che indica al servizio Pub/Sub di rispondere immediatamente alla richiesta di pull anche se viene restituita senza alcun messaggio. Ciò può comportare la restituzione di richieste di pull con 0 messaggi anche in presenza di un backlog.
Gestione dei 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 iscritti 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 percentuale di duplicazione, estendi le scadenze dei messaggi.
- Le librerie client gestiscono automaticamente le estensioni di scadenza, ma sono previsti 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 il sottoscrittore continua ad avere un numero eccessivo di richieste, le estensioni di scadenza ripetute non vanno a buon fine. Nello scenario peggiore, questo può portare a un numero eccessivo di duplicati, con conseguente esacerbazione dell'arretrato. 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 il sottoscrittore ha meno messaggi da elaborare entro la scadenza. Meno messaggi scadono e meno messaggi vengono recapitati di nuovo.
Per ridurre il numero di messaggi di cui il sottoscrittore esegue il pull contemporaneamente, è necessario ridurre l'impostazione del numero massimo di messaggi in sospeso nella configurazione di controllo del flusso del sottoscrittore. 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 ciascuna applicazione elabora i messaggi in modo diverso e richiede una diversa quantità di tempo per la conferma.
Nuovi tentativi in corso...
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 un valore ackDeadlineSeconds impostato su 0.
Ordinazione delle chiavi
Quando Pub/Sub recapita nuovamente un messaggio con una chiave di ordinamento, recapita anche tutti i messaggi successivi con la stessa chiave di ordinamento, anche se sono stati confermati in precedenza. Questo viene fatto per mantenere l'ordine della sequenza. Tuttavia, non esiste una garanzia rigorosa che i messaggi dipendenti vengano inviati solo dopo l'acquisizione riuscita dei messaggi precedenti della sequenza.
Il sottoscrittore sta aggiungendo i messaggi
Vedi L'iscritto sta aggiungendo i messaggi.
Risoluzione dei problemi di una sottoscrizione StreamingPull
I flussi StreamingPull si chiudono sempre con stato non OK. A differenza di uno stato di errore per le RPC unaarie, questo stato per StreamingPull indica solo che il flusso è disconnesso. Le richieste non vanno a buon fine. Pertanto, anche se l'API StreamingPull potrebbe avere un tasso di errore sorprendente del 100%, questo comportamento è dovuto alla progettazione.
Poiché i flussi StreamingPull si chiudono sempre con un errore, non è utile esaminare le metriche di terminazione dei flussi durante la diagnosi degli errori. Concentrati piuttosto sulla metrica di 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 della sottoscrizione sono presenti messaggi criptati con una chiave Cloud KMS disabilitata. Per riprendere il pull, 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 riproverà a eseguire le richieste. Se utilizzi una libreria client, non è necessario alcun intervento da parte tua.
Gli errori Non trovato possono verificarsi quando l'abbonamento viene eliminato o se non è mai esistito. Il secondo caso si verifica se hai fornito un percorso di sottoscrizione non valido.