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

Las métricas definidas por el usuario (también llamadas métricas personalizadas) en Cloud Monitoring te permiten capturar la telemetría específica de la aplicación o del cliente que las métricas Google Cloud integradas no recopilan. Por ejemplo, puedes registrar la cantidad de rutinas en segundo plano que genera tu aplicación y, luego, crear gráficos, leer y alertar sobre esas métricas, tal como lo harías con las métricas integradas.

Formas de recopilar y leer métricas definidas por el usuario

Para instrumentar tu código y recopilar métricas definidas por el usuario, te recomendamos usar OpenTelemetry, aunque también puedes usar Prometheus o la API de Cloud Monitoring directamente. Para derivar métricas de las entradas de registro, crea métricas basadas en registros en Cloud Logging. Puedes supervisar la transferencia de métricas en la página Administración de métricas de la consola de Google Cloud .

Para obtener información sobre cómo crear métricas definidas por el usuario, consulta los siguientes documentos:

  • En Recopila métricas y seguimientos de OTLP, se describe cómo usar el Agente de operaciones y el receptor del protocolo OpenTelemetry (OTLP) del agente para recopilar métricas y seguimientos de aplicaciones instrumentadas con OpenTelemetry y que se ejecutan en Compute Engine.

  • En Google Cloud Managed Service para Prometheus, se describe cómo recopilar métricas de Prometheus de las aplicaciones que se ejecutan en Google Kubernetes Engine y Kubernetes.

  • En Recopila métricas de Prometheus, se describe cómo usar el Agente de operaciones para recopilar métricas de Prometheus de aplicaciones que se ejecutan en Compute Engine.

  • En Crea métricas definidas por el usuario con la API, se describe cómo crear métricas con la API de Cloud Monitoring y cómo agregar datos a esas métricas. En este documento, se ilustra cómo usar la API de Monitoring con ejemplos en los que se usan el Explorador de APIs y los lenguajes de programación C#, Go, Java, Node.js, PHP, Python y Ruby.

  • En Crea métricas personalizadas en Cloud Run, se muestra cómo usar el recopilador de OpenTelemetry como un agente de sidecar en las implementaciones de Cloud Run.

En lo que respecta a Cloud Monitoring, puedes usar las métricas definidas por el usuario, como las métricas integradas. Puedes graficarlas, configurar alertas, leerlas y supervisarlas de otra manera. Para obtener información sobre cómo leer datos de métricas, consulta los siguientes documentos:

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

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 la métrica. El descriptor de métrica también define las etiquetas para la métrica y el nombre de la métrica. Por ejemplo, las listas de métricas muestran los descriptores de métricas para todos los tipos de métricas integrados.

Cloud Monitoring puede crear el descriptor de métrica por ti con los datos de métricas que escribas, o puedes crear de forma explícita el descriptor de métrica y, luego, escribir los datos de métricas. En cualquier caso, debes decidir cómo quieres 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 llama a los programas auxiliares A y B. Quieres contar con qué frecuencia se llama a los programas A y B. También quieres saber cuándo se llama al programa A más de 10 veces por minuto y cuándo se llama al programa B más de 5 veces por minuto. Por último, supongamos que tienes un solo proyecto de Google Cloud y que planeas escribir los datos en el recurso supervisado global.

En este ejemplo, se describen algunos diseños diferentes que puedes usar para tus métricas definidas por el usuario:

  • Usas dos métricas: Metric-type-A cuenta las llamadas al programa A y Metric-type-B cuenta 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 o puedes crear dos políticas de alertas, cada una con una condición con este modelo 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 una etiqueta para almacenar un identificador de programa. Por ejemplo, la etiqueta podría 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 una alerta cuando la tasa de llamadas para el programa A supera un umbral debe usar 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 usas una etiqueta para registrar 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 porque los datos de los dos programas no se pueden separar.

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

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

Nombres de las métricas definidas por el usuario

Cuando creas una métrica definida por el usuario, defines un identificador de cadena que representa el tipo de métrica. Esta cadena debe ser única entre las métricas definidas por el usuario en tu proyecto deGoogle Cloud y 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. Al prefijo, le sigue un nombre que describe lo que recopilas. Para obtener detalles sobre la forma recomendada de nombrar una métrica, consulta Convenciones de nombres de 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 ambas métricas son definidas por el usuario. Ambos ejemplos son para métricas que miden el uso de CPU; sin embargo, usan diferentes modelos organizativos. Cuando preveas que tendrás una gran cantidad de métricas definidas por el usuario, te recomendamos que uses una estructura de nombres jerárquica como la que se usa en el segundo ejemplo.

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

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, los nombres de los recursos para estas métricas son 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 las 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 un tipo de recurso supervisado que represente de dónde provienen tus datos y, luego, úsalo para describir el origen específico. El recurso supervisado no forma parte del tipo de métrica. En su lugar, la serie temporal en la que escribes 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.

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 recurso de VM de Compute Engine contiene etiquetas 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, las etiquetas de recursos incluyen el ID de la instancia, por lo que no necesitas una etiqueta para el ID de la 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 conservan en diferentes series temporales.

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

Una práctica habitual es usar los objetos de recurso supervisado que representan los recursos físicos en los que se ejecuta el código de la 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 los datos de tus métricas definidas por el usuario con otros datos de métricas de los 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.

En cambio, el tipo de recurso global solo tiene la etiqueta project_id. Cuando tienes muchas fuentes de métricas en un proyecto, usar el mismo objeto de recurso global puede causar colisiones y reemplazos de tus datos de métricas.

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

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

Método de la API de Monitoring Usa con métricas definidas por el usuario de
 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 conocer 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 los datos de las métricas más allá del período de retención, debes copiarlos de forma manual en otra ubicación, como Cloud Storage o BigQuery.

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

¿Qué sigue?