Panoramica del monitoraggio

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Per monitorare Pub/Sub, puoi utilizzare la console Google Cloud o l'API Cloud Monitoring.

Prima di iniziare

Prima di utilizzare Cloud Monitoring, assicurati di aver preparato quanto segue:

  • Un account di fatturazione Cloud

  • Un progetto Pub/Sub con fatturazione abilitata

Un modo per assicurarti di aver ottenuto entrambi è completare la Guida rapida utilizzando Cloud Console.

Visualizza una dashboard esistente

Una dashboard ti consente di visualizzare e analizzare i dati da origini diverse nello stesso contesto. Google Cloud fornisce dashboard predefinite e personalizzate. Ad esempio, puoi visualizzare una dashboard Pub/Sub predefinita o crearne una personalizzata che mostri 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 i seguenti passaggi:

  1. In Google Cloud Console, vai alla pagina Monitoring.

    Vai a Monitoring

  2. Seleziona il nome del tuo 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, consulta Gestire le dashboard personalizzate.

Visualizzare una singola metrica Pub/Sub

Per visualizzare una singola metrica Pub/Sub utilizzando la console Google Cloud, esegui i seguenti passaggi:

  1. In Google Cloud Console, vai alla pagina Monitoring.

    Vai a Monitoring

  2. Nel riquadro di navigazione, seleziona Metrics Explorer.

  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.

    Si apre la pagina relativa a una metrica specifica.

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

Visualizza metriche Pub/Sub e tipi di risorse

Monitora l'utilizzo della quota

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

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 alla quota, consulta l'elenco delle metriche.

Ad esempio, la seguente query Monitoring Query Language crea un grafico con la frazione di quota del publisher utilizzata in ogni area geografica:

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 supera 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 di quota.

Consulta Quote e limiti per ulteriori informazioni sulle quote.

Mantenere un abbonamento sano

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

Fai riferimento alle sezioni successive per ulteriori dettagli sulle metriche specifiche.

Monitora backlog dei messaggi

Per assicurarti che i tuoi iscritti continuino a seguire il flusso dei messaggi, crea una dashboard. La dashboard può mostrare le seguenti metriche di 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 una sottoscrizione che prevede un milione di messaggi al secondo, ma non è accettabile per una sottoscrizione di un messaggio al secondo.

Problemi di backlog comuni

Sintomi Problema Soluzioni
Sia oldest_unacked_message_age che num_undelivered_messages stanno crescendo in tandem. Gli iscritti non riescono a stare al passo con il volume dei messaggi
  • Aggiungi altri thread o processi agli iscritti.
  • Aggiungi altri computer o container degli abbonati.
  • Verifica la presenza di segnali di bug nel codice che impediscono il riconoscimento corretto dei messaggi o l'elaborazione tempestiva dei messaggi. Vedi Scadenza scadenza monitoraggio.
Se le dimensioni del backlog sono piccole e costanti, insieme a un oldest_unacked_message_age in costante crescita, potrebbero esserci alcuni messaggi che non possono essere elaborati. Messaggi bloccati
  • Esamina i log dell'applicazione per capire se alcuni messaggi stanno causando l'arresto anomalo del tuo codice. È improbabile, ma possibile, che i messaggi offensivi vengano bloccati in Pub/Sub anziché nel client. Invia una richiesta di assistenza dopo aver verificato che il codice sia stato elaborato correttamente per ogni messaggio.
  • Se alcuni messaggi causano l'arresto anomalo del tuo codice, valuta la possibilità di inoltrare tali messaggi a un argomento messaggi non recapitabili.
oldest_unacked_message_age supera la durata di conservazione dei messaggi dell'abbonamento. Perdita permanente dei dati
  • Configura un avviso che si attiva prima che scada il tempo di conservazione dei messaggi.

Monitorare lo stato della latenza di pubblicazione

In Pub/Sub, la latenza di pubblicazione è la quantità di tempo trascorso dopo la pubblicazione di un messaggio e la sua consegna a un sottoscrittore. Se il backlog dei tuoi messaggi è in aumento, puoi utilizzare il punteggio di integrità della latenza di pubblicazione (subscription/delivery_latency_health_score) per verificare quali fattori contribuiscono a una latenza più elevata.

Questa metrica misura lo stato di un singolo abbonamento in una finestra temporale continua di 10 minuti. La metrica fornisce informazioni sui seguenti criteri, che sono necessari affinché un abbonamento abbia una bassa latenza coerente:

  • Richieste di rimozione trascurabili.

  • Messaggi trascurabili riconosciuti come negativi.

  • Scadenza trascurabile di conferma di ricezione di messaggi.

  • Latenza di riconoscimento coerente inferiore a 30 secondi.

  • Un utilizzo ridotto e costante, il che significa che la sottoscrizione ha costantemente una capacità adeguata per elaborare i nuovi messaggi.

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

  • Cerca richieste: se la sottoscrizione ha ricevuto richieste di ricerca negli ultimi 10 minuti, il punteggio è impostato su 0. La ricerca di una sottoscrizione potrebbe causare la riproduzione ripetuta dei messaggi precedenti dopo la prima pubblicazione, con un conseguente aumento della latenza di recapito.

  • Messaggi confermati negativi (nack): se la sottoscrizione ha ricevuto richieste di riconoscimento negativo (nack) negli ultimi 10 minuti, il punteggio è impostato su 0. Una conferma negativa comporta il riconsegna di un messaggio con un aumento della latenza di recapito.

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

  • 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 è impostato su 0. Una latenza elevata di riconoscimento è un segnale che un client sottoscrittore sta impiegando un tempo insolitamente lungo per elaborare un messaggio. Questo punteggio può indicare un bug o alcuni vincoli delle risorse sul lato client di abbonamento.

  • 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 altri stream per assicurarti di avere capacità sufficiente per i nuovi messaggi.

    • Inviare: se il numero di messaggi in sospeso per l'endpoint push è eccessivo, il punteggio è 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 di pull in sospeso, il punteggio è impostato su 0. Apri altre richieste di pull simultanee per assicurarti di poter ricevere nuovi messaggi.

Per visualizzare la metrica, in Metrics Explorer, seleziona la metrica Punteggio integrità di latenza di pubblicazione per il tipo di risorsa di sottoscrizione Pub/Sub. Aggiungi un filtro per selezionare un solo abbonamento alla volta. Seleziona il grafico ad area in pila e seleziona un punto specifico per visualizzare i punteggi dei criteri per l'abbonamento per 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 arriva fino a 5 alle 4:15, con un punteggio di 1 per ogni criterio. Successivamente, il punteggio combinato scende 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 di 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 conferma di conferma

Per ridurre la latenza di recapito dei messaggi, Pub/Sub consente ai client di sottoscrizione un periodo di tempo limitato di confermare (ACK) un determinato messaggio. Questo periodo di tempo è noto come scadenza dell'ACK. Se i tuoi iscritti impiegano troppo tempo per confermare l'accettazione dei messaggi, questi vengono ripubblicati e gli utenti visualizzeranno messaggi duplicati. Questa pubblicazione può avvenire per diversi motivi:

  • Il numero degli iscritti risulta insufficiente. Ti servono più thread o macchine.

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

  • Alcuni messaggi arrestano in modo anomalo il client.

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

Tassi di scadenza eccessivi per la scadenza possono comportare inutili inefficienze nel tuo sistema. Paghi per ogni nuova pubblicazione e per tentare di elaborare ciascun messaggio ripetutamente. Al contrario, un tasso di scadenza ridotto (ad esempio, 0,1-1%) potrebbe essere integro.

Monitorare la velocità effettiva del messaggio

I sottoscrittori pull e StreamingPull potrebbero ricevere batch di messaggi in ogni risposta pull; le sottoscrizioni push ricevono un singolo messaggio in ogni richiesta push. Puoi monitorare la velocità effettiva del messaggio batch elaborato dai tuoi abbonati con queste metriche:

Puoi monitorare la velocità effettiva del messaggio singolo o non in batch elaborata dai tuoi abbonati con la metrica subscription/sent_message_count filtrata dall'etichetta delivery_type.

Monitorare gli abbonamenti push

Per gli abbonamenti 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 di messaggi implicite, è importante monitorare i codici di risposta delle richieste push. Poiché gli abbonamenti push escono in modo esponenziale quando si verificano timeout o errori, il tuo backlog può crescere rapidamente in base alle risposte dell'endpoint.

    Potresti impostare un avviso per tassi di errore elevati, poiché queste percentuali generano una pubblicazione lenta e un backlog in crescita. Puoi creare una metrica filtrata in base alla classe di risposta. Tuttavia, è probabile che il conteggio delle richieste push sia più utile come strumento per analizzare le dimensioni e l'età del backlog in crescita.

  • subscription/num_outstanding_messages

    In genere, Pub/Sub limita il numero di messaggi in sospeso. Cerca di avere meno di 1000 messaggi in sospeso nella maggior parte delle situazioni. Quando la velocità effettiva 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 applicata in incrementi di 1000. Non vengono fornite garanzie specifiche oltre il valore massimo, quindi 1000 messaggi in sospeso sono una guida utile.

  • subscription/push_request_latencies

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

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

Puoi calcolare la frazione dei messaggi che gli abbonati riconoscono utilizzando il linguaggio di query di Monitoring. La seguente query MQL crea un grafico con la frazione di messaggi che gli abbonati 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

Pub/Sub riconosce automaticamente i messaggi che non corrispondono a un filtro. Puoi monitorare il numero, le dimensioni e il costo di questi messaggi.

Per monitorare il numero di messaggi che non corrispondono a un filtro, utilizza la metrica subscription/ack_message_count con l'etichetta delivery_type e il valore filter.

Per monitorare le dimensioni e il costo dei messaggi che non corrispondono a un filtro, utilizza la metrica subscription/byte_cost con l'etichetta operation_type e il valore filter_drop. Per ulteriori informazioni sulle tariffe per questi messaggi, consulta la pagina dei prezzi di Pub/Sub.

Monitorare 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. Esegui un confronto per l'argomento messaggi non recapitati a cui Pub/Sub inoltra questi messaggi.

Puoi anche allegare una sottoscrizione all'argomento messaggi non recapitabili e quindi monitorare i messaggi non recapitati inoltrati su questa sottoscrizione utilizzando le seguenti metriche:

Mantenere un publisher integro

L'obiettivo principale di un publisher è rendere rapidamente i dati dei messaggi. Monitora queste prestazioni utilizzando topic/send_request_count, raggruppate per response_code. Questa metrica fornisce un'indicazione dello stato di integrità di Pub/Sub e accetta le richieste.

Una frequenza di background con errori ripetibili (inferiore all'1%) non causa problemi, in quanto la maggior parte delle librerie client di Cloud Client tenta gli errori relativi ai messaggi. Esamina tassi di errore superiori all'1%. Esamina i codici di risposta perché sono gestiti dalla tua applicazione (anziché dalla libreria client). Se la tua applicazione dell'editore non ha un buon metodo per segnalare uno stato non integro, 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. Anche se in genere le librerie client riprovano le richieste non riuscite, non garantiscono la pubblicazione. Fai riferimento all'articolo sulla pubblicazione di messaggi per informazioni su come rilevare errori di pubblicazione permanenti quando si utilizzano le librerie client di Cloud. Come minimo, l'applicazione dell'editore 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à effettiva del messaggio

I publisher potrebbero inviare messaggi in gruppi. Puoi monitorare la velocità effettiva del messaggio inviata dai tuoi publisher con queste metriche:

  • topic/send_request_count: il volume di messaggi batch inviati dai publisher.

  • Un conteggio di topic/message_sizes: il volume di singoli messaggi (non raggruppati) inviati dai publisher.

    Per calcolare il conteggio dei messaggi inviati, applica un aggregatore di conteggio a questa metrica o utilizza il linguaggio di query di Monitoring. La seguente query MQL crea un grafico con la frequenza dei 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