En este documento, se describe cómo los períodos de alineación y la nueva prueba de ventanas determinar cuándo se cumple una condición, cómo las políticas de alertas combinan varias de alertas y cómo las políticas de alertas 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 demoras en las notificaciones.
Este contenido no se aplica a las políticas de alertas basadas en registros. Para obtener información sobre políticas de alertas basadas en registros, consulta Supervisa tus registros.
Períodos de alineación y períodos para volver a probar
Cloud Monitoring evalúa el período de alineación y el período para volver a probar para determinar 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 para que la política de alertas haya espaciado con regularidad los datos que se evaluarán. El proceso de regularización se denomina alineación.
La alineación implica dos pasos:
La división de las series temporales en intervalos de tiempo regulares, también llamado agrupamiento los 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 único punto; podrías sumar todos los valores o calcular su promedio o usar el máximo. La función que combina los puntos de datos se llama alineador. El resultado de la combinación es el 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 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.
Monitoring configura un período de alineación de la siguiente manera:
Consola de Google Cloud
Tú configuras el período de alineación elegir un valor para los siguientes campos en la página Condiciones de alerta:
- Período progresivo: Especifica el intervalo de tiempo que se debe evaluar.
- Función de ventana progresiva: Especifica la función matemática para realizar en el período de datos.
Para obtener más información sobre las funciones disponibles,
Consulta Aligner en la referencia de la API. Algunos de los alineadores
ambas funciones alinean los datos
y convertirlo de un tipo o tipo de métrica a otro. Para obtener una
consulta Tipos, tipos y conversiones.
API
Para configurar el período de alineación, establece el
Campos aggregations.alignmentPeriod y aggregations.perSeriesAligner
en el MetricThreshold y
MetricAbsence.
Para obtener más información sobre las funciones disponibles,
Consulta Aligner en la referencia de la API. Algunos de los alineadores
ambas funciones alinean los datos
y convertirlo de un tipo o tipo de métrica a otro. Para obtener una
consulta Tipos, tipos y conversiones.
Para ilustrar el efecto del período de alineación en una condición de una alerta
política, considera una condición de umbral de métrica que
supervisar una métrica con un período de muestreo
de un minuto. Supón que el período de alineación se fija en cinco minutos y que
el alineador está establecido en sum. Además, supongamos que la condición se cumple
cuando el valor alineado de la serie temporal es mayor que dos
al menos tres minutos, y que la condición se evalúe cada minuto.
En este ejemplo, el período de alineación es de dos minutos
y la ventana para volver a probar
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 más antiguos 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 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 de dos.
En la tercera evaluación, la suma es tres, y como este valor es
mayor que el umbral, se inicia un temporizador para el período para volver a probar.
Cómo volver a probar ventanas
La condición de una política de alertas tiene un período para volver a probar, que evita que se se cumpla debido a una sola medición o previsión. Por ejemplo, supongamos que el período para volver a probar 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 del umbral de métrica se cumplen cuando, para un una serie temporal única, cada medición alineada en un intervalo de 15 minutos infringe 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 previsión se cumplen cuando se produce cada previsión. 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 desactivan las notificaciones que se envía cuando se cumple la condición. Estos incidentes permanecen abiertos mientras la condición se sigue cumpliendo.
Consola de Google Cloud
A fin de configurar la ventana de nueva prueba, utiliza el campo Retest window en la Configura el activador de alertas.
API
Para configurar la ventana de nueva prueba, se establece el campo llamado
duration en MetricThreshold y
Estructuras de MetricAbsence.
En la figura anterior, se ilustraban tres evaluaciones de un umbral de métrica
estado. En el
tiempo start + 2 minutes, el valor alineado es mayor que el umbral;
Sin embargo, la condición no se cumple porque el período para volver a probar está configurado en
tres minutos. En la siguiente figura, se ilustran los resultados de la siguiente
evaluaciones de la condición:
A pesar de que el valor alineado es mayor que el umbral en
hora start + 2 minutes, la condición no se cumple hasta que el valor alineado
es mayor que el umbral por tres minutos. Ese evento ocurre a la hora
start + 5 minutes.
Una condición restablece su período para volver a probar cada vez que se realiza una medición o una previsión no cumple 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 cinco minutos para volver a probar.
Si la latencia de respuesta HTTP es superior a dos segundos,
y, si la latencia es mayor que el umbral durante cinco minutos,
Luego, abre un incidente y envía un correo electrónico a tu equipo de asistencia.En la siguiente secuencia, se ilustra la forma en que el período de nueva prueba afecta la evaluación de la condición:
- La latencia de HTTP es menor a dos segundos.
- Durante los siguientes tres minutos consecutivos, la latencia de HTTP es mayor de dos segundos.
- En la siguiente medición, la latencia es menor a dos segundos, así que restablece el período para volver a probar.
Durante los siguientes cinco minutos consecutivos, la latencia de HTTP es mayor que dos segundos, por lo que se cumple la condición.
Dado que la política de alertas tiene una condición, Monitoring envía notificaciones cuando se cumple la condición.
Establecer que el período de repetición de la prueba sea lo suficientemente extenso como para minimizar los falsos positivos, pero lo suficientemente corta 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 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 es se muestrean cada 300 segundos, el período de alineación debe ser de, al menos, 300 segundos. Sin embargo, si deseas combinar 5 muestras, configura el 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 que la transferencia demora 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 la ventana Volver a probar para especificar la capacidad de respuesta de la alerta. Por ejemplo: si establece el período de repetición de la prueba en 20 minutos durante condición de ausencia de métrica, entonces no debe haber datos durante 20 minutos antes de que se cumpla la condición. Para una política de alertas más responsiva, establece el período para volver a probar con un valor menor. Para que las condiciones de umbral de métrica tengan la política de alertas más responsiva, establece en cero el período para volver a probar. Un solo valor alineado genera estos tipos condiciones que se deben cumplir.
Las condiciones de la política de alertas se evalúan con una frecuencia fija. Las opciones que para el período de alineación y la ventana de nueva prueba no determina cada cuánto 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 tu política de alertas tiene varias condiciones, luego debes especificar cuando se abre un incidente. Para configurar cómo se combinan varias condiciones, realiza una de las siguientes acciones:
Consola de Google Cloud
Las opciones de combinador se configuran en el paso Activador de varias condiciones.
API
Las opciones de combinador se configuran en el campo combiner del
Estructura de AlertPolicy.
En esta tabla, se indican los parámetros de configuración de la consola de Google Cloud, los en la API de Cloud Monitoring y una descripción de cada parámetro de configuración:
| Consola de Google Cloud Valor de 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 |
Se abre un incidente si cada se cumple una condición, incluso si una 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 conocido
significa que la configuración de la condición se evalúa como true. Para
por ejemplo, si la configuración está
Any time series is greater than 10 for 5 minutes,
entonces, cuando esta instrucción se evalúe como true, se cumplirá 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 highsupervisa el uso de CPU de las instancias. Esta condición se cumple cuando el uso de CPU de cualquier instancia se superior a 100 ms/s durante 1 minuto. - La condición denominada
Excessive utilizationsupervisa 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. Porque
el uso de CPU sea mayor que el umbral por un minuto, la condición
Se cumple 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 que el uso de CPU de vm2 supere 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, entonces que también genera un incidente. Un incidente se crea porque vm1 y vm2, lo que causa que se cumpla la condiciónCPU usage is too highson eventos diferentes.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 cumplaExcessive utilization.
Datos parciales de la métrica
Cuando los datos de series temporales dejan de llegar o cuando se retrasan Monitoring clasifica los datos como faltantes. La falta de datos puede impedir el cierre de incidentes. Demoras en los datos que llegan desde puede llegar hasta 30 minutos y los retrasos más comunes son de 5 a 15 minutos. Largo un retraso mayor que el período para volver a probar un estado "desconocido" state. Cuando los datos finalmente llegan, Monitoring podría haber perdido parte del historial reciente de las afecciones. 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 cómo Monitoring evalúa un condición de umbral de métrica cuando dejan de llegar los datos. Por ejemplo, cuando un incidente está abierto y una medición no llega, quieres que Monitoring deje el incidente abrir o cerrarlo de inmediato? Del mismo modo, cuando los datos dejan de llegar y si no hay ningún incidente abierto, ¿quieres que se abra un incidente? Por último, ¿cuánto tiempo ¿debería un incidente permanecer abierto después de que los datos dejan de llegar?
Hay dos campos configurables que especifican cómo Monitoring Evalúa las condiciones del umbral de métricas cuando dejan de llegar los datos:
Para configurar la forma en que Monitoring determina el valor de reemplazo para datos faltantes, usa el campo Evaluación de datos faltantes que estableciste en el paso Activador de condición. Este campo se inhabilita cuando ventana para volver a probar esté configurado en No volver a probar.
El período para volver a probar es el campo llamado duración en la API de Cloud Monitoring.
Para configurar cuánto tiempo espera Monitoring antes de cerrar un incidente abierto después de que los datos dejan de llegar, usa el Campo Duración del cierre automático de incidentes. Establece la duración del cierre automático Notificación. La duración predeterminada del cierre automático es siete días.
A continuación, se describen las distintas opciones para el campo de datos faltante:
| Consola de Google Cloud "Evaluación de datos faltantes" campo |
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 sigue siendo se cumplen cuando los datos dejan de llegar. Si hay un incidente abierto para esta condición, el incidente permanece abierto. Cuando un incidente está abierto y no hay datos llega, el temporizador de cierre automático comienza luego de una demora de al menos 15 minutos. Si el temporizador expira, se cierra el incidente. En el caso de las condiciones que no se cumplen, la condición sigue cuando los datos dejen de llegar. |
| Datos faltantes que se consideran 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 sigue siendo se cumplen cuando los datos dejan de llegar. Si hay un incidente 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 se cierra el incidente. En el caso de las condiciones que no se cumplen, este parámetro de configuración hace que
condición de umbral de métrica para comportarse como un |
| Datos faltantes que se consideran valores que no incumplen la condición de la política | Los incidentes abiertos están cerrados. No se abren los incidentes nuevos. |
Para las condiciones que se cumplen, la condición deja de cumplirse cuando dejan de llegar los datos. Si hay un incidente abierto para esta condición, se cierra el incidente. En el caso de las condiciones que no se cumplen, la condición sigue cuando los datos dejen de llegar. |
API
Puedes configurar cómo Monitoring evalúa un condición de umbral de métrica cuando dejan de llegar los datos. Por ejemplo, cuando un incidente está abierto y una medición no llega, quieres que Monitoring deje el incidente abrir o cerrarlo de inmediato? Del mismo modo, cuando los datos dejan de llegar y si no hay ningún incidente abierto, ¿quieres que se abra un incidente? Por último, ¿cuánto tiempo ¿debería un incidente permanecer abierto después de que los datos dejan de llegar?
Hay dos campos configurables que especifican cómo Monitoring Evalúa las condiciones del umbral de métricas cuando dejan de llegar los datos:
Configurar la forma en que Monitoring determina el valor de reemplazo para datos faltantes, usa
evaluationMissingDatade la estructuraMetricThreshold. Este campo se ignora cuando el campodurationes cero.Para configurar cuánto tiempo espera Monitoring antes de cerrar un incidente abierto después de que los datos dejen de llegar, usa el campo
autoCloseen la estructuraAlertStrategy.
A continuación, se describen las distintas opciones para el campo de datos faltante:
| API Campo evaluationMissingData |
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 sigue siendo se cumplen cuando los datos dejan de llegar. Si hay un incidente abierto para esta condición, el incidente permanece abierto. Cuando un incidente está abierto y no hay datos llega, el temporizador de cierre automático comienza luego de una demora de al menos 15 minutos. Si el temporizador expira, se cierra el incidente. En el caso de las condiciones que no se cumplen, la condición sigue cuando los datos dejen de llegar. |
EVALUATION_MISSING_DATA_ACTIVE |
Los incidentes abiertos permanecen abiertos. Se pueden abrir incidentes nuevos. |
Para las condiciones que se cumplen, la condición sigue siendo se cumplen cuando los datos dejan de llegar. Si hay un incidente abierto para esta condición, el incidente permanece abierto. Cuando un incidente está abierto y no hay datos llega para el cierre automático que dura más de 24 horas se cierra el incidente. En el caso de las condiciones que no se cumplen, este parámetro de configuración hace que
condición de umbral de métrica para comportarse como un |
EVALUATION_MISSING_DATA_INACTIVE |
Los incidentes abiertos están cerrados. No se abren los incidentes nuevos. |
Para las condiciones que se cumplen, la condición deja de cumplirse cuando dejan de llegar los datos. Si hay un incidente abierto para esta condición, se cierra el incidente. En el caso de las condiciones que no se cumplen, la condición sigue cuando los datos dejen de llegar. |
Para minimizar los problemas debido a la falta de datos, puedes hacer lo siguiente:
- Comunícate con tu proveedor de servicios en la nube externo para identificar formas de reducir latencia de recopilación de métricas.
- Usa períodos más largos para volver a probar tus afecciones. Cómo usar un período más largo para volver a probar tiene la desventaja de reducir las políticas de alertas adaptables.
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 Supervisión
- Métricas basadas en registros, si la recopilación de entradas de registro no se retrasa.
Para obtener más información, consulta Descripción general del agente de Monitoring, Descripción general de las métricas definidas por el usuario métricas basadas en registros.
Cuando Monitoring envía notificaciones y crea incidentes
Cloud Monitoring envía una notificación cuando se crea hace que se cumpla una condición. La notificación se envía a todos canales de notificaciones. No puedes restringir una notificación a un canal específico o a un subconjunto de las políticas canales.
Si configuras las notificaciones repetidas, la misma notificación se reenvía a un canales de notificaciones para tu política de alertas.
Es posible que recibas varias notificaciones únicas relacionadas con una política de alertas cuando cualquiera de los siguientes son verdaderas:
Una condición supervisa varias series temporales.
Una política contiene varias condiciones. En este caso, las notificaciones que dependen del valor de la política de alertas activador:
Se cumplen todas las condiciones: Cuando se cumplen todas las condiciones, de cada serie temporal que dé como resultado el cumplimiento de una condición, la política de alertas envía una notificación y crea un incidente.
No puedes configurar Cloud Monitoring para crear solo un incidente y puede enviar solo una notificación cuando la política de alertas contenga conditions.
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 la condición se cumple y cuando la condición deja de cumplirse. Las políticas de alertas creadas con la consola de Google Cloud no envían cuando la condición deje 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 o enviar notificaciones cuando se cumplan las condiciones de una política de alertas:
- La política de alertas está inhabilitada.
- La política de alertas está pospuesta.
- Monitoring alcanzó el límite de la cantidad máxima de espacios abiertos de seguridad sobre posibles incidentes.
Políticas de alertas inhabilitadas
Monitoring no envía, crea incidentes ni envía notificaciones para políticas de alertas inhabilitadas. Sin embargo, Monitoring continúa evaluando las condiciones de una política de alertas inhabilitada.
Cuando habilitas una política inhabilitada, Monitoring valores de todas las condiciones durante el período de reintento más reciente. El período más reciente para volver a probar podría incluir datos tomados antes, durante y después el se habilitó la política. Las condiciones de una política inhabilitada se pueden cumplir de inmediato después de reanudar la política, incluso con períodos extensos de reintento.
Por ejemplo, imagina que tienes una política de alertas que supervisa y que inhabilitas esta política. La semana siguiente, el proceso y, como la política de alertas está inhabilitada, no recibirás ninguna notificación. Si reinicias el proceso y habilitas la política de alertas de inmediato, Monitoring reconoce que el proceso no ha finalizado los últimos cinco minutos y abre un incidente.
Los incidentes relacionados con una política de alertas inhabilitada permanecen abiertos hasta la 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 está pospuesta. Recomendamos posponer políticas de alertas cuando quieres evitar que una política de alertas envíe notificaciones solo durante intervalos cortos. Por ejemplo, antes de realizar el mantenimiento de una máquina virtual (VM), puedes crear una alerta pospone los criterios de las políticas de alertas que supervisan la instancia.
Cuando pospones una política de alertas, Monitoring todos los incidentes abiertos relacionados con la política. Supervisión puedes abrir incidentes nuevos después de que venza la función para posponer. Para obtener más 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 es posible que exista un problema que todos los recursos pueden hacer que la política de alertas abra incidentes para cada recurso. Se abre un incidente por cada serie temporal que da como resultado una condición que se está cumpliendo.
Para evitar la sobrecarga del sistema, la cantidad de incidentes que un solo política que se puede abrir simultáneamente está limitada a 1,000.
Por ejemplo, imagina una política que se aplica al nivel 2,000 de Compute Engine instancias y cada una hace que se cumplan las condiciones de alerta. La supervisión limita la cantidad de incidentes abiertos a 1,000. Cualquier condición restante que se cumpla se hasta que se cierren algunos incidentes para esa política.
Como resultado de este límite, un solo canal de notificaciones puede recibir hasta 1,000 notificaciones a la vez Si tus alertas política tiene varios canales de notificación, este límite se aplica a cada canal de notificaciones de forma independiente.
Latencia
La latencia se refiere al tiempo que transcurre entre el momento en que Monitoring realiza un muestreo de un y cuando el dato de la métrica se vuelve visible como datos de series temporales. La latencia afecta cuándo se envían las notificaciones. Por ejemplo, si una canalización tiene una latencia de hasta 180 segundos y, luego, Monitoring no creará un incidente durante un máximo de 180 segundos la condición de la política de alertas se evalúa 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:
Retraso de la recopilación de métricas: El tiempo que Monitoring necesita para recopilar valores de métricas. Para los valores de Google Cloud, la mayoría de las métricas Visible durante 60 segundos después de la recopilación Sin embargo, la demora depende en función de la métrica. Los cálculos de la política de alertas toman un retraso adicional de 60 a 90 segundos. Para las métricas de AWS CloudWatch, el retraso de visibilidad puede tardar varios minutos. Para las verificaciones de tiempo de actividad, esto puede ser un promedio de dos minutos (desde el final del período para volver a probar).
Ventana Volver a probar: La ventana configurada para la condición. Las condiciones solo se cumplen cuando una condición es verdadera durante la repetición de la prueba en la ventana modal. Por ejemplo, un parámetro de configuración de cinco minutos en un período para volver a probar retrasos en la notificación de al menos cinco minutos desde que evento por primera vez.
Hora de recibir la notificación: Incluye los canales de notificación, como el correo electrónico. y SMS, pueden experimentar latencias de red u otras latencias (no relacionadas con lo que se está entregando), a veces se aproximan 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 vínculos: documentos:
Para ver una selección de políticas de alertas, consulta Políticas de muestra.