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 Cloud 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:

Policies

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. No puedes usar métricas con valores de string en las políticas de alertas.
  • 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 se asocian con recursos y miden algunas características 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 métrica, que se activa si alguna serie temporal de la métrica no tiene datos para un período de duración específico.

    Las condiciones de ausencia de 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 (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 para generar datos adicionales durante 30 minutos.

  • Una condición de límite de métrica, que se activa si una métrica supera un valor o es inferior a 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 de visualización de 10 minutos que una condición de cambio de frecuencia de la métrica 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 las verificaciones del tiempo de actividad: Se activa si creaste una verificación de tiempo de actividad y el recurso tiene errores para responder de forma correcta a una solicitud enviada desde al menos dos ubicaciones geográficas.

      Los resultados de las verificaciones de tiempo de actividad se muestran en varios lugares. En Google Cloud Console, las páginas Descripción general de la supervisión y Descripción general de las verificaciones de tiempo de actividad proporcionan una lista de políticas y un estado. La página de detalles de una verificación de tiempo de actividad también muestra su estado. 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 un número específico o es inferior a alguno en un período de duración.

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

    • Proporción de métrica: Se activa si la proporción de dos métricas excede el límite de una duración. Esta es una condición de límite que usa dos métricas relacionadas, por ejemplo, la proporción de respuestas de error de HTTP a todas las respuestas HTTP. No puedes crear este tipo de política en la IU. Puedes crear políticas basadas en la proporción mediante la API; consulta Proporción de métrica para ver una política de muestra.

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
Proporción de métrica Ver

Combina 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 las infracciones de las condiciones individuales generan una alerta:

  • 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 genera una alerta si algún recurso infringe alguna de las condiciones.
Se cumplen todas las condiciones AND Se genera una alerta si 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 genera una alerta si el mismo recurso infringe cada condición. Esta configuración es la opción de combinación más estricta.

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 HTTP superior a dos segundos durante cinco minutos consecutivos.

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. 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.

Los períodos de duración deben ser lo suficientemente largos a fin de reducir los falsos positivos, pero lo suficientemente cortos 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, los períodos 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) incidentes, pero no impide que el paquete de operaciones de Google Cloud 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 funcionó durante los últimos 5 minutos y abre un incidente.

Cuando se vuelve a habilitar una política inhabilitada, el conjunto de operaciones de Google Cloud examina los valores de todas las condiciones durante el período de duración más reciente, que puede incluir datos tomados antes, durante y después del intervalo detenido. Las políticas pueden activarse de inmediato después de reanudarlas, incluso con períodos de larga duración.

Incidentes anómalos

Las políticas de alertas, en especial aquellas con condiciones de límite de ausencia de 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 identificarlos. 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 causa que se infrinjan las condiciones de alerta, solo se abrirán 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 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 solo contiene una condición, solo se envía una notificación cuando se abre un incidente, incluso si las mediciones subsiguientes siguen cumpliendo con 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 2 minutos (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.