Solucionar problemas con las métricas basadas en registros

En esta página se proporciona información para solucionar problemas habituales al usar métricas basadas en registros en Cloud Logging.

No se pueden ver ni crear métricas

Las métricas basadas en registros solo se aplican a un Google Cloud proyecto o a un segmento de registros de un Google Cloud proyecto. No puedes crear métricas basadas en registros para otros recursos de Google Cloud como cuentas de facturación u organizaciones. Las métricas basadas en registros se calculan solo para los registros del Google Cloud proyecto o del segmento en el que se reciben.

Para crear métricas, necesita los permisos de Gestión de Identidades y Accesos correctos. Para obtener más información, consulta Control de acceso con IAM: métricas basadas en registros.

Faltan datos de registro en la métrica

Hay varios motivos posibles por los que faltan datos en las métricas basadas en registros:

  • Es posible que las nuevas entradas de registro no coincidan con el filtro de tu métrica. Una métrica basada en registros obtiene datos de las entradas de registro coincidentes que se reciben después de que se cree la métrica. El registro no rellena la métrica con las entradas de registro anteriores.

  • Es posible que las nuevas entradas de registro no contengan el campo correcto o que los datos no tengan el formato adecuado para que tu métrica de distribución los extraiga. Comprueba que los nombres de los campos y las expresiones regulares sean correctos.

  • Es posible que los recuentos de tus métricas se retrasen. Aunque las entradas de registro contabilizables aparecen en el explorador de registros, las métricas basadas en registros pueden tardar hasta 10 minutos en actualizarse en Cloud Monitoring.

  • Es posible que las entradas de registro que se muestran se contabilicen tarde o no se contabilicen en absoluto porque su marca de tiempo sea demasiado antigua o futura. Si Cloud Logging recibe una entrada de registro que tiene una antigüedad de más de 24 horas o una fecha posterior a 10 minutos, no se contabilizará en la métrica basada en registros.

    El número de entradas que llegan tarde se registra en la métrica basada en registros logging.googleapis.com/logs_based_metrics_error_count.

    Ejemplo: Una entrada de registro que coincide con una métrica basada en registros llega tarde. Tiene una timestamp a las 14:30 del 20 de febrero del 2020 y una receivedTimestamp a las 14:45 del 21 de febrero del 2020. Esta entrada no se contabilizará en la métrica basada en registros.

  • La métrica basada en registros se creó después de que llegaran las entradas de registro que la métrica podría contar. Las métricas basadas en registros evalúan las entradas de registro a medida que se almacenan en los segmentos de registros. Estas métricas no evalúan las entradas de registro almacenadas en Logging.

  • La métrica basada en registros tiene lagunas en los datos. Es normal que haya algunas lagunas en los datos, ya que los sistemas que procesan los datos de métricas basados en registros no garantizan la persistencia de todos los puntos de datos de las métricas. Cuando se producen, suelen ser poco frecuentes y de corta duración. Sin embargo, si tienes una política de alertas que monitoriza una métrica basada en registros, los huecos en los datos pueden provocar una notificación falsa. Los ajustes que uses en tu política de alertas pueden reducir esta posibilidad.

    Ejemplo: Se escribe una entrada de registro "latido" cada cinco minutos y una métrica basada en registros cuenta el número de entradas de registro "latido". Una política de alertas suma los recuentos en un intervalo de cinco minutos y te avisa cuando el total es inferior a uno. Cuando falta un punto de datos en la serie temporal, la política de alertas inserta un valor sintético, que es un duplicado de la muestra más reciente y que probablemente sea cero, y, a continuación, evalúa la condición. Por lo tanto, aunque falte un solo punto de datos, el valor sumado podría ser cero, lo que provocaría que esta política de alertas enviara una notificación.

    Para reducir el riesgo de que se envíe una notificación falsa, configura la política para que cuente varias entradas de registro de "latido", no solo una.

El tipo de recurso es "undefined" en Cloud Monitoring

Algunos tipos de recursos supervisados de Cloud Logging no se corresponden directamente con los tipos de recursos supervisados de Cloud Monitoring. Por ejemplo, cuando creas una política de alertas o un gráfico a partir de una métrica basada en registros, es posible que el tipo de recurso sea "undefined" (sin definir).

El tipo de recurso no está definido.

El tipo de recurso monitorizado se asigna a global o a otro tipo de recurso monitorizado en Cloud Monitoring. Consulta las asignaciones de recursos solo de registro para determinar qué tipo de recurso monitorizado debes elegir.

Las etiquetas de una notificación no se resuelven

Crea una métrica basada en registros y, a continuación, una política de alertas para monitorizarla. En el campo de documentación de tu política de alertas, haces referencia a las etiquetas extraídas mediante una variable con el formato ${log.extracted_label.KEY}, donde KEY es el nombre que has asignado a la etiqueta extraída. La etiqueta no se resuelve en la notificación.

Para solucionar este problema, haz una de las siguientes acciones:

  • Elimina el contenido de la etiqueta extraída de la documentación. Las políticas de alertas que monitorizan métricas basadas en registros no pueden extraer datos de las entradas de registro.

  • Crea una alerta basada en registros. Estas políticas de alertas pueden extraer datos de la entrada de registro que provoca que se activen.

No se crean incidentes o son falsos positivos

Puede que se produzcan incidentes falsos positivos o situaciones en las que Monitoring no cree incidentes a partir de métricas basadas en registros porque el periodo de alineación de la política de alertas es demasiado corto. Puede que se produzcan falsos positivos en los siguientes casos:

  • Cuando una política de alertas usa la lógica menor que.
  • Cuando una política de alertas se basa en una condición de percentil de una métrica de distribución.
  • Cuando hay un hueco en los datos de la métrica.

Pueden producirse incidentes de falsos positivos porque las entradas de registro se pueden enviar a Logging con retraso. Por ejemplo, los campos de registro timestamp y receiveTimestamp pueden tener un delta de minutos en algunos casos. Además, cuando Logging almacena registros en segmentos de registro, hay un retraso inherente entre el momento en que se generan las entradas de registro y el momento en que Logging las recibe. Esto significa que es posible que Logging no tenga el recuento total de una entrada de registro concreta hasta un momento posterior a la generación de las entradas de registro. Por eso, una política de alertas que use la lógica menor que o que se base en una condición de percentil de una métrica de distribución puede generar una alerta falsa positiva, ya que aún no se han tenido en cuenta todas las entradas de registro.

Sin embargo, las métricas basadas en registros son coherentes con el tiempo, ya que una entrada de registro que coincida con una métrica basada en registros se puede enviar a Logging con una timestamp que sea significativamente anterior o posterior a la receiveTimestamp del registro.

Esto significa que la métrica basada en registros puede recibir entradas de registro con marcas de tiempo anteriores después de que Logging ya haya recibido entradas de registro con la misma marca de tiempo. Por lo tanto, el valor de la métrica debe actualizarse.

Para que las notificaciones sigan siendo precisas incluso con datos actualizados, te recomendamos que definas un periodo de alineación de al menos 10 minutos para la condición. En concreto, este valor debe ser lo suficientemente grande como para asegurarse de que se contabilicen varias entradas de registro que coincidan con su filtro. Por ejemplo, si una métrica basada en registros cuenta las entradas de registro "latido", que se esperan cada N minutos, define el periodo de alineación en 2N minutos o 10 minutos, el que sea mayor:

  • Si usas la consola Google Cloud , utiliza el menú Ventana de acumulación para definir el periodo de alineación.

  • Si usas la API, utiliza el campo aggregations.alignmentPeriod de la condición para definir el periodo de alineación.

La métrica tiene demasiadas series temporales

El número de series temporales de una métrica depende del número de combinaciones diferentes de valores de etiquetas. El número de series temporales se denomina cardinalidad de la métrica y no debe superar las 30.000.

Como puede generar una serie temporal para cada combinación de valores de etiquetas, si tiene una o más etiquetas con un número elevado de valores, no es difícil superar las 30.000 series temporales. Debe evitar las métricas de cardinalidad elevada.

A medida que aumenta la cardinalidad de una métrica, esta puede limitarse y es posible que algunos puntos de datos no se escriban en ella. Los gráficos que muestran la métrica pueden tardar en cargarse debido al gran número de series temporales que tienen que procesar. También se pueden aplicar costes por las llamadas a la API para consultar datos de series temporales. Consulta las secciones de Cloud Monitoring de la página de precios de Google Cloud Observability.

Para evitar crear métricas de cardinalidad elevada, siga estas recomendaciones:

  • Compruebe que los campos de etiqueta y las expresiones regulares del extractor coincidan con valores que tengan una cardinalidad limitada.

    Por ejemplo, no almacene tallas, recuentos ni duraciones en etiquetas. Además, no almacenes campos como URLs, direcciones IP o IDs únicos, ya que todos ellos pueden generar un gran número de series temporales.

  • Evita extraer mensajes de texto que puedan cambiar sin límites como valores de etiqueta.

  • Evita extraer valores numéricos con cardinalidad ilimitada.

  • Extrae solo los valores de las etiquetas de cardinalidad conocida; por ejemplo, los códigos de estado con un conjunto de valores conocidos.

Estas métricas basadas en registros del sistema pueden ayudarte a medir el efecto que tiene añadir o quitar etiquetas en la cardinalidad de tu métrica:

Cuando inspeccione estas métricas, podrá filtrar los resultados por nombre de métrica. Para obtener más información, consulta el artículo Seleccionar métricas: filtrar.

El nombre de la métrica no es válido

Cuando crees una métrica de contador o de distribución, elige un nombre de métrica que sea único entre las métricas basadas en registros de tu Google Cloud proyecto.

Las cadenas de nombre de métrica no deben superar los 100 caracteres y solo pueden incluir los siguientes caracteres:

  • A-Z
  • a-z
  • 0-9
  • Los caracteres especiales _-.,+!*',()%\/.

    La barra diagonal / indica una jerarquía de partes dentro del nombre de la métrica y no puede ser el primer carácter del nombre.

Los valores de las métricas no son correctos

Observa que los valores registrados de una métrica basada en registros a veces son diferentes del número de entradas de registro que muestra el Explorador de registros.

Para minimizar la discrepancia, haga lo siguiente:

  • Asegúrate de que las aplicaciones no envíen entradas de registro duplicadas. Las entradas de registro se consideran duplicados cuando tienen el mismo timestamp y insertId. El Explorador de registros suprime automáticamente las entradas de registro duplicadas. Sin embargo, las métricas basadas en registros cuentan cada entrada de registro que coincide con el filtro de la métrica.

  • Asegúrate de que se envíe una entrada de registro a Cloud Logging cuando la marca de tiempo sea de hace menos de 24 horas o de dentro de menos de 10 minutos. Las métricas basadas en registros no tienen en cuenta las entradas de registro cuyas marcas de tiempo no estén dentro de estos límites.

No puedes eliminar la posibilidad de que haya registros duplicados. Si se produce un error interno durante la gestión de una entrada de registro, Cloud Logging invoca un proceso de reintento. El proceso de reintento puede provocar que se duplique la entrada de registro. Si hay entradas de registro duplicadas, el valor de una métrica basada en registros puede ser demasiado alto, ya que estas métricas cuentan cada entrada de registro que coincide con el filtro de la métrica.

Los valores de las etiquetas se truncan

Los valores de las etiquetas definidas por el usuario no deben superar los 1024 bytes.

No se puede eliminar una métrica de registro personalizada

Intentas eliminar una métrica personalizada basada en registros mediante la consola. Google Cloud La solicitud de eliminación falla y se muestra el cuadro de diálogo de eliminación con el mensaje de error There is an unknown error while executing this operation.

Para solucionar este problema, prueba lo siguiente:

  • Actualiza la página Métricas basadas en registros de la Google Cloud consola. El mensaje de error puede mostrarse debido a un problema interno con los tiempos.

  • Identifica y elimina las políticas de alertas que monitorizan la métrica basada en registros. Después de verificar que la métrica basada en registros no está monitorizada por una política de alertas, elimínala. Las métricas basadas en registros que monitoriza una política de alertas no se pueden eliminar.