Comportamiento de alertas

Las políticas de alertas existen en entornos dinámicos y complejos, por lo que usarlas bien requiere la comprensión de algunas de las variables que pueden afectar su comportamiento. Las métricas y los recursos que las condiciones supervisan, las ventanas de duración para las condiciones y los canales de notificación pueden tener un efecto.

En esta página, se proporciona información adicional para ayudarte a comprender el comportamiento de tus políticas de alertas.

El período de alineación y la 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 particular. Por ejemplo, si 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 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.

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. Por último, supongamos que los datos de series temporales no son aceptables si el valor alineado es mayor a dos durante tres minutos, y 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 puntos anteriores son grises. Cada fila muestra el valor alineado y si este valor supera el umbral de dos. Para la fila etiquetada start, el valor alineado se calcula como 1, que está por debajo del umbral. En la siguiente evaluación, la suma de las muestras en el período de alineación es 2. En la tercera evaluación, la suma es 3 y es mayor que el umbral. El evaluador de condiciones también inicia el temporizador de la ventana de duración.

Período de duración

Para evitar que una política de alertas se active por anomalías transitorias, puedes configurar la condición a fin de que la serie temporal sea inaceptable por un período. Este período se denomina duración o ventana de duración. Si usas Google Cloud Console, el campo Para en el panel Configuración corresponde a la ventana de duración.

En la figura anterior, se ilustran tres evaluaciones de la condición. En el momento, start + 2m, el valor alineado era superior al umbral. Sin embargo, la condición no se cumple porque la ventana de duración se establece en tres minutos. En la siguiente figura, se ilustran los resultados de las siguientes evaluaciones de la condición:

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

Como se ilustra, a pesar de que el valor alineado está por encima del umbral en el momento start + 2m, la condición no se cumple hasta que el valor alineado esté por encima del umbral durante tres minutos. Eso ocurre en el momento start + 5m.

En la figura, se muestra que el período de alineación determina cuántas muestras de datos se combinan con el alineador. Si eliges un período prolongado, se combinarán muchas muestras. Si eliges un período corto, es posible que solo haya un dato en el intervalo. Por el contrario, el período de duración especifica la cantidad de tiempo que los valores alineados deben superar el umbral antes de que se cumpla la condición. Si el período de duración se establece en 0, un solo valor alineado que esté por encima del umbral significa que se cumple la condición.

Para aclarar, el ejemplo anterior omitió la posibilidad de combinar los datos alineados de varias series temporales en una sola medida. Es la medida que se compara con el umbral para determinar si la serie temporal tiene valores no aceptables.

Una condición restablece su ventana de duración cada vez que una medición no satisface la condición. Este comportamiento se ilustra 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 supera ese límite durante cinco minutos,
abre un incidente y envía un correo electrónico a tu equipo de asistencia.

La siguiente secuencia 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 inferior a dos segundos.
  2. Durante los próximos tres minutos consecutivos, la latencia de HTTP es mayor de dos segundos.
  3. En la siguiente medida, la latencia es inferior a dos segundos, por lo que la condición restablece la ventana de duración.
  4. Durante los siguientes cinco minutos consecutivos, la latencia de HTTP es mayor de 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.

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 abren incidentes de las condiciones individuales:

  • Si usas Google Cloud Console, debes usar el campo Activadores de políticas.
  • Si usas la API de Cloud Monitoring, usa el campo combiner.

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

Cloud Console
Valor de activadores de política
API de Cloud Monitoring
Valor del combinador
Significado
Se cumple cualquier condición
(valor predeterminado)
OR Se abre un incidente si algún recurso infringe alguna de las condiciones.
Se cumplen todas las condiciones AND Se abre un incidente si al menos un recurso infringe cada condición, incluso si un recurso diferente infringe cada condición.
Todas las condiciones se cumplen
en los recursos coincidentes
AND_WITH_MATCHING_RESOURCE Se abre un incidente si el mismo recurso infringe 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 above 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 supera el 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. Esto genera que CPU usage is too high se evalúe como true. 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 en los recursos coincidentes, no se crea un incidente. Estas opciones de combinador requieren que ambas condiciones se evalúen como true.

Ahora, supongamos que el uso de CPU de vm1 continúa por encima de los 100 ms/s y que el uso de CPU de vm2 supera el 60% durante 1 minuto. El resultado es que ambas condiciones se evalúan como true. A continuación, se describe lo que ocurre según cómo se combinan las condiciones:

  • Se cumple cualquier condición: Se crea un segundo incidente porque vm2 genera que Excessive utilization se evalúe como true.

    Cuando la configuración de una condición se evalúa como true, la política de alertas mantiene un registro del recurso supervisado y la condición. Un incidente se crea en función de la vinculación del recurso y la condición. Por lo tanto, vm1 provoca que CPU usage is too high sea true y vm2 que provoca que CPU usage is too high sea true son eventos distintos. Se crea un incidente para cada evento.

  • Se cumplen todas las condiciones: Se crea un incidente porque ambas condiciones se evalúan como true.

    En este ejemplo, vm1 hace que CPU usage is too high sea true mientras vm2 hace que Excessive utilization se evalúe como true. En consecuencia, se crea un incidente.

  • Todas las condiciones se cumplen en los recursos coincidentes: un incidente no se crea en este caso porque ni vm1 ni vm2 provocaron que ambas condiciones se evalúen como true. Si se crea un incidente para esta opción de combinador, la misma instancia de VM debe hacer que ambas condiciones se evalúen como true.

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, si tienes una política de alertas que te notifica cuando un proceso está inactivo durante más de 5 minutos, puedes inhabilitar la política de alertas cuando desactives el proceso para realizar una actualización o cualquier otro tipo de mantenimiento.

Inhabilitar una política de alertas evita que la política active (o resuelva) los incidentes, pero no evita que Cloud Monitoring evalúe las condiciones de la política y registre los resultados.

Supongamos que el proceso supervisado está inactivo durante 20 minutos por mantenimiento. Si reinicias el proceso y vuelves a habilitar la política de alertas de inmediato, reconoce que el proceso no se inició en los últimos 5 minutos y abre un incidente.

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.

Incidentes anómalos

Las políticas de alertas, en especial aquellas con condiciones de límite de "falta de métrica" o "menor que", pueden aparecer en el panel Incidentes de la ventana Alertas y parecer que se activaron de forma anticipada o incorrecta. .

Esto ocurre cuando hay intervalos en la transmisión datos, pero no siempre es fácil identificarlas. Algunas veces el intervalo se oculta y otras veces se corrige.

Por ejemplo, los intervalos en la transmisión de datos se interpolan en los gráficos. Es posible que falten varios minutos de transmisión de datos, pero el gráfico conecta los puntos que faltan para la contigüidad visual. Este intervalo en los datos subyacentes puede ser suficiente para activar una política de alertas.

Los datos de las métricas basadas en registros pueden llegar tarde y reabastecerse, hasta 10 minutos antes. Esto corrige de forma eficaz el intervalo y se completa cuando los datos finalmente llegan. Por lo tanto, un intervalo en una métrica basada en registros que ya no se puede ver pudo haber provocado que una política de alertas se activara.

Las condiciones de límite de ausencia de la métrica y las de "inferior a" se evalúan en tiempo real, con un pequeño retraso de consulta. El estado de la condición puede cambiar entre el momento en que se evalúa y el momento en que el incidente correspondiente es visible en Monitoring.

Datos parciales de la métrica

Si faltan mediciones (por ejemplo, si no hay solicitudes HTTP durante un par de minutos), la política usa el valor registrado más reciente para evaluar las condiciones.

Ejemplo

  1. Una condición especifica la latencia de HTTP de dos segundos o más durante cinco minutos consecutivos.
  2. Durante tres minutos consecutivos, la latencia de HTTP es de tres segundos.
  3. Durante dos minutos consecutivos, no hay solicitudes HTTP. En este caso, una condición traslada la última medición (tres segundos) durante estos dos minutos.
  4. La política se activa después de cinco minutos en total, aunque no haya habido datos durante los últimos dos minutos.

Los datos de la métrica que falten o se retrasen pueden provocar que las políticas no generen alertas y que los incidentes no 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 duración, puede hacer que las condiciones entren en un estado "desconocido". Cuando finalmente lleguen los datos, es posible que Cloud 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.

Puedes minimizar estos problemas si realizas alguna de estas acciones:

  • Comunícate con tu proveedor de servicios en la nube de terceros para ver si hay una manera de reducir la latencia de recopilación de métricas.
  • Usa ventanas de mayor duración en tus condiciones. Esto 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 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 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 infrinja 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, si una política se aplica a 2,000 (o 20,000) instancias de Compute Engine y algo hace que cada una infrinja las condiciones de alerta, entonces solo se abren 5,000 incidentes. Las infracciones restantes se ignoran hasta que se resuelvan algunos de los incidentes abiertos de esa política.

Notificaciones por incidente

Se envía una notificación por cada incidente que active la política de alertas. Se envía otra notificación por cada incidente cuando se resuelve. Se abre un incidente por cada serie temporal que infrinja una condición, por lo que cada incidente nuevo genera una notificación.

Si una política contiene solo una condición, se envía una notificación cuando el incidente se abre al principio, incluso si las mediciones posteriores continúan cumpliendo la condición.

Si una política contiene varias condiciones, puede enviar varias notificaciones según la forma en la que configures la política:

  • Si una política se activa solo cuando se cumplen todas las condiciones, la política enviará una notificación solo cuando se abra un incidente.

  • Si una política se activa cuando se cumple cualquier condición, la política enviará una notificación cada vez que se cumpla una combinación nueva de condiciones. Por ejemplo:

    1. Se cumple ConditionA, se abre un incidente y se envía una notificación.
    2. El incidente aún está abierto cuando una medición posterior cumple ConditionA y ConditionB. En este caso, el incidente permanece abierto y se envía otra notificación.

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, esto suele ser insignificante. Para las métricas de AWS CloudWatch, esto puede significar varios minutos. Para las verificaciones de tiempo de actividad, puede ser un promedio de dos minutos (desde el final de la ventana de duración).

  • Período de duración: La ventana se configuró para la condición. Ten en cuenta que las condiciones solo se cumplen si una condición es verdadera en todo el período de duración. Por ejemplo, si especificas una ventana de cinco minutos, la notificación se retrasa 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