Anota incidentes con etiquetas

En este documento, se describe cómo puedes organizar y priorizar tus incidentes asignándoles etiquetas definidas por el usuario. Estas etiquetas se configuran en las políticas de alertas y se enumeran en las políticas de alertas y los incidentes. Según tu configuración, las etiquetas también se muestran en ciertas notificaciones.

Acerca de las etiquetas

Las etiquetas, que son pares clave-valor, se usan para adjuntar información a una serie temporal, una política de alertas, un incidente o una notificación. Por ejemplo, las etiquetas de una serie temporal pueden identificar la instancia específica de la máquina virtual (VM) desde la que se recopilaron los datos. Las etiquetas son definidas por el usuario o predefinidas.

Etiquetas definidas por el usuario

Las etiquetas definidas por el usuario contienen la información que especificas. Estas etiquetas pueden tener valores estáticos o dinámicos:

Las claves de etiquetas deben comenzar con una letra en minúscula. Tanto las claves de etiquetas como los valores de las etiquetas solo pueden contener letras en minúscula, números, guiones bajos y guiones.

Etiquetas predefinidas

Las etiquetas predefinidas se incluyen en los descriptores de recursos. Estas etiquetas se deben propagar cuando se escriben los datos de las series temporales. Estas etiquetas muestran información sobre la métrica que se recopila o el recurso en el que se escribe. Por ejemplo, las etiquetas de una serie temporal pueden identificar una máquina virtual (VM), una zona, un proyecto de Google Cloud y un tipo de dispositivo. Cuando Monitoring crea un incidente en función de esa serie temporal, el incidente hereda esas etiquetas.

Cómo ver las etiquetas

Puedes ver las etiquetas de una política de alertas o un incidente en la página de detalles de un incidente, la página de detalles de una política de alertas y en algunas notificaciones.

  • Políticas de alertas: Las etiquetas estáticas definidas por el usuario se enumeran en la sección Etiquetas del usuario. Las etiquetas definidas por el usuario y las predefinidas no son visibles.
  • Incidentes: Las etiquetas estáticas definidas por el usuario se enumeran en la sección Etiquetas de políticas, y las etiquetas dinámicas definidas por el usuario se enumeran en la sección Etiquetas de métricas. Las etiquetas predefinidas se enumeran en las secciones Etiquetas de recursos supervisados y Etiquetas de métricas.
  • Notificaciones: Las etiquetas predefinidas y las definidas por el usuario se enumeran en los siguientes tipos de notificaciones:

    • Correo electrónico
    • Google Chat
    • PagerDuty
    • Pub/Sub
    • Webhook

Ejemplo: Agrega etiquetas definidas por el usuario con valores dinámicos

Puedes usar MQL para configurar una etiqueta de modo que su valor cambie de forma dinámica según los datos de series temporales. Por ejemplo, quieres que tus incidentes tengan una etiqueta criticality cuyo valor cambie según el valor de la métrica de uso de CPU supervisada:

fetch gce_instance
| metric 'compute.googleapis.com/instance/cpu/utilization'
| group_by sliding(5m), [value_utilization_mean: mean(value.utilization)]
| map
    add[
      criticality:
        if(val() >= 90 '%', 'CRITICAL',
          if(val() >= 80 '%', 'WARNING',
            if(val() >= 70 '%', 'INFO', 'GOOD')))
    ]
| condition val() >= 70 '%'

En la siguiente imagen, se ilustra cómo las políticas de alertas que usan consultas de MQL procesan los datos de series temporales que supervisan:

Ilustración de cómo las políticas de alertas procesan sus series temporales supervisadas.

El controlador de políticas procesa los datos de utilización de la CPU y genera una serie temporal que indica cuándo se cumple la condición. En el ejemplo anterior, la condición se cumple cuando el uso de CPU es de al menos el 70%. Para cada serie temporal de entrada, el controlador de políticas puede generar una de las siguientes cuatro series temporales:

Nombre de la serie temporal de salida Se cumplió la condición Descripción
"BUENO" No Esta serie temporal tiene las mismas etiquetas que la serie temporal de entrada. No tiene una etiqueta de gravedad.
"CRITICAL" El uso de CPU es de al menos el 90%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal "BUENA", además de una etiqueta de gravedad con el valor "CRÍTICA".
“ADVERTENCIA” El uso de CPU es de al menos el 80%, pero inferior al 90%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal "BUENA", además de una etiqueta de gravedad con el valor "ADVERTENCIA".
"INFO" El uso de CPU es de al menos el 70%, pero inferior al 80%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal "BUENA", además de una etiqueta de gravedad con el valor "INFO".

Los datos de series temporales que genera el controlador de políticas son la entrada del administrador de incidentes, que determina cuándo se crean y cierran los incidentes. Para determinar cuándo cerrar un incidente, el administrador de incidentes usa los valores de los campos duration, evaluationMissingData y autoClose.

Prácticas recomendadas

Para asegurarte de que haya, como máximo, un incidente abierto a la vez cuando crees etiquetas cuyos valores se establezcan de forma dinámica, haz lo siguiente:

  • En el objeto MetricThreshold, anula los valores predeterminados de los siguientes campos:

    • Campo duration: Se establece en un valor distinto de cero.
    • Campo evaluationMissingData: Configúralo para que los incidentes se cierren cuando dejen de llegar datos. Cuando uses la API de Cloud Monitoring, establece este campo en EVALUATION_MISSING_DATA_INACTIVE. Cuando uses la consola de Google Cloud, establece el campo en "Puntos de datos faltantes tratados como valores que no incumplen la condición de la política".
  • En el objeto AlertStrategy, establece el campo autoClose en su valor mínimo de 30 minutos. Cuando uses la API de Cloud Monitoring, establece este campo en 30m.

Para obtener más información, consulta Datos de métricas parciales.

Flujo de incidentes

Supongamos que las mediciones del uso de la CPU son inferiores al 70% cuando se crea la política de alertas. En la siguiente secuencia, se ilustra cómo se abren y cierran los incidentes:

  1. Debido a que las mediciones de uso de la CPU son inferiores al 70%, el controlador de políticas genera las series temporales "BUENAS" y no se abren incidentes.

  2. A continuación, supongamos que el uso de CPU aumenta al 93%. El controlador de políticas deja de generar los datos de las series temporales "BUENOS" y comienza a generar datos para las series temporales "CRÍTICOS".

    El administrador de incidentes ve una nueva serie temporal "CRÍTICA" que cumple con la condición y, luego, abre un incidente. La notificación incluye la etiqueta de gravedad con un valor de CRITICAL.

  3. Supongamos que el uso de CPU disminuye al 75%. El controlador de políticas deja de generar la serie temporal "CRITICAL" y comienza a generar la serie temporal "INFO".

    El administrador de incidentes ve una nueva serie temporal "INFO" que cumple con la condición y, luego, abre un incidente. La notificación incluye la etiqueta de gravedad con un valor de INFO.

    El administrador de incidentes ve que no llegan datos para la serie temporal "CRÍTICA" y que hay un incidente abierto para esa serie temporal. Debido a que la política está configurada para cerrar incidentes cuando dejan de llegar datos, el administrador de incidentes cierra el incidente asociado con la serie temporal "CRÍTICA". Por lo tanto, solo permanece abierto el incidente cuya etiqueta de gravedad tiene un valor de INFO.

  4. Por último, supongamos que el uso de CPU disminuye al 45%. Este valor es inferior a todos los umbrales, por lo que el controlador de políticas deja de generar la serie temporal "INFO" y comienza a generar la serie temporal "BUENA".

    El administrador de incidentes ve que no llegan datos para la serie temporal “INFO” y que hay un incidente abierto para esa serie temporal. Como la política usa la configuración recomendada, se cierra el incidente.

Si no usas el valor recomendado para el campo evaluationMissingData, cuando dejen de llegar datos, los incidentes abiertos no se cerrarán de inmediato. Como resultado, es posible que veas varios incidentes abiertos para la misma serie temporal de entrada. Para obtener más información, consulta Datos de métricas parciales.

¿Qué sigue?