Risolvere i problemi relativi a un argomento standard

Questo documento fornisce alcuni suggerimenti comuni per la risoluzione dei problemi durante la pubblicazione di messaggi in un argomento Pub/Sub standard.

Scopri di più su come pubblicare messaggi negli argomenti e sulle diverse funzionalità.

Latenza di pubblicazione elevata

La latenza di pubblicazione è il tempo necessario per completare una richiesta di pubblicazione emessa da un client publisher. La latenza di pubblicazione è diversa da latenza di consegna end-to-end, ovvero il tempo necessario per la consegna di un messaggio pubblicato in Pub/Sub a un client sottoscrittore. Potresti notare una latenza di pubblicazione o end-to-end elevata, anche quando il valore dell'altro tipo di latenza è basso. Una latenza di pubblicazione elevata può essere sostenuta nel client publisher Pub/Sub, durante il transito tra il client e il backend Pub/Sub o nel backend Pub/Sub. Puoi controllare la latenza di pubblicazione sostenuta nel backend Pub/Sub utilizzando la topic/send_request_latencies metrica. Una latenza di pubblicazione del backend elevata potrebbe essere correlata ai seguenti fattori:

  • Pub/Sub è progettato per una consegna a bassa latenza e ad alta velocità effettiva. Se l'argomento ha una velocità effettiva bassa, l'inizializzazione delle risorse associate all'argomento potrebbe richiedere più tempo.

  • Se utilizzi un criterio di archiviazione dei messaggi, potrebbe influire sulla latenza complessiva delle richieste all'argomento e alla sottoscrizione. Controlla le implicazioni di prestazioni e disponibilità dell'utilizzo di questa configurazione.

Se il client publisher rileva una latenza di pubblicazione significativamente superiore a quella indicata nella metrica, potrebbe essere un segnale di uno di questi fattori lato client:

  • Assicurati di non creare un nuovo publisher per ogni pubblicazione. È consigliabile utilizzare un singolo client publisher per argomento per applicazione per pubblicare tutti i messaggi. L'avvio di nuovi oggetti publisher e l'aggiunta di nuovi thread comportano un costo di latenza. Se utilizzi le funzioni Cloud Run per pubblicare i messaggi, tieni presente che anche le chiamate possono influire sulla latenza di pubblicazione.

  • Se ritieni che le impostazioni di nuovi tentativi predefinite non siano sufficienti per il tuo caso d'uso, apporta le modifiche corrispondenti. Tuttavia, verifica che i nuovi valori non siano troppo elevati. Scopri come configurare i nuovi tentativi delle richieste.

Tieni presente che una latenza di pubblicazione elevata può causare errori DEADLINE_EXCEEDED, di cui parleremo nella sezione successiva.

Le operazioni di pubblicazione non vanno a buon fine con DEADLINE_EXCEEDED

Un errore DEADLINE_EXCEEDED durante una richiesta di pubblicazione indica che la richiesta non è stata completata entro il tempo allocato. Ciò potrebbe essere dovuto a vari fattori, ad esempio le richieste non raggiungono il servizio Pub/Sub o problemi di prestazioni che influiscono sulle richieste.

Per verificare che le richieste di pubblicazione raggiungano il servizio Pub/Sub, monitora l'argomento utilizzando la topic/send_request_count metrica, raggruppata per response_code. Questa metrica ti aiuta a determinare se le richieste non vanno a buon fine prima di raggiungere l'argomento Pub/Sub. Se la metrica è vuota, esiste un fattore esterno che impedisce ai messaggi di raggiungere il servizio Pub/Sub. Inoltre, per escludere la possibilità di un problema intermittente, controlla il tasso di errore utilizzando il grafico delle metriche topic/send_request_count menzionato in precedenza o la pagina API e servizi nella Google Cloud console. Se il tasso di errore è molto basso, potrebbe trattarsi di un problema intermittente.

Se le richieste raggiungono Pub/Sub, ecco alcune possibili cause di errori nelle operazioni di pubblicazione con un errore DEADLINE_EXCEEDED:

Collo di bottiglia lato client

È probabile che gli errori di pubblicazione siano causati da un collo di bottiglia lato client, ad esempio memoria insufficiente, pressione della CPU, stato del thread non ottimale o congestione della rete nella VM che ospita il client publisher. Se una chiamata Publish restituisce DEADLINE_EXCEEDED, è possibile che le chiamate Publish asincrone vengano accodate più velocemente di quanto vengano inviate al servizio, il che aumenta progressivamente la latenza delle richieste. Inoltre, verifica se uno dei seguenti elementi ti aiuta a determinare un possibile collo di bottiglia nel tuo sistema:

  • Verifica se stai pubblicando i messaggi più velocemente di quanto il client possa inviarli. In genere, ogni chiamata Publish asincrona restituisce un Future oggetto. Per monitorare il numero di messaggi in attesa di essere inviati, memorizza il numero di messaggi da inviare con ogni chiamata Publish ed eliminalo solo nel callback dell'oggetto Future.

  • Assicurati di avere una larghezza di banda di caricamento sufficiente tra la macchina su cui è in esecuzione il publisher e Google Cloud. In genere, le reti Wi-Fi di sviluppo hanno una larghezza di banda di 1-10 MBps o 1000-10000 messaggi tipici al secondo. La pubblicazione di messaggi in un loop senza limitazione di frequenza potrebbe creare un breve picco di larghezza di banda elevata in un breve periodo di tempo. Per evitare questo problema, puoi eseguire il publisher su una macchina all'interno di Google Cloud o ridurre la frequenza di pubblicazione dei messaggi in modo che corrisponda alla larghezza di banda disponibile.

  • Verifica se riscontri una latenza molto elevata tra l'host e Google Cloud per motivi quali la congestione della rete di avvio o i firewall. Il calcolo della velocità effettiva della rete contiene indicazioni su come trovare la larghezza di banda e la latenza per diversi scenari.

  • In definitiva, esistono limiti alla quantità di dati che una singola macchina può pubblicare. Potresti dover provare a scalare orizzontalmente o eseguire più istanze del client publisher su più macchine. Il test dei client Cloud Pub/Sub per massimizzare le prestazioni di streaming mostra come Pub/Sub scala su una singola Google Cloud VM con un numero crescente di CPU. Ad esempio, puoi raggiungere da 500 MBps a 700 MBps per i messaggi di 1 KB su un'istanza Compute Engine con 16 core.

Durata del timeout di pubblicazione insufficiente

Per ridurre la frequenza di timeout per le chiamate di pubblicazione, assicurati di aver definito un timeout sufficientemente lungo nelle impostazioni di nuovi tentativi del client publisher. Per le impostazioni di nuovi tentativi, imposta la scadenza iniziale su 10 secondi e il timeout totale su 600 secondi. Anche se non stai accumulando un backlog elevato di messaggi non inviati, i picchi occasionali nella latenza delle richieste possono causare il timeout delle chiamate di pubblicazione. Tuttavia, se i problemi sono causati da un collo di bottiglia persistente, anziché da timeout occasionali, ripetere più volte i tentativi potrebbe causare un numero maggiore di errori.

Problemi con la libreria client

Potresti utilizzare una versione della libreria client con un problema noto. Il seguente elenco include gli issue tracker per tutte le librerie client. Se riscontri un problema noto che interessa la versione della libreria client che stai utilizzando, esegui l'upgrade all'ultima versione della libreria client. In questo modo, ti assicuri di aver applicato tutti gli aggiornamenti pertinenti, incluse le correzioni e i miglioramenti delle prestazioni.

Problemi dello schema

Se le pubblicazioni iniziano a restituire INVALID_ARGUMENT, è possibile che qualcuno abbia aggiornato l'argomento per modificare lo schema associato, eliminato lo schema o eliminato le revisioni dello schema associate all'argomento. In questo caso, aggiorna le impostazioni dello schema dell'argomento a uno schema e a un insieme di revisioni che corrispondono ai messaggi pubblicati oppure modifica il formato del messaggio in modo che corrisponda allo schema corrente.

Problemi di crittografia dei messaggi

Se hai configurato l'argomento Pub/Sub per criptare i messaggi pubblicati utilizzando una chiave di crittografia gestita dal cliente, la pubblicazione potrebbe non riuscire con un errore FAILED_PRECONDITION. Questo errore potrebbe verificarsi se la chiave Cloud KMS è disattivata o se le chiavi gestite esternamente tramite Cloud EKM non sono più accessibili. Per riprendere la pubblicazione, ripristina l'accesso alla chiave.

Problemi con i criteri di archiviazione dei messaggi

Se le sottoscrizioni non ricevono i messaggi pubblicati, l'argomento potrebbe avere un criterio di archiviazione dei messaggi attivo. In questo caso, potresti visualizzare errori FAILED_PRECONDITION nelle metriche di pubblicazione.

In genere, questi errori contengono messaggi come:

Cannot publish messages that contain ordering keys
to topic projects/...  due a message storage policy on the topic that would
require the messages to be forwarded to another region. Please either change
the topic's message storage policy or publish to an allowed region using
the appropriate regional Cloud Pub/Sub endpoint.

o

The topic's message storage policy requires enforcement
in transit, but the Publish request was received by a Pub/Sub server in
a non-allowed region. Please either publish via a regional Pub/Sub endpoint
corresponding to an allowed region, or update the topic's message storage policy.

Per risolvere questo problema, procedi in uno dei seguenti modi:

  • Aggiorna il criterio di archiviazione dei messaggi dell'argomento per consentire la regione.
  • Configura il client publisher per pubblicare in una regione consentita utilizzando il appropriato endpoint Pub/Sub regionale.

Problemi con le trasformazioni di messaggi singoli (SMT)

Se hai configurato SMT nell'argomento Pub/Sub, la pubblicazione potrebbe non riuscire con INVALID_ARGUMENT errori quando le trasformazioni non vengono applicate ai messaggi. Se la trasformazione di un messaggio in un batch di pubblicazione non va a buon fine, l'intero batch non viene pubblicato. L'errore restituito indica il motivo dell'errore, ad esempio:

INVALID_ARGUMENT: Pub/Sub failed to apply a message transformation to one or
more messages in the publish request. Error: Failed to execute JavaScript UDF:
`my_function`. Return value is not an object.

Monitorare le SMT

Per comprendere le prestazioni e l'impatto delle SMT su un argomento, utilizza le seguenti metriche di monitoraggio:

La metrica topic/message_transform_latencies misura il tempo necessario per applicare le SMT a un messaggio. La metrica misura solo la latenza SMT e non include altre parti del tempo di consegna dei messaggi.

La metrica fornisce due etichette chiave:

  • status: indica se la trasformazione è riuscita o se si è verificato un problema.

  • filtered: indica se la SMT ha causato il filtraggio del messaggio. Quando una SMT filtra un messaggio in un argomento, Pub/Sub elimina il messaggio e non lo invia mai ai sottoscrittori. Questa etichetta filtered è vera solo quando una SMT esegue il filtraggio. I messaggi filtrati utilizzando le funzionalità di filtraggio integrate di Pub/Sub non sono inclusi in questa metrica specifica.

La metrica topic/byte_cost viene utilizzata per identificare i messaggi filtrati dalle SMT o in cui le SMT non sono riuscite. Cerca questi valori specifici:

  • Quando una SMT filtra un messaggio, operation_type è smt_publish_filter_drop.

  • Se una SMT non riesce a trasformare un messaggio, viene visualizzato un response_code diverso da OK.

Passaggi successivi

Esplora il tracciamento OpenTelemetry per eseguire il debug della latenza di pubblicazione.