Monitorare Pub/Sub in Cloud Monitoring

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

Questo documento illustra come monitorare l'utilizzo di Pub/Sub in alla console Google Cloud usando Monitoring.

Per le best practice sull'utilizzo delle metriche in scalabilità automatica, consulta le 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 assicurarti di ottenerli entrambi è completare la Guida rapida all'utilizzo della console Cloud.

Visualizza una dashboard esistente

Una dashboard ti consente di visualizzare e analizzare dati provenienti da origini diverse nello stesso contesto. Google Cloud fornisce dashboard sia predefinite che personalizzate. Per Ad esempio, puoi visualizzare una dashboard Pub/Sub predefinita o creare dashboard che visualizza i dati delle metriche, i criteri di avviso e le voci di log relativi in 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.

Visualizza una singola metrica Pub/Sub

Per visualizzare una singola metrica Pub/Sub utilizzando nella 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 l'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 IAM e Dashboard delle quote di amministrazione per visualizzare le quote e l'utilizzo attuali.

Puoi visualizzare l'utilizzo storico delle quote 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 Monitoring Query Language crea un grafico con la frazione della quota dell'editore 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 vengono attivati quando l'utilizzo raggiunge una parte 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.

Mantieni un abbonamento integro

Per mantenere un abbonamento integro, puoi monitorare diversi abbonamenti 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 controllare se il tuo abbonamento è integro sufficientemente una bassa latenza di consegna dei messaggi.

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

Monitora 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 risorsa, per tutte le tue sottoscrizioni:

Crea criteri di avviso che si attivano quando questi valori non rientrano nel accettabile nel contesto del tuo sistema. Ad esempio, l'assoluta 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. 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 segnali di bug nel codice che impediscono il corretto funzionamento di riconoscere i messaggi o di elaborarli tempestivamente. Consulta Scadenza della scadenza ACK Monitoring.
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 causano l'arresto anomalo del tuo 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 quei messaggi a un argomento messaggi non recapitabili.
Il oldest_unacked_message_age supera l'abbonamento di conservazione dei messaggi. Perdita permanente dei dati
  • Configura un avviso che si attivi prima che il messaggio scada durata di conservazione.

Monitora l'integrità della latenza di distribuzione

In Pub/Sub, la latenza di consegna è il tempo necessario per messaggio da recapitare a un sottoscrittore. Se il backlog dei messaggi è in aumento, puoi utilizzare lo strumento Stato 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 di 10 minuti. La metrica fornisce insight sui seguenti criteri: necessari affinché un abbonamento ottenga 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 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 di 1 indica uno stato di salute e Un punteggio pari a 0 indica uno stato non integro.

  • Richieste di ricerca: se l'abbonamento ha avuto richieste di ricerca nell'ultimo periodo. Dopo 10 minuti, il punteggio è impostato su 0. Alla ricerca una sottoscrizione potrebbe causare la riproduzione dei messaggi precedenti molto tempo dopo la loro prima pubblicate, aumentando la latenza di pubblicazione.

  • Messaggi riconosciuti negativamente (nack): se la sottoscrizione aveva uno di questi. richieste di conferma negativa (nack) negli ultimi 10 minuti, il punteggio è 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. Messaggi la cui scadenza di conferma è scaduta vengono ricaricati con un latenza di distribuzione.

  • 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 sottintendere un bug o da 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. a 0. Apri più flussi per assicurarti di disporre di capacità adeguata per i nuovi messaggi.

    • Push: se hai troppi messaggi in sospeso per l'endpoint push, il punteggio è impostato su 0. Aggiungi ulteriore capacità al tuo endpoint push in modo da avere capacità massima 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 Stato latenza di pubblicazione per il tipo di risorsa di sottoscrizione Pub/Sub. Aggiungi un filtro per selezionare un solo abbonamento alla volta. Seleziona Area in pila e indica un momento specifico per controllare i punteggi dei criteri 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 salute combinato sale a 5 alle 04:15, con un pari a 1 per ogni criterio. Successivamente, 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 di 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 clienti sottoscrittori un periodo di tempo limitato per confermare (ACK) un determinato per creare un nuovo messaggio email. 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 provisioning dei tuoi sottoscrittori è in difetto (hai bisogno di 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, un per le librerie è in vigore anche la scadenza massima per l'estensione.

  • 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 numero eccessivo di tassi di scadenza della conferma di ricezione può comportare costose inefficienze nei del tuo sistema. Paghi per ogni nuova pubblicazione e per il tentativo di elaborare ognuna ripetutamente. Al contrario, un tasso di scadenza ridotto (ad es.0, 1-1%) potrebbe essere integro.

Monitora la velocità effettiva dei messaggi

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 Monitora la velocità effettiva dei messaggi batch che viene elaborata dai sottoscrittori. con queste metriche:

Puoi monitorare la velocità effettiva di un messaggio singolo o non in batch elaborati dagli abbonati con la metrica subscription/sent_message_count filtrato 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 conferma implicita dei messaggi, è importante per monitorare i codici di risposta alle richieste push. Perché il push delle sottoscrizioni in modo esponenziale di tornare indietro quando riscontrate timeout o errori, il backlog può aumentare rapidamente in base il modo in cui risponde l'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 a . Tuttavia, i conteggi delle richieste push sono probabilmente più utili uno strumento per indagare sull'aumento in termini di dimensioni ed età del backlog.

  • subscription/num_outstanding_messages

    Pub/Sub di solito limita il numero di messaggi in sospeso. Cerca di avere meno di 1000 messaggi in sospeso in nella maggior parte delle situazioni. Una volta che la velocità effettiva raggiunge una velocità dell'ordine 10.000 messaggi al secondo, il servizio regola il limite relativo al numero messaggi in sospeso. Questa limitazione viene applicata per incrementi di 1000. No garanzie specifiche vengono effettuate oltre il valore massimo, quindi 1000 messaggi in sospeso è un'ottima guida.

  • subscription/push_request_latencies

    Questa metrica consente di 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 sono necessari 100 millisecondi per elaborare ognuno , il limite di velocità effettiva è 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 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 riconosce automaticamente i messaggi che non corrispondono il 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.

Monitora i messaggi non recapitabili inoltrati

per monitorare i messaggi non recapitabili che Pub/Sub inoltra a un argomento messaggi non recapitabili, utilizza subscription/dead_letter_message_count in un file di dati. 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 topic/send_request_count in un file di dati. 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:

Mantieni un publisher integro

L'obiettivo principale di un publisher è rendere persistenti rapidamente i dati dei messaggi. Monitora questo delle prestazioni utilizzando topic/send_request_count , raggruppate per response_code. Questo fornisce un'indicazione dello stato di integrità di Pub/Sub 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 riutilizzabili vengono gestiti dall'applicazione (anziché libreria 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 ritentino in genere le richieste non riuscite, non garantiscono pubblicazione. Fai riferimento a Pubblicazione di messaggi per come rilevare errori di pubblicazione permanenti quando si utilizza Cloud Client Biblioteche. L'applicazione del publisher deve registrare almeno gli errori di pubblicazione permanenti. Se registrare questi errori in Cloud Logging, puoi configurare metrica basata su log con un criterio di avviso.

Monitora la velocità effettiva dei messaggi

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

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

  • R numero di topic/message_sizes: il volume di messaggi singoli (non in batch) inviati dai publisher.

    Puoi calcolare il conteggio dei messaggi inviati applicando un conteggio o il Monitoring Query Language. La seguente query MQL crea un grafico con la percentuale di singoli utenti 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