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

En este documento, se describe cómo los períodos de alineación y los períodos de nueva prueba determinan cuándo se cumple una condición, cómo las políticas de alertas combinan varias condiciones y cómo reemplazan los datos faltantes. También describe la cantidad máxima de incidentes abiertos para una política, la cantidad de notificaciones por incidente y qué causa las 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.

Períodos de alineación y ventanas de nueva prueba

Cloud Monitoring evalúa el período de alineación y la ventana de nueva prueba cuando determina si se cumplió la condición de una política de alertas.

Período de alineación

Antes de que una política de alertas supervise los datos de series temporales, se deben regularizar para que la política de alertas tenga datos espaciados con regularidad para evaluar. El proceso de regularización se denomina alineación.

La alineación implica dos pasos:

• Dividir las series temporales en intervalos de tiempo regulares, también llamado agrupamiento de datos. El intervalo es el período de alineación.

• Calcular un solo valor para los puntos en el período de alineación. Tú eliges cómo se calcula ese punto único, puedes sumar todos los valores, calcular su promedio, o usar la máxima. La función que combina los datos se llama alineador. El resultado de la combinación se denomina valor alineado.

  Para obtener más información sobre la alineación, consulta Alineación: regularización dentro de la serie.

Por ejemplo, cuando el período de alineación es de cinco minutos, a la 1:00 p.m., el período de alineación 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.

La supervisión configura un período de alineación de la siguiente manera:

Para ilustrar el efecto del período de alineación en una condición en una política de alertas, considera una condición de límite de métrica que supervise una métrica con un período de muestreo de un minuto. Supongamos que el período de alineación se establece en cinco minutos y que el alineador está configurado como sum. Además, supongamos que la condición se cumple cuando el valor alineado de la serie temporal es mayor que dos durante al menos tres minutos y que la condición se evalúa cada minuto. En este ejemplo, el período de alineación es de dos minutos, y la ventana de nueva prueba, que se describe en la siguiente sección, es de tres minutos. En la siguiente figura, se ilustran varias evaluaciones secuenciales de la condición:

Cada fila de la figura ilustra una sola evaluación de la condición. Se muestran los datos de series temporales. Los puntos en el período de alineación se muestran con puntos azules; los puntos anteriores son negros. 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 a uno es menor que el umbral. En la siguiente evaluación, la suma de las muestras en el período de alineación es dos. En la tercera evaluación, la suma es tres y, como este valor es mayor que el umbral, se inicia un temporizador para la ventana de nueva prueba.

Períodos para volver a probar

La condición de una política de alertas tiene un período de nueva prueba, que evita que se cumpla la condición debido a una sola medición o previsión. Por ejemplo, supongamos que el período de nueva prueba de una condición se establece en 15 minutos. A continuación, se describe el comportamiento de la condición según su tipo:

• Las condiciones de umbral de métricas se cumplen cuando, para una sola serie temporal, cada medición alineada en un intervalo de 15 minutos incumple el umbral.
• Las condiciones de ausencia de métricas se cumplen cuando no llegan datos para una serie temporal en un intervalo de 15 minutos.
• Las condiciones de pronóstico se cumplen cuando cada pronóstico que se produce durante un período de 15 minutos predice que la serie temporal incumplirá el umbral dentro del período de pronóstico.

En el caso de las políticas con una condición, se abre un incidente y se envían notificaciones cuando se cumple la condición. Estos incidentes permanecen abiertos mientras la condición siga cumpliéndose.

En la figura anterior, se ilustran tres evaluaciones de una condición de umbral de métrica. En el momento start + 2 minutes, el valor alineado es mayor que el umbral. Sin embargo, la condición no se cumple porque el período de nueva prueba se establece en tres minutos. En la siguiente figura, se ilustran los resultados para las siguientes evaluaciones de la condició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. Ese evento ocurre a la hora start + 5 minutes.

Una condición restablece su ventana de nueva prueba cada vez que una medición o previsión no satisface la condición. Este comportamiento se ilustra en el siguiente ejemplo:

Ejemplo: Esta política de alertas contiene una condición de umbral de métrica que especifica un período de nueva prueba de cinco minutos.

Si la latencia de respuesta HTTP es superior a dos segundos,
y si la latencia supera el 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 nueva prueba afecta la evaluación de la condición:

1. La latencia de HTTP es inferior a dos segundos.
2. Durante los próximos tres minutos consecutivos, la latencia de HTTP es mayor que dos segundos.
3. En la siguiente medición, la latencia es inferior a dos segundos, por lo que la condición restablece la ventana de nueva prueba.

4. Durante los próximos cinco minutos consecutivos, la latencia de HTTP es mayor que dos segundos, por lo que se cumple la condición.

   Como la política de alertas tiene una condición, Monitoring envía notificaciones cuando se cumple la condición.

Establece el período de nueva prueba para que sea lo suficientemente extenso como para minimizar los falsos positivos, pero lo suficientemente corto como para garantizar que los incidentes se abran de manera oportuna.

Prácticas recomendadas para configurar el período de alineación y la ventana de nueva prueba

El período de alineación determina cuántas muestras se combinan con el alineador:

• El valor mínimo del período de alineación para un tipo de métrica es el período de muestreo de ese tipo de métrica. Por ejemplo, si el tipo de métrica se muestrea cada 300 segundos, el período de alineación debe ser de al menos 300 segundos. Sin embargo, si deseas combinar 5 muestras, establece el período de alineación en 5 × 300 s o 1,500 segundos.

• El valor máximo del período de alineación es de 24 horas menos la demora de transferencia del tipo de métrica. Por ejemplo, si la demora de transferencia de una métrica es de 6 horas, el valor máximo del período de alineación es de 18 horas.

Usa el período de nueva prueba para especificar la capacidad de respuesta de la alerta. Por ejemplo, si configuras el período de nueva prueba en 20 minutos para una condición de ausencia de la métrica, no debe haber datos durante 20 minutos antes de que se cumpla la condición. Para obtener una política de alertas más responsiva, establece el período de nueva prueba en un valor más bajo. Para las condiciones de umbral de métrica, si deseas tener la política de alertas más responsiva, configura la ventana de nueva prueba en cero. Un solo valor alineado hace que se cumplan estos tipos de condiciones.

Las condiciones de la política de alertas se evalúan con una frecuencia fija. Las elecciones que tomas para el período de alineación y el período de nueva prueba no determinan la frecuencia con la que se evalúa la condición.

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:

En esta tabla, se enumeran los parámetros de configuración de la consola de Google Cloud, el valor equivalente en la API de Cloud Monitoring y una descripción de cada configuración:

Consola de Google Cloud Valor de activadores de política	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 hace 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 cumplir 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, 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 supera los 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. Como el uso de CPU es mayor que el 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, supongamos 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 la 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, y 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 dejan de llegar datos de las series temporales o cuando se retrasan, la supervisión los clasifica como faltantes. Los datos faltantes pueden impedir que los incidentes se cierren. Los retrasos en los datos que llegan de proveedores de servicios en la nube de terceros pueden ser de hasta 30 minutos. Los retrasos más comunes son de 5 a 15 minutos. Un retraso prolongado, mayor que el período de nueva prueba, puede hacer que las condiciones entren en un estado "desconocido". Cuando finalmente lleguen 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.

Para minimizar los problemas debido a datos faltantes, puedes hacer lo siguiente:

• 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 nueva prueba más largas en tus condiciones. El uso de una ventana de nueva prueba más larga tiene la desventaja de hacer que tus políticas de alertas tengan menos capacidad de respuesta.

• 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 Monitoring.
  • Métricas basadas en registros, si la recopilación de entradas de registro no se demora.

Para obtener más información, consulta Descripción general del agente de supervisión, Descripción general de las métricas definidas por el usuario y métricas basadas en registros.

Cuándo Monitoring envía notificaciones y crea incidentes

Cloud Monitoring envía una notificación cuando una serie temporal hace que se cumpla una condición. La notificación se envía a todos los canales de notificaciones. No puedes restringir una notificación a un canal específico o a un subconjunto de los canales de tu política.

Si configuras notificaciones repetidas, la misma notificación se vuelve a enviar a canales de notificaciones específicos para tu política de alertas.

Es posible que recibas varias notificaciones únicas relacionadas con una política de alertas cuando se cumpla alguna de las siguientes condiciones:

• Una condición supervisa varias series temporales.

• Una política contiene varias condiciones. En este caso, las notificaciones que recibes dependen del valor del activador de varias condiciones de la política de alertas:

  • 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 de alertas envía una notificación y crea un incidente.

    No puedes configurar Cloud Monitoring para crear un solo incidente y enviar una sola notificación cuando la política de alertas contiene varias condiciones.

  • Se cumple cualquier condición: La política de alertas envía una notificación cuando una serie temporal hace que se cumpla la condición.

  Para obtener más información, consulta Políticas con varias condiciones.

Las políticas de alertas creadas con la API de Cloud Monitoring también te notifican cuando se cumple la condición y cuando esta se deja de cumplir. Las políticas de alertas creadas con la consola de Google Cloud no envían una notificación cuando la condición deja de cumplirse, a menos que hayas habilitado ese comportamiento.

Cuando Monitoring no envía notificaciones ni crea incidentes

En las siguientes situaciones, Monitoring no crea incidentes ni envía notificaciones cuando se cumplen las condiciones de una política de alertas:

• La política de alertas está inhabilitada.
• La política de alertas está pospuesta.
• La supervisión alcanzó el límite de la cantidad máxima de incidentes abiertos.

Políticas de alertas inhabilitadas

Monitoring no crea incidentes ni envía notificaciones para políticas de alertas inhabilitadas. Sin embargo, Monitoring sigue evaluando las condiciones de una política de alertas inhabilitada.

Cuando habilitas una política inhabilitada, Monitoring evalúa los valores de todas las condiciones en el período de nueva prueba más reciente. El período de nueva prueba más reciente puede incluir datos que se tomaron antes, durante y después de que se habilitó la política. Las condiciones de una política inhabilitada se pueden cumplir inmediatamente después de reanudarla, incluso con períodos de nueva prueba grandes.

Por ejemplo, supongamos que tienes una política de alertas que supervisa un proceso específico y que inhabilitas esta política. La semana siguiente, el proceso falla y, como la política de alertas está inhabilitada, no recibes una notificación. Si reinicias el proceso y habilitas la política de alertas de inmediato, Monitoring reconoce que el proceso no funcionó durante los últimos cinco minutos y abre un incidente.

Los incidentes relacionados con una política de alertas inhabilitada permanecen abiertos hasta que venza la duración del cierre automático de la política.

Políticas de alertas pospuestas

Monitoring no envía notificaciones ni crea incidentes para una política de alertas que se aplazó. Te recomendamos posponer las políticas de alertas cuando quieras evitar que una política de alertas envíe notificaciones solo durante intervalos cortos. Por ejemplo, antes de realizar mantenimiento en una máquina virtual (VM), puedes crear un aplazamiento y agregar a los criterios de aplazamiento las políticas de alertas que supervisan la instancia.

Cuando aplazas una política de alertas, Monitoring cierra todos los incidentes abiertos relacionados con la política. Monitoring puede abrir incidentes nuevos después de que venza el aplazamiento. Para obtener información, consulta Cómo posponer notificaciones y alertas.

Límites de las notificaciones y los incidentes abiertos

Una política de alertas puede aplicarse a muchos recursos, y un problema que afecte a todos los recursos puede hacer que la política de alertas abra incidentes 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 1,000.

Por ejemplo, considera una política que se aplica a 2, 000 instancias de Compute Engine y cada instancia hace que se cumplan las condiciones de alerta. La supervisión limita la cantidad de incidentes abiertos a 1,000. Se ignoran las condiciones restantes que se cumplan hasta que se resuelvan algunos de los incidentes abiertos de esa política.

Como resultado de este límite, un solo canal de notificaciones puede recibir hasta 1,000 notificaciones a la vez. Si tu política de alertas tiene varios canales de notificaciones, este límite se aplica a cada canal de notificaciones de forma independiente.

Latencia

La latencia se refiere al retraso entre el momento en que Monitoring toma una muestra de una métrica y el momento en que el dato de la métrica se vuelve visible como datos de serie temporal. La latencia afecta el momento en que se envían las notificaciones. Por ejemplo, si una métrica supervisada tiene una latencia de hasta 180 segundos, la supervisión no creará un incidente durante un máximo de 180 segundos después de que la condición de la política de alertas se evalúe como verdadera. Para obtener más información, consulta Latencia de los datos de métricas.

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

• Demora en la recopilación de métricas: El tiempo que 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 la política de alertas tardan entre 60 y 90 segundos adicionales. Para las métricas de AWS CloudWatch, la demora de visibilidad puede ser de varios minutos. Para las verificaciones de tiempo de actividad, puede ser un promedio de dos minutos (desde el final de la ventana de nueva prueba).

• Período para volver a probar: Es la ventana configurada para la condición. Las condiciones solo se cumplen cuando una condición es verdadera durante el período de reprueba. Por ejemplo, un parámetro de configuración de ventana de nueva prueba de cinco minutos causa retrasos en la notificación de al menos cinco minutos desde el momento en que se produce el evento.

• 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?

• Para obtener información sobre cómo crear una política de alertas, consulta los siguientes documentos:

  • Crea políticas de alertas de límite de métrica
  • Crea políticas de alertas de ausencia de métricas
  • Crea políticas de alertas de valores de métricas previstos
  • Crea políticas de alertas con la API de Monitoring

• Para ver una selección de políticas de alertas, consulta Políticas de muestra.