Monitorare Pub/Sub in Cloud Monitoring

Puoi utilizzare la console Google Cloud o l'API Cloud Monitoring per monitorare Pub/Sub.

Questo documento mostra come monitorare l'utilizzo di Pub/Sub nella console Google Cloud utilizzando Monitoring.

Per le best practice sull'utilizzo delle metriche nella scalabilità automatica, consulta Best practice per l'utilizzo delle metriche Pub/Sub come indicatore di scalabilità.

Prima di iniziare

Prima di utilizzare il monitoraggio, assicurati di aver preparato quanto segue:

  • Un account di fatturazione Cloud

  • Un progetto Pub/Sub con la fatturazione abilitata

Un modo per assicurarti di averli ottenuti entrambi è completare la guida rapida all'utilizzo della console Cloud.

Visualizzare una dashboard esistente

Una dashboard ti consente di visualizzare e analizzare i dati provenienti da origini diverse nello stesso contesto. Google Cloud fornisce dashboard predefinite e personalizzate. Ad esempio, puoi visualizzare una dashboard Pub/Sub predefinita o creare una dashboard personalizzata che mostri dati delle metriche, criteri di avviso e voci di log correlati a Pub/Sub.

Per monitorare il tuo progetto Pub/Sub utilizzando Cloud Monitoring, segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina Monitoring.

    Vai a Monitoring

  2. Seleziona il nome del tuo progetto se non è già selezionato nella parte superiore della pagina.

  3. Nel menu di navigazione, fai clic su Dashboard.

  4. Nella pagina Panoramica delle dashboard, crea una nuova dashboard o seleziona la dashboard Pub/Sub esistente.

    Per cercare la dashboard Pub/Sub esistente, nel filtro per Tutte le dashboard, seleziona la proprietà Nome e inserisci Pub/Sub.

Per ulteriori informazioni su come creare, modificare e gestire una dashboard personalizzata, vedi Gestire le dashboard personalizzate.

Visualizzare una singola metrica Pub/Sub

Per visualizzare una singola metrica Pub/Sub utilizzando la console Google Cloud , segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina Monitoring.

    Vai a Monitoring

  2. Nel riquadro di navigazione, seleziona Esplora metriche.

  3. Nella sezione Configurazione, fai clic su Seleziona una metrica.

  4. Nel filtro, inserisci Pub/Sub.

  5. In Risorse attive, seleziona Sottoscrizione Pub/Sub o Argomento Pub/Sub.

  6. Visualizza in dettaglio una metrica specifica e fai clic su Applica.

    Si apre la pagina di una metrica specifica.

Per saperne di più sulla dashboard di monitoraggio, consulta la documentazione di Cloud Monitoring.

Visualizzare le metriche e i tipi di risorse Pub/Sub

Accedere all'editor PromQL

Esplora metriche è un'interfaccia all'interno di Cloud Monitoring progettata per esplorare e visualizzare i dati delle metriche. In Esplora metriche, puoi utilizzare il linguaggio di query Prometheus (PromQL) per eseguire query e analizzare le metriche Pub/Sub.

Per accedere all'editor di codice ed eseguire query sulle metriche di Cloud Monitoring con PromQL in Metrics Explorer, consulta Utilizzare l'editor di codice per PromQL.

Ad esempio, puoi inserire una query PromQL per monitorare il conteggio dei messaggi inviati a un abbonamento specifico in un periodo di 1 ora:

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="your-project-id",
    "subscription_id"="your-subscription-id"
  }[1h])
)

Monitorare l'utilizzo della quota

Per un determinato progetto, puoi utilizzare la dashboard delle quote di IAM e amministrazione per visualizzare le quote e l'utilizzo correnti.

Puoi visualizzare l'utilizzo storico della quota utilizzando le seguenti metriche:

Queste metriche utilizzano il tipo di risorsa monitorata consumer_quota. Per altre metriche relative alle quote, consulta l'elenco delle metriche.

Ad esempio, la seguente query PromQL crea un grafico con la frazione di quota publisher utilizzata in ogni regione:

sum by (quota_metric, location) (
  rate({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
)
/
(max by (quota_metric, location) (
  max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com",
    "quota_metric"="pubsub.googleapis.com/regionalpublisher"
  }[${__interval}])
) / 60 )

Se prevedi che il tuo utilizzo superi i limiti di quota predefiniti, crea criteri di avviso per tutte le quote pertinenti. Questi avvisi vengono attivati quando l'utilizzo raggiunge una frazione del limite. Ad esempio, la seguente query PromQL attiva un criterio di avviso quando l'utilizzo di una quota Pub/Sub supera l'80%:

sum by (quota_metric, location) (
  increase({
    "__name__"="serviceruntime.googleapis.com/quota/rate/net_usage",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
/
max by (quota_metric, location) (
   max_over_time({
    "__name__"="serviceruntime.googleapis.com/quota/limit",
    "monitored_resource"="consumer_quota",
    "service"="pubsub.googleapis.com"
  }[1m])
)
> 0.8

Per un monitoraggio e avvisi più personalizzati sulle metriche delle quote, consulta Utilizzo delle metriche delle quote.

Per ulteriori informazioni sulle quote, consulta Quote e limiti.

Mantenere un abbonamento sano

Per mantenere una sottoscrizione integra, puoi monitorare diverse proprietà della sottoscrizione utilizzando le metriche fornite da Pub/Sub. Ad esempio, puoi monitorare il volume di messaggi non confermati, la scadenza dei termini di conferma dei messaggi e così via. Puoi anche verificare se il tuo abbonamento è sufficiente per ottenere una bassa latenza di pubblicazione dei messaggi.

Consulta le sezioni successive per saperne di più sulle metriche specifiche.

Monitorare il backlog dei messaggi

Per assicurarti che gli abbonati siano al passo con il flusso di messaggi, crea una dashboard. La dashboard può mostrare le seguenti metriche del backlog, aggregate per risorsa, per tutti i tuoi abbonamenti:

Crea criteri di avviso che vengono attivati quando questi valori non rientrano nell'intervallo accettabile nel contesto del tuo sistema. Ad esempio, il numero assoluto di messaggi non confermati non è necessariamente significativo. Un backlog di un milione di messaggi potrebbe essere accettabile per una sottoscrizione di un milione di messaggi al secondo, ma inaccettabile per una sottoscrizione di un messaggio al secondo.

Problemi comuni relativi al backlog

Sintomi Problema Soluzioni
oldest_unacked_message_age_by_region e num_unacked_messages_by_region stanno crescendo di pari passo. Gli iscritti non riescono a tenere il passo con il volume dei messaggi
  • Aggiungi altri thread o processi di sottoscrizione.
  • Aggiungi altre macchine o contenitori abbonati.
  • Cerca segni di bug nel codice che impediscono di riconoscere correttamente i messaggi o di elaborarli in modo tempestivo. Consulta la sezione Monitoraggio della scadenza dell'ACK.
Se le dimensioni del backlog sono piccole e costanti e il valore di oldest_unacked_message_age_by_region aumenta costantemente, è possibile che alcuni messaggi non possano essere elaborati. Messaggi bloccati
  • Esamina i log dell'applicazione per capire se alcuni messaggi causano l'arresto anomalo del codice. È improbabile, ma possibile, che i messaggi incriminati siano bloccati in Pub/Sub anziché nel client. Apri una richiesta di assistenza dopo aver verificato che il codice elabora correttamente ogni messaggio.
  • Se alcuni messaggi causano l'arresto anomalo del codice, valuta la possibilità di inoltrarli a un argomento dead letter.
oldest_unacked_message_age_by_region supera la durata di conservazione dei messaggi della sottoscrizione. Perdita definitiva dei dati
  • Configura un avviso che si attiva prima della scadenza del periodo di conservazione dei messaggi.

Monitorare l'integrità della latenza di pubblicazione

In Pub/Sub, la latenza di consegna è il tempo necessario per recapitare un messaggio pubblicato a un sottoscrittore. Se il backlog di messaggi è in aumento, puoi utilizzare il punteggio di integrità della latenza di pubblicazione (subscription/delivery_latency_health_score) per verificare quali fattori contribuiscono a un aumento della latenza.

Questa metrica misura l'integrità di un singolo abbonamento in una finestra temporale continua di 10 minuti. La metrica fornisce informazioni dettagliate sui seguenti criteri, necessari per garantire una bassa latenza costante per un abbonamento:

  • Richieste di ricerca trascurabili.

  • Messaggi con riconoscimento negativo (nacked) trascurabili.

  • Scadenze di conferma dei messaggi scaduti trascurabili.

  • Latenza di conferma coerente inferiore a 30 secondi.

  • Utilizzo basso e costante, il che significa che l'abbonamento ha sempre una capacità adeguata per elaborare nuovi messaggi.

La metrica Punteggio integrità latenza di pubblicazione restituisce un punteggio pari a 0 o 1 per ciascuno dei criteri specificati. Un punteggio pari a 1 indica uno stato integro mentre un punteggio pari a 0 indica uno stato non integro.

  • Richieste di ricerca: se l'abbonamento ha ricevuto richieste di ricerca negli ultimi 10 minuti, il punteggio viene impostato su 0. La ricerca di una sottoscrizione potrebbe causare la riproduzione di messaggi precedenti molto tempo dopo la loro prima pubblicazione, con conseguente aumento della latenza di consegna.

  • Messaggi con riconoscimento negativo (nack): se l'abbonamento ha ricevuto richieste di riconoscimento negativo (nack) negli ultimi 10 minuti, il punteggio viene impostato su 0. Un riconoscimento negativo fa sì che un messaggio venga riconsegnato con una latenza di consegna maggiore.

  • Scadenze di conferma scadute: se l'abbonamento aveva scadenze di conferma scadute negli ultimi 10 minuti, il punteggio viene impostato su 0. I messaggi la cui scadenza di conferma è scaduta vengono riconsegnati con una latenza di consegna maggiore.

  • Latenze di riconoscimento: se il 99,9° percentile di tutte le latenze di riconoscimento negli ultimi 10 minuti è stato superiore a 30 secondi, il punteggio viene impostato su 0. Una latenza di riconoscimento elevata indica che un client sottoscrittore impiega un tempo insolitamente lungo per elaborare un messaggio. Questo punteggio potrebbe indicare un bug o alcune limitazioni delle risorse sul lato client dell'abbonato.

  • Utilizzo ridotto: l'utilizzo viene calcolato in modo diverso per ogni tipo di abbonamento.

    • StreamingPull: se non hai aperto un numero sufficiente di flussi, il punteggio viene impostato su 0. Apri più stream per assicurarti di avere una capacità adeguata per i nuovi messaggi.

    • Push: se hai troppi messaggi in sospeso per l'endpoint push, il punteggio viene impostato su 0. Aggiungi più capacità all'endpoint push in modo da avere capacità per i nuovi messaggi.

    • Pull: se non hai un numero sufficiente di richieste pull in sospeso, il punteggio viene impostato su 0. Apri più richieste pull simultanee per assicurarti di essere pronto a ricevere nuovi messaggi.

Per visualizzare la metrica, in Esplora metriche, seleziona la metrica Punteggio di integrità della latenza di pubblicazione per il tipo di risorsa Abbonamento Pub/Sub. Aggiungi un filtro per selezionare un solo abbonamento alla volta. Seleziona il grafico ad area in pila e punta a un momento specifico per controllare i punteggi dei criteri per l'abbonamento in quel momento.

Di seguito è riportato uno screenshot della metrica tracciata per un periodo di un'ora utilizzando un grafico ad area in pila. Il punteggio di salute combinato raggiunge 5 alle 4:15, con un punteggio di 1 per ogni criterio. Successivamente, il punteggio combinato scende a 4 alle 4:20, quando il punteggio di utilizzo scende a 0.

Screenshot della metrica Latenza di pubblicazione

PromQL fornisce un'interfaccia espressiva basata su testo per i dati delle serie temporali di Cloud Monitoring. La seguente query PromQL crea un grafico per misurare il punteggio integrità latenza di pubblicazione per un abbonamento.

sum_over_time(
  {
    "__name__"="pubsub.googleapis.com/subscription/delivery_latency_health_score",
    "monitored_resource"="pubsub_subscription",
    "subscription_id"="$SUBSCRIPTION"
  }[${__interval}]
)

Monitorare la scadenza del termine di conferma

Per ridurre la latenza di distribuzione dei messaggi, Pub/Sub consente ai client sottoscrittori un periodo di tempo limitato per confermare la ricezione di un determinato messaggio. Questo periodo di tempo è noto come scadenza di conferma. Se i tuoi abbonati impiegano troppo tempo per confermare i messaggi, questi vengono inviati di nuovo, con il risultato che gli abbonati vedono messaggi duplicati. Questa nuova consegna può avvenire per vari motivi:

  • I tuoi abbonati sono sottoutilizzati (hai bisogno di più thread o macchine).

  • L'elaborazione di ogni messaggio richiede più tempo rispetto al termine per l'invio dell'ACK. Le librerie client di Cloud in genere estendono il termine per i singoli messaggi fino a un massimo configurabile. Tuttavia, per le biblioteche è in vigore anche una scadenza massima per l'estensione.

  • Alcuni messaggi causano costantemente l'arresto anomalo del client.

Puoi misurare la frequenza con cui gli abbonati non rispettano la scadenza dell'ack. La metrica specifica dipende dal tipo di abbonamento:

Tassi di scadenza eccessivi dell'ack possono comportare inefficienze costose nel tuo sistema. Paghi per ogni nuova consegna e per ogni tentativo di elaborazione ripetuta di ogni messaggio. Al contrario, un tasso di scadenza basso (ad esempio, 0,1-1%) potrebbe essere positivo.

Monitorare il throughput dei messaggi

Gli abbonati Pull e StreamingPull potrebbero ricevere batch di messaggi in ogni risposta pull; gli abbonamenti push ricevono un singolo messaggio in ogni richiesta push. Puoi monitorare la velocità effettiva dei messaggi batch elaborati dai tuoi abbonati con queste metriche:

Puoi monitorare la velocità effettiva di elaborazione dei messaggi individuali o non batch da parte dei tuoi abbonati con la metrica subscription/sent_message_count filtrata in base all'etichetta delivery_type.

La seguente query PromQL mostra un grafico delle serie temporali che indica il numero totale di messaggi inviati a un abbonamento Pub/Sub specifico in un periodo di 10 minuti. Sostituisci i valori segnaposto per $PROJECT_NAME e $SUBSCRIPTION_NAME con gli identificatori effettivi del progetto e dell'argomento.

sum(
  increase({
    "__name__"="pubsub.googleapis.com/subscription/sent_message_count",
    "monitored_resource"="pubsub_subscription",
    "project_id"="$PROJECT_NAME",
    "subscription_id"="$SUBSCRIPTION_NAME"
  }[10m])
)

Monitorare le sottoscrizioni push

Per gli abbonamenti push, monitora queste metriche:

  • subscription/push_request_count

    Raggruppa la metrica per response_code e subscription_id. Poiché le sottoscrizioni push Pub/Sub utilizzano i codici di risposta come riconoscimenti impliciti dei messaggi, è importante monitorare i codici di risposta delle richieste push. Poiché le iscrizioni push si ritirano in modo esponenziale quando si verificano timeout o errori, il backlog può aumentare rapidamente in base alla risposta dell'endpoint.

    Ti consigliamo di impostare un avviso per tassi di errore elevati, in quanto questi tassi comportano una consegna lenta e un backlog crescente. Puoi creare una metrica filtrata in base alla classe di risposta. Tuttavia, i conteggi delle richieste push sono probabilmente più utili come strumento per esaminare le dimensioni e l'età del backlog in crescita.

  • subscription/num_outstanding_messages

    Pub/Sub in genere limita il numero di messaggi in sospeso. Nella maggior parte dei casi,cerca di avere meno di 1000 messaggi in sospeso. Una volta che il throughput raggiunge una velocità dell'ordine di 10.000 messaggi al secondo, il servizio regola il limite per il numero di messaggi in sospeso. Questa limitazione viene eseguita in incrementi di 1000. Oltre al valore massimo, non vengono fornite garanzie specifiche,pertanto 1000 messaggi in attesa è un buon punto di riferimento.

  • subscription/push_request_latencies

    Questa metrica ti aiuta a comprendere la distribuzione della latenza di risposta dell'endpoint push. A causa del limite al numero di messaggi in sospeso, la latenza dell'endpoint influisce sulla velocità effettiva della sottoscrizione. Se l'elaborazione di ogni messaggio richiede 100 millisecondi, il limite di throughput è probabilmente di 10 messaggi al secondo.

Per accedere a limiti più elevati per i messaggi in sospeso, gli iscritti push devono confermare più del 99% dei messaggi che ricevono.

Puoi calcolare la frazione di messaggi riconosciuti dagli abbonati utilizzando PromQL. La seguente query PromQL crea un grafico con la frazione di messaggi riconosciuti dagli abbonati in un abbonamento:

rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION",
  "response_class"="ack"
}[${__interval}])
/
rate({
  "__name__"="pubsub.googleapis.com/subscription/push_request_count",
  "monitored_resource"="pubsub_subscription",
  "subscription_id"="$SUBSCRIPTION"
}[${__interval}])

Monitorare gli abbonamenti con i filtri

Se configuri un filtro per una sottoscrizione, Pub/Sub riconosce automaticamente i messaggi che non corrispondono al filtro. Puoi monitorare questa conferma automatica.

Le metriche del backlog includono solo i messaggi che corrispondono al filtro.

Per monitorare la frequenza dei messaggi con riconoscimento automatico che non corrispondono al filtro, utilizza la metrica subscription/ack_message_count con l'etichetta delivery_type impostata su filter.

Per monitorare la velocità effettiva e il costo dei messaggi con riconoscimento automatico che non corrispondono al filtro, utilizza la metrica subscription/byte_cost con l'etichetta operation_type impostata su filter_drop. Per ulteriori informazioni sulle tariffe per questi messaggi, consulta la pagina dei prezzi di Pub/Sub.

Monitorare gli abbonamenti con i SMT

Se il tuo abbonamento contiene un SMT che filtra i messaggi, le metriche del backlog includono i messaggi filtrati fino a quando l'SMT non viene eseguito. Ciò significa che il backlog potrebbe apparire più grande e l'età del messaggio senza ACK meno recente potrebbe apparire più vecchia di quella che verrà inviata al tuo abbonato. È particolarmente importante tenerlo presente se utilizzi queste metriche per la scalabilità automatica degli abbonati.

Monitorare i messaggi inoltrati non recapitabili

Per monitorare i messaggi non recapitabili che Pub/Sub inoltra a un argomento dead letter, utilizza la metrica subscription/dead_letter_message_count. Questa metrica mostra il numero di messaggi non recapitabili che Pub/Sub inoltra da una sottoscrizione.

Per verificare che Pub/Sub inoltri i messaggi non recapitabili, puoi confrontare la metrica subscription/dead_letter_message_count con la metrica topic/send_request_count. Esegui il confronto per l'argomento messaggi non recapitabili a cui Pub/Sub inoltra questi messaggi.

Puoi anche collegare un abbonamento all'argomento messaggi non recapitabili e monitorare i messaggi non recapitabili inoltrati in questo abbonamento utilizzando le seguenti metriche:

Mantenere un publisher sano

L'obiettivo principale di un publisher è rendere persistenti rapidamente i dati dei messaggi. Monitora questo rendimento utilizzandotopic/send_request_count, raggruppato per response_code. Questa metrica indica se Pub/Sub è integro e accetta richieste.

Un tasso di errori ripetibili in background (inferiore all'1%) non è motivo di preoccupazione, poiché la maggior parte delle librerie client Cloud ritenta gli errori dei messaggi. Esamina i tassi di errore superiori all'1%. Poiché i codici non riproducibili vengono gestiti dall'applicazione (anziché dalla libreria client), devi esaminare i codici di risposta. Se la tua applicazione publisher non ha un buon modo per segnalare uno stato non integro, valuta la possibilità di impostare un avviso per la metrica topic/send_request_count.

È altrettanto importante monitorare le richieste di pubblicazione non riuscite nel client di pubblicazione. Sebbene le librerie client in genere riprovino le richieste non riuscite, non garantiscono la pubblicazione. Consulta la sezione Pubblicazione di messaggi per scoprire come rilevare errori di pubblicazione permanenti quando utilizzi le librerie client Cloud. Come minimo, l'applicazione dell'editore deve registrare gli errori di pubblicazione permanenti. Se registri questi errori in Cloud Logging, puoi configurare una metrica basata su log con un criterio di avviso.

Monitorare il throughput dei messaggi

I publisher potrebbero inviare messaggi in batch. Puoi monitorare il throughput dei messaggi inviati dai tuoi publisher con queste metriche:

Per ottenere un conteggio preciso dei messaggi pubblicati, utilizza la seguente query PromQL. Questa query PromQL recupera in modo efficace il conteggio dei singoli messaggi pubblicati in un argomento Pub/Sub specifico entro intervalli di tempo definiti. Sostituisci i valori segnaposto per $PROJECT_NAME e $TOPIC_ID con gli identificatori effettivi del progetto e dell'argomento.

sum by (topic_id) (
  increase({
    "__name__"="pubsub.googleapis.com/topic/message_sizes_count",
    "monitored_resource"="pubsub_topic",
    "project_id"="$PROJECT_NAME",
    "topic_id"="$TOPIC_ID"
  }[${__interval}])
)

Per una visualizzazione migliore, soprattutto per le metriche giornaliere, tieni presente quanto segue:

  • Visualizza i tuoi dati su un periodo più lungo per fornire un contesto più ampio per le tendenze giornaliere.

  • Utilizza i grafici a barre per rappresentare il conteggio giornaliero dei messaggi.

Passaggi successivi