Monitorare Pub/Sub in Cloud Monitoring

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

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

  • Se vuoi visualizzare le metriche di altre risorse Google Cloud, oltre a le metriche Pub/Sub, utilizzano Monitoring.

  • Altrimenti, puoi usare le dashboard di monitoraggio fornite in Pub/Sub. Consulta Monitorare gli argomenti e Monitorare le iscrizioni.

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 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 dati metrici, criteri di avviso e voci di log relativi a Pub/Sub.

Per monitorare il progetto Pub/Sub con 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 di 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 un dashboard personalizzata, consulta 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 l'argomento Pub/Sub.

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

    Viene aperta la pagina di una metrica specifica.

Per ulteriori informazioni sulla dashboard di monitoraggio, consulta la documentazione di Cloud Monitoring.

Visualizzare le metriche e i tipi di risorse Pub/Sub

Accedi all'editor MQL

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

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

Crea la tua query MQL

Di seguito sono riportate alcune regole di base per creare una query MQL e le metriche Pub/Sub.

  1. Inizia con fetch pubsub_topic o fetch pubsub_subscription. Questa riga indica all'editor il tipo di risorsa Pub/Sub che vuoi su cui eseguire query, come argomenti o abbonamenti.

  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. Usa | 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 consumer_quota monitorato un tipo di risorsa. Per altre metriche relative alla quota, consulta 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 l'utilizzo supererà la 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. Per Ad esempio, la seguente query Monitoring Query Language attiva un criterio di avviso 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 monitoraggio e avvisi più personalizzati sulle metriche delle quote, consulta Utilizzo delle metriche delle quote.

Consulta Quote e limiti per ulteriori informazioni sulle quote.

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 monitora il volume dei messaggi non confermati, la loro scadenza le scadenze di conferma 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 sottoscrittori stiano al passo con il flusso dei messaggi, crea una dashboard. La dashboard può mostrare le seguenti metriche di backlog, aggregate per per tutte le tue sottoscrizioni:

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 milioni di messaggi potrebbero essere accettabili per un milione di messaggi al secondo ma inaccettabile per una sottoscrizione di un messaggio al secondo.

Problemi comuni arretrati

Sintomi Problema Soluzioni
Sia oldest_unacked_message_age che num_undelivered_messages stanno crescendo di pari passo. Gli iscritti non riescono a stare al passo con il volume di messaggi
  • Aggiungi altri thread o processi di abbonamento.
  • Aggiungi altre macchine o container di sottoscrittori.
  • 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 è costante e ridotto e il volume in aumento di oldest_unacked_message_age, è possibile che alcuni messaggi non possano essere elaborati. Messaggi bloccati
  • Esamina i log dell'applicazione per capire se alcuni messaggi stanno causando l'arresto anomalo del codice. È improbabile, ma è possibile che i messaggi offensivi siano bloccati in Pub/Sub anziché nel client. Genera un richiesta di assistenza, dopo aver acquisito il codice elabora correttamente ogni messaggio.
  • Se alcuni messaggi causano l'arresto anomalo del codice, valuta la possibilità di inoltrarli a un argomento per la posta inutilizzata.
oldest_unacked_message_age supera la durata di conservazione dei messaggi della sottoscrizione. Perdita permanente dei dati
  • Configura un avviso che si attivi prima che il messaggio scada durata di conservazione.

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 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 trascurabili con conferma negativa (nacking).

  • Scadenze di conferma dei messaggi scaduti trascurabili.

  • Latenza di conferma coerente inferiore a 30 secondi.

  • Utilizzo ridotto e costante, il che significa che l'abbonamento ha costantemente di elaborazione dei 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. Una conferma negativa determina la visualizzazione di un messaggio viene ricaricato con una latenza di distribuzione maggiore.

  • Scadenze di conferma scadute. Se l'abbonamento è scaduto per la conferma negli ultimi 10 minuti, il punteggio è 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 riconoscimento: se il 99,9° percentile di tutti i riconoscimenti negli ultimi 10 minuti sia stato mai superiore a 30 secondi, il punteggio sia impostato su 0. Una latenza di conferma elevata indica che il client di un sottoscrittore sta impiegando 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 di 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 dell'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 salute combinato sale a 5 alle 04:15, con un pari a 1 per ogni criterio. In seguito, il punteggio combinato diminuisce a 4 04:20, quando il punteggio di utilizzo scende a 0.

Screenshot della metrica della latenza di pubblicazione

Monitoring Query Language fornisce un'interfaccia espressiva e basata su testo per 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

Monitora la scadenza della scadenza di 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 ACK. Se i tuoi abbonati ricevono troppo lunga per confermare i messaggi, questi vengono recapitati di nuovo, sottoscrittori che vedono messaggi duplicati. Questo nuovo caricamento può avvenire per motivi:

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

  • L'elaborazione di ogni messaggio richiede più tempo rispetto alla conferma la scadenza del periodo di conservazione. Le librerie client di Cloud in genere estendono per i singoli messaggi fino a un 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.

Monitora la velocità effettiva 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 una sottoscrizione Pub/Sub specifica ogni 10 minuti. Sostituisci i valori segnaposto per $PROJECT_NAME e $SUBSCRIPTION_NAME con il tuo identificatori effettivi di progetti e argomenti.

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 sottoscrizioni 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 conferma implicita dei messaggi, è importante per monitorare i codici di risposta alle 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 gli alti tassi di errore, poiché questi tassi una distribuzione lenta 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 oltre il 99% dei messaggi che ricevono.

Puoi calcolare la frazione dei messaggi che i sottoscrittori riconoscono utilizzando Monitoring Query Language. La seguente query MQL crea grafico con la frazione di messaggi che i sottoscrittori riconoscono di un abbonamento:

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 gli abbonamenti con i filtri

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

Le metriche di backlog includono solo messaggi che corrispondono al filtro.

Per monitorare la percentuale di messaggi con ACK automatico che non corrispondono al filtro, utilizza il metodo subscription/ack_message_count con l'etichetta delivery_type impostata su filter.

Per monitorare la velocità effettiva e il costo dei messaggi con ACK automatico che non corrispondono usa il filtro subscription/byte_cost metrica con l'etichetta operation_type impostata su filter_drop. Per ulteriori informazioni sulle tariffe per questi messaggi, vedi 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 che Pub/Sub inoltra da un abbonamento.

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. Confrontare l'argomento messaggi non recapitabili a cui Pub/Sub inoltra questi messaggi.

Puoi anche collegare una sottoscrizione all'argomento messaggi non recapitabili e quindi monitorare ha inoltrato i messaggi non recapitabili in questa sottoscrizione 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. Questo metrica indica se Pub/Sub è integro e accettare richieste.

Una percentuale di errori irreversibili (inferiore all'1%) non è un motivo di preoccupazione, poiché la maggior parte delle librerie client di Cloud riprova messaggi non riusciti. Esamina i tassi di errore superiori all'1%. Poiché i codici non ripetibili vengono gestiti dalla tua applicazione (anziché dalla biblioteca client), devi esaminare i codici di risposta. Se il publisher non ha un buon modo per segnalare uno stato non integro, impostando un avviso sulla metrica topic/send_request_count.

È altrettanto importante tenere traccia delle 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. L'applicazione del publisher deve registrare almeno 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 la velocità in bit dei messaggi

I publisher potrebbero inviare i messaggi in batch. Tu monitorare la velocità effettiva dei messaggi inviati dai publisher con questi metriche:

Per ottenere un conteggio preciso dei messaggi pubblicati, utilizza quanto segue una query MQL. Questa query MQL recupera in modo efficace il conteggio di singoli messaggi pubblicati in uno specifico argomento Pub/Sub entro 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, considera quanto segue:

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

  • Utilizza i grafici a barre per rappresentare i conteggi giornalieri dei messaggi.

Passaggi successivi