Risolvere i problemi relativi a un argomento standard

Questo documento fornisce alcuni suggerimenti comuni per la risoluzione dei problemi relativi alla 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 inviata da un client publisher. La latenza di pubblicazione è diversa dalla latenza di recapito end-to-end, ovvero il tempo necessario per la consegna di un messaggio pubblicato su Pub/Sub a un client sottoscrittore. Potresti notare una latenza di pubblicazione o end-to-end elevata, anche se il valore dell'altro tipo di latenza è basso. È possibile che si verifichi una latenza di pubblicazione elevata nel client publisher Pub/Sub, durante il transito tra il client e il back-end Pub/Sub o nel back-end Pub/Sub. Puoi esaminare la latenza di pubblicazione sostenuta nel backend di Pub/Sub utilizzando la metrica topic/send_request_latencies. Un'elevata latenza di pubblicazione del backend potrebbe essere correlata ai seguenti fattori:

• Pub/Sub è progettato per la pubblicazione a bassa latenza e con una velocità effettiva elevata. Se l'argomento ha un throughput ridotto, l'inizializzazione delle risorse associate potrebbe richiedere più tempo.

• Se utilizzi un criterio di archiviazione dei messaggi, questo potrebbe influire sulla latenza complessiva delle richieste all'argomento e all'iscrizione. Controlla le conseguenze sul rendimento e sulla disponibilità dell'utilizzo di questa configurazione.

Se il client del publisher registra una latenza di pubblicazione notevolmente superiore a quella indicata nella metrica, potrebbe essere un indicatore di uno di questi fattori lato client:

• Assicurati di non creare un nuovo editore per ogni pubblicazione. Per pubblicare tutti i messaggi, ti consigliamo di utilizzare un singolo client publisher per argomento per applicazione. La creazione di nuovi oggetti publisher e l'aggiunta di nuovi thread comporta un costo di latenza. Se utilizzi le funzioni Cloud Run per pubblicare i messaggi, tieni presente che le invocazioni possono influire anche sulla latenza di pubblicazione.

• Se ritieni che le impostazioni di ripetizione 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 le richieste di ripetizione.

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

Le operazioni di pubblicazione non riescono 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 che non raggiungono il servizio Pub/Sub o problemi di prestazioni che interessano le richieste.

Per verificare che le richieste di pubblicazione raggiungano il servizio Pub/Sub, monitora l'argomento utilizzando la metrica topic/send_request_count, 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, è presente 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 console Google Cloud. Se il tasso di errore è molto basso, potrebbe trattarsi di un problema intermittente.

Se le richieste raggiungono Pub/Sub, di seguito sono riportate alcune possibili cause di errore DEADLINE_EXCEEDED durante le operazioni di pubblicazione:

Collo di bottiglia lato client

I problemi di pubblicazione sono probabilmente causati da un collo di bottiglia lato client, ad esempio memoria insufficiente, utilizzo elevato della CPU, stato del thread scadente o congestione della rete nella VM che ospita il client del publisher. Se una chiamata Publish restituisce DEADLINE_EXCEEDED, è possibile che le chiamate Publish asincrone vengano inserite in coda più velocemente di quanto non vengano inviate al servizio, il che aumenta progressivamente la latenza della richiesta. Inoltre, controlla se uno dei seguenti elementi ti aiuta a determinare un possibile collo di bottiglia nel sistema:

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

• Assicurati di disporre di una larghezza di banda per il caricamento sufficiente tra la macchina su cui è in esecuzione il publisher e Google Cloud. Le reti Wi-Fi di sviluppo hanno in genere una larghezza di banda di 1-10 MBps o 1000-10000 messaggi tipici al secondo. La pubblicazione di messaggi in loop senza alcuna 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 in Google Cloud o ridurre la frequenza di pubblicazione dei messaggi in base alla larghezza di banda disponibile.

• Controlla se noti una latenza molto elevata tra l'host e Google Cloud per uno dei motivi, ad esempio la congestione della rete all'avvio o i firewall. L'articolo Calcolo del throughput 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 eseguire la scalabilità orizzontale o a eseguire più istanze del client publisher su più macchine. Test dei client Cloud Pub/Sub per massimizzare le prestazioni in streaming mostra come Pub/Sub si scala su una singola VM Google Cloud con un numero crescente di CPU. Ad esempio, puoi raggiungere velocità da 500 a 700 MB/s per messaggi di 1 KB su un'istanza Compute Engine con 16 core.

Durata del timeout di pubblicazione non adeguata

Per ridurre il tasso di timeout per le chiamate di pubblicazione, assicurati di avere definito un timeout sufficientemente lungo nelle impostazioni di ripetizione del client publisher. Per le impostazioni di ripetizione, imposta la scadenza iniziale su 10 secondi e il timeout totale su 600 secondi. Anche se non stai accumulando un numero elevato di messaggi non inviati, 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, riprovare più volte potrebbe causare altri errori.

Problemi relativi alla libreria client

Potresti utilizzare una versione della libreria client con un problema noto. L'elenco seguente include i tracker dei problemi per tutte le librerie client. Se riscontri un problema noto che interessa la versione della libreria client in uso, esegui l'upgrade alla versione più recente della libreria client. In questo modo, avrai ricevuto tutti gli aggiornamenti pertinenti, incluse correzioni e miglioramenti delle prestazioni.

Problemi relativi allo 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 con uno schema e un insieme di revisioni corrispondenti 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 può verificarsi se la chiave Cloud KMS è disattivata o se le chiavi con gestione esterna tramite Cloud EKM non sono più accessibili. Per riprendere la pubblicazione, ripristina l'accesso alla chiave.