Comportamiento de las políticas de alertas basadas en métricas

En este documento se describe cómo la configuración del período y la duración de la alineación determinan cuándo se activa una condición, cómo combinan las políticas de alertas y cómo las políticas de alertas reemplazan los datos faltantes. También se describe la cantidad máxima de incidentes abiertos para una política, la cantidad de notificaciones por incidente y lo que causa demoras en las notificaciones.

Este contenido no se aplica a las políticas de alertas basadas en registros. Para obtener información sobre las políticas de alertas basadas en registros, consulta Supervisa tus registros.

Configuración de los períodos de alineación y duración

El período de alineación y el período de duración son dos campos que estableces cuando especificas una condición para una política de alertas. En esta sección, se proporciona una breve ilustración del significado de estos campos.

Período de alineación

El período de alineación es un intervalo retrospectivo de un punto en el tiempo específico. Por ejemplo, cuando el período de alineación es de cinco minutos, a la 1:00 p.m., contiene las muestras recibidas entre las 12:55 p.m. y la 1:00 p.m. A la 1:01 p.m., el período de alineación se desliza un minuto y contiene las muestras recibidas entre las 12:56 p.m. y la 1:01 p.m.

consola de Google Cloud

Puedes configurar los campos de alineación con los menús Ventana progresiva y Función de ventana progresiva que forman parte del diálogo Condición nueva.

API

Para configurar los campos de alineación, debes configurar los campos aggregations.alignmentPeriod y aggregations.perSeriesAligner en las estructuras MetricThreshold y MetricAbsence.

Para ilustrar el efecto del período de alineación en una condición en una política de alertas, considera una condición que supervisa una métrica con un período de muestra de un minuto. Supongamos que el período de alineación se establece en cinco minutos y que el alineador está configurado como sum. Cuando el valor alineado de la serie temporal es mayor que dos por al menos tres minutos, la condición se describe como met o activa. Para este ejemplo, supongamos que la condición se evalúa cada minuto.

En la siguiente figura, se ilustran varias evaluaciones secuenciales de la condición:

Figura que ilustra el efecto del período de alineación.

Cada fila de la figura ilustra una sola evaluación de la condición. Se muestran los datos de series temporales. Los puntos del período de alineación se muestran con puntos azules y todos los más antiguos son de color negro. Cada fila muestra el valor alineado y si este valor es mayor que el umbral de dos. Para la fila etiquetada start, el valor alineado se calcula en uno, que es inferior al umbral. En la siguiente evaluación, la suma de las muestras en el período de alineación es de dos. En la tercera evaluación, la suma es tres y es mayor que el umbral. El evaluador de condiciones también inicia el temporizador del período de duración.

Período de duración

Usa la duración, o el período de duración, para evitar que se cumpla una condición debido a una sola medición.

consola de Google Cloud

Para configurar la duración, usa el campo Retest window en el paso Configure activador.

API

Para configurar el período de duración, establece el campo duration en las estructuras MetricThreshold y MetricAbsence.

En la figura anterior, se ilustran tres evaluaciones de la condición. En el momento start + 2 minutes, el valor alineado es mayor que el umbral. Sin embargo, no se cumple la condición porque el período de duración se establece en tres minutos. En la siguiente imagen, se ilustran los resultados de las siguientes evaluaciones de la condición:

Figura que ilustra el efecto de la ventana de duración.

Aunque el valor alineado es mayor que el umbral en el momento start + 2 minutes, la condición no se cumple hasta que el valor alineado es mayor que el umbral durante tres minutos. Esto ocurre a las start + 5 minutes.

Como aclaración, el ejemplo anterior omitió la posibilidad de combinar los datos alineados de varias series temporales en una sola medición. Las mediciones se comparan con el umbral para determinar si se cumple la condición.

Una condición restablece su ventana de duración cada vez que una medición no satisface la condición. Este comportamiento se muestra en el siguiente ejemplo:

Ejemplo: Esta política especifica un período de cinco minutos.

Si la latencia de respuesta HTTP es superior a dos segundos,
y si la latencia es superior al umbral durante cinco minutos,
abre un incidente y envía un correo electrónico a tu equipo de asistencia al cliente.

En la siguiente secuencia, se ilustra la forma en la que el período de duración afecta la evaluación de la condición:

  1. La latencia de HTTP es menor que dos segundos.
  2. Durante los próximos tres minutos consecutivos, la latencia de HTTP es superior a dos segundos.
  3. En la siguiente medición, la latencia es inferior a dos segundos, por lo que la condición restablece el período de duración.
  4. Durante los próximos cinco minutos consecutivos, la latencia de HTTP es superior a dos segundos, por lo que se cumple la condición y se activa la política.

Establece el período de duración para que sea lo suficientemente extenso como para minimizar los falsos positivos, pero lo suficientemente cortos para garantizar que los incidentes se abran de manera oportuna.

Selecciona el período de alineación y la ventana de duración

Las condiciones de la política de alertas se evalúan con una frecuencia fija. Las decisiones que tomes para el período de alineación y el período de duración no determinarán la frecuencia con la que se evalúa la condición.

En la figura, se ilustra que el período de alineación determina cuántas muestras de datos se combinan con el alineador. Para combinar muchas muestras, elige un período largo. Para restringir el intervalo a una sola muestra, elige un período corto. Por el contrario, el período de duración especifica cuánto tiempo los valores alineados deben ser más altos que el umbral antes de que se cumpla la condición. Para permitir que se cumpla la condición cuando un único valor alineado sea mayor que el umbral, establece la ventana de duración en cero.

Políticas con varias condiciones

Una política de alertas puede contener hasta 6 condiciones.

Si usas la API de Cloud Monitoring o si tu política de alertas tiene varias condiciones, debes especificar cuándo se abre un incidente. Para configurar cómo se combinan varias condiciones, realiza una de las siguientes acciones:

consola de Google Cloud

Puede configurar las opciones del combinador en el paso Activador de varias condiciones.

API

Configura las opciones del combinador con el campo combiner de la estructura AlertPolicy.

En esta tabla, se muestra la configuración en Google Cloud Console, el valor equivalente en la API de Cloud Monitoring y una descripción de cada configuración:

Google Cloud Console
La política activa el valor
API de Cloud Monitoring
Valor del combinador
Significado
: Se cumple cualquier condición OR Se abre un incidente si algún recurso hace que se cumpla alguna de las condiciones.
Se cumplen todas las condiciones
incluso para diferentes recursos
de cada condición

(predeterminado)
AND Se abre un incidente si se cumple cada condición, incluso si un recurso diferente causa que se cumplan esas condiciones.
Se cumplen todas las condiciones AND_WITH_MATCHING_RESOURCE Se abre un incidente si el mismo recurso hace que se cumpla cada condición. Esta configuración es la opción de combinación más estricta.

En este contexto, el término cumple significa que la configuración de la condición se evalúa como true. Por ejemplo, si la configuración es Any time series is greater than 10 for 5 minutes, entonces, cuando esta declaración se evalúa como true, se cumple la condición.

Ejemplo

Supongamos que tienes un proyecto de Google Cloud que contiene dos instancias de VM, vm1 y vm2. Además, supongamos que creas una política de alertas con 2 condiciones:

  • La condición llamada CPU usage is too high supervisa el uso de CPU de las instancias. Esta condición se cumple cuando el uso de CPU de cualquier instancia es superior a 100 ms/s durante 1 minuto.
  • La condición denominada Excessive utilization supervisa el uso de CPU de las instancias. Esta condición se cumple cuando el uso de CPU de cualquier instancia es superior al 60% durante 1 minuto.

En un principio, supongamos que ambas condiciones se evalúan como false.

A continuación, supongamos que el uso de CPU de vm1 supera los 100 ms/s durante 1 minuto. Debido a que el uso de CPU es superior al umbral durante un minuto, se cumple la condición CPU usage is too high. Si las condiciones se combinan con Se cumple cualquier condición, se crea un incidente, ya que se cumple una condición. Si las condiciones se combinan con Se cumplen todas las condiciones o Se cumplen todas las condiciones incluso con recursos diferentes para cada condición, no se crea un incidente. Estas opciones de combinador requieren que se cumplan ambas condiciones.

A continuación, supón que el uso de CPU de vm1 sigue siendo superior a 100 ms/s y que el uso de CPU de vm2 supera el 60% durante 1 minuto. Como resultado, se cumplen ambas condiciones. A continuación, se describe lo que ocurre según cómo se combinan las condiciones:

  • Se cumple cualquier condición: se crea un incidente cuando el recurso hace que se cumple una condición. En este ejemplo, la vm2 hace que se cumpla la condición Excessive utilization.

    Si vm2 hace que se cumpla la condición CPU usage is too high, también se crea un incidente. Se crea un incidente porque vm1 y vm2 hacen que se cumpla la condición CPU usage is too high son eventos distintos.

  • Todas las condiciones se cumplen incluso en recursos diferentes de cada condición: Se crea un incidente porque se cumplen ambas condiciones.

  • Todas las condiciones se cumplen: Un incidente no se crea porque este combinador requiere que el mismo recurso haga que se cumplan todas las condiciones. En este ejemplo, no se crea ningún incidente porque la vm1 hace que se cumpla CPU usage is too high, mientras que la vm2 hace que se cumpla Excessive utilization.

Datos parciales de la métrica

Cuando los datos de las series temporales dejan de llegar o cuando se retrasan, Monitoring clasifica los datos como faltantes. Si faltan datos, es posible que las políticas no generen alertas y no se cierren los incidentes. Los retrasos en los datos que llegan de proveedores de servicios en la nube de terceros pueden ser de hasta 30 minutos, y los retrasos más comunes son de 5 a 15 minutos. Un retraso prolongado, mayor que el período de duración, puede hacer que las condiciones entren en un estado "desconocido". Cuando finalmente llegan los datos, es posible que Monitoring haya perdido parte del historial reciente de las condiciones. Es posible que la inspección posterior de los datos de series temporales no muestre este problema debido a que no hay evidencia de retrasos una vez que llegan los datos.

consola de Google Cloud

Puedes configurar cómo Monitoring evalúa una condición de umbral de métrica cuando los datos dejan de llegar. Por ejemplo, cuando está abierto un incidente y no llega una medición esperada, ¿quieres que Monitoring deje el incidente abierto o lo cierre de inmediato? Del mismo modo, cuando los datos dejan de llegar y no hay ningún incidente abierto, ¿quieres que se abra un incidente? Por último, ¿cuánto tiempo debe permanecer abierto un incidente después de que dejan de llegar los datos?

Existen dos campos configurables en los que se especifica la forma en que Monitoring evalúa las condiciones del umbral de las métricas cuando dejan de llegar los datos:

  • Para configurar cómo Monitoring determina el valor de reemplazo para datos faltantes, usa el campo Datos faltantes de evaluación que estableciste en el paso Activador de condición. Este campo se inhabilita cuando laventana de prueba está configurada en Sin reprueba.

  • Para configurar cuánto tiempo espera Monitoring antes de cerrar un incidente abierto después de que dejan de llegar los datos, usa el campo Duración del cierre automático de incidentes. Puedes establecer la duración del cierre automático en el paso Notificación. La duración predeterminada de cierre automático es de siete días.

A continuación, se describen las diferentes opciones para el campo de datos faltantes:

Google Cloud Console
Campo de datos faltantes de la evaluación
Resumen Detalles
Datos faltantes vacíos Los incidentes abiertos permanecen abiertos.
No se abren incidentes nuevos.

Para las condiciones que se cumplen, la condición se sigue cumpliendo cuando los datos dejan de llegar. Si un incidente está abierto para esta condición, el incidente permanece abierto. Cuando hay un incidente abierto y no llegan datos, el temporizador de cierre automático comienza después de un retraso de al menos 15 minutos. Si el temporizador expira, el incidente se cierra.

En el caso de que las condiciones no se cumplan, no se cumplirá cuando los datos dejen de llegar.

Datos faltantes que se tratan como valores que infringen la condición de la política Los incidentes abiertos permanecen abiertos.
Se pueden abrir incidentes nuevos.

Para las condiciones que se cumplen, la condición se sigue cumpliendo cuando los datos dejan de llegar. Si un incidente está abierto para esta condición, el incidente permanece abierto. Cuando un incidente está abierto y no llegan datos que duran el cierre automático más 24 horas, se cierra.

En el caso de las condiciones que no se cumplen, esta configuración hace que la condición de umbral de métrica se comporte como metric-absence condition. Si los datos no llegan en el tiempo especificado en el período que se vuelve a probar, la condición se evalúa como cumplida. Para una política de alertas con una condición, la condición que se cumple genera un incidente.

Datos faltantes que se tratan como valores que no infringen la condición de la política Se cerraron los incidentes abiertos.
No se abren incidentes nuevos.

En las condiciones que se cumplen, la condición deja de cumplirse cuando los datos dejan de llegar. Si hay un incidente abierto para esta condición, entonces el incidente se cierra.

En el caso de que las condiciones no se cumplan, no se cumplirá cuando los datos dejen de llegar.

API

Puedes configurar cómo Monitoring evalúa una condición de umbral de métrica cuando los datos dejan de llegar. Por ejemplo, cuando está abierto un incidente y no llega una medición esperada, ¿quieres que Monitoring deje el incidente abierto o lo cierre de inmediato? Del mismo modo, cuando los datos dejan de llegar y no hay ningún incidente abierto, ¿quieres que se abra un incidente? Por último, ¿cuánto tiempo debe permanecer abierto un incidente después de que dejan de llegar los datos?

Existen dos campos configurables en los que se especifica la forma en que Monitoring evalúa las condiciones del umbral de las métricas cuando dejan de llegar los datos:

  • Para configurar la forma en que Monitoring determina el valor de reemplazo para datos faltantes, usa el campo evaluationMissingData de la estructura MetricThreshold. Este campo se ignora cuando el campo duration es cero.

  • Para configurar cuánto tiempo espera Monitoring antes de cerrar un incidente abierto después de que dejan de llegar los datos, usa el campo autoClose en la estructura AlertStrategy.

A continuación, se describen las diferentes opciones para el campo de datos faltantes:

API
Campo evaluationMissingData
Resumen Detalles
EVALUATION_MISSING_DATA_UNSPECIFIED Los incidentes abiertos permanecen abiertos.
No se abren incidentes nuevos.

Para las condiciones que se cumplen, la condición se sigue cumpliendo cuando los datos dejan de llegar. Si un incidente está abierto para esta condición, el incidente permanece abierto. Cuando hay un incidente abierto y no llegan datos, el temporizador de cierre automático comienza después de un retraso de al menos 15 minutos. Si el temporizador expira, el incidente se cierra.

En el caso de que las condiciones no se cumplan, no se cumplirá cuando los datos dejen de llegar.

EVALUATION_MISSING_DATA_ACTIVE Los incidentes abiertos permanecen abiertos.
Se pueden abrir incidentes nuevos.

Para las condiciones que se cumplen, la condición se sigue cumpliendo cuando los datos dejan de llegar. Si un incidente está abierto para esta condición, el incidente permanece abierto. Cuando un incidente está abierto y no llegan datos para la duración del cierre automático más 24 horas, se cierra.

En el caso de las condiciones que no se cumplen, esta configuración hace que la condición de umbral de métrica se comporte como metric-absence condition. Si los datos no llegan en el tiempo especificado en el campo “duration”, la condición se evalúa como cumplida. Para una política de alertas con una condición, la condición que se cumple genera un incidente.

EVALUATION_MISSING_DATA_INACTIVE Se cerraron los incidentes abiertos.
No se abren incidentes nuevos.

En las condiciones que se cumplen, la condición deja de cumplirse cuando los datos dejan de llegar. Si hay un incidente abierto para esta condición, entonces el incidente se cierra.

En el caso de que las condiciones no se cumplan, no se cumplirá cuando los datos dejen de llegar.

Para minimizar los problemas por datos faltantes, realiza una de las siguientes acciones:

  • Comunícate con tu proveedor de servicios en la nube de terceros para identificar formas de reducir la latencia de recopilación de métricas.
  • Usa ventanas de mayor duración en tus condiciones. Usar un período de mayor duración tiene la desventaja de que las políticas de alertas sean menos responsivas.
  • Elige métricas que tengan un retraso de recopilación menor:

    • Métricas del agente de supervisión, en especial cuando el agente se ejecuta en instancias de VM en servicios en la nube de terceros.
    • Métricas personalizadas, cuando escribes sus datos directamente en Cloud Monitoring.
    • Métricas basadas en registros, si la recopilación de registros no se demora.

Para obtener más información, consulta Descripción general del agente de Monitoring, Usa métricas personalizadas y Métricas basadas en registros.

Incidentes y notificaciones por política

Cuando una política de alertas está inhabilitada, no se crean incidentes para la política y no se envían notificaciones.

Cuando se habilita una política de alertas, se pueden crear incidentes y se pueden enviar notificaciones. En esta sección, se describen los límites sobre la cantidad de incidentes abiertos por política y cuándo es posible que veas varias notificaciones del mismo incidente.

Cantidad de incidentes abiertos por política

Una política de alertas puede aplicarse a muchos recursos, y un problema que afecte a todos los recursos puede activar la política y los incidentes abiertos para cada recurso. Se abre un incidente por cada serie temporal que provoque que se cumpla una condición.

Para evitar sobrecargar el sistema, la cantidad de incidentes que una sola política puede abrir en simultáneo se limita a 5,000.

Por ejemplo, considera una política que se aplica a 2,000 o 20,000 instancias de Compute Engine, y cada instancia hace que se cumplan las condiciones de alerta. Monitoring limita la cantidad de incidentes abiertos a 5,000. Se ignorarán las condiciones restantes que se cumplan hasta que se cierren algunos de los incidentes abiertos de esa política.

Cantidad de notificaciones por incidente

De forma predeterminada, se envía una notificación cuando una serie temporal hace que se cumple una condición. Es posible que recibas varias notificaciones cuando se cumpla cualquiera de las siguientes condiciones:

  • Una condición supervisa varias series temporales.

  • Una política contiene varias condiciones:

    • Se cumplen todas las condiciones: Cuando se cumplen todas las condiciones, para cada serie temporal que genere que se cumpla una condición, la política envía una notificación y crea un incidente. Por ejemplo, supón que tienes una política con dos condiciones y que cada condición supervisa una serie temporal. Cuando se active esta política, recibirás dos notificaciones y verás dos incidentes.

    • Se cumple cualquier condición: La política envía una notificación cada vez que se cumple una combinación nueva de condiciones. Por ejemplo, supongamos que se cumple ConditionA, que se abre un incidente y que se envía una notificación. Si el incidente aún está abierto cuando una medición posterior cumple ConditionA y ConditionB, se envía otra notificación.

Las políticas de alertas creadas mediante la API de Cloud Monitoring te notifican cuando se cumple la condición y cuando la condición deja de cumplirse. De forma predeterminada, las políticas de alertas creadas mediante Google Cloud Console te notifican cuando se abre un incidente. No te notifican cuando se cierra un incidente. Puedes habilitar las notificaciones sobre el cierre de un incidente.

Notificaciones de políticas de alertas inhabilitadas

Las políticas de alertas se pueden pausar y reiniciar temporalmente si inhabilitas y habilitas la política. Por ejemplo, antes de realizar el mantenimiento en una máquina virtual (VM), puedes inhabilitar las políticas de alertas que supervisan esa instancia.

Inhabilitar una política de alertas evita que la política active o cierre los incidentes, pero no evita que Cloud Monitoring evalúe las condiciones de la política y registre los resultados. Para cerrar los problemas abiertos después de inhabilitar una política de alertas, silencia los incidentes correspondientes. Para obtener información sobre ese proceso, consulta Cómo silenciar incidentes.

Cuando una política inhabilitada se vuelve a habilitar, Monitoring analiza los valores de todas las condiciones en el período de duración más reciente, que puede incluir datos que se tomaron antes y después del intervalo de pausa, o durante este. Las políticas pueden activarse de inmediato después de reanudarlas, incluso con ventanas de larga duración.

Por ejemplo, supongamos que un proceso supervisado está inactivo durante 20 minutos por mantenimiento. Si reinicias el proceso y vuelves a habilitar la política de alertas de inmediato, Monitoring reconoce que el proceso no estuvo activo durante los últimos cinco minutos y abre un incidente.

Latencia de notificaciones

La latencia de notificaciones es el retraso desde el momento en el que un comience un problema hasta el momento en el que se active una política.

Los siguientes eventos y parámetros de configuración contribuyen a la latencia de notificaciones general:

  • Demora en la recopilación de métricas: El tiempo que Cloud Monitoring necesita para recopilar valores de métricas. En el caso de los valores de Google Cloud, la mayoría de las métricas no son visibles durante 60 segundos después de la recopilación. Sin embargo, la demora depende de la métrica. Los cálculos de políticas de alertas tardan un retraso adicional de 60 a 90 segundos. En el caso de las métricas de AWS CloudWatch, el retraso de visibilidad puede ser de varios minutos. Para las verificaciones de tiempo de actividad, puede ser un promedio de dos minutos (desde el final del período de duración).

  • Período de duración: La ventana se configuró para la condición. Las condiciones solo se cumplen cuando una condición se cumple durante el período de duración. Por ejemplo, una configuración de ventana de duración de cinco minutos provoca retrasos en la notificación de al menos cinco minutos desde que se produce el evento por primera vez.

  • Momento en el que llega la notificación: Los canales de notificación como el correo electrónico y los SMS pueden presentar latencias de red o de otros tipos (que no se relacionan con lo que se entrega), que a veces se aproximan a minutos. En algunos canales, como SMS y Slack, no hay garantía de que se entreguen los mensajes.

¿Qué sigue?