Descripción general de las métricas definidas por el usuario

Las métricas definidas por el usuario son todas las métricas que no define Google Cloud. Estas incluyen métricas que podrías definir que define una aplicación de terceros. Las métricas definidas por el usuario le permiten datos específicos de la aplicación o datos del sistema del cliente. Las métricas integradas que recopila Cloud Monitoring puede brindarte información sobre la latencia de backend o el uso del disco, pero no por ejemplo, cuántas rutinas en segundo plano generó tu aplicación.

También puedes crear métricas basadas en el contenido de las entradas de registro. Las métricas basadas en registros son una clase de métrica definida por el usuario, pero debes crear de Cloud Logging. Para obtener más información sobre las métricas basadas en registros, consulta Descripción general de las métricas basadas en registros.

Las métricas definidas por el usuario a veces se denominan métricas personalizadas. métricas específicas de la aplicación. Estas métricas te permiten a ti o a un tercero aplicación, definir y recopilar información que las métricas integradas de Cloud Monitoring no pueden. Captas esas métricas usando una API proporcionada por una biblioteca para instrumentar tu código y, luego, enviarás las métricas a una aplicación de backend, como Cloud Monitoring

Puedes crear métricas definidas por el usuario, excepto métricas basadas en registros, con la API de Cloud Monitoring directamente. Sin embargo, te recomendamos que utilices OpenTelemetry. Para obtener información sobre cómo para crear métricas definidas por el usuario, consulta los siguientes documentos:

En lo que respecta a Cloud Monitoring, puedes usar métricas definidas por el usuario como las métricas integradas. Puedes crear un gráfico de ellos, establecer alertas, leer y supervisarlos. Para obtener información sobre cómo leer datos de métricas, consulta los siguientes documentos:

  • En Enumerar tipos de métricas y recursos, se explica cómo enumerar y examina tus tipos de métricas integrados y definidos por el usuario. Por ejemplo, puede usar la información de ese documento para enumerar todos los recursos definidos descriptores de métricas en tu proyecto.
  • Recupera datos de series temporales explica cómo recuperar datos de series temporales de métricas con el API de Monitoring. Por ejemplo, este documento describe cómo puedes usar la API para obtener el uso de CPU de máquina virtual (VM) en tu proyecto de Google Cloud.

La consola de Google Cloud proporciona una página dedicada para ayudarte a ver el uso de métricas definidas por el usuario. Para obtener información sobre el contenido de esta página, consulta Visualiza y administra el uso de métricas.

Descriptores de métricas para métricas definidas por el usuario

Cada tipo de métrica debe tener un descriptor de métrica que defina cómo se organizan los datos de las métricas. El descriptor de métrica también define las etiquetas de la métrica y el nombre de esta. Por ejemplo, el Las listas de métricas muestran los descriptores de métricas de todos los tipos de métricas.

Cloud Monitoring puede crear el descriptor de métrica por ti mediante el los datos de métricas que escribes o puedes crear explícitamente la métrica y, luego, escribirás datos de métricas. En cualquier caso, debes decidir cómo deseas organizar tus datos de métricas.

Ejemplo de diseño

Supongamos que tienes un programa que se ejecuta en una sola máquina y que este programa llame a los programas auxiliares A y B. Deseas contar la frecuencia con la que se llama a los programas A y B. También debes saber cuándo programa A se llama más de 10 veces por minuto y cuando el programa B se se llaman más de 5 veces por minuto. Por último, supón que tienes un solo proyecto de Google Cloud y planeas escribir los datos en el recurso supervisado global.

Este ejemplo describe algunos diseños diferentes que podrías usar para tus métricas definidas por el usuario:

  • Usas dos métricas: Metric-type-A registra las llamadas al programa A y Metric-type-B registra las llamadas al programa B. En este caso, Metric-type-A contiene 1 serie temporal y Metric-type-B contiene 1 serie temporal.

    Puedes crear una sola política de alertas con dos condiciones crear dos políticas de alertas, cada una con una condición con este modo de datos. Una política de alertas puede admitir varias condiciones, pero tiene una sola configuración para los canales de notificaciones.

    Este modelo podría ser adecuado cuando no te interesan las similitudes de los datos entre las actividades que se supervisan. En este ejemplo, las actividades son la tasa de llamadas a los programas A y B.

  • Usas una sola métrica y usas una etiqueta para almacenar un identificador de programa. Por ejemplo, la etiqueta puede almacenar el valor A o B. Monitoring crea una serie temporal para cada combinación única de etiquetas. Por lo tanto, hay una serie temporal cuyo valor de etiqueta es A y otra serie temporal cuyo valor de etiqueta es B.

    Al igual que con el modelo anterior, puedes crear una sola política de alertas o dos políticas de alertas. Sin embargo, las condiciones de la política de alertas son más complicadas. Una condición que genera un cuando la frecuencia de llamadas del programa A excede un umbral usa un filtro que incluya solo los datos cuyo valor de etiqueta sea A.

    Una de las ventajas de este modelo es que es sencillo para calcular proporciones. Por ejemplo, puedes determinar qué cantidad del total se debe a las llamadas a A.

  • Usas una sola métrica para contar la cantidad de llamadas, pero no uses un sello discográfico para grabar a qué programa se llamó. En este modelo, hay una sola serie temporal que combina los datos de los dos programas. Sin embargo, no puedes crear una política de alertas que cumpla con tus objetivos, ya que los datos de dos programas no se pueden separar.

Los dos primeros diseños te permiten cumplir con tus requisitos de análisis de datos; Sin embargo, el último diseño, no.

Para obtener más información, consulta Crea una métrica definida por el usuario.

Nombres de métricas definidas por el usuario

Cuando creas una métrica definida por el usuario, defines un identificador de cadena representa el tipo de métrica. Esta cadena debe ser única entre las de las métricas definidas por el usuario proyecto de Google Cloud y se debe usar un prefijo que marque la métrica como una métrica definida por el usuario. Para Monitoring, los prefijos permitidos son custom.googleapis.com/, workload.googleapis.com/, external.googleapis.com/user y external.googleapis.com/prometheus. El prefijo va seguido de un nombre que describe lo que estás recopilando. Para obtener detalles sobre la forma recomendada para asignar un nombre a una métrica, consulta Convenciones de nombres de las métricas. A continuación, se muestran ejemplos de los dos tipos de identificadores para los tipos de métricas:

    custom.googleapis.com/cpu_utilization
    custom.googleapis.com/instance/cpu/utilization

En el ejemplo anterior, el prefijo custom.googleapis.com indica que ambos son métricas definidas por el usuario. Ambos ejemplos son para métricas que miden la el uso de CPU; pero usan diferentes modelos organizativos. Cuando preveas tener una gran cantidad de métricas definidas por el usuario, te recomendamos usan una estructura de nomenclatura jerárquica como la del segundo ejemplo.

Todos los tipos de métricas tienen identificadores únicos a nivel global llamados nombres de recursos. Esta es la estructura del nombre de un recurso para un tipo de métrica:

projects/PROJECT_ID/metricDescriptors/METRIC_TYPE

En el ejemplo anterior, METRIC_TYPE es el identificador de string del tipo de métrica. Si los ejemplos de métricas anteriores se crean en el proyecto my-project-id, entonces, sus nombres de recurso para estas métricas serían los siguientes:

    projects/my-project-id/metricDescriptors/custom.googleapis.com/cpu_utilization
    projects/my-project-id/metricDescriptors/custom.googleapis.com/instance/cpu/utilization

¿Nombre o tipo? En el descriptor de métrica, el campo name almacena el nombre del recurso del tipo de métrica y el campo type almacena la string METRIC_TYPE.

Tipos de recursos supervisados para métricas definidas por el usuario

Cuando escribes tus datos en una serie temporal, debes indicar de dónde provienen. Para especificar la fuente de los datos, elige una un tipo de recurso supervisado representa de dónde provienen los datos y, luego, usarlo para describir un origen específico. El recurso supervisado no forma parte del tipo de métrica. En cambio, las series temporales en el que se escriben datos incluye una referencia al tipo de métrica y una referencia al recurso supervisado. El tipo de métrica describe los datos, mientras que el recurso supervisado describe dónde se originaron los datos.

Considera el recurso supervisado antes de crear tu descriptor de métrica. El tipo de recurso supervisado que uses afecta las etiquetas que debes incluir en el descriptor de métrica. Por ejemplo, el El recurso de VM de Compute Engine contiene etiquetas de recurso para el ID del proyecto, el ID de la instancia y la zona de la instancia. Por lo tanto, si planeas escribir tu métrica en un recurso de VM de Compute Engine, entonces las etiquetas de recursos incluyen el ID de la instancia para no necesitan una etiqueta para el ID de instancia en el descriptor de métrica.

Cada uno de los datos de tu métrica debe estar asociado con un objeto de recurso supervisado. Los puntos de diferentes objetos de recursos supervisados se mantienen en diferentes Series temporales.

Debes usar uno de los siguientes tipos de recurso supervisado con métricas definidas por el usuario:

Se suelen usar los objetos de recursos supervisados que representan los recursos físicos donde se ejecuta el código de tu aplicación. Este enfoque tiene varias ventajas:

  • Obtienes un mejor rendimiento en comparación con el uso de un solo tipo de recurso.
  • Evitas los datos fuera de orden causados por múltiples procesos que escriben en la misma serie temporal.
  • Puedes agrupar tus datos de métricas definidas por el usuario con otros datos de métricas del mismos recursos.

global y recursos genéricos

Los tipos de recursos generic_task y generic_node son útiles en situaciones en las que ninguno de los tipos de recursos más específicos es apropiado. El tipo generic_task es útil para definir recursos similares a las tareas, como las aplicaciones. El tipo generic_node es útil para definir recursos similares a los nodos, como máquinas virtuales. Ambos tipos generic_* tienen varias etiquetas comunes que puedes usar a fin de definir objetos de recursos únicos, lo que facilita su uso en filtros de métricas para agregaciones y reducciones.

Por el contrario, el tipo de recurso global solo tiene etiquetas project_id y location. Cuando tienes muchas fuentes de métricas dentro de un proyecto, usar el mismo objeto de recurso global puede provocar y reemplazos de tus datos de métricas.

Métodos de API que admiten métricas definidas por el usuario

En la siguiente tabla, se muestran los métodos de la API de Monitoring admiten métricas definidas por el usuario y qué métodos admiten métricas integradas:

Método de la API de Monitoring Usar con
métricas definidas por el usuario		 Permite el uso con
métricas integradas
monitoredResourceDescriptors.get Sí sí
monitoredResourceDescriptors.list Sí sí
metricDescriptors.get Sí sí
metricDescriptors.list Sí sí
timeSeries.list Sí sí
timeSeries.create sí
metricDescriptors.create sí
metricDescriptors.delete Sí

Límites y latencias

Para los límites relacionados con las métricas definidas por el usuario y la retención de datos, consulta Cuotas y límites.

Para conservar tus datos de métricas luego del período de retención, debes copiar de forma manual los datos a otra ubicación, como Cloud Storage o en BigQuery.

Para obtener información sobre las latencias asociadas con la escritura de datos en para las métricas definidas por el usuario, consulta Latencia de datos de métricas.

¿Qué sigue?