Esportazione delle metriche di Cloud Monitoring

Last reviewed 2023-05-16 UTC

Questo articolo descrive una soluzione per esportare le metriche di Cloud Monitoring per l'analisi a lungo termine. Cloud Monitoring offre una soluzione di monitoraggio per Google Cloud e Amazon Web Services (AWS). Cloud Monitoring conserva le metriche per sei settimane perché il valore delle metriche di monitoraggio è spesso vincolato al tempo. Pertanto, il valore delle metriche storiche diminuisce nel tempo. Dopo questo periodo di sei settimane, le metriche aggregate potrebbero ancora contenere un valore per l'analisi a lungo termine di tendenze che potrebbero non essere evidenti con l'analisi a breve termine.

Questa soluzione fornisce una guida per comprendere i dettagli delle metriche per l'esportazione e un'implementazione di riferimento serverless per l'esportazione delle metriche in BigQuery.

I report State of DevOps hanno identificato le funzionalità che promuovono le prestazioni di distribuzione del software. Questa soluzione ti aiuterà con le seguenti funzionalità:

Esportazione dei casi d'uso delle metriche

Cloud Monitoring raccoglie metriche e metadati da Google Cloud, AWS e dalla strumentazione delle app. Le metriche di Monitoring offrono una profonda osservabilità di prestazioni, uptime e integrità complessiva delle app cloud tramite API, dashboard e Metrics Explorer. Questi strumenti consentono di esaminare i valori delle metriche delle precedenti sei settimane a scopo di analisi. Se hai requisiti di analisi delle metriche a lungo termine, utilizza l'API Cloud Monitoring per esportare le metriche per l'archiviazione a lungo termine.

Cloud Monitoring conserva le metriche delle ultime 6 settimane. Viene spesso utilizzato per scopi operativi come il monitoraggio dell'infrastruttura delle macchine virtuali (CPU, memoria, metriche di rete) e le metriche delle prestazioni delle applicazioni (latenza delle richieste o delle risposte). Quando queste metriche superano le soglie preimpostate, viene attivato un processo operativo tramite avvisi.

Le metriche acquisite potrebbero essere utili anche per le analisi a lungo termine. Ad esempio, puoi confrontare le metriche sulle prestazioni delle app del Cyber Monday o altri eventi con traffico elevato con le metriche dell'anno precedente per pianificare il successivo evento con traffico elevato. Un altro caso d'uso è analizzare l'utilizzo dei servizi Google Cloud in un trimestre o un anno per prevedere meglio i costi. Potresti anche voler visualizzare metriche sul rendimento dell'app relative a mesi o anni.

In questi esempi, è necessario mantenere le metriche per l'analisi per un periodo di tempo a lungo termine. L'esportazione di queste metriche in BigQuery fornisce le funzionalità analitiche necessarie per affrontare questi esempi.

Requisiti

Per eseguire un'analisi a lungo termine sui dati delle metriche di Monitoring, sono previsti tre requisiti principali:

  1. Esportare i dati da Cloud Monitoring. Devi esportare i dati della metrica di Cloud Monitoring come valore aggregato della metrica. L'aggregazione delle metriche è obbligatoria perché l'archiviazione di punti dati timeseries non elaborati, sebbene tecnicamente fattibile, non aggiunge valore. La maggior parte dell'analisi a lungo termine viene eseguita a livello aggregato in un periodo di tempo più lungo. La granularità dell'aggregazione è univoca per il tuo caso d'uso, ma consigliamo un'aggregazione di almeno 1 ora.
  2. Importare i dati per l'analisi. Devi importare le metriche di Cloud Monitoring esportate in un motore di analisi a scopo di analisi.
  3. Scrivere query e creare dashboard in base ai dati. Per eseguire query, analizzare e visualizzare i dati, hai bisogno di dashboard e di accesso SQL standard.

Passaggi funzionali

  1. Crea un elenco di metriche da includere nell'esportazione.
  2. Leggere le metriche dall'API Monitoring.
  3. Mappa le metriche dall'output JSON esportato dall'API Monitoring al formato della tabella BigQuery.
  4. Scrivi le metriche in BigQuery.
  5. Crea una pianificazione programmatica per esportare regolarmente le metriche.

Architettura

Il design di questa architettura sfrutta i servizi gestiti per semplificare le operazioni e l'attività di gestione, riduce i costi e offre la possibilità di scalare in base alle esigenze.

Diagramma dell'architettura dei prodotti utilizzati nella soluzione

Nell'architettura vengono utilizzate le seguenti tecnologie:

  • App Engine - Soluzione Scalable Platform as a Service (PaaS) utilizzata per chiamare l'API Monitoring e scrivere in BigQuery.
  • BigQuery - Un motore di analisi completamente gestito utilizzato per importare e analizzare i dati di timeseries.
  • Pub/Sub - Un servizio di messaggistica in tempo reale completamente gestito e utilizzato per fornire un'elaborazione asincrona scalabile.
  • Cloud Storage - Archiviazione unificata di oggetti per sviluppatori e aziende, utilizzata per archiviare i metadati relativi allo stato dell'esportazione.
  • Cloud Scheduler - Uno scheduler in stile cron utilizzato per eseguire il processo di esportazione.

Informazioni sui dettagli delle metriche di Cloud Monitoring

Per capire come esportare al meglio le metriche da Cloud Monitoring, è importante capire come archivia le metriche.

Tipi di metriche

In Cloud Monitoring esistono 4 tipi principali di metrics che puoi esportare.

Ciascuno di questi tipi di metrica ha un descrittore della metrica, che include il tipo di metrica e altri metadati della metrica. La seguente metrica è un esempio di elenco dei descrittori delle metriche del metodo dell'API Monitoring projects.metricDescriptors.list.

{
  "metricDescriptors": [
    {
      "name": "projects/sage-facet-201016/metricDescriptors/pubsub.googleapis.com/subscription/push_request_count",
      "labels": [
        {
          "key": "response_class",
          "description": "A classification group for the response code. It can be one of ['ack', 'deadline_exceeded', 'internal', 'invalid', 'remote_server_4xx', 'remote_server_5xx', 'unreachable']."
        },
        {
          "key": "response_code",
          "description": "Operation response code string, derived as a string representation of a status code (e.g., 'success', 'not_found', 'unavailable')."
        },
        {
          "key": "delivery_type",
          "description": "Push delivery mechanism."
        }
      ],
      "metricKind": "DELTA",
      "valueType": "INT64",
      "unit": "1",
      "description": "Cumulative count of push attempts, grouped by result. Unlike pulls, the push server implementation does not batch user messages. So each request only contains one user message. The push server retries on errors, so a given user message can appear multiple times.",
      "displayName": "Push requests",
      "type": "pubsub.googleapis.com/subscription/push_request_count",
      "metadata": {
        "launchStage": "GA",
        "samplePeriod": "60s",
        "ingestDelay": "120s"
      }
    }
  ]
}

I valori importanti da interpretare dal descrittore della metrica sono i campi type, valueType e metricKind. Questi campi identificano la metrica e influiscono sull'aggregazione possibile per un descrittore della metrica.

Tipi di metriche

Ogni metrica ha un tipo di metrica e un tipo di valore. Per ulteriori informazioni, consulta Tipi di valore e di metriche. Il tipo di metrica e il tipo di valore associato sono importanti perché la loro combinazione influisce sul modo in cui le metriche vengono aggregate.

Nell'esempio precedente, il tipo di metrica pubsub.googleapis.com/subscription/push_request_count metric ha un tipo di metrica DELTA e un tipo di valore INT64.

Richiesta push

In Cloud Monitoring, i tipi di metriche e di valore vengono archiviati in metricsDescriptors, disponibili nell'API Monitoring.

Timeseries

timeseries sono misurazioni regolari per ogni tipo di metrica archiviate nel tempo che contengono il tipo di metrica, i metadati, le etichette e i singoli punti dati misurati. Le metriche raccolte automaticamente da Monitoring, ad esempio le metriche di Google Cloud e AWS, vengono raccolte regolarmente. Ad esempio, la metrica appengine.googleapis.com/http/server/response_latencies viene raccolta ogni 60 secondi.

Un insieme di punti raccolti per un determinato timeseries potrebbe aumentare nel tempo, in base alla frequenza dei dati nei report e a eventuali etichette associate al tipo di metrica. L'esportazione dei punti dati timeseries non elaborati potrebbe comportare un'esportazione di grandi dimensioni. Per ridurre il numero di punti dati timeseries restituiti, puoi aggregare le metriche in un determinato periodo di allineamento. Ad esempio, utilizzando l'aggregazione puoi restituire un punto dati all'ora per una determinata metrica timeseries che ha un punto dati al minuto. In questo modo si riduce il numero di punti dati esportati e l'elaborazione analitica richiesta nel motore di analisi. In questo articolo, vengono restituiti timeseries per ogni tipo di metrica selezionato.

Aggregazione delle metriche

Puoi utilizzare l'aggregazione per combinare i dati di diversi timeseries in un unico timeseries. L'API Monitoring offre potenti funzioni di allineamento e aggregazione in modo che tu non debba eseguire l'aggregazione autonomamente, passando i parametri di allineamento e aggregazione alla chiamata API. Per ulteriori dettagli sul funzionamento dell'aggregazione per l'API Monitoring, consulta Filtri e aggregazione e questo post del blog.

Esegui la mappatura metric typea aggregation type per assicurarti che le metriche siano allineate e che il timeseries sia ridotto per soddisfare le tue esigenze di analisi. Esistono elenchi di allineatori e riduttori che puoi utilizzare per aggregare i timeseries. Gli allineatori e i riduttori dispongono di un insieme di metriche che puoi utilizzare per allineare o ridurre in base ai tipi di metriche e ai tipi di valore. Ad esempio, se aggreghi più di 1 ora, il risultato dell'aggregazione è 1 punto restituito all'ora per l'elemento timeseries.

Un altro modo per ottimizzare l'aggregazione è utilizzare la funzione Group By, che consente di raggruppare i valori aggregati in elenchi di timeseries aggregati. Ad esempio, puoi scegliere di raggruppare le metriche di App Engine in base al modulo App Engine. Il raggruppamento in base al modulo App Engine, in combinazione con allineatori e riduttori, che vengono aggregati in un'ora, produce 1 punto dati per modulo App Engine all'ora.

L'aggregazione delle metriche bilancia il costo maggiore della registrazione di singoli punti dati con la necessità di conservare dati sufficienti per un'analisi dettagliata a lungo termine.

Dettagli sull'implementazione del riferimento

L'implementazione di riferimento contiene gli stessi componenti descritti nel Diagramma di progettazione dell'architettura. Di seguito sono descritti i dettagli funzionali e pertinenti dell'implementazione in ogni passaggio.

Crea elenco delle metriche

Cloud Monitoring definisce oltre mille tipi di metriche per aiutarti a monitorare Google Cloud, AWS e software di terze parti. L'API Monitoring fornisce il metodo projects.metricDescriptors.list, che restituisce un elenco di metriche disponibili per un progetto Google Cloud. L'API Monitoring fornisce un meccanismo di filtro per visualizzare un elenco di metriche da esportare per l'archiviazione e l'analisi a lungo termine.

L'implementazione di riferimento in GitHub utilizza un'app Python App Engine per ottenere un elenco di metriche e quindi scrive separatamente ogni messaggio in un argomento Pub/Sub. L'esportazione viene avviata da un Cloud Scheduler che genera una notifica Pub/Sub per eseguire l'app.

Esistono molti modi per chiamare l'API Monitoring e, in questo caso, le API Cloud Monitoring e Pub/Sub vengono richiamate utilizzando la libreria client delle API di Google per Python grazie al suo accesso flessibile alle API di Google.

Ottieni serie temporali

Estrai il valore timeseries per la metrica e poi scrivi ogni elemento timeseries in Pub/Sub. Con l'API Monitoring puoi aggregare i valori delle metriche in un determinato periodo di allineamento utilizzando il metodo project.timeseries.list. L'aggregazione dei dati riduce il carico di elaborazione, i requisiti di archiviazione, i tempi di esecuzione delle query e i costi di analisi. L'aggregazione dei dati è una best practice per eseguire in modo efficiente l'analisi delle metriche a lungo termine.

L'implementazione di riferimento in GitHub utilizza un'app Python App Engine per iscriversi all'argomento, in cui ogni metrica per l'esportazione viene inviata come messaggio separato. Per ogni messaggio ricevuto, Pub/Sub esegue il push del messaggio all'app App Engine, che riceve il valore timeseries per una determinata metrica aggregata in base alla configurazione di input. In questo caso, le API Cloud Monitoring e Pub/Sub vengono richiamate utilizzando la libreria client delle API di Google.

Ogni metrica può restituire 1 o più timeseries. Ogni metrica viene inviata da un messaggio Pub/Sub separato da inserire in BigQuery. La mappatura delle metriche type-to-aligner e della metrica type-to-reducer è incorporata nell'implementazione di riferimento. La seguente tabella acquisisce la mappatura utilizzata nell'implementazione di riferimento in base alle classi dei tipi di metriche e dei tipi di valore supportati dagli allineatori e riduzioni.

Tipo di valore GAUGE Allineatore Riduttore DELTA Allineatore Riduttore CUMULATIVE2 Allineatore Riduttore
BOOL sì ALIGN_FRACTION_TRUE nessuno no N/A N/A no N/A N/A
INT64 sì ALIGN_SUM nessuno sì ALIGN_SUM nessuno sì nessuno nessuno
DOUBLE sì ALIGN_SUM nessuno sì ALIGN_SUM nessuno sì nessuno nessuno
STRING sì esclusi esclusi no N/A N/A no N/A N/A
DISTRIBUTION sì ALIGN_SUM nessuno sì ALIGN_SUM nessuno sì nessuno nessuno
MONEY no N/A N/A no N/A N/A no N/A N/A

È importante considerare la mappatura di valueType ad allineatori e riduzioni perché l'aggregazione è possibile solo per valueTypes e metricKinds specifici per ciascun allineatore e riduttore.

Ad esempio, considera il tipo pubsub.googleapis.com/subscription/push_request_count metric. In base al tipo di metrica DELTA e al tipo di valore INT64, un modo per aggregare la metrica è:

  • Periodo di allineamento - 3600 s (1 ora)
  • Aligner = ALIGN_SUM: il punto dati risultante nel periodo di allineamento è la somma di tutti i punti dati nel periodo di allineamento.
  • Reducer = REDUCE_SUM - Riduci calcolando la somma su un timeseries per ogni periodo di allineamento.

Insieme ai valori del periodo di allineamento, dell'allineatore e del riduttore, il metodo project.timeseries.list richiede diversi altri input:

  • filter - Seleziona la metrica da restituire.
  • startTime: seleziona il punto di partenza nel tempo per cui tornare timeseries.
  • endTime: seleziona l'ultimo punto temporale per il quale tornare timeseries.
  • groupBy: inserisci i campi in base ai quali raggruppare la risposta timeseries.
  • alignmentPeriod - Inserisci i periodi di tempo in cui vuoi allineare le metriche.
  • perSeriesAligner: allinea i punti in intervalli di tempo pari definiti da un alignmentPeriod.
  • crossSeriesReducer: combina più punti con valori di etichetta diversi fino a un punto per intervallo di tempo.

La richiesta GET all'API include tutti i parametri descritti nell'elenco precedente.

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=START_TIME_VALUE&
interval.endTime=END_TIME_VALUE&
aggregation.alignmentPeriod=ALIGNMENT_VALUE&
aggregation.perSeriesAligner=ALIGNER_VALUE&
aggregation.crossSeriesReducer=REDUCER_VALUE&
filter=FILTER_VALUE&
aggregation.groupByFields=GROUP_BY_VALUE

Il seguente HTTP GET fornisce una chiamata di esempio al metodo dell'API projects.timeseries.list utilizzando i parametri di input:

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=2019-02-19T20%3A00%3A01.593641Z&
interval.endTime=2019-02-19T21%3A00%3A00.829121Z&
aggregation.alignmentPeriod=3600s&
aggregation.perSeriesAligner=ALIGN_SUM&
aggregation.crossSeriesReducer=REDUCE_SUM&
filter=metric.type%3D%22kubernetes.io%2Fnode_daemon%2Fmemory%2Fused_bytes%22+&
aggregation.groupByFields=metric.labels.key

La precedente chiamata API Monitoring include crossSeriesReducer=REDUCE_SUM, il che significa che le metriche vengono compresse e ridotte in un'unica somma, come mostrato nell'esempio seguente.

{
  "timeSeries": [
    {
      "metric": {
        "type": "pubsub.googleapis.com/subscription/push_request_count"
      },
      "resource": {
        "type": "pubsub_subscription",
        "labels": {
          "project_id": "sage-facet-201016"
        }
      },
      "metricKind": "DELTA",
      "valueType": "INT64",
      "points": [
        {
          "interval": {
            "startTime": "2019-02-08T14:00:00.311635Z",
            "endTime": "2019-02-08T15:00:00.311635Z"
          },
          "value": {
            "int64Value": "788"
          }
        }
      ]
    }
  ]
}

Questo livello di aggregazione aggrega i dati in un singolo punto dati, rendendolo una metrica ideale per il tuo progetto Google Cloud complessivo. Tuttavia, non ti consente di visualizzare in dettaglio quali risorse hanno contribuito alla metrica. Nell'esempio precedente, non puoi indicare quale sottoscrizione Pub/Sub ha contribuito maggiormente al conteggio delle richieste.

Se vuoi esaminare i dettagli dei singoli componenti che generano timeseries, puoi rimuovere il parametro crossSeriesReducer. Senza crossSeriesReducer, l'API Monitoring non combina i vari timeseries per creare un singolo valore.

Il seguente HTTP GET fornisce una chiamata di esempio al metodo dell'API projects.timeseries.list utilizzando i parametri di input. crossSeriesReducer non è incluso.

https://monitoring.googleapis.com/v3/projects/sage-facet-201016/timeSeries?
interval.startTime=2019-02-19T20%3A00%3A01.593641Z&
interval.endTime=2019-02-19T21%3A00%3A00.829121Z
aggregation.alignmentPeriod=3600s&
aggregation.perSeriesAligner=ALIGN_SUM&
filter=metric.type%3D%22kubernetes.io%2Fnode_daemon%2Fmemory%2Fused_bytes%22+

Nella seguente risposta JSON, metric.labels.keys è lo stesso in entrambi i risultati perché timeseries è raggruppato. Vengono restituiti punti separati per ciascuno dei valori resource.labels.subscription_ids. Esamina i valori metric_export_init_pub e metrics_list nel seguente JSON. Questo livello di aggregazione è consigliato perché consente di utilizzare i prodotti Google Cloud, inclusi come etichette delle risorse, nelle query BigQuery.

{
    "timeSeries": [
        {
            "metric": {
                "labels": {
                    "delivery_type": "gae",
                    "response_class": "ack",
                    "response_code": "success"
                },
                "type": "pubsub.googleapis.com/subscription/push_request_count"
            },
            "metricKind": "DELTA",
            "points": [
                {
                    "interval": {
                        "endTime": "2019-02-19T21:00:00.829121Z",
                        "startTime": "2019-02-19T20:00:00.829121Z"
                    },
                    "value": {
                        "int64Value": "1"
                    }
                }
            ],
            "resource": {
                "labels": {
                    "project_id": "sage-facet-201016",
                    "subscription_id": "metric_export_init_pub"
                },
                "type": "pubsub_subscription"
            },
            "valueType": "INT64"
        },
        {
            "metric": {
                "labels": {
                    "delivery_type": "gae",
                    "response_class": "ack",
                    "response_code": "success"
                },
                "type": "pubsub.googleapis.com/subscription/push_request_count"
            },
            "metricKind": "DELTA",
            "points": [
                {
                    "interval": {
                        "endTime": "2019-02-19T21:00:00.829121Z",
                        "startTime": "2019-02-19T20:00:00.829121Z"
                    },
                    "value": {
                        "int64Value": "803"
                    }
                }
            ],
            "resource": {
                "labels": {
                    "project_id": "sage-facet-201016",
                    "subscription_id": "metrics_list"
                },
                "type": "pubsub_subscription"
            },
            "valueType": "INT64"
        }
    ]
}

Ogni metrica nell'output JSON della chiamata API projects.timeseries.list viene scritta direttamente in Pub/Sub come messaggio separato. Esiste un potenziale fan-out in cui 1 metrica di input genera 1 o più timeseries. Pub/Sub consente di assorbire un fan-out potenzialmente di grandi dimensioni senza superare i timeout.

Il periodo di allineamento fornito come input significa che i valori nel periodo di tempo in questione vengono aggregati in un singolo valore come mostrato nella risposta di esempio precedente. Il periodo di allineamento definisce anche la frequenza di esecuzione dell'esportazione. Ad esempio, se il periodo di allineamento è di 3600 secondi o 1 ora, l'esportazione viene eseguita ogni ora per esportare regolarmente l'timeseries.

Archivia metriche

L'implementazione di riferimento in GitHub utilizza un'app Python App Engine per leggere ogni timeseries e quindi inserire i record nella tabella BigQuery. Per ogni messaggio ricevuto, Pub/Sub ne esegue il push all'app App Engine. Il messaggio Pub/Sub contiene dati di metriche esportati dall'API Monitoring in un formato JSON e deve essere mappato a una struttura tabulare in BigQuery. In questo caso, le API BigQuery vengono chiamate utilizzando la libreria client delle API di Google.

Lo schema BigQuery è progettato per essere mappato da vicino al JSON esportato dall'API Monitoring. Quando crei lo schema della tabella BigQuery, una considerazione è la scala delle dimensioni dei dati man mano che crescono nel tempo.

In BigQuery, ti consigliamo di partizionare la tabella in base a un campo data, perché può rendere le query più efficienti selezionando intervalli di date senza dover eseguire una scansione completa della tabella. Se prevedi di eseguire l'esportazione regolarmente, puoi utilizzare in sicurezza la partizione predefinita in base alla data di importazione.

Screenshot del partizionamento in BigQuery

Se prevedi di caricare le metriche in blocco o non esegui l'esportazione periodicamente, esegui la partizione su end_time,, che richiede modifiche allo schema di BigQuery. Puoi spostare end_time in un campo di primo livello dello schema, dove puoi utilizzarlo per il partizionamento, oppure aggiungere un nuovo campo allo schema. Lo spostamento del campo end_time è obbligatorio perché il campo è contenuto in un record BigQuery e il partizionamento deve essere eseguito in un campo di primo livello. Per ulteriori informazioni, consulta la documentazione sul partizionamento di BigQuery.

BigQuery consente inoltre di far scadere i set di dati, le tabelle e le partizioni delle tabelle dopo un determinato periodo di tempo.

Screenshot dell'impostazione della scadenza dei dati in BigQuery

Questa funzionalità è utile per eliminare definitivamente i dati meno recenti quando non sono più utili. Ad esempio, se l'analisi riguarda un periodo di tempo di 3 anni, puoi aggiungere un criterio per eliminare i dati risalenti a più di 3 anni fa.

Pianifica esportazione

Cloud Scheduler è un programma di pianificazione dei cron job completamente gestito. Cloud Scheduler consente di utilizzare il formato standard di pianificazione cron per attivare un'app App Engine, inviare un messaggio utilizzando Pub/Sub o inviare un messaggio a un endpoint HTTP arbitrario.

Nell'implementazione di riferimento in GitHub, Cloud Scheduler attiva l'app list-metrics App Engine ogni ora inviando un messaggio Pub/Sub con un token che corrisponde alla configurazione di App Engine. Il periodo di aggregazione predefinito nella configurazione dell'app è 3600, o 1 ora, ed è correlato alla frequenza di attivazione dell'app. È consigliabile un'aggregazione minima di 1 ora perché consente di trovare un equilibrio tra la riduzione dei volumi di dati e la conservazione di dati ad alta fedeltà. Se utilizzi un periodo di allineamento diverso, modifica la frequenza dell'esportazione in modo che corrisponda al periodo di allineamento. L'implementazione di riferimento archivia l'ultimo valore end_time in Cloud Storage e utilizza questo valore come start_time successivo, a meno che non venga trasmesso un valore start_time come parametro.

Il seguente screenshot di Cloud Scheduler mostra come utilizzare la console Google Cloud per configurare Cloud Scheduler in modo da richiamare l'app App Engine list-metrics ogni ora.

Configurazione di Cloud Scheduler

Il campo Frequenza utilizza la sintassi di tipo cron per indicare a Cloud Scheduler la frequenza di esecuzione dell'app. Il campo Target specifica un messaggio Pub/Sub generato, mentre il campo Payload contiene i dati contenuti nel messaggio Pub/Sub.

Utilizzo delle metriche esportate

Con i dati esportati in BigQuery, ora puoi utilizzare SQL standard per eseguire query sui dati o creare dashboard per visualizzare le tendenze delle metriche nel tempo.

Query di esempio: latenze di App Engine

La seguente query trova i valori minimo, massimo e medio dei valori delle metriche di latenza media per un'app App Engine. metric.type identifica la metrica App Engine, mentre le etichette identificano l'app App Engine in base al valore dell'etichetta project_id. point.value.distribution_value.mean viene utilizzato perché questa metrica è un valore DISTRIBUTION nell'API Monitoring, mappato all'oggetto campo distribution_value in BigQuery. Il campo end_time esamina i valori degli ultimi 30 giorni.

SELECT
  metric.type AS metric_type,
  EXTRACT(DATE  FROM point.INTERVAL.start_time) AS extract_date,
  MAX(point.value.distribution_value.mean) AS max_mean,
  MIN(point.value.distribution_value.mean) AS min_mean,
  AVG(point.value.distribution_value.mean) AS avg_mean
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
CROSS JOIN
  UNNEST(resource.labels) AS resource_labels
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  AND metric.type = 'appengine.googleapis.com/http/server/response_latencies'
  AND resource_labels.key = "project_id"
  AND resource_labels.value = "sage-facet-201016"
GROUP BY
  metric_type,
  extract_date
ORDER BY
  extract_date

Query di esempio: conteggio delle query BigQuery

La seguente query restituisce il numero di query giornaliere su BigQuery in un progetto. Il campo int64_value viene utilizzato perché questa metrica è un valore INT64 nell'API Monitoring, mappato al campo int64_value in BigQuery. metric.type identifica la metrica BigQuery e le etichette identificano il progetto in base al valore dell'etichetta project_id. Il campo end_time esamina i valori degli ultimi 30 giorni.

SELECT
  EXTRACT(DATE  FROM point.interval.end_time) AS extract_date,
  sum(point.value.int64_value) as query_cnt
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
CROSS JOIN
  UNNEST(resource.labels) AS resource_labels
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  and metric.type = 'bigquery.googleapis.com/query/count'
  AND resource_labels.key = "project_id"
  AND resource_labels.value = "sage-facet-201016"
group by extract_date
order by extract_date

Query di esempio: istanze di Compute Engine

La seguente query trova i valori settimanali minimi, massimi e medi dei valori delle metriche di utilizzo della CPU per le istanze di Compute Engine di un progetto. metric.type identifica la metrica Compute Engine e le etichette identificano le istanze in base al valore dell'etichetta project_id. Il campo end_time esamina i valori degli ultimi 30 giorni.

SELECT
  EXTRACT(WEEK  FROM point.interval.end_time) AS extract_date,
  min(point.value.double_value) as min_cpu_util,
  max(point.value.double_value) as max_cpu_util,
  avg(point.value.double_value) as avg_cpu_util
FROM
  `sage-facet-201016.metric_export.sd_metrics_export`
WHERE
   point.interval.end_time > TIMESTAMP(DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY))
  AND  point.interval.end_time <= CURRENT_TIMESTAMP
  AND metric.type = 'compute.googleapis.com/instance/cpu/utilization'
group by extract_date
order by extract_date

Visualizzazione dati

BigQuery è integrato con molti strumenti utilizzabili per la visualizzazione dei dati.

Looker Studio è uno strumento gratuito creato da Google con cui puoi creare grafici di dati e dashboard per visualizzare i dati delle metriche e poi condividerli con il tuo team. L'esempio seguente mostra un grafico a linee di tendenza della latenza e del conteggio per la metrica appengine.googleapis.com/http/server/response_latencies nel tempo.

Grafico delle tendenze di App Engine nel tempo

Colaboratory è uno strumento di ricerca per la formazione e la ricerca nell'ambito del machine learning. Si tratta di un ambiente di blocco note Jupyter ospitato che non richiede alcuna configurazione per utilizzare e accedere ai dati in BigQuery. Con un blocco note di Colab, comandi Python e query SQL, puoi sviluppare analisi e visualizzazioni dettagliate.

Grafico dell'utilizzo della CPU

Monitorare l'implementazione del riferimento di esportazione

Quando l'esportazione è in esecuzione, devi monitorarla. Un modo per decidere quali metriche monitorare è impostare un obiettivo del livello di servizio (SLO). Uno SLO è un valore o un intervallo di valori target per un livello di servizio misurato da una metrica. Il libro Site Reliability Engineering descrive le quattro aree principali degli SLO: disponibilità, velocità effettiva, percentuale di errori e latenza. Per un'esportazione di dati, la velocità effettiva e il tasso di errore sono due aspetti principali da considerare e puoi monitorarli tramite le seguenti metriche:

  • Velocità effettiva - appengine.googleapis.com/http/server/response_count
  • Tasso di errori - logging.googleapis.com/log_entry_count

Ad esempio, puoi monitorare la percentuale di errori utilizzando la metrica log_entry_count e filtrandola per le app App Engine (list-metrics, get-timeseries, write-metrics) con una gravità ERROR. Potrai quindi utilizzare i criteri di avviso in Cloud Monitoring per ricevere un avviso in caso di errori riscontrati nell'app di esportazione.

Criteri di avviso

L'interfaccia utente Avvisi mostra un grafico della metrica log_entry_count rispetto alla soglia per generare l'avviso.

Grafico delle condizioni

Passaggi successivi