Métricas personalizadas

Las métricas personalizadas te permiten capturar datos específicos de la aplicación o datos del sistema del cliente. Las métricas integradas que recopila Cloud Monitoring pueden brindarte información sobre la latencia del backend o el uso del disco, pero no pueden decirte, 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. Para obtener información sobre esos tipos de métricas personalizadas, consulta Descripción general de las métricas basadas en registros.

Las métricas personalizadas, también conocidas como métricas específicas de aplicaciones, te permiten definir y recopilar información que las métricas integradas de Cloud Monitoring no pueden. Para capturar estas métricas, usa una API que haya proporcionado una biblioteca a fin de instrumentar tu código. Luego, envía las métricas a una aplicación de backend como Cloud Monitoring.

Puedes crear métricas personalizadas mediante la API de Cloud Monitoring directamente. Sin embargo, te recomendamos que uses OpenCensus. Para obtener información sobre cómo crear métricas personalizadas, consulta los siguientes documentos:

  • En Crea métricas personalizadas con OpenCensus, se describe cómo usar OpenCensus, una biblioteca de supervisión y seguimiento de código abierto. Esta biblioteca te permite crear métricas personalizadas, agregar datos de métricas a esas métricas y exportar los datos de métricas a Cloud Monitoring.

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

En lo que respecta a Cloud Monitoring, puedes usar métricas personalizadas, como las métricas integradas. Puedes graficarlas, establecer alertas, leerlas y supervisarlas. Para obtener información sobre la lectura de datos de métricas, consulta los siguientes documentos:

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

Google Cloud Console proporciona una página exclusiva para ayudarte a ver el uso de las métricas personalizadas. Para obtener información sobre el contenido de esta página, consulta Cómo ver diagnósticos de métricas.

Descriptores de métricas para métricas personalizadas

Cada tipo de métrica debe tener un descriptor de métrica que defina cómo se organizan los datos correspondientes. El descriptor de métrica también define las etiquetas 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 integradas.

Cuando usas métricas personalizadas, Cloud Monitoring puede crear el descriptor de métricas por ti con los datos de métricas que escribes. Como alternativa, puedes crear el descriptor de métrica de forma explícita y, luego, escribir los datos de métrica. En cualquier caso, debes decidir cómo quieres organizar los datos de métrica.

Ejemplo de diseño

Supongamos que tienes un programa que se ejecuta en una sola máquina y que este llama a los programas auxiliares A y B. Deseas contar la frecuencia con la que 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 planeas escribir los datos en el recurso supervisado global.

En este ejemplo, se describen algunos diseños diferentes que puedes usar para las métricas personalizadas:

  • Usas dos métricas personalizadas: 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 o dos políticas con cada una en 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.

  • Use una sola métrica personalizada 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 serie temporal cuyo valor 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 incidente cuando la frecuencia 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.

  • Usa una sola métrica personalizada para contar la cantidad de llamadas, pero no uses una etiqueta a fin de registrar 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 primeros dos diseños te permiten cumplir con los requisitos de análisis de datos. Sin embargo, el último diseño no lo es.

Para obtener información sobre cómo crear descriptores de métricas, consulta Crea descriptores de métricas.

Nombres de métricas personalizadas

Cuando creas una métrica personalizada, defines un identificador de string que representa el tipo de métrica. Esta string debe ser única entre las métricas personalizadas de tu proyecto de Google Cloud y debe usar un prefijo que marque la métrica como definida por el usuario. En Monitoring, los prefijos permitidos son custom.googleapis.com/, external.googleapis.com/user y external.googleapis.com/prometheus. El prefijo va seguido de un nombre que describe lo que recopilas. Para obtener detalles sobre la forma recomendada de asignar un nombre a una métrica personalizada, 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 métricas personalizadas. Ambos ejemplos son para métricas que miden el uso de CPU; sin embargo, usan diferentes modelos organizacionales. Si esperas tener una gran cantidad de métricas personalizadas, 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 globales llamados nombres de recursos. A continuación, se muestra la estructura de un nombre de 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 se crearon los ejemplos de métricas anteriores 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é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 personalizadas

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 la procedencia de tus datos y, luego, úsalo para describir el origen específico. El recurso supervisado no forma parte del tipo de métrica. En cambio, las series temporales en las que escribes datos incluyen una referencia al tipo de métrica y 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 personalizada en un recurso de VM de Compute Engine, las etiquetas de recursos incluyen el ID de instancia, de modo que no necesitarás 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 distintas series temporales.

Debes usar uno de los siguientes tipos de recursos supervisados con métricas personalizadas:

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 personalizadas 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.

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 colisiones y reemplazos de los datos de métricas.

Métodos de la API que admiten métricas personalizadas

En la siguiente tabla, se muestran los métodos de la API de Monitoring compatibles con las métricas personalizadas y los métodos compatibles con las métricas integradas:

Método de la API de Monitoring Permite el uso con
métricas personalizadas
Permite el uso con
métricas integradas
monitoredResourceDescriptors.get
monitoredResourceDescriptors.list
metricDescriptors.get
metricDescriptors.list
timeSeries.list
timeSeries.create
metricDescriptors.create
metricDescriptors.delete

Límites y latencias

Para obtener información sobre los límites relacionados con las métricas personalizadas y la retención de datos, consulta Cuotas y límites.

Para mantener 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 más información sobre las latencias asociadas con la escritura de datos en métricas personalizadas, consulta Latencia de datos de métricas.

¿Qué sigue?