Políticas de alertas en profundidad

En esta página, se proporciona una descripción general detallada de los conceptos de las políticas de alertas de Stackdriver Monitoring. Comprender este material te ayudará a usar estas políticas de alertas de manera eficaz.

Para obtener más información sobre cómo crear y administrar políticas de alertas, consulta los siguientes recursos:

Políticas

Una política de alertas define las condiciones en las que un servicio se considera en mal estado. Cuando se cumplen las condiciones, la política se activa y abre un incidente nuevo. La política activada también envía notificaciones si la configuraste para hacerlo.

Una política pertenece a un lugar de trabajo individual, y cada lugar de trabajo puede contener hasta 500 políticas.

Condiciones

Una condición determina el momento en el que se activa una política de alertas. Para describir una condición, debes especificar lo siguiente:

  • Una métrica para medir.
  • Una prueba para determinar el momento en el que esa métrica alcanza un estado que desees conocer.

Según lo que desees supervisar, puedes crear una condición que haga referencia a los siguientes elementos:

Tipos de condiciones

Las condiciones se compilan en métricas y pueden supervisarse, por ejemplo, si una métrica alcanza un valor o comienza a cambiar con rapidez. Las métricas están asociadas con recursos y miden alguna característica de ese recurso, por ejemplo, el uso de CPU promedio en un grupo de VM. Para obtener más información sobre las métricas, consulta Métricas, series temporales y recursos.

Todas las condiciones tienen en cuenta tres aspectos: Algunas métricas se comportan de alguna manera durante cierto período.

Todas las condiciones se implementan como uno de los dos tipos generales:

  • Una condición de ausencia de la métrica, que activa cualquier serie temporal en la métrica no cuenta con datos para un período de duración específico.

    Las condiciones de ausencia de la métrica requieren al menos una medición correcta, una que recupere datos, desde la instalación de la política o dentro del período de duración máximo (las 24 horas).

    Por ejemplo, supongamos que estableces el período de duración en una política de ausencia de la métrica en 30 minutos. La condición no se cumple si el subsistema que escribe datos de la métrica nunca ha escrito un dato. El subsistema debe generar al menos un dato y, luego, tener errores en generar datos adicionales durante 30 minutos.

  • Una condición de límite de la métrica, que se activa si una métrica supera o es inferior a un valor para un período de duración específico.

    Dentro de la clase de condiciones de límite de la métrica, hay patrones que se dividen en subcategorías generales:

    • Frecuencia de la métrica (porcentaje) de cambio: Se activa si una métrica aumenta o disminuye en un porcentaje específico o más en el período de duración.

      En este tipo de condición, se aplica un cálculo de porcentaje de cambio a la serie temporal antes de la comparación con el límite.

      La condición calcula el promedio de los valores de la métrica de los últimos 10 minutos, luego compara el resultado con el promedio de 10 minutos que se midió antes del período de duración. La ventana retrospectiva de 10 minutos que una condición de frecuencia de la métrica de cambio usó es un valor fijo, no puedes cambiarlo. Sin embargo, sí puedes especificar el período de duración cuando creas una condición.

    • Límite de grupo agregado: Se activa si una métrica que se mide en un grupo de recursos pasa un límite.

    • Estado de la verificación de tiempo de actividad: Se activa si creaste una verificación de tiempo de actividad y el recurso tiene errores para responder correctamente a una solicitud enviada desde al menos dos ubicaciones geográficas.

      Los resultados de las verificaciones de tiempo de actividad aparecen solo en la página Descripción general de verificaciones de tiempo de actividad de la consola de Stackdriver Monitoring. Si creas una política de alertas en una verificación de tiempo de actividad, podrás tener verificaciones de tiempo de actividad que abren incidentes de forma indirecta y, de manera opcional, envían notificaciones cuando tienen errores.

    • Estado del proceso: Se activa si el número de procesos (1) que se ejecutan en una instancia o grupo de instancias de VM y (2) que coinciden con alguna string, supera o es inferior a un número específico en un período de duración.

      Este tipo de condición requiere que el agente de supervisión se ejecute en los recursos supervisados.

Hay ejemplos de cada uno de estos tipos disponibles:

Tipo de condición Ejemplo de JSON
Límite de la métrica Ver
Frecuencia de cambio Ver
Grupo agregado Ver
Verificación del tiempo de actividad Ver
Estado del proceso Ver

Combina condiciones

Una política puede contener hasta 6 condiciones. Si usas varias condiciones, hay tres opciones para especificar las combinaciones que violan una política:

  • OR: se cumple cualquier condición.
  • AND: al menos un recurso viola cada condición, incluso si un recurso diferente viola cada condición.
  • AND_WITH_RESOURCES: el mismo recurso viola todas las condiciones. (Esta opción solo está disponible para las condiciones creadas con la API de Monitoring).

Período de duración

Una condición incluye un período de duración, el tiempo que debe tardar una condición en evaluarse como verdadera antes de activarse. Las ventanas de duración de las condiciones evitan que la política de alertas reaccione de forma exagerada. Desearás reducir los falsos positivos, ya que una política de alertas que envía una transmisión constante de notificaciones finalmente se ignorará.

Como regla general, cuanto más alta disponibilidad tenga el servicio o mayor sea la penalización por no detectar problemas, menor será el período de duración que desees especificar.

Debido a las fluctuaciones normales en el rendimiento, no desearás que se active una política si una medición única coincide con una condición. En su lugar, generalmente desearás que varias mediciones consecutivas cumplan una condición antes de considerar que tu aplicación se encuentra en mal estado.

Cada vez que la medición no satisface una condición, esta restablece su período de duración.

Ejemplo

La siguiente condición especifica un período de duración de cinco minutos:
Latencia de HTTP mayor de dos segundos durante cinco minutos consecutivos.

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

  1. Durante tres minutos consecutivos, la latencia de HTTP es mayor de dos segundos.
  2. 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.
  3. Durante los siguientes cinco minutos consecutivos, la latencia de HTTP es mayor de dos segundos, por lo que se activa la política.

Las ventanas de duración deben ser lo suficientemente largas a fin de reducir los falsos positivos, pero lo suficientemente cortas para garantizar que los incidentes se abran de manera oportuna.

Comportamiento de la política

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 sección, se proporciona información adicional para ayudarte a comprender el comportamiento de tus políticas de alertas.

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 Stackdriver 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, Stackdriver 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, durante y después del intervalo de pausa. 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 ausencia métrica o “inferior a”, pueden aparecer en la página Alertas > Incidentes como activadas de forma prematura 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 puntos en las métricas basadas en registros pueden llegar tarde y reabastecerse, hasta después de 10 minutos. 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 el que se evalúa y el momento en el que el incidente correspondiente se vuelve visible en la consola de Stackdriver 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 Stackdriver 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 Stackdriver Monitoring.
    • Métricas basadas en registros, si la recopilación de registros no se retrasa.

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

Notificaciones por incidente

La cantidad de notificaciones enviadas por incidente varía según las condiciones de la política.

Si una política contiene solo una condición, se envía solo una notificación cuando el incidente se abre en un principio, incluso si las mediciones posteriores aún cumplen 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 envía una notificación solo cuando el incidente se abre en un principio.

  • Si una política se activa cuando 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:

    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:

  • Retraso de la recopilación de la métrica: El momento en el que Stackdriver Monitoring debe recopilar valores de la métrica. Para los valores de GCP, esto no suele tener importancia. Para las métricas de AWS CloudWatch, esto puede significar varios minutos. Para las verificaciones de tiempo de actividad, esto puede significar un promedio de 4 minutos, hasta un máximo de 5 minutos y 30 segundos (desde el final del período 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 retrasará al menos cinco minutos desde el primer momento en el 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 los SMS y Slack, no se garantiza que los mensajes se entregarán.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Stackdriver Monitoring
Si necesitas ayuda, visita nuestra página de asistencia.