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

En este documento, se describe cómo la configuración del período de alineación y la duración determinan cuándo se activa una condición, cómo las políticas de alertas combinan varias condiciones 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 del 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 de retrospectiva desde un momento determinado. El alineador es la función que combina los puntos en el intervalo de retrospectiva en un valor alineado. 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.

Consola de Google Cloud

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

Para obtener más información sobre las funciones disponibles, consulta Aligner en la referencia de la API. Algunas de las funciones del alineador alinean los datos y los convierten de un tipo o tipo de métrica a otro. Para obtener una explicación detallada, consulta Tipos, tipos y conversiones.

API

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

Para obtener más información sobre las funciones disponibles, consulta Aligner en la referencia de la API. Algunas de las funciones del alineador alinean los datos y los convierten de un tipo o tipo de métrica a otro. Para obtener una explicación detallada, consulta Tipos, tipos y conversiones.

Para ilustrar el efecto del período de alineación en una condición de una política de alertas, considera una condición de umbral 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 está configurado en cinco minutos y que el alineador está configurado en sum. Además, supongamos que la condición se activa 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 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 en el período de alineación se muestran con puntos azules, mientras que todos los más antiguos son negros. Cada fila muestra el valor alineado y si este es mayor que el umbral de dos. Para la fila etiquetada start, el valor alineado se calcula en uno, que 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 duración.

Período de duración

Usa la duración, o el período de duración, para evitar que se active una condición debido a una sola medición o previsión. Por ejemplo, supongamos que el campo de duración 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étrica se activan cuando, para una sola serie temporal, cada medición alineada en un intervalo de 15 minutos infringe el umbral.
  • Las condiciones de ausencia de métricas se activan cuando no se reciben datos para una serie temporal en un intervalo de 15 minutos.
  • Las condiciones de previsión se activan cuando cada previsión generada durante un período de 15 minutos predice que la serie temporal incumplirá el umbral dentro del período de previsión.

En el caso de las políticas con una condición, se abre un incidente y se envían notificaciones cuando se activa su condición. Estos incidentes permanecen abiertos mientras se sigue cumpliendo la condición.

Consola de Google Cloud

Para configurar el período de duración, usa el campo Volver a probar el período del paso Configurar activador.

API

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

En la figura anterior, se ilustraron 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 activa porque el período de duración se establece en tres minutos. En la siguiente figura, se muestran 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 activa hasta que el valor alineado es mayor que el umbral durante tres minutos. Ese evento ocurre en el momento start + 5 minutes.

Una condición restablece su período de duración cada vez que una medición o previsión no la cumple. 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 duración 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.

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 menor de dos segundos.
  2. Durante los siguientes 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 el período de duración.
  4. Durante los siguientes cinco minutos consecutivos, la latencia de HTTP es mayor de dos segundos, por lo que se activa la condición.

    Como la política de alertas tiene una condición, se abre un incidente y se envían notificaciones cuando la condición se activa.

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.

Prácticas recomendadas para establecer el período de alineación y la ventana de duración

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 de 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 debería 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 el retraso de transferencia del tipo de métrica. Por ejemplo, si el retraso 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 duración para especificar la capacidad de respuesta de la alerta. Por ejemplo, si estableces el período de duración en 20 minutos para una condición de ausencia de métrica, entonces no debe haber datos durante 20 minutos antes de que se active la condición. Si quieres recibir una alerta con mayor capacidad de respuesta, establece la duración en un valor menor. Para tener la alerta más responsiva, establece la duración en cero en las condiciones de umbral de métrica. Un solo valor alineado hace que se activen estos tipos de condiciones.

Las condiciones de la política de alertas se evalúan con una frecuencia fija. Las elecciones que realizas para el período de alineación y el período de duración 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 abrirá un incidente. Para configurar cómo se combinan varias condiciones, realiza una de las siguientes acciones:

Consola de Google Cloud

Las opciones del combinador se configuran en el paso Activador de varias condiciones.

API

Las opciones del combinador se configuran con el campo combiner de la estructura AlertPolicy.

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

Consola de Google Cloud
Valor de los activadores de políticas
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 Un incidente se abre 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 met 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, la condición se cumple.

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 mayor que el umbral de 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.

Luego, 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 vm2 hace que se cumpla la condición CPU usage is too high, también se creará un incidente. Se crea un incidente porque vm1 y vm2 que provocan 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 dejan de llegar datos de series temporales o cuando estos se retrasan, Monitoring clasifica los datos como faltantes. Los datos faltantes pueden hacer que las políticas no generen alertas y que los incidentes no se cierren. Los retrasos en los datos que llegan de los proveedores de servicios en la nube externos 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 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 la forma en que Monitoring evalúa una condición de umbral de métrica cuando dejan de llegar los datos. Por ejemplo, cuando un incidente está abierto y no llega una medición esperada, ¿deseas que Monitoring deje el incidente abierto o lo cierre de inmediato? Del mismo modo, cuando dejan de llegar datos y ningún incidente está abierto, ¿quieres que se abra un incidente? Por último, ¿cuánto tiempo debe permanecer abierto un incidente después de que dejen de llegar los datos?

Hay dos campos configurables que especifican cómo Monitoring evalúa las condiciones de umbral de métrica cuando dejan de llegar los datos:

  • Para configurar la forma en que Monitoring determina el valor de reemplazo de los datos faltantes, usa el campo Evaluación de datos faltantes que estableciste en el paso Activador de condición. Este campo se inhabilita cuando la ventana para volver a probar se establece en No retest.

  • Para configurar el tiempo que 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. Estableces la duración del cierre automático en el paso Notificación. La duración predeterminada del cierre automático es de siete días.

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

Consola de Google Cloud
Campo “Evaluación de datos faltantes”
Resumen Detalles
Datos faltantes vacíos Los incidentes abiertos permanecen abiertos.
No se abren los incidentes nuevos.

Para las condiciones que se cumplen, la condición se sigue cumpliendo cuando dejan de llegar los datos. Si un incidente está abierto para esta condición, el incidente permanece abierto. Cuando un incidente está 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 vence, el incidente se cierra.

En el caso de las condiciones que no se cumplen, la condición aún no se cumplirá cuando dejan de llegar los datos.

Datos faltantes que se tratan como valores que incumplen 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 dejan de llegar los datos. Si un incidente está abierto para esta condición, el incidente permanece abierto. Cuando un incidente está abierto y no llegan datos durante el cierre automático más 24 horas, el incidente se cierra.

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

Datos faltantes que se tratan como valores que no incumplen la condición de la política Los incidentes abiertos están cerrados.
No se abren los incidentes nuevos.

Cuando se cumplen las condiciones, esta deja de cumplirse cuando dejan de llegar los datos. Si un incidente está abierto para esta condición, se cierra.

En el caso de las condiciones que no se cumplen, la condición aún no se cumplirá cuando dejan de llegar los datos.

API

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

Hay dos campos configurables que especifican cómo Monitoring evalúa las condiciones de umbral de métrica cuando dejan de llegar los datos:

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

  • Para configurar el tiempo que 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 faltante:

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

Para las condiciones que se cumplen, la condición se sigue cumpliendo cuando dejan de llegar los datos. Si un incidente está abierto para esta condición, el incidente permanece abierto. Cuando un incidente está 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 vence, el incidente se cierra.

En el caso de las condiciones que no se cumplen, la condición aún no se cumplirá cuando dejan de llegar los datos.

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 dejan de llegar los datos. Si un incidente está abierto para esta condición, el incidente permanece abierto. Cuando un incidente está abierto y no llegan datos durante el cierre automático más 24 horas, el incidente se cierra.

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

EVALUATION_MISSING_DATA_INACTIVE Los incidentes abiertos están cerrados.
No se abren los incidentes nuevos.

Cuando se cumplen las condiciones, esta deja de cumplirse cuando dejan de llegar los datos. Si un incidente está abierto para esta condición, se cierra.

En el caso de las condiciones que no se cumplen, la condición aún no se cumplirá cuando dejan de llegar los datos.

Puedes minimizar los problemas debido a la falta de datos. Para ello, 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 más largo 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 retrasa.

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.

Incidentes y notificaciones por política

A fin de evitar que Monitoring cree incidentes y envíe notificaciones para una política de alertas, crea una alerta pospuesta y, luego, incluye la política de alertas en los criterios de posposición. Cuando la función para posponer está activa, la política de alertas no crea incidentes ni envía notificaciones.

Cuando las políticas están habilitadas y no coinciden con los criterios de una alerta pospuesta activa, se pueden crear incidentes y se pueden enviar notificaciones. En esta sección, se describen los límites en la cantidad de incidentes abiertos por política y cuándo es posible que veas varias notificaciones para el 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 hacer que la política de alertas genere incidentes para cada recurso. Se abre un incidente para cada serie temporal que da como resultado que se cumpla una condición.

Para evitar la sobrecarga del sistema, la cantidad de incidentes que una sola política puede abrir de forma simultánea se limita a 1,000.

Por ejemplo, considera una política que se aplique a 2,000 (o 20, 000) instancias de Compute Engine y que cada instancia haga que se cumplan las condiciones de alerta. Monitoring limita la cantidad de incidentes abiertos a 1,000. Cualquier condición restante que se cumpla se ignorará hasta que se cierren algunos de los incidentes abiertos de esa política.

Cantidad de notificaciones por política

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

  • Una condición supervisa varias series temporales.

  • Una política contiene varias condiciones:

    • Se cumplen todas las condiciones: cuando se activan todas las condiciones, entonces, para cada serie temporal que provoca la activación de una condición, la política de alertas envía una notificación y crea un incidente. Por ejemplo, supongamos que tienes una política con dos condiciones y que cada condición supervisa una serie temporal. Cuando se activen todas las condiciones, recibirás dos notificaciones y verás dos incidentes.

    • Se cumple cualquier condición: la política de alertas envía una notificación cada vez que se activa una condición. Por ejemplo, supongamos que tienes una política con dos condiciones y que cada condición supervisa una serie temporal. Supongamos que se activa la primera condición. Esto hace que se abra un incidente y se envíe una notificación. Si el incidente aún está abierto cuando una medición posterior hace que se active la segunda condición, se envía otra notificación.

Las políticas de alertas creadas con la API de Cloud Monitoring te notifican cuando se activa la condición y cuando deja de cumplirse. De forma predeterminada, las políticas de alertas creadas con la consola de Google Cloud 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

Cuando inhabilitas una política de alertas, esta continúa evaluando sus condiciones. Sin embargo, no se crean incidentes y no se envían notificaciones.

Cuando habilitas una política inhabilitada, Monitoring examina los valores de todas las condiciones en el período de duración más reciente. La duración más reciente puede incluir datos que se tomaron antes, durante y después de que se habilitara la política. Las políticas pueden activarse de inmediato después de reanudarlas, incluso con períodos de gran duración.

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 finaliza y, como la política de alertas está inhabilitada, no recibes notificaciones. Si reinicias el proceso y habilitas la política de alertas de inmediato, Monitoring reconoce que el proceso no se llevó a cabo durante los últimos cinco minutos y abrirá un incidente.

Cuando inhabilitas una política de alertas, los incidentes abiertos permanecen abiertos hasta que vence la duración del cierre automático. Cuando pospones una política de alertas, todos los incidentes abiertos relacionados con esa política se cierran. Sin embargo, cuando finalice la alerta pospuesta, es posible que se abran incidentes nuevos. Para obtener más información, consulta Cómo posponer notificaciones y alertas.

Notificaciones sobre políticas que coinciden con los criterios de una alerta pospuesta activa

Si deseas evitar que una política de alertas envíe notificaciones durante intervalos cortos, te recomendamos que crees una alerta pospuesta en lugar de inhabilitar la política de alertas. Por ejemplo, antes de realizar el mantenimiento de una máquina virtual (VM), puedes crear una alerta pospuesta y agregar a los criterios de posponer las políticas de alertas que supervisan la instancia.

Cuando se activa una condición de una política de alertas y esa política coincide con los criterios de una alerta pospuesta activa, no se crea ningún incidente ni se envía ninguna notificación. Cuando vence la alerta pospuesta, la política de alertas puede crear incidentes y enviar notificaciones.

Enviar notificaciones repetidas

Para recordarles a los destinatarios de sus incidentes abiertos y reconocidos, configura notificaciones repetidas. Esta función es útil para las políticas de alertas que supervisan los recursos críticos que, cuando se agotan, pueden hacer que un servicio falle. Por ejemplo, puedes configurar notificaciones repetidas para una política de alertas que supervise la cantidad de espacio libre en el disco.

De forma predeterminada, una política de alertas envía una notificación a cada canal de notificaciones cuando se abre un incidente. Sin embargo, puedes cambiar el comportamiento predeterminado y configurar una política de alertas para reenviar notificaciones a todos o algunos de los canales de notificaciones de la política de alertas. Estas notificaciones repetidas se envían para los incidentes que tienen el estado Abierto o Confirmado. El intervalo de estas notificaciones debe ser de al menos 30 minutos y no más de 24 horas, expresado en segundos.

Consola de Google Cloud

No se pueden configurar notificaciones repetidas en la consola de Google Cloud. En su lugar, usa Google Cloud CLI o la API.

API

Agrega al menos un objeto NotificationChannelStrategy a tu objeto AlertStrategy. Un objeto NotificationChannelStrategy tiene los siguientes dos campos:

  • renotifyInterval: Es la cantidad de tiempo, en segundos, entre notificaciones repetidas.

    Puedes cambiar el valor del campo renotifyInterval en cualquier momento. Si un incidente relacionado con la política de alertas está abierto cuando cambias el intervalo, la política de alertas envía otra notificación del incidente y, luego, reinicia el período de intervalo.

  • notificationChannelNames: Es un array de nombres de recursos del canal de notificaciones, que son cadenas en el formato de projects/PROJECT_ID/notificationChannels/CHANNEL_ID. Estos canales de notificaciones reciben las notificaciones repetidas en los intervalos definidos por el valor renotifyInterval.

    El ID del canal del nombre del recurso es un valor numérico. Si quieres obtener más información para recuperar el ID del canal, consulta Cómo enumerar los canales de notificaciones de un proyecto.

En el siguiente ejemplo de JSON, se muestra una estrategia de alerta configurada para enviar notificaciones repetidas cada 1,800 segundos (30 minutos) al canal de notificaciones de la lista:

  "alertStrategy": {
    "notificationChannelStrategy": [
      {
        "notificationChannelNames": [
          "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
        ],
        "renotifyInterval": "1800s"
      }
    ]
  }

Para obtener más información sobre cómo crear políticas de alertas con la API, consulta Crea políticas de alertas con la API.

Para detener las notificaciones repetidas por un período, inhabilita o crea una alerta pospuesta para la política de alertas. Para detener por completo las notificaciones repetidas, edita la política de alertas con la API y quita el objeto NotificationChannelStrategy.

Latencia

La latencia hace referencia al retraso entre el momento en el que Monitoring muestra una métrica y el momento en que los datos de la métrica se hacen visibles como datos de series temporales. 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, Monitoring 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 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 Cloud Monitoring necesita para recopilar valores de métricas. Para 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, el retraso depende de la métrica. Los cálculos de políticas de alertas toman un retraso adicional de 60 a 90 segundos. Para 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 es verdadera durante el período de duración. Por ejemplo, una configuración de ventana de duración de cinco minutos provoca demoras en la notificación de al menos cinco minutos desde la primera vez que ocurre 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?