Información general sobre las métricas definidas por el usuario

Las métricas definidas por el usuario son todas las métricas que no están definidas por Google Cloud. Entre ellas se incluyen las métricas que definas y las que defina una aplicación de terceros. Las métricas definidas por el usuario te permiten registrar datos específicos de la aplicación o datos del sistema del lado del cliente. Las métricas integradas que recoge Cloud Monitoring pueden proporcionarte información sobre la latencia del backend o el uso del disco, pero no pueden decirte, por ejemplo, cuántas rutinas en segundo plano ha generado 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 un tipo de métrica definida por el usuario, pero debes crearlas desde Cloud Logging. Para obtener más información sobre las métricas basadas en registros, consulta el artículo Información general sobre las métricas basadas en registros.

Las métricas definidas por el usuario a veces se denominan métricas personalizadas o métricas específicas de la aplicación. Estas métricas te permiten a ti o a una aplicación de terceros definir y recoger información que las métricas integradas de Cloud Monitoring no pueden. Para registrar estas métricas, se usa una API proporcionada por una biblioteca para instrumentar el código y, a continuación, se envían 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, mediante la API de Cloud Monitoring directamente. Sin embargo, te recomendamos que uses OpenTelemetry. Para obtener información sobre cómo crear métricas definidas por el usuario, consulta los siguientes documentos:

  • En el artículo Recoger métricas y trazas de OTLP se describe cómo usar el agente de operaciones y el receptor del protocolo OpenTelemetry (OTLP) del agente para recoger métricas y trazas de aplicaciones instrumentadas con OpenTelemetry y que se ejecutan en Compute Engine.

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

  • En el artículo Recoger métricas de Prometheus se describe cómo usar el agente de operaciones para recoger métricas de Prometheus de aplicaciones que se ejecutan en Compute Engine.

  • En el artículo Crear 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 añadir datos de métricas a esas métricas. En este documento se explica cómo usar la API Monitoring con ejemplos en los lenguajes de programación C#, Go, Java, Node.js, PHP, Python y Ruby, así como con el Explorador de APIs.

  • En el artículo Crear métricas personalizadas en Cloud Run se explica cómo usar el OpenTelemetry Collector como agente sidecar en los despliegues de Cloud Run.

En lo que respecta a Cloud Monitoring, puedes usar métricas definidas por el usuario como las métricas integradas. Puedes representarlos en gráficos, configurar alertas, leerlos y monitorizarlos de otras formas. Para obtener información sobre cómo leer datos de métricas, consulta los siguientes documentos:

  • En List metric and resource types (Consultar métricas y tipos de recursos) se explica cómo consultar y examinar los tipos de métricas integrados y definidos 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 de tu proyecto.
  • En Recuperar datos de series temporales se explica cómo recuperar datos de series temporales de métricas mediante la API Monitoring. Por ejemplo, en este documento se describe cómo puedes usar la API para obtener el uso de la CPU de las instancias de máquina virtual (VM) de tu Google Cloud proyecto.

La consola de Google Cloud proporciona una página específica para ayudarte a ver el uso que haces de las métricas definidas por el usuario. Para obtener información sobre el contenido de esta página, consulta Ver y gestionar el uso de métricas.

Descriptores de 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 de la métrica y el nombre de la métrica. Por ejemplo, las listas de métricas muestran los descriptores de métricas de todos los tipos de métricas integrados.

Cloud Monitoring puede crear el descriptor de métricas por ti usando los datos de métricas que escribas, o bien puedes crear el descriptor de métricas de forma explícita y, a continuación, escribir los datos de métricas. En cualquier caso, debe decidir cómo quiere organizar los 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 llaman 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 Google Cloud y que quieres escribir los datos en el recurso monitorizado 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 una serie temporal y Metric-type-B contiene otra.

    Puede crear una sola política de alertas con dos condiciones o 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 solo tiene una configuración para los canales de notificación.

    Este modelo puede ser adecuado si no te interesan las similitudes entre los datos de las actividades que se están monitorizando. En este ejemplo, las actividades son la frecuencia de llamadas a los programas A y B.

  • Usa una sola métrica y 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 cuyo valor de etiqueta es B.

    Al igual que con el modelo anterior, puede crear una o dos políticas de alertas. Sin embargo, las condiciones de la política de alertas son más complejas. Una condición que genera un incidente cuando la tasa de llamadas del programa A supera un umbral debe usar un filtro que incluya solo los puntos de datos cuyo valor de etiqueta sea A.

    Una de las ventajas de este modelo es que es fácil calcular las ratios. Por ejemplo, puedes determinar qué parte del total se debe a las llamadas a A.

  • Usa una sola métrica para contar el número de llamadas, pero no usa una etiqueta para registrar qué programa se ha llamado. 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 tus objetivos porque los datos de los dos programas no se pueden separar.

Los dos primeros diseños te permiten cumplir los requisitos de análisis de datos, pero el último no.

Para obtener más información, consulta Crear 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 de su proyecto deGoogle Cloud y debe usar un prefijo que marque la métrica como métrica definida por el usuario. En el caso de Monitoring, los prefijos permitidos son custom.googleapis.com/, workload.googleapis.com/, external.googleapis.com/user y external.googleapis.com/prometheus. Después del prefijo, se incluye un nombre que describe lo que estás recogiendo. Para obtener información sobre la forma recomendada de asignar nombres a las métricas, consulta las convenciones de nomenclatura de métricas. A continuación se muestran ejemplos de los dos tipos de identificadores de 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 métricas definidas por el usuario. Ambos ejemplos son de métricas que miden el uso de la CPU, pero utilizan modelos de organización diferentes. Si prevé que va a tener un gran número de métricas definidas por el usuario, le recomendamos que utilice una estructura de nomenclatura jerárquica como la del segundo ejemplo.

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

projects/PROJECT_ID/metricDescriptors/METRIC_TYPE

METRIC_TYPE es el identificador de cadena del tipo de métrica. Si los ejemplos de métricas anteriores se crean en el proyecto my-project-id, los nombres de recursos de 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étricas, el campo name almacena el nombre de recurso del tipo de métrica y el campo type almacena la cadena METRIC_TYPE.

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

Cuando escribas tus datos en una serie temporal, debes indicar de dónde proceden. Para especificar la fuente de los datos, elija un tipo de recurso monitorizado que represente de dónde proceden los datos y, a continuación, úselo para describir el origen específico. El recurso monitorizado 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 monitorizado. El tipo de métrica describe los datos, mientras que el recurso monitorizado describe de dónde proceden los datos.

Ten en cuenta el recurso monitorizado antes de crear el descriptor de métrica. El tipo de recurso monitorizado que utilices influye en las etiquetas que debes incluir en el descriptor de métricas. 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 tienes previsto escribir tu métrica en un recurso de VM de Compute Engine, las etiquetas de recursos incluirán el ID de la instancia, por lo que no necesitarás una etiqueta para el ID de la instancia en el descriptor de métricas.

Cada uno de los puntos de datos de tu métrica debe estar asociado a un objeto de recurso monitorizado. Los puntos de diferentes objetos de recursos monitorizados se almacenan en diferentes series temporales.

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

Una práctica habitual es usar los objetos de recursos monitorizados que representan los recursos físicos en los que se ejecuta el código de tu aplicación. Este enfoque tiene varias ventajas:

  • Obtendrás un mejor rendimiento que si usaras un solo tipo de recurso.
  • De esta forma, se evitan los datos desordenados causados por varios procesos que escriben en la misma serie temporal.
  • Puede agrupar los datos de 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 no es adecuado ninguno de los tipos de recursos más específicos. El tipo generic_task es útil para definir recursos similares a tareas, como aplicaciones. El tipo generic_node es útil para definir recursos similares a nodos, como las máquinas virtuales. Ambos tipos de generic_* tienen varias etiquetas comunes que puede usar para 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 la etiqueta project_id. Si tienes muchas fuentes de métricas en un proyecto, usar el mismo objeto de recurso global puede provocar colisiones y sobrescrituras de tus datos de métricas.

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

En la siguiente tabla se muestra qué métodos de la API Monitoring admiten métricas definidas por el usuario y cuáles admiten métricas integradas:

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

Límites y latencias

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

Para conservar los datos de métricas más allá del periodo de conservación, debe copiar los datos manualmente en otra ubicación, como Cloud Storage o BigQuery.

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

Siguientes pasos