Anota alertas con etiquetas

En este documento, se describe cómo administrar las notificaciones y los incidentes mediante la incorporación de etiquetas definidas por el usuario a una política de alertas. Debido a que las etiquetas definidas por el usuario se incluyen en las notificaciones, si agregas etiquetas que indican la gravedad de un incidente, la notificación contendrá información que puede ayudarte a priorizar tus alertas para su investigación.

Acerca de las etiquetas

Las etiquetas son pares clave-valor que se asocian con series temporales, incidentes y políticas de alertas. Hay etiquetas de métrica, etiquetas de recursos y etiquetas de recursos definidas por el usuario. Las etiquetas de métricas y recursos contienen información específica sobre la métrica que se recopila o el recurso en el que se escribe la métrica. En cambio, las etiquetas definidas por el usuario son aquellas que creas y registras información específica según tus necesidades.

Cuando se escriben datos de series temporales, se adjuntan etiquetas a los datos para registrar su información. 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.

Puedes agregar etiquetas de usuario a las políticas de alertas y a los incidentes:

Una etiqueta en una política de alertas tiene un valor estático. Puedes agregar estas etiquetas a una política de alertas cuando usas la consola de Google Cloud o la API de Cloud Monitoring. Para obtener más información, consulta los siguientes documentos:
- Crea políticas de alertas sobre el umbral de la métrica.
- Crea políticas de alertas con la API.
Las claves de etiquetas deben comenzar con una letra en minúscula. Tanto las claves como los valores de las etiquetas pueden contener solo letras minúsculas, dígitos, guiones bajos y guiones.
El valor de una etiqueta de un incidente puede establecerse de forma dinámica. Es decir, el valor de los datos de series temporales puede determinar el valor de la etiqueta. Para ver un ejemplo, consulta Crea niveles de gravedad dinámicos con el lenguaje de consulta de Monitoring (MQL).

Puedes definir estas etiquetas cuando especificas la condición de una política de alertas con MQL.

Ver etiquetas en las notificaciones

Puedes ver las etiquetas de una política de alertas o de 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:

En las notificaciones por correo electrónico, las etiquetas que agregas a la política se enumeran en la sección Etiquetas de política, mientras que las etiquetas que agregas a un incidente se enumeran en la sección Etiquetas de métricas.
En las notificaciones de PagerDuty, Webhooks y Pub/Sub, las etiquetas que agregas a una política de alertas o incidente se incluyen en los datos JSON. Las etiquetas de política de alertas se enumeran en el campo policy_user_labels de la estructura JSON:
```
"policy_user_labels": {
  "severity": "critical",
}
```
Las etiquetas de incidentes se incluyen en el campo metric de la estructura JSON:
```
"metric": {
  "type" : "compute.googleapis.com/instance/cpu/utilization"
  "displayName": "CPU Utilization",
  "labels": {
    "instance_name": "some_instance_name",
    "severity": "critical"
  },
}
```
Como se mostró anteriormente, el campo metric enumera un tipo de métrica, el nombre visible de la métrica, las etiquetas de la métrica y cualquier etiqueta definida por el usuario que se haya agregado al incidente.

Ejemplo: Crea niveles de gravedad dinámicos con etiquetas y MQL

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, deseas 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 figura, 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 uso de CPU y genera una serie temporal que indica cuándo se activa la condición. En el ejemplo anterior, la condición se activa 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 activó la condición	Descripción
“BUENA”	No.	Esta serie temporal tiene las mismas etiquetas que la serie temporal de entrada. No tiene una etiqueta de gravedad.
“CRÍTICO”	Sí	El uso de CPU es de al menos el 90%. La serie temporal de salida tiene las mismas etiquetas que la serie temporal “BUENO” más una etiqueta de gravedad con el valor “CRÍTICO”.
“ADVERTENCIA”	Sí	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 “BUENO” más una etiqueta de gravedad con el valor “WARNING”.
"INFO"	Sí	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 “BUENO” más una etiqueta de gravedad con el valor “INFO”.

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

prácticas recomendadas

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

En el objeto MetricThreshold, anula los valores predeterminados de los siguientes campos:
- Campo duration: establecido en un valor distinto de cero.
- Campo evaluationMissingData: Se establece para que los incidentes se cierren cuando dejan 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, configura el campo como “Datos faltantes tratados como valores que no infringen 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 parciales de la métrica.

Flujo de incidentes

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

Debido a que las mediciones de uso de CPU son inferiores al 70%, el controlador de políticas genera la serie temporal “BUENO” y no se abren incidentes.
A continuación, supongamos que el uso de CPU aumenta al 93%. El controlador de políticas deja de generar los datos de series temporales “BUENO” y comienza a generar datos para la serie temporal “Crítica”.

El administrador de incidentes ve una serie temporal nueva que activa la condición, la serie temporal "CRÍTICA", y crea un incidente. La notificación incluye la etiqueta de gravedad con un valor de CRITICAL.
Supongamos que el uso de CPU cae 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 serie temporal nueva que activa la condición, la serie temporal “INFO” y 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 el incidente cuya etiqueta de gravedad tiene un valor de INFO permanece abierto.
Por último, supongamos que el uso de CPU cae al 45%. Este valor es menor que 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 “BUENO”.

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

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