Exporta métricas con Cloud Monitoring

Last reviewed 2024-08-14 UTC

En este artículo se describe una solución para exportar métricas de Cloud Monitoring para realizar análisis a largo plazo. Cloud Monitoring ofrece una solución de monitorización paraGoogle Cloud y Amazon Web Services (AWS). Cloud Monitoring conserva las métricas durante seis semanas porque el valor de las métricas de monitorización suele estar limitado en el tiempo. Por lo tanto, el valor de las métricas históricas disminuye con el tiempo. Después de ese periodo, las métricas agregadas pueden seguir siendo útiles para analizar tendencias a largo plazo que no se aprecien con un análisis a corto plazo.

Esta solución proporciona una guía para entender los detalles de las métricas que se van a exportar y una implementación de referencia sin servidor para exportar métricas a BigQuery.

En los informes State of DevOps se identificaron las funciones que mejoran el rendimiento del envío de software. Esta solución te ayudará a hacer lo siguiente:

Casos prácticos de exportación de métricas

Cloud Monitoring recoge métricas y metadatos de Google Cloud, AWS y la instrumentación de aplicaciones. Las métricas de monitorización proporcionan una observabilidad detallada del rendimiento, el tiempo de actividad y el estado general de las aplicaciones en la nube a través de una API, paneles de control y un explorador de métricas. Estas herramientas permiten revisar los valores de las métricas de las últimas seis semanas para analizarlos. Si necesitas analizar las métricas a largo plazo, usa la API de Cloud Monitoring para exportarlas y almacenarlas durante más tiempo.

Cloud Monitoring conserva las métricas de las últimas 6 semanas. Se usa con frecuencia para fines operativos, como monitorizar la infraestructura de máquinas virtuales (métricas de CPU, memoria y red) y las métricas de rendimiento de las aplicaciones (latencia de solicitudes o respuestas). Cuando estas métricas superan los umbrales predefinidos, se activa un proceso operativo mediante alertas.

Las métricas recogidas también pueden ser útiles para realizar análisis a largo plazo. Por ejemplo, puede comparar las métricas de rendimiento de la aplicación del Ciberlunes u otros eventos con mucho tráfico con las del año anterior para planificar el próximo evento de este tipo. Otro caso práctico es consultar el uso del servicio Google Cloud durante un trimestre o un año para predecir mejor los costes. También puede haber métricas de rendimiento de la aplicación que quieras consultar a lo largo de meses o años.

En estos ejemplos, es necesario mantener las métricas para analizarlas durante un periodo prolongado. Exportar estas métricas a BigQuery proporciona las funciones analíticas necesarias para abordar estos ejemplos.

Requisitos

Para realizar análisis a largo plazo de los datos de métricas de Monitoring, se deben cumplir tres requisitos principales:

  1. Exporta los datos de Cloud Monitoring. Debe exportar los datos de métricas de Cloud Monitoring como un valor de métrica agregado. Es necesario agregar las métricas porque, aunque técnicamente es posible almacenar puntos de datos timeseries sin procesar, no aporta ningún valor. La mayoría de los análisis a largo plazo se realizan a nivel agregado durante un periodo más largo. La granularidad de la agregación es única para cada caso práctico, pero recomendamos que sea de al menos 1 hora.
  2. Ingiere los datos para analizarlos. Debe importar las métricas de Cloud Monitoring exportadas a un motor de analíticas para analizarlas.
  3. Escribir consultas y crear paneles de control a partir de los datos. Necesitas paneles de control y acceso SQL estándar para consultar, analizar y visualizar los datos.

Pasos funcionales

  1. Crea una lista de métricas que quieras incluir en la exportación.
  2. Lee métricas de la API Monitoring.
  3. Asigna las métricas de la salida JSON exportada de la API Monitoring al formato de tabla de BigQuery.
  4. Escriba las métricas en BigQuery.
  5. Crea una programación programática para exportar las métricas con regularidad.

Arquitectura

El diseño de esta arquitectura aprovecha los servicios gestionados para simplificar las operaciones y la gestión, reducir los costes y ofrecer la posibilidad de escalar según sea necesario.

Diagrama de arquitectura de los productos utilizados en la solución

En la arquitectura se utilizan las siguientes tecnologías:

  • App Engine: solución de plataforma como servicio (PaaS) escalable que se usa para llamar a la API Monitoring y escribir en BigQuery.
  • BigQuery: un motor de analíticas totalmente gestionado que se usa para ingerir y analizar los datos de timeseries.
  • Pub/Sub: un servicio de mensajería en tiempo real totalmente gestionado que se usa para proporcionar un procesamiento asíncrono escalable.
  • Cloud Storage: un sistema de almacenamiento de objetos unificado para desarrolladores y empresas que se usa para almacenar los metadatos sobre el estado de la exportación.
  • Cloud Scheduler: un programador de estilo cron que se usa para ejecutar el proceso de exportación.

Información sobre los detalles de las métricas de Cloud Monitoring

Para saber cómo exportar métricas de Cloud Monitoring de la mejor forma posible, es importante entender cómo almacena las métricas.

Tipos de métricas

Hay cuatro tipos principales de métricas en Cloud Monitoring que puedes exportar.

Cada uno de estos tipos de métricas tiene un descriptor de métrica, que incluye el tipo de métrica, así como otros metadatos de métricas. La siguiente métrica es un ejemplo de lista de descriptores de métricas del método projects.metricDescriptors.list de la 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"
      }
    }
  ]
}

Los valores importantes que debes conocer del descriptor de métricas son los campos type, valueType y metricKind. Estos campos identifican la métrica e influyen en la agregación que se puede hacer en un descriptor de métrica.

Tipos de métricas

Cada métrica tiene un tipo de métrica y un tipo de valor. Para obtener más información, consulta el artículo Tipos de valores y tipos de métricas. El tipo de métrica y el tipo de valor asociado son importantes porque su combinación afecta a la forma en que se agregan las métricas.

En el ejemplo anterior, el tipo de métrica pubsub.googleapis.com/subscription/push_request_count metric tiene un tipo de métrica DELTA y un tipo de valor INT64.

Solicitud push

En Cloud Monitoring, el tipo de métrica y los tipos de valor se almacenan en metricsDescriptors, que están disponibles en la API Monitoring.

Serie temporal

Los timeseries son mediciones periódicas de cada tipo de métrica almacenadas a lo largo del tiempo que contienen el tipo de métrica, los metadatos, las etiquetas y los puntos de datos medidos individuales. Las métricas que recoge Monitoring automáticamente, como las métricas deGoogle Cloud y AWS, se recogen periódicamente. Por ejemplo, la métrica appengine.googleapis.com/http/server/response_latencies se recoge cada 60 segundos.

Un conjunto de puntos recogidos de un timeseries determinado puede crecer con el tiempo en función de la frecuencia de los datos registrados y de las etiquetas asociadas al tipo de métrica. Si exportas los timeseries puntos de datos sin procesar, es posible que la exportación sea de gran tamaño. Para reducir el número de puntos de datos timeseries devueltos, puedes agregar las métricas durante un periodo de alineación determinado. Por ejemplo, si usa la agregación, puede devolver un punto de datos por hora de una métrica determinada timeseries que tenga un punto de datos por minuto. De esta forma, se reduce el número de puntos de datos exportados y el procesamiento analítico necesario en el motor de analíticas. En este artículo, se devuelve timeseries por cada tipo de métrica seleccionado.

Agregación de métricas

Puedes usar la agregación para combinar datos de varios timeseries en un solo timeseries. La API Monitoring proporciona potentes funciones de alineación y agregación para que no tengas que realizar la agregación tú mismo. Para ello, debes pasar los parámetros de alineación y agregación a la llamada a la API. Para obtener más información sobre cómo funciona la agregación en la API Monitoring, consulta Filtrado y agregación y esta entrada de blog.

Asigna metric type a aggregation type para asegurarte de que las métricas estén alineadas y de que timeseries se reduzca para satisfacer tus necesidades analíticas. Hay listas de alineadores y reductores que puedes usar para agregar el timeseries. Los alineadores y los reductores tienen un conjunto de métricas que puede usar para alinear o reducir en función de los tipos de métricas y los tipos de valores. Por ejemplo, si agregas datos durante 1 hora, el resultado de la agregación será 1 punto por hora para timeseries.

Otra forma de ajustar la agregación es usar la función Group By, que te permite agrupar los valores agregados en listas de timeseries agregados. Por ejemplo, puede agrupar las métricas de App Engine por módulo de App Engine. Si se agrupan los datos por módulo de App Engine y se combinan con los alineadores y reductores que agregan los datos por horas, se obtiene un punto de datos por módulo de App Engine por hora.

La agregación de métricas equilibra el aumento del coste de registrar puntos de datos individuales con la necesidad de conservar suficientes datos para realizar un análisis detallado a largo plazo.

Detalles de la implementación de referencia

La implementación de referencia contiene los mismos componentes que se describen en el diagrama de diseño de la arquitectura. A continuación, se describen los detalles de implementación funcionales y relevantes de cada paso.

Crear una lista de métricas

Cloud Monitoring define más de mil tipos de métricas para ayudarte a monitorizar Google Cloud, AWS y software de terceros. La API Monitoring proporciona el método projects.metricDescriptors.list, que devuelve una lista de métricas disponibles para un proyecto Google Cloud. La API Monitoring proporciona un mecanismo de filtrado para que puedas filtrar una lista de métricas que quieras exportar para almacenarlas y analizarlas a largo plazo.

La implementación de referencia en GitHub usa una aplicación de App Engine de Python para obtener una lista de métricas y, a continuación, escribe cada mensaje en un tema de Pub/Sub por separado. La exportación la inicia un Cloud Scheduler que genera una notificación de Pub/Sub para ejecutar la aplicación.

Hay muchas formas de llamar a la API Monitoring. En este caso, se llama a las APIs Cloud Monitoring y Pub/Sub mediante la biblioteca de cliente de la API de Google para Python debido a su acceso flexible a las APIs de Google.

Get timeseries

Extrae el timeseries de la métrica y, a continuación, escribe cada timeseries en Pub/Sub. Con la API Monitoring, puedes agregar los valores de métricas de un periodo de alineación determinado mediante el método project.timeseries.list. Al agregar datos, se reduce la carga de procesamiento, los requisitos de almacenamiento, los tiempos de consulta y los costes de análisis. La agregación de datos es una práctica recomendada para llevar a cabo análisis de métricas a largo plazo de forma eficiente.

La implementación de referencia en GitHub usa una aplicación Python App Engine para suscribirse al tema, donde cada métrica que se va a exportar se envía como un mensaje independiente. Por cada mensaje que se recibe, Pub/Sub envía el mensaje a la aplicación de App Engine. La aplicación obtiene el timeseries de una métrica determinada agregada en función de la configuración de entrada. En este caso, se llama a las APIs Cloud Monitoring y Pub/Sub mediante la biblioteca de cliente de las APIs de Google.

Cada métrica puede devolver uno o varios timeseries.. Cada métrica se envía mediante un mensaje Pub/Sub independiente para insertarla en BigQuery. La asignación de la métrica type-to-aligner y la métrica type-to-reducer está integrada en la implementación de referencia. En la siguiente tabla se muestra la asignación utilizada en la implementación de referencia en función de las clases de tipos de métricas y de valores admitidos por los alineadores y los reductores.

Tipo de valor GAUGE Alineador Reductor DELTA Alineador Reductor CUMULATIVE2 Alineador Reductor
BOOL yes ALIGN_FRACTION_TRUE ninguno no N/A N/A no N/A N/A
INT64 yes ALIGN_SUM ninguno yes ALIGN_SUM ninguno yes ninguno ninguno
DOUBLE yes ALIGN_SUM ninguno yes ALIGN_SUM ninguno yes ninguno ninguno
STRING yes Excluido Excluido no N/A N/A no N/A N/A
DISTRIBUTION yes ALIGN_SUM ninguno yes ALIGN_SUM ninguno yes ninguno ninguno
MONEY no N/A N/A no N/A N/A no N/A N/A

Es importante tener en cuenta la asignación de valueType a los alineadores y reductores, ya que la agregación solo es posible para valueTypes y metricKinds específicos de cada alineador y reductor.

Por ejemplo, considera el tipo pubsub.googleapis.com/subscription/push_request_count metric. En función del tipo de métrica DELTA y del tipo de valor INT64, una forma de agregar la métrica es la siguiente:

  • Periodo de alineación: 3600 s (1 hora)
  • Aligner = ALIGN_SUM: el dato resultante del periodo de alineación es la suma de todos los datos del periodo de alineación.
  • Reducer = REDUCE_SUM: se reduce calculando la suma de un timeseries para cada periodo de alineación.

Además del periodo de alineación, el alineador y los valores del reductor, el método project.timeseries.list requiere otros datos:

  • filter: selecciona la métrica que quieras devolver.
  • startTime: selecciona el punto de partida en el tiempo al que quieres volver. timeseries
  • endTime: selecciona el último punto temporal para el que se debe devolver el valor. timeseries
  • groupBy: introduce los campos por los que se agrupará la respuesta timeseries.
  • alignmentPeriod: introduce los periodos en los que quieras que se alineen las métricas.
  • perSeriesAligner - Alinea los puntos en intervalos de tiempo uniformes definidos por un alignmentPeriod.
  • crossSeriesReducer: combina varios puntos con diferentes valores de etiqueta en un punto por intervalo de tiempo.

La solicitud GET a la API incluye todos los parámetros descritos en la lista anterior.

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

En el siguiente HTTP GET se muestra una llamada de ejemplo al método de la API projects.timeseries.list mediante los parámetros de entrada:

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 llamada a la API Monitoring anterior incluye un crossSeriesReducer=REDUCE_SUM, lo que significa que las métricas se combinan y se reducen a una sola suma, como se muestra en el ejemplo siguiente.

{
  "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"
          }
        }
      ]
    }
  ]
}

Este nivel de agregación agrega datos en un único punto de datos, lo que la convierte en una métrica ideal para tu Google Cloud proyecto en general. Sin embargo, no te permite desglosar qué recursos han contribuido a la métrica. En el ejemplo anterior, no se puede saber qué suscripción de Pub/Sub ha contribuido más al recuento de solicitudes.

Si quieres revisar los detalles de los componentes individuales que generan el timeseries, puedes quitar el parámetro crossSeriesReducer. Sin crossSeriesReducer, la API Monitoring no combina los distintos timeseries para crear un solo valor.

En el siguiente HTTP GET se muestra una llamada de ejemplo al método de la API projects.timeseries.list mediante los parámetros de entrada. La crossSeriesReducer no está incluida.

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+

En la siguiente respuesta JSON, los metric.labels.keys son los mismos en ambos resultados porque el timeseries está agrupado. Se devuelven puntos independientes para cada uno de los resource.labels.subscription_ids valores. Revisa los valores de metric_export_init_pub y metrics_list en el siguiente JSON. Recomendamos este nivel de agregación porque le permite usarGoogle Cloud productos, incluidos como etiquetas de recursos, en sus consultas de 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"
        }
    ]
}

Cada métrica de la salida JSON de la llamada a la API projects.timeseries.list se escribe directamente en Pub/Sub como un mensaje independiente. Se produce una posible dispersión en la que una métrica de entrada genera una o varias timeseries. Pub/Sub ofrece la posibilidad de absorber una posible gran difusión sin superar los tiempos de espera.

El periodo de alineación proporcionado como entrada significa que los valores de ese periodo se agregan en un solo valor, como se muestra en la respuesta del ejemplo anterior. El periodo de alineación también define la frecuencia con la que se debe ejecutar la exportación. Por ejemplo, si el periodo de alineación es de 3600 segundos (1 hora), la exportación se realizará cada hora para exportar el timeseries con regularidad.

Métricas de la tienda

La implementación de referencia en GitHub usa una aplicación de Python App Engine para leer cada timeseries y, a continuación, insertar los registros en la tabla de BigQuery. Por cada mensaje recibido, Pub/Sub envía el mensaje a la aplicación de App Engine. El mensaje de Pub/Sub contiene datos de métricas exportados desde la API Monitoring en formato JSON y debe asignarse a una estructura de tabla en BigQuery. En este caso, se llama a las APIs de BigQuery mediante la biblioteca de cliente de la API de Google.

El esquema de BigQuery se ha diseñado para que se corresponda con el JSON exportado de la API Monitoring. Al crear el esquema de la tabla de BigQuery, se debe tener en cuenta la escala de los tamaños de los datos a medida que aumentan con el tiempo.

En BigQuery, le recomendamos que cree particiones en la tabla en función de un campo de fecha, ya que esto puede hacer que las consultas sean más eficientes al seleccionar intervalos de fechas sin tener que analizar toda la tabla. Si tienes previsto ejecutar la exportación con regularidad, puedes usar sin problemas la partición predeterminada basada en la fecha de ingestión.

Captura de pantalla de la creación de particiones en BigQuery

Si tiene previsto subir métricas en bloque o no ejecuta la exportación periódicamente, cree particiones en end_time,, lo que requiere cambios en el esquema de BigQuery. Puedes mover el end_time a un campo de nivel superior del esquema, donde puedes usarlo para crear particiones, o añadir un campo nuevo al esquema. Es obligatorio mover el campo end_time porque está incluido en un registro de BigQuery y la partición debe hacerse en un campo de nivel superior. Para obtener más información, consulta la documentación sobre particiones de BigQuery.

BigQuery también ofrece la posibilidad de que los conjuntos de datos, las tablas y las particiones de tablas caduquen después de un periodo determinado.

Captura de pantalla de la configuración de caducidad de datos en BigQuery

Esta función es una forma útil de purgar datos antiguos cuando ya no son útiles. Por ejemplo, si tu análisis abarca un periodo de 3 años, puedes añadir una política para eliminar los datos que tengan más de 3 años.

Programar exportación

Cloud Scheduler es un programador de tareas cron totalmente gestionado. Cloud Scheduler te permite usar el formato de programación cron estándar para activar una aplicación de App Engine, enviar un mensaje mediante Pub/Sub o enviar un mensaje a un endpoint HTTP arbitrario.

En la implementación de referencia de GitHub, Cloud Scheduler activa la aplicación de App Engine cada hora enviando un mensaje de Pub/Sub con un token que coincida con la configuración de App Engine.list-metrics El periodo de agregación predeterminado en la configuración de la aplicación es de 3600 segundos (1 hora), que se corresponde con la frecuencia con la que se activa la aplicación. Se recomienda una agregación de al menos 1 hora, ya que ofrece un equilibrio entre la reducción de los volúmenes de datos y la conservación de datos de alta fidelidad. Si usas un periodo de alineación diferente, cambia la frecuencia de la exportación para que corresponda al periodo de alineación. La implementación de referencia almacena el último valor de end_time en Cloud Storage y lo usa como start_time posterior, a menos que se proporcione un start_time como parámetro.

En la siguiente captura de pantalla de Cloud Scheduler se muestra cómo puedes usar la consola para configurar Cloud Scheduler de forma que invoque la aplicación de App Engine list-metrics cada hora. Google Cloud

Configuración de Cloud Scheduler

El campo Frecuencia usa la sintaxis de estilo cron para indicar a Cloud Scheduler con qué frecuencia debe ejecutar la aplicación. El campo Destino especifica un mensaje de Pub/Sub que se genera, y el campo Carga útil contiene los datos incluidos en el mensaje de Pub/Sub.

Usar las métricas exportadas

Con los datos exportados en BigQuery, ahora puede usar SQL estándar para consultar los datos o crear paneles de control para visualizar las tendencias de sus métricas a lo largo del tiempo.

Consulta de ejemplo: latencias de App Engine

La siguiente consulta busca el valor mínimo, el máximo y la media de los valores de la métrica de latencia media de una aplicación de App Engine. metric.type identifica la métrica de App Engine y las etiquetas identifican la aplicación de App Engine en función del valor de la etiqueta project_id. Se usa point.value.distribution_value.mean porque esta métrica es un valor de DISTRIBUTION en la API Monitoring, que se asigna al objeto de campo distribution_value en BigQuery. El campo end_time muestra los valores de los últimos 30 días.

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

Consulta de ejemplo: recuentos de consultas de BigQuery

La siguiente consulta devuelve el número de consultas en BigQuery por día en un proyecto. El campo int64_value se usa porque esta métrica es un valor INT64 en la API Monitoring, que se asigna al campo int64_value en BigQuery. El metric.type identifica la métrica de BigQuery y las etiquetas identifican el proyecto en función del valor de la etiqueta project_id. El campo end_time muestra los valores de los últimos 30 días.

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

Consulta de ejemplo: instancias de Compute Engine

La siguiente consulta busca los valores mínimo, máximo y medio semanales de la métrica de uso de CPU de las instancias de Compute Engine de un proyecto. El metric.type identifica la métrica de Compute Engine y las etiquetas identifican las instancias en función del valor de la etiqueta project_id. El campo end_time muestra los valores de los últimos 30 días.

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

Visualización de datos

BigQuery se integra con muchas herramientas que puedes usar para visualizar datos.

Looker Studio es una herramienta gratuita creada por Google que te permite crear gráficos y paneles de datos para visualizar los datos de métricas y, después, compartirlos con tu equipo. En el siguiente ejemplo se muestra un gráfico de líneas de tendencia de la latencia y el recuento de la métrica appengine.googleapis.com/http/server/response_latencies a lo largo del tiempo.

Gráfico de las tendencias de App Engine a lo largo del tiempo

Colaboratory es una herramienta de investigación para la enseñanza y la investigación del aprendizaje automático. Es un entorno de Jupyter Notebook alojado que no requiere configuración para usarlo y acceder a los datos de BigQuery. Con un cuaderno de Colab, comandos de Python y consultas SQL, puedes desarrollar análisis y visualizaciones detallados.

Gráfico de uso de la CPU

Monitorizar la implementación de referencia de la exportación

Mientras se ejecuta la exportación, debes monitorizarla. Una forma de decidir qué métricas monitorizar es definir un objetivo de nivel de servicio. Un objetivo de nivel de servicio es un valor objetivo o un intervalo de valores de un nivel de servicio que se mide mediante una métrica. En el libro Site Reliability Engineering se describen cuatro áreas principales para los SLOs: disponibilidad, rendimiento, tasa de errores y latencia. En el caso de las exportaciones de datos, el rendimiento y la tasa de errores son dos factores importantes que puede monitorizar mediante las siguientes métricas:

  • Rendimiento: appengine.googleapis.com/http/server/response_count
  • Tasa de errores: logging.googleapis.com/log_entry_count

Por ejemplo, puedes monitorizar la tasa de errores mediante la métrica log_entry_count y filtrarla por las aplicaciones de App Engine (list-metrics, get-timeseries y write-metrics) con una gravedad de ERROR. A continuación, puedes usar las políticas de alertas de Cloud Monitoring para recibir alertas sobre los errores que se produzcan en la aplicación de exportación.

Políticas de alertas

La interfaz de usuario de las alertas muestra un gráfico de la métrica log_entry_count en comparación con el umbral para generar la alerta.

Gráfico de las condiciones

Siguientes pasos