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 tramite 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 Monitoring, assicurati di aver preparato quanto segue:

  • Un account di fatturazione Cloud.

  • Un progetto Pub/Sub con fatturazione abilitata

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

Visualizza una dashboard esistente

Una dashboard ti consente di visualizzare e analizzare dati 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 visualizza i dati delle metriche, i criteri di avviso e le voci di log relative a Pub/Sub.

Per monitorare il progetto Pub/Sub utilizzando Cloud Monitoring, esegui 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 saperne di più su come creare, modificare e gestire una dashboard personalizzata, consulta Gestire le dashboard personalizzate.

Visualizza 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 Abbonamento Pub/Sub o Argomento Pub/Sub.

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

    Viene visualizzata la pagina relativa a 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

Monitora 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 attuali.

Puoi visualizzare l'utilizzo storico delle quote 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 Monitoring Query Language 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à i limiti di quota predefiniti, crea criteri di avviso per tutte le quote pertinenti. Questi avvisi vengono attivati quando l'utilizzo raggiunge una parte del limite. Ad esempio, la seguente query Monitoring Query Language attiva un criterio di avviso quando una 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.

Mantieni un abbonamento integro

Per mantenere un abbonamento integro, puoi monitorare diverse proprietà di sottoscrizione utilizzando le metriche fornite da Pub/Sub. Ad esempio, puoi monitorare il volume dei messaggi non confermati, la scadenza delle scadenze di conferma dei messaggi e così via. Puoi anche controllare se la sottoscrizione è sufficientemente integro da raggiungere una bassa latenza di consegna dei messaggi.

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

Monitora il backlog dei messaggi

Crea una dashboard per assicurarti che i sottoscrittori stiano al passo con il flusso dei messaggi. La dashboard può mostrare le seguenti metriche di backlog, aggregate per risorsa, per tutte le 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 un milione di messaggi potrebbe essere accettabile per una sottoscrizione a un milione di messaggi al secondo, ma non è accettabile per una sottoscrizione a un messaggio al secondo.

Problemi comuni arretrati

Sintomi Problema Soluzioni
Sia oldest_unacked_message_age che num_undelivered_messages stanno crescendo di pari passo. I sottoscrittori non riescono a tenere il passo con il volume dei messaggi
  • Aggiungi altri thread o processi del sottoscrittore.
  • Aggiungi altre macchine o container di sottoscrittori.
  • Cerca nel codice la presenza di eventuali bug che gli impediscano di riconoscere correttamente i messaggi o di elaborarli in modo tempestivo. Consulta Scadenza della scadenza ACK Monitoring.
Se il backlog è fisso e ridotto e il valore oldest_unacked_message_age è in costante crescita, è possibile che alcuni messaggi non possano essere elaborati. Messaggi bloccati
  • Esamina i log delle applicazioni per capire se alcuni messaggi causano l'arresto anomalo del codice. È improbabile, ma possibile, che i messaggi offensivi siano bloccati in Pub/Sub anziché nel tuo client. Invia una richiesta di assistenza dopo aver verificato che il codice abbia elaborato correttamente ogni messaggio.
  • Se alcuni messaggi causano l'arresto anomalo del codice, valuta la possibilità di inoltrarli a un argomento messaggi non recapitabili.
Il 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 scada la durata di conservazione dei messaggi.

Monitora l'integrità della latenza di distribuzione

In Pub/Sub, la latenza di consegna è il tempo necessario per consegnare un messaggio pubblicato a un sottoscrittore. Se il backlog dei 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 insight sui seguenti criteri, necessari affinché un abbonamento possa raggiungere una bassa latenza coerente:

  • 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 la sottoscrizione ha costantemente una capacità adeguata per l'elaborazione di nuovi messaggi.

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

  • Richieste di ricerca: se l'abbonamento ha ricevuto richieste di ricerca negli ultimi 10 minuti, il punteggio è impostato su 0. Cercare una sottoscrizione potrebbe causare la riproduzione dei messaggi precedenti molto tempo dopo la loro prima pubblicazione, aumentando la latenza di recapito.

  • Messaggi riconosciuti negativamente (nack): se la sottoscrizione ha ricevuto richieste di conferma negativa (nack) negli ultimi 10 minuti, il punteggio è impostato su 0. Una conferma negativa comporta il riconsegna di un messaggio con una maggiore latenza di recapito.

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

  • Latenze di riconoscimento: 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 il client sottoscrittore sta impiegando tempi insolitamente lunghi per elaborare un messaggio. Questo punteggio potrebbe sottintendere un bug o alcuni vincoli 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 abbastanza stream aperti, il punteggio è impostato su 0. Apri più flussi per assicurarti di disporre di capacità adeguata per i nuovi messaggi.

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

    • Pull: se non disponi di un numero sufficiente di richieste di pull in sospeso, il punteggio è 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 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 posiziona il cursore su un'ora specifica 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 integrità combinato sale a 5 alle 04:15, con un punteggio di 1 per ogni criterio. In seguito, il punteggio combinato diminuisce a 4 alle 04:20, quando il punteggio di utilizzo scende a 0.

Screenshot della metrica della latenza di pubblicazione

Monitoring Query Language fornisce un'interfaccia espressiva basata su testo per i dati delle serie temporali di Cloud Monitoring. La seguente query MQL crea un grafico per misurare il punteggio di integrità della latenza di distribuzione 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 consegna dei messaggi, Pub/Sub consente ai client sottoscritti per un periodo di tempo limitato di confermare (ACK) un determinato messaggio. Questo periodo di tempo è noto come scadenza ACK. Se i sottoscrittori impiegano troppo tempo per confermare i messaggi, questi vengono recapitati di nuovo, di conseguenza i sottoscrittori vedono messaggi duplicati. Questo nuovo caricamento può avvenire per vari motivi:

  • Il provisioning dei tuoi sottoscrittori è in difetto (hai bisogno di più thread o macchine).

  • L'elaborazione di ogni messaggio richiede più tempo rispetto alla scadenza di conferma. Le librerie client di Cloud di solito estendono la scadenza per i singoli messaggi fino a un massimo configurabile. Tuttavia, è prevista una scadenza massima per l'estensione anche per le librerie.

  • Alcuni messaggi causano l'arresto anomalo del client in modo costante.

Puoi misurare la frequenza con cui gli iscritti non rispettano la scadenza di conferma. La metrica specifica dipende dal tipo di sottoscrizione:

Un'eccessiva frequenza di scadenza della conferma di ricezione può causare costose inefficienze nel sistema. Paghi per ogni nuova consegna e per il tentativo di elaborare ogni messaggio ripetutamente. Al contrario, una percentuale di scadenza ridotta (ad es.0, 1-1%) potrebbe essere integra.

Monitora la velocità effettiva dei messaggi

I sottoscrittori Pull e StreamingPull possono ricevere batch di messaggi in ogni risposta pull; le sottoscrizioni push ricevono un singolo messaggio in ogni richiesta push. Puoi monitorare la velocità effettiva dei messaggi batch che viene elaborata dai sottoscrittori con queste metriche:

Puoi monitorare la velocità effettiva dei messaggi singoli o non in batch elaborati dai sottoscrittori utilizzando la metrica subscription/sent_message_count filtrata in base all'etichetta delivery_type.

Monitorare le sottoscrizioni 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 conferme implicite dei messaggi, è importante monitorare i codici di risposta alle richieste push. Poiché il push delle sottoscrizioni si annulla in modo esponenziale quando si verificano timeout o errori, il tuo backlog può crescere rapidamente in base alla risposta dell'endpoint.

    Valuta la possibilità di impostare un avviso per tassi di errore elevati, poiché queste percentuali portano a una distribuzione lenta e a un backlog crescente. Puoi creare una metrica filtrata per classe di risposta. Tuttavia, i conteggi delle richieste push sono probabilmente più utili come strumento per indagare sull'aumento delle dimensioni e dell'età del backlog.

  • subscription/num_outstanding_messages

    Pub/Sub di solito limita il numero di messaggi in sospeso. Nella maggior parte dei casi,cerca di contenere meno di 1000 messaggi in sospeso. Una volta che la velocità effettiva raggiunge una velocità nell'ordine di 10.000 messaggi al secondo, il servizio regola il limite per il numero di messaggi in sospeso. Questa limitazione viene applicata per incrementi di 1000. Non vengono fornite garanzie specifiche oltre il valore massimo, quindi 1000 messaggi in sospeso sono una buona guida.

  • subscription/push_request_latencies

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

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

Puoi calcolare la frazione dei messaggi confermati dai sottoscrittori utilizzando Monitoring Query Language. La seguente query MQL crea un grafico con la frazione dei messaggi che i sottoscrittori riconoscono in 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 gli abbonamenti con i filtri

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

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

Per monitorare la percentuale di 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 velocità effettiva e il costo dei messaggi con ACK 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.

Monitora i messaggi non recapitabili inoltrati

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

Puoi anche collegare una sottoscrizione all'argomento messaggi non recapitabili e monitorare i messaggi non recapitabili inoltrati in questa sottoscrizione utilizzando le seguenti metriche:

Mantieni un publisher integro

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

Una percentuale in background di errori non irreversibili (inferiore all'1%) non è motivo di preoccupazione, poiché la maggior parte delle librerie client di Cloud riprova a eseguire gli errori relativi ai messaggi. Esamina i tassi di errore superiori all'1%. Poiché i codici non riutilizzabili vengono gestiti dall'applicazione (anziché dalla libreria client), è necessario esaminare i codici di risposta. Se la tua applicazione del publisher non dispone di un modo valido per segnalare uno stato non integro, ti consigliamo di impostare un avviso per la metrica topic/send_request_count.

È altrettanto importante tenere traccia delle richieste di pubblicazione non riuscite nel client di pubblicazione. Anche se le librerie client in genere riprovano le richieste non riuscite, non garantiscono la pubblicazione. Consulta Pubblicazione di messaggi per scoprire come rilevare errori di pubblicazione permanenti quando si utilizzano le librerie client di 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.

Monitora la velocità effettiva dei messaggi

I publisher possono inviare messaggi in batch. Puoi monitorare la velocità effettiva dei messaggi inviata dai publisher con queste metriche:

  • topic/send_request_count: il volume di messaggi in blocco inviati dagli editori.

  • Un conteggio di topic/message_sizes: il volume di messaggi singoli (non in batch) inviati dagli editori.

    Per calcolare il conteggio dei messaggi inviati, puoi applicare un aggregatore di conteggio a questa metrica o utilizzare Monitoring Query Language. La seguente query MQL crea un grafico con la percentuale di singoli messaggi inviati su un argomento:

    fetch pubsub_topic
| metric 'pubsub.googleapis.com/topic/message_sizes'
| filter
    (resource.topic_id == '$TOPIC')
| align delta(1m)
| every 1m
| group_by [], [row_count: row_count()]

Passaggi successivi