Monitorare Pub/Sub in Cloud Monitoring

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

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

  • Se vuoi visualizzare le metriche di altre risorse Google Cloud oltre alle metriche Pub/Sub, utilizza Monitoraggio.

  • In caso contrario, puoi utilizzare le dashboard di monitoraggio fornite in Pub/Sub. Consulta Monitorare gli argomenti e Monitorare le sottoscrizioni.

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 sia predefinite che personalizzate. Ad esempio, puoi visualizzare una dashboard Pub/Sub predefinita o creare una dashboard personalizzata che mostri i dati delle metriche, i criteri di avviso e le voci di log relativi 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 progetto se non è già selezionato nella parte superiore della pagina.

  3. Fai clic su Dashboard nel menu di navigazione.

  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, svolgi i seguenti 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 Abbonamento Pub/Sub o Argomento Pub/Sub.

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

    Viene aperta la pagina di una metrica specifica.

Per scoprire di più sulla dashboard di monitoraggio, leggi la documentazione di Cloud Monitoring.

Visualizzare le metriche e i tipi di risorse Pub/Sub

Accedere all'editor MQL

Metrics Explorer è un'interfaccia in Cloud Monitoring progettata per esplorare e visualizzare i dati delle metriche. In Metrics Explorer, puoi utilizzare il Monitoring Query Language(MQL) per eseguire query e analizzare le tue metriche Pub/Sub.

Per accedere all'editor MQL quando utilizzi Metrics Explorer, consulta Accedere all'editor di codice.

Crea la query MQL

Ecco alcune regole di base per creare una query MQL per le metriche Pub/Sub.

  1. Inizia con fetch pubsub_topic o fetch pubsub_subscription. Questa riga di codice indica all'editor il tipo di risorsa Pub/Sub su cui vuoi eseguire una query, ad esempio argomenti o iscrizioni.

  2. Seleziona la metrica. Utilizza | metric 'metric_name' per specificare la metrica che vuoi analizzare. Un esempio di metrica Pub/Sub è pubsub.googleapis.com/subscription/ack_message_count (per i messaggi confermati).

  3. Utilizza | filter per restringere i dati. I filtri più comuni includono:

    • resource.project_id == 'your-project-id'
    • resource.topic_id == 'your-topic-id'
    • resource.subscription_id == 'your-subscription-id'

  4. Utilizza | align e | group_by per aggregare i dati in intervalli e raggruppamenti significativi.

  5. Perfeziona i dati con altre clausole. MQL offre varie altre clausole, come | every (per impostare la frequenza di esecuzione delle query), | within (per specificare un intervallo di tempo) e altre ancora.

Ecco un esempio di query per monitorare il conteggio orario dei messaggi inviati a un abbonamento specifico:

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == 'your-project-id'
&& resource.subscription_id == 'your-subscription-id'
| align delta(1h)
| every 1h
| group_by [], [value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

Monitorare l'utilizzo delle quote

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 MQL crea un grafico con la frazione della quota del publisher utilizzata in ogni regione:

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | filter metric.quota_metric == 'pubsub.googleapis.com/regionalpublisher'
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio

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 il tuo utilizzo raggiunge una certa frazione del limite. Ad esempio, la seguente query Monitoring Query Language attiva un criterio di avviso quando qualsiasi quota Pub/Sub supera l'80% di utilizzo:

fetch consumer_quota
| filter resource.service == 'pubsub.googleapis.com'
| { metric serviceruntime.googleapis.com/quota/rate/net_usage
    | align delta_gauge(1m)
    | group_by [metric.quota_metric, resource.location],
        sum(value.net_usage)
  ; metric serviceruntime.googleapis.com/quota/limit
    | group_by [metric.quota_metric, resource.location],
        sliding(1m), max(val()) }
| ratio
| every 1m
| condition gt(val(), 0.8 '1')

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

Per ulteriori informazioni sulle quote, consulta Quote e limiti.

Mantenere un abbonamento in salute

Per mantenere un abbonamento efficiente, puoi monitorare diverse proprietà dell'abbonamento utilizzando le metriche fornite da Pub/Sub. Ad esempio, puoi monitorare il volume di messaggi non confermati, la scadenza delle scadenze di conferma dei messaggi e così via. Puoi anche verificare se il tuo abbonamento è sufficientemente affidabile per ottenere una latenza di recapito dei messaggi ridotta.

Per ulteriori dettagli sulle metriche specifiche, consulta le sezioni successive.

Monitorare il backlog dei messaggi

Per assicurarti che i tuoi iscritti riescano a tenere il passo con il flusso di messaggi, crea una dashboard. La dashboard può mostrare le seguenti metriche relative al backlog, aggregate per risorsa, per tutti i tuoi abbonamenti:

Crea criteri di avviso che si attivano 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 un abbonamento di un milione di messaggi al secondo, ma non per un abbonamento di un messaggio al secondo.

Problemi comuni relativi alla coda

Sintomi Problema Soluzioni
Sia oldest_unacked_message_age sia num_undelivered_messages stanno crescendo in tandem. Gli iscritti non riescono a stare al passo con il volume di messaggi
  • Aggiungi altri thread o processi di abbonamento.
  • Aggiungi altre macchine o altri contenitori degli abbonati.
  • Cerca segni di bug nel codice che ne impediscono il corretto riconoscimento dei messaggi o la loro elaborazione in modo tempestivo. Consulta Monitorare la scadenza della conferma.
Se il backlog è di piccole dimensioni e costante, ma il valore di oldest_unacked_message_age è in costante crescita, è possibile che alcuni messaggi non possano essere elaborati. Messaggi bloccati
oldest_unacked_message_age supera la durata di conservazione dei messaggi della sottoscrizione. Perdita permanente dei dati
  • Configura un avviso che venga attivato prima del termine del tempo di conservazione dei messaggi.

Monitorare l'integrità della latenza di pubblicazione

In Pub/Sub, la latenza di recapito è il tempo necessario per la consegna di un messaggio pubblicato a un sottoscrittore. Se la coda dei messaggi è in aumento, puoi utilizzare il punteggio di stato della latenza di invio (subscription/delivery_latency_health_score) per verificare quali fattori contribuiscono all'aumento della latenza.

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

  • Richieste di ricerca trascurabili.

  • Messaggi con conferma negativa trascurabili (nacked).

  • Scadenze di conferma dei messaggi scaduti trascurabili.

  • Latenza di conferma coerente inferiore a 30 secondi.

  • Utilizzo ridotto costante, il che significa che l'abbonamento ha costantemente una capacità adeguata per elaborare i nuovi messaggi.

La metrica Punteggio integrità latenza di pubblicazione riporta 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 vecchi messaggi molto tempo dopo la loro prima pubblicazione, aumentando la latenza di recapito.

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

  • Scadenze di ack scadute: se l'abbonamento ha avuto scadenze di ack scadute negli ultimi 10 minuti, il punteggio viene impostato su 0. I messaggi per i quali è scaduta la scadenza di conferma vengono recapitati di nuovo con una latenza di recapito maggiore.

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

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

    • StreamingPull: se non hai abbastanza stream aperti, 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 la capacità per i nuovi messaggi.

    • Pull: se non hai richieste pull in sospeso sufficienti, 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 stato della latenza di invio per il tipo di risorsa abbonamento Pub/Sub. Aggiungi un filtro per selezionare un solo abbonamento alla volta. Seleziona il grafico ad area cumulativa e passa il mouse sopra 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 integrità combinato aumenta a 5 alle 04:15, con un punteggio di 1 per ogni criterio. Successivamente, il punteggio combinato diminuisce a 4 alle 4:20, quando il punteggio di utilizzo scende a 0.

Screenshot della metrica relativa alla latenza di pubblicazione

Monitoring Query Language fornisce un'interfaccia espressiva basata su testo per accedere ai dati delle serie temporali di Cloud Monitoring. La seguente query MQL crea un grafico per misurare il punteggio di integrità della latenza di pubblicazione per un abbonamento.

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/delivery_latency_health_score'
| filter (resource.subscription_id == '$SUBSCRIPTION')
| group_by 1m,
   [value_delivery_latency_health_score_sum:
     sum(if(value.delivery_latency_health_score, 1, 0))]
| every 1m

Monitorare la scadenza della conferma

Per ridurre la latenza di recapito dei messaggi, Pub/Sub consente ai client sottoscrittori un periodo di tempo limitato per confermare (ack) un determinato messaggio. Questo periodo di tempo è noto come scadenza per l'acknowledgement. Se i tuoi abbonati impiegano troppo tempo per confermare i messaggi, questi vengono recapitati di nuovo, con il risultato che gli abbonati li vedono duplicati. Questo ricaricamento può verificarsi per vari motivi:

  • Il numero di iscritti è insufficiente (sono necessari più thread o macchine).

  • L'elaborazione di ogni messaggio richiede più tempo rispetto alla scadenza per l'ACK del messaggio. In genere, le librerie client Cloud estendono la scadenza per i singoli messaggi fino a un valore massimo configurabile. Tuttavia, è in vigore anche una data di scadenza massima per le estensioni delle librerie.

  • Alcuni messaggi fanno sempre arrestare in modo anomalo il client.

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

Tassi di scadenza della conferma eccessivi possono comportare inefficienze costose nel sistema. Paghi per ogni nuova consegna e per ogni tentativo di elaborare ripetutamente ogni messaggio. Al contrario, un tasso di scadenza ridotto (ad esempio 0, 1-1%) potrebbe essere considerato normale.

Monitorare la velocità in bit dei messaggi

Gli iscritti a pull e streaming pull potrebbero ricevere lotti 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 dagli abbonati con le seguenti metriche:

Puoi monitorare la produttività dei messaggi singoli o non raggruppati elaborati dai tuoi abbonati con la metrica subscription/sent_message_count filtrata in base all'etichetta delivery_type.

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

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/sent_message_count'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.subscription_id == '$SUBSCRIPTION_NAME'
| align delta(10m)
| every 10m
| group_by [],
[value_sent_message_count_aggregate: aggregate(value.sent_message_count)]

Monitorare le iscrizioni push

Per le iscrizioni push, monitora queste metriche:

  • subscription/push_request_count

    Raggruppa la metrica per response_code e subcription_id. Poiché le sottoscrizioni push di 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ò crescere rapidamente in base alla risposta dell'endpoint.

    Valuta la possibilità di impostare un avviso per tassi di errori elevati, poiché questi tassi comportano un caricamento lento e un backlog in crescita. 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 la durata crescenti del backlog.

  • subscription/num_outstanding_messages

    In genere, Pub/Sub limita il numero di messaggi in sospeso. Cerca di avere meno di 1000 messaggi in attesa nella maggior parte delle situazioni. Una volta che il throughput raggiunge una frequenza dell'ordine di 10.000 messaggi al secondo, il servizio regola il limite per il numero di messaggi in sospeso. Questa limitazione viene applicata in incrementi di 1000. Non vengono fornite garanzie specifiche oltre il valore massimo, quindi 1000 messaggi in attesa sono una buona guida.

  • subscription/push_request_latencies

    Questa metrica ti aiuta a comprendere la distribuzione della latenza di risposta dell'endpoint push. A causa del limite sul numero di messaggi in sospeso, la latenza dell'endpoint influisce sul throughput dell'abbonamento. Se sono necessari 100 millisecondi per elaborare ogni messaggio, è probabile che il limite di throughput sia di 10 messaggi al secondo.

Per accedere a limiti di messaggi in attesa più elevati, gli iscritti alle notifiche push devono confermare più del 99% dei messaggi che ricevono.

Puoi calcolare la frazione di messaggi confermati dagli abbonati utilizzando il Monitoring Query Language. La seguente query MQL crea un grafico con la frazione di messaggi confermati dagli iscritti su una sottoscrizione:

fetch pubsub_subscription
| metric 'pubsub.googleapis.com/subscription/push_request_count'
| filter
    (resource.subscription_id == '$SUBSCRIPTION')
    | filter_ratio_by [], metric.response_class == 'ack'
    | every 1m

Monitorare le iscrizioni con i filtri

Se configuri un filtro su una sottoscrizione, Pub/Sub conferma automaticamente i messaggi che non corrispondono al filtro. Puoi monitorare questo riconoscimento automatico.

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

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

Per monitorare la produttività e il costo dei messaggi con conferma automatica 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 i messaggi inoltrati non recapitati

Per monitorare i messaggi non recapitabili che Pub/Sub inoltra a un argomento messaggi non recapitabili, utilizza la metrica subscription/dead_letter_message_count. Questa metrica mostra il numero di messaggi non recapitabili inoltrati da Pub/Sub 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 allegare un abbonamento all'argomento messaggi non recapitabili e monitorare i messaggi non recapitati inoltrati su questo abbonamento utilizzando le seguenti metriche:

Mantenere un publisher sano

L'obiettivo principale di un publisher è mantenere rapidamente i dati dei messaggi. Monitora questo rendimento utilizzando topic/send_request_count , raggruppato per response_code. Questa metrica indica se Pub/Sub è in stato di integrità e accetta richieste.

Una percentuale di errori ripetibili in background (inferiore all'1%) non è motivo di preoccupazione, poiché la maggior parte delle librerie client Cloud riprova in caso di errori di messaggio. Esamina i tassi di errore superiori all'1%. Poiché i codici non ripetibili vengono gestiti dall'applicazione (anziché dalla libreria client), devi esaminare i codici di risposta. Se l'applicazione del publisher non ha un buon modo per segnalare uno stato non corretto, valuta la possibilità di impostare un avviso sulla metrica topic/send_request_count.

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

Monitorare la velocità in bit dei messaggi

I publisher potrebbero inviare i messaggi in lotti. 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 MQL. Questa query MQL recupera in modo efficace il conteggio dei singoli messaggi pubblicati in un argomento Pub/Sub specifico in intervalli di tempo definiti. Sostituisci i valori segnaposto per $PROJECT_NAME e $TOPIC_ID con gli identificativi del progetto e dell'argomento effettivi.

fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter resource.project_id == '$PROJECT_NAME'
&& resource.topic_id == '$TOPIC_ID'
| align delta(60m)
| every 60m
| group_by [resource.topic_id],
[value_message_sizes_sum: count(value.message_sizes)]

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

  • Visualizza i dati su un periodo di tempo più lungo per fornire un contesto più ampio alle tendenze giornaliere.

  • Utilizza i grafici a barre per rappresentare il numero di messaggi giornalieri.

Passaggi successivi