Esportazione delle metriche di Cloud Monitoring

Questo documento descrive una soluzione per esportare le metriche di Cloud Monitoring per l'analisi a lungo termine. Cloud Monitoring fornisce una soluzione di monitoraggio per Google Cloud. 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 il periodo di sei settimane, le metriche aggregate potrebbero essere ancora utili per l'analisi a lungo termine delle 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 migliorano le prestazioni di distribuzione del software. Questa soluzione ti aiuterà con le seguenti funzionalità:

Casi d'uso per l'esportazione delle metriche

Cloud Monitoring raccoglie metriche e metadati da Google Cloud e strumentazione delle app. Le metriche di monitoraggio forniscono una visibilità approfondita su prestazioni, uptime e integrità complessiva delle app cloud tramite un'API, dashboard e un esploratore di metriche. Questi strumenti consentono di esaminare i valori delle metriche delle 6 settimane precedenti per l'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, ad esempio per monitorare l'infrastruttura delle macchine virtuali (metriche di CPU, memoria e rete) e le metriche delle prestazioni delle applicazioni (latenza di richiesta o risposta). Quando queste metriche superano le soglie preimpostate, viene attivato un processo operativo tramite avvisi.

Le metriche acquisite potrebbero essere utili anche per l'analisi a lungo termine. Ad esempio, potresti voler confrontare le metriche sul rendimento delle app del Cyber Monday o di altri eventi con traffico elevato con le metriche dell'anno precedente per pianificare il prossimo evento con traffico elevato. Un altro caso d'uso è esaminare l'utilizzo del servizio Google Cloud in un trimestre o in un anno per prevedere meglio i costi. Potrebbero anche esserci metriche sulle prestazioni dell'app che vuoi visualizzare nel corso di mesi o anni.

In questi esempi, è necessario mantenere le metriche per l'analisi in un periodo di tempo prolungato. 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, esistono tre requisiti principali:

  1. Esporta i dati da Cloud Monitoring. Devi esportare i dati delle metriche di Cloud Monitoring come valore di metrica aggregato. L'aggregazione delle metriche è necessaria perché l'archiviazione dei punti dati timeseries non elaborati, sebbene tecnicamente fattibile, non aggiunge valore. La maggior parte delle analisi a lungo termine viene eseguita a livello aggregato in un periodo di tempo più lungo. La granularità dell'aggregazione è specifica per il tuo caso d'uso, ma ti consigliamo un'aggregazione minima di 1 ora.
  2. Importa i dati per l'analisi. Devi importare le metriche di Cloud Monitoring esportate in un motore di analisi.
  3. Scrivi query e crea dashboard in base ai dati. Hai bisogno di dashboard e accesso SQL standard per eseguire query, analizzare e visualizzare i dati.

Passaggi funzionali

  1. Crea un elenco di metriche da includere nell'esportazione.
  2. Leggi le metriche dall'API Monitoring.
  3. Mappa le metriche dell'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

La progettazione di questa architettura sfrutta i servizi gestiti per semplificare le operazioni e l'impegno di gestione, ridurre i costi e fornire la possibilità di scalare in base alle esigenze.

Architettura per esportare le metriche di Cloud Monitoring per le analisi a lungo termine

Il diagramma mostra la seguente implementazione dell'architettura:

  • Crea un elenco di metriche: esporta i dati delle metriche dall'API Cloud Monitoring e crea un elenco di metriche utilizzando il metodo project.metricsDescriptors.list(). Escludi l'elenco delle metriche utilizzando le configurazioni. Pianifica l'esecuzione periodica dell'attività (ad esempio, una volta all'ora).
  • Ottieni timeseries: utilizza il metodo project.timeseries.list() per estrarre ogni metrica dall'API Monitoring. Aggrega a un livello di 1 ora utilizzando l'aggregazione API.
  • Memorizza metriche: App Engine scrive ogni metrica in BigQuery.
  • Metriche aggregate: esegui query sulle metriche aggregate utilizzando BigQuery.
  • Metriche dei report: utilizza Looker Studio per l'analisi a lungo termine.

Nell'architettura vengono utilizzate le seguenti tecnologie:

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

Informazioni dettagliate sulle metriche di Cloud Monitoring

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

Tipi di metriche

Esistono quattro tipi principali di metriche in Cloud Monitoring che puoi esportare.

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

{
  "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 comprendere dal descrittore della metrica sono i campi type, valueType e metricKind. Questi campi identificano la metrica e influenzano l'aggregazione possibile per undescrittore della metricaa.

Tipi di metriche

Ogni metrica ha un tipo di metrica e un tipo di valore. Per saperne di più, leggi Tipi di valori e tipi 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, il tipo di metrica e i tipi di valore vengono archiviati in metricsDescriptors, che sono 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 metricheGoogle Cloud , 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 riportati e a eventuali etichette associate al tipo di metrica. Se esporti i punti dati timeseries non elaborati, l'esportazione potrebbe essere 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 più timeseries in un unico timeseries. L'API Monitoring fornisce potenti funzioni di allineamento e aggregazione, in modo da non dover eseguire l'aggregazione autonomamente, passando i parametri di allineamento e aggregazione alla chiamata API. Per maggiori dettagli su come funziona l'aggregazione per l'API Monitoring, leggi Filtri e aggregazione e questo post del blog.

Mappa metric type a aggregation type per assicurarti che le metriche siano allineate e che timeseries sia ridotto per soddisfare le tue esigenze di analisi. Esistono elenchi di allineatori e riduttori, che puoi utilizzare per aggregare timeseries. Gli allineatori e i riduttori hanno un insieme di metriche che puoi utilizzare per allineare o ridurre in base ai tipi di metrica e ai tipi di valore. Ad esempio, se esegui l'aggregazione per un'ora, il risultato dell'aggregazione è un punto restituito all'ora per timeseries.

Un altro modo per perfezionare 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 per modulo App Engine in combinazione con gli allineatori e i riduttori che aggregano a 1 ora produce 1 punto dati per modulo App Engine all'ora.

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

Dettagli dell'implementazione di riferimento

L'implementazione di riferimento contiene gli stessi componenti descritti nel diagramma di progettazione dell'architettura. I dettagli di implementazione funzionali e pertinenti in ogni passaggio sono descritti nelle sezioni seguenti.

Elenco delle metriche di build

Cloud Monitoring definisce oltre mille tipi di metriche per aiutarti a monitorare Google Cloud 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 filtraggio che ti consente di filtrare 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 poi scrive ogni messaggio in un argomento Pub/Sub separatamente. L'esportazione viene avviata da 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 chiamate utilizzando la libreria client delle API di Google per Python, grazie al suo accesso flessibile alle API di Google.

Get timeseries

Estrai timeseries per la metrica e poi scrivi ogni 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 query e i costi di analisi. L'aggregazione dei dati è una best practice per condurre 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 da esportare viene inviata come messaggio separato. Per ogni messaggio ricevuto, Pub/Sub lo invia all'app App Engine. L'app riceve il timeseries per una determinata metrica aggregata in base alla configurazione di input. In questo caso, le API Cloud Monitoring e Pub/Sub vengono chiamate utilizzando la libreria client delle API di Google.

Ogni metrica può restituire uno o più timeseries. Ogni metrica viene inviata da un messaggio Pub/Sub separato da inserire in BigQuery. Il mapping della metrica type-to-aligner e della metrica type-to-reducer è integrato nell'implementazione di riferimento. La tabella seguente mostra la mappatura utilizzata nell'implementazione di riferimento in base alle classi di tipi di metriche e tipi di valori supportati dagli allineatori e dai riduttori.

Tipo di valore GAUGE Allineatore Riduttore DELTA Allineatore Riduttore CUMULATIVE2 Allineatore Riduttore
BOOL sì ALIGN_FRACTION_TRUE nessuno no N/D N/D no N/D N/D
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/D N/D no N/D N/D
DISTRIBUTION sì ALIGN_SUM nessuno sì ALIGN_SUM nessuno sì nessuno nessuno
MONEY no N/D N/D no N/D N/D no N/D N/D

È importante considerare il mapping di valueType agli allineatori e ai riduttori perché l'aggregazione è possibile solo per valueTypes e metricKinds specifici per ogni 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 allineamento - 3600 secondi (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 - Riduzione calcolando la somma in un timeseries per ogni periodo di allineamento.

Oltre al periodo di allineamento, allineatore e riduttore, il metodo project.timeseries.list richiede diversi altri input:

  • filter: seleziona la metrica da restituire.
  • startTime - Seleziona il punto di partenza nel tempo da cui tornare timeseries.
  • endTime - Seleziona l'ultimo punto temporale per cui restituire 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 uniformi definiti da un alignmentPeriod.
  • crossSeriesReducer - Combina più punti con valori di etichetta diversi in un unico 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 un esempio di chiamata al metodo 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 chiamata all'API Monitoring precedente include un crossSeriesReducer=REDUCE_SUM, il che significa che le metriche vengono compresse e ridotte a una singola 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 unico punto dati, rendendolo una metrica ideale per il tuo Google Cloud progetto complessivo. Tuttavia, non ti consente di esaminare in dettaglio le risorse che hanno contribuito alla metrica. Nell'esempio precedente, non puoi sapere quale abbonamento Pub/Sub ha contribuito maggiormente al conteggio delle richieste.

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

Il seguente HTTP GET fornisce un esempio di chiamata al metodo 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, i metric.labels.keys sono gli stessi in entrambi i risultati perché timeseries è raggruppato. Vengono restituiti punti separati per ciascuno dei resource.labels.subscription_ids valori. Esamina i valori metric_export_init_pub e metrics_list nel seguente JSON. Questo livello di aggregazione è consigliato perché ti consente di utilizzare iGoogle Cloud prodotti, 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 una metrica di input genera una o più timeseries. Pub/Sub offre la possibilità di assorbire un fan-out potenzialmente grande senza superare i timeout.

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

Metriche del negozio

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

Lo schema BigQuery è progettato per essere mappato in modo preciso al JSON esportato dall'API Monitoring. Quando crei lo schema della tabella BigQuery, una considerazione da fare è la scala delle dimensioni dei dati man mano che aumentano 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 collettivamente o non esegui l'esportazione periodicamente, esegui il partizionamento in base a end_time,, che richiede modifiche allo schema BigQuery. Puoi spostare end_time in un campo di primo livello nello 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 su un campo di primo livello. Per ulteriori informazioni, leggi la documentazione sul partizionamento di BigQuery.

BigQuery offre anche la possibilità di far scadere set di dati, tabelle e partizioni di tabelle dopo un determinato periodo di tempo.

Screenshot dell'impostazione di scadenza dei dati in BigQuery

L'utilizzo di questa funzionalità è un modo utile per eliminare i dati meno recenti quando non sono più utili. Ad esempio, se l'analisi copre un periodo di tre anni, puoi aggiungere una norma per eliminare i dati più vecchi di tre anni.

Pianifica esportazione

Cloud Scheduler è un servizio di pianificazione di cron job completamente gestito. Cloud Scheduler ti consente di utilizzare il formato di pianificazione cron standard per attivare un'app di 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 App Engine list-metrics 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 è di 3600 secondi, ovvero 1 ora, che corrisponde alla frequenza con cui viene attivata l'app. È consigliata un'aggregazione minima di 1 ora perché offre un equilibrio tra la riduzione dei volumi di dati e il mantenimento di dati ad alta fedeltà. Se utilizzi un periodo di allineamento diverso, modifica la frequenza di esportazione in modo che corrisponda al periodo di allineamento. L'implementazione di riferimento memorizza l'ultimo valore end_time in Cloud Storage e lo utilizza come start_time successivo a meno che non venga passato un start_time come parametro.

Lo screenshot seguente di Cloud Scheduler mostra come puoi utilizzare la console Google Cloud per configurare Cloud Scheduler in modo che richiami l'app App Engine list-metrics ogni ora.

Configurazione di Cloud Scheduler

Il campo Frequenza utilizza la sintassi in stile cron per indicare a Cloud Scheduler la frequenza di esecuzione dell'app. Il campo Destinazione 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 il minimo, il massimo e la media dei valori della metrica latenza media per un'app App Engine. metric.type identifica la metrica App Engine e 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, che viene mappato all'oggetto campo distribution_value in BigQuery. Il campoend_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: conteggi delle query BigQuery

La seguente query restituisce il numero di query eseguite su BigQuery al giorno in un progetto. Il campo int64_value viene utilizzato perché questa metrica è un valore INT64 nell'API Monitoring, che è 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 considera 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 Compute Engine

La seguente query trova il valore minimo, massimo e medio settimanale dei valori della metrica di utilizzo della CPU per le istanze 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 dei dati

BigQuery è integrato con molti strumenti che puoi utilizzare per la visualizzazione dei dati.

Looker Studio è uno strumento gratuito creato da Google che ti consente di creare grafici e dashboard di dati per visualizzare i dati delle metriche e condividerli con il tuo team. Il seguente esempio mostra un grafico della linea di tendenza della latenza e del conteggio per la metrica appengine.googleapis.com/http/server/response_latencies nel tempo.

Grafico dei trend di App Engine nel tempo

Colaboratory è uno strumento di ricerca per l'insegnamento e la ricerca nel campo del machine learning. Si tratta di un ambiente notebook Jupyter ospitato che non richiede configurazione per utilizzare e accedere ai dati in BigQuery. Utilizzando un notebook Colab, comandi Python e query SQL, puoi sviluppare analisi e visualizzazioni dettagliate.

Grafico dell&#39;utilizzo della CPU

Monitoraggio dell'implementazione di riferimento dell'esportazione

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

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

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

Criteri di avviso

L'interfaccia utente degli avvisi mostra un grafico della metrica log_entry_count rispetto alla soglia per la generazione dell'avviso.

Grafico delle condizioni

Passaggi successivi