Las políticas de alertas basadas en métricas de Cloud Monitoring te permiten supervisar datos de series temporales, crear alertas y enviar notificaciones. Tú controlas cuándo las políticas de alertas crean alertas y envían notificaciones configurando períodos de alineación, ventanas de reanálisis y reglas de varias condiciones. Comprender cómo las políticas de alertas manejan los datos faltantes, los límites de las alertas y las notificaciones, y los retrasos en las notificaciones te ayuda a minimizar los falsos positivos y ajustar la capacidad de respuesta de las alertas.
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.
Períodos de alineación y ventanas de nueva prueba
Cloud Monitoring evalúa el período de alineación y la ventana de nueva prueba cuando determina 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 de series temporales, estos deben regularizarse para que la política de alertas tenga datos espaciados de forma regular para evaluar. El proceso de regularización se denomina alineación.
La alineación implica dos pasos:
Dividir las series temporales en intervalos de tiempo regulares, también llamado agrupamiento de 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 punto único: puedes sumar todos los valores, calcular su promedio o usar el valor máximo. La función que combina los puntos de datos se denomina alineador. El resultado de la combinación 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 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
Para configurar el período de alineación, elige un valor para los siguientes campos en la página Condiciones de la alerta:
- Período: Especifica el período que se evaluará.
- Función de ventana progresiva: Especifica la función matemática que se realizará en la ventana de puntos de datos.
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 clase de métrica a otro. Para obtener una explicación detallada, consulta Categorías, tipos y conversiones.
API
Para configurar el período de alineación, establece 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 clase de métrica a otro. Para obtener una explicación detallada, consulta Categorías, 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 supervisa una métrica con un período de muestreo de un minuto. Supongamos que el período de alineación se establece en cinco minutos y que el alineador se establece en sum. Además, supón que se cumple la condición cuando el valor alineado de la serie temporal es superior a dos durante al menos tres minutos y que la condición se evalúa cada minuto.
En este ejemplo, el período de nueva prueba, 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 del período de alineación se muestran con puntos azules, y los puntos más antiguos, con puntos negros. Cada fila muestra el valor alineado y si este es mayor que el umbral de dos. Para la fila etiquetada como start, el valor alineado se calcula como 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 el período de nueva prueba.
Períodos para volver a probar
La condición de una política de alertas tiene un período de nueva prueba, que impide que se cumpla la condición debido a una sola medición o previsión. Por ejemplo, supongamos que el período de nueva prueba 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étricas se cumplen cuando, para una sola serie temporal, cada medición alineada en un intervalo de 15 minutos incumple 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 cada previsión producida 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 una alerta y se envían notificaciones cuando se cumple la condición. Estas alertas permanecen abiertas mientras se siga cumpliendo la condición.
Consola de Google Cloud
Puedes configurar el período de nueva prueba con el campo Período de nueva prueba en el paso Configurar activador de alertas.
API
Para configurar el período de nueva prueba, establece el campo llamado 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, no se cumple la condición porque el período de nueva prueba se establece en tres minutos. En la siguiente figura, se ilustran los resultados de las próximas evaluaciones de la condición:
Aunque el valor alineado es mayor que el umbral en el momento start + 2 minutes, la condición no se cumple 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 nueva prueba cada vez que una medición o previsión no satisface la condición. Por lo tanto, establece el período de nueva prueba de manera que sea lo suficientemente largo para minimizar los falsos positivos, pero lo suficientemente corto para verificar que las alertas se abran de manera oportuna. 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 reanálisis 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 una alerta y envía un correo electrónico a tu equipo de asistencia al cliente.
La siguiente secuencia ilustra cómo el período de nueva prueba afecta la evaluación de la condición:
- La latencia de HTTP es inferior a dos segundos.
- Durante los próximos tres minutos consecutivos, la latencia de HTTP es superior a dos segundos.
- En la siguiente medición, la latencia es inferior a dos segundos, por lo que la condición restablece el período de nueva prueba.
Durante los siguientes cinco minutos consecutivos, la latencia de HTTP es superior a dos segundos, por lo que se cumple la condición.
Como la política de alertas tiene una condición, Monitoring envía notificaciones cuando se cumple la condición.
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 combina el alineador. El intervalo de muestreo, la demora en la transferencia y la cantidad de muestras que deseas combinar afectan la forma en que estableces el período de alineación:
El período de alineación no debe ser superior a 24 horas menos la demora en la transferencia.
Te recomendamos que establezcas el período de alineación para que sea al menos tan largo como la demora en la transferencia. Sin embargo, el período de alineación siempre debe ser al menos tan largo como el intervalo de muestreo.
En el caso de las condiciones de umbral de métrica, el valor máximo típico del período de alineación es de 25 horas menos la demora en la transferencia del tipo de métrica. Por ejemplo, si la demora en la transferencia de una métrica es de 6 horas, el valor máximo del período de alineación es de 19 horas. Puedes usar PromQL para generar alertas sobre datos con una antigüedad superior a 25 horas. Para obtener más información, consulta Usa PromQL para crear políticas de alertas.
Por ejemplo, si la demora en la transferencia de un tipo de métrica es de 6 horas, te recomendamos que uses un período de alineación de entre 6 y 18 horas. Supongamos que el intervalo de muestreo es de 60 segundos. Si estableces el período de alineación en 6 horas y 5 minutos, el alineador combinará 5 muestras en promedio.
Si un tipo de métrica tiene una demora de incorporación muy larga, como 18 horas, establece el período de alineación para que sea al menos tan largo como el intervalo de muestreo, pero no más de 24 horas menos la demora de incorporación.
Usa el período de nueva prueba para especificar la capacidad de respuesta de la alerta. Por ejemplo, si estableces el período de nueva prueba en 20 minutos para una condición de ausencia de métrica, no debe haber datos durante 20 minutos antes de que se cumpla la condición. Para que la política de alertas sea más sensible, establece la ventana de reanálisis en un valor más pequeño. En el caso de las condiciones de límite de métrica, para tener la política de alertas más responsiva, establece la ventana de nueva prueba en cero. Un solo valor alineado hace que se cumplan estos tipos de condiciones.
Si estableces el período de nueva prueba, es posible que debas acortar el período de alineación debido a los límites de las políticas de alertas.
Las condiciones de la política de alertas se evalúan con una frecuencia fija. Las opciones que elijas para el período de alineación y la ventana de nueva prueba 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 abre una alerta. Para configurar cómo se combinan varias condiciones, realiza una de las siguientes acciones:
Consola de Google Cloud
Configuras las opciones del combinador en el paso Activador de varias condiciones.
API
Puedes configurar las opciones del combinador con el campo combiner de la estructura AlertPolicy.
En esta tabla, se enumeran los parámetros de 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:
| Google Cloud console Valor de Policy triggers |
API de Cloud Monitoring Valor del combinador |
Significado |
|---|---|---|
| : Se cumple cualquier condición | OR |
Se abre una alerta 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 una alerta para cada condición que se cumple cuando se cumplen todas las condiciones, incluso si un recurso diferente hace que se cumplan esas condiciones. |
| Se cumplen todas las condiciones | AND_WITH_MATCHING_RESOURCE |
Se abre una alerta para cada condición que se cumple cuando se cumplen todas las condiciones, solo si el mismo recurso hace que se cumpla cada condición. Este parámetro de configuración es la opción de combinación más estricta. |
En este contexto, el término cumplido significa que la configuración de la condición se evalúa como verdadero. Por ejemplo, si la configuración es Any time series is greater than 10 for 5 minutes, cuando esta instrucción se evalúa como verdadero, se cumple la condición.
Ejemplo
Considera un proyecto 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 es 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. Dado que el uso de CPU es superior al umbral durante 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 una alerta porque se cumple una condición. Si las condiciones se combinan con Se cumplen todas las condiciones o Se cumplen todas las condiciones, incluso para diferentes recursos para cada condición, no se crea una alerta. Estas opciones de combinador requieren que se cumplan ambas condiciones.
A continuación, supón 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 una alerta cuando un recurso provoca que se cumpla 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á una alerta. Se crea una alerta porque vm1 y vm2 que provocan que se cumpla la condiciónCPU usage is too highson eventos distintos.Se cumplen todas las condiciones, incluso para diferentes recursos en cada condición: Se crea una alerta porque se cumplen ambas condiciones.
Se cumplen todas las condiciones: No se crea una alerta porque este combinador requiere que el mismo recurso cumpla con todas las condiciones. En este ejemplo, no se crea ninguna alerta porque vm1 hace que se cumpla
CPU usage is too high, mientras que vm2 hace que se cumplaExcessive utilization.
Datos parciales de la métrica
Cuando los datos de series temporales dejan de llegar o se retrasan, Monitoring los clasifica como faltantes. La falta de datos puede impedir que se cierren las alertas. Los retrasos en la llegada de datos de proveedores de servicios en la nube externos pueden ser de hasta 30 minutos, y los retrasos de 5 a 15 minutos son los más comunes. Una demora prolongada, más allá del período de nueva prueba, puede hacer que las condiciones entren en un estado "desconocido". Cuando finalmente llegan los datos, es posible que la Supervisión 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 cómo Monitoring evalúa una condición de umbral de métrica cuando dejan de llegar datos. Por ejemplo, cuando una alerta está abierta y no llega una medición esperada, ¿quieres que Monitoring deje la alerta abierta o que la cierre de inmediato? Del mismo modo, cuando dejan de llegar datos y no hay ninguna alerta abierta, ¿quieres que se abra una alerta? Por último, ¿durante cuánto tiempo debe permanecer abierta una alerta después de que dejan de llegar los datos?
Existen dos campos configurables que especifican cómo Monitoring evalúa las condiciones de umbral de métricas cuando dejan de llegar datos:
Para configurar cómo Monitoring determina el valor de reemplazo para 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 de nueva prueba se establece en Sin nueva prueba.
El período de nueva prueba es el campo llamado duración en la API de Cloud Monitoring.
Para configurar cuánto tiempo espera Monitoring antes de cerrar una alerta abierta después de que dejan de llegar datos, usa el campo Duración del cierre automático de alertas. Establece 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 faltantes:
| Campo "Evaluación de datos faltantes" de laGoogle Cloud consola |
Resumen | Detalles |
|---|---|---|
| Tratar datos faltantes como vacíos | Las alertas abiertas permanecen abiertas. No se abren Alertas de Google Noticias nuevas. |
En el caso de las condiciones que se cumplen, la condición sigue cumpliéndose cuando dejan de llegar datos. Si hay una alerta abierta para esta condición, la alerta permanecerá abierta. Cuando se abre una alerta y no llegan datos, el temporizador de cierre automático comienza después de una demora de al menos 15 minutos. Si vence el temporizador, se cierra la alerta. En el caso de las condiciones que no se cumplen, la condición sigue sin cumplirse cuando dejan de llegar datos. |
| Los datos faltantes se tratan como valores que incumplen la condición de la política | Las alertas abiertas permanecen abiertas. Se pueden abrir alertas nuevas. |
En el caso de las condiciones que se cumplen, la condición sigue cumpliéndose cuando dejan de llegar datos. Si hay una alerta abierta para esta condición, la alerta permanecerá abierta. Cuando se abre una alerta y no llegan datos durante el período de cierre automático más 24 horas, se cierra la alerta. 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 un |
| Los datos faltantes se tratan como valores que no incumplen la condición de la política | Se cierran las alertas abiertas. No se abren Alertas de Google Noticias nuevas. |
En el caso de las condiciones que se cumplen, la condición deja de cumplirse cuando los datos dejan de llegar. Si hay una alerta abierta para esta condición, se cierra. En el caso de las condiciones que no se cumplen, la condición sigue sin cumplirse cuando dejan de llegar datos. |
API
Puedes configurar cómo Monitoring evalúa una condición de umbral de métrica cuando dejan de llegar datos. Por ejemplo, cuando una alerta está abierta y no llega una medición esperada, ¿quieres que Monitoring deje la alerta abierta o que la cierre de inmediato? Del mismo modo, cuando dejan de llegar datos y no hay ninguna alerta abierta, ¿quieres que se abra una alerta? Por último, ¿durante cuánto tiempo debe permanecer abierta una alerta después de que dejan de llegar los datos?
Existen dos campos configurables que especifican cómo Monitoring evalúa las condiciones de umbral de métricas cuando dejan de llegar datos:
Para configurar cómo Monitoring determina el valor de reemplazo de los datos faltantes, usa el campo
evaluationMissingDatade la estructuraMetricThreshold. Este campo se ignora cuando el campodurationes cero.Para configurar cuánto tiempo espera Monitoring antes de cerrar una alerta abierta después de que dejan de llegar datos, usa el campo
autoCloseen la estructuraAlertStrategy.
A continuación, se describen las diferentes opciones para el campo de datos faltantes:
Campo de la APIevaluationMissingData |
Resumen | Detalles |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Las alertas abiertas permanecen abiertas. No se abren alertas nuevas. |
En el caso de las condiciones que se cumplen, la condición sigue cumpliéndose cuando dejan de llegar datos. Si hay una alerta abierta para esta condición, la alerta permanecerá abierta. Cuando se abre una alerta y no llegan datos, el temporizador de cierre automático comienza después de una demora de al menos 15 minutos. Si vence el temporizador, se cierra la alerta. En el caso de las condiciones que no se cumplen, la condición sigue sin cumplirse cuando dejan de llegar datos. |
EVALUATION_MISSING_DATA_ACTIVE |
Las alertas abiertas permanecen abiertas. Se pueden abrir alertas nuevas. |
En el caso de las condiciones que se cumplen, la condición sigue cumpliéndose cuando dejan de llegar datos. Si hay una alerta abierta para esta condición, la alerta permanecerá abierta. Cuando una alerta está abierta y no llegan datos durante el período de cierre automático más 24 horas, se cierra la alerta. 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 un |
EVALUATION_MISSING_DATA_INACTIVE |
Se cierran las alertas abiertas. No se abren alertas nuevas. |
En el caso de las condiciones que se cumplen, la condición deja de cumplirse cuando dejan de llegar datos. Si hay una alerta abierta para esta condición, se cierra. En el caso de las condiciones que no se cumplen, la condición sigue sin cumplirse cuando dejan de llegar datos. |
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 la latencia de recopilación de métricas.
- Usa ventanas de nueva prueba más largas en tus condiciones. Usar una ventana de reanálisis más larga tiene la desventaja de que tus políticas de alertas sean menos sensibles.
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 Monitoring
- Métricas basadas en registros, si no se retrasa la recopilación de entradas de registro
Para obtener más información, consulta la Descripción general del agente de operaciones, la Descripción general de las métricas definidas por el usuario y las métricas basadas en registros.
Cuándo Monitoring envía notificaciones y crea alertas
Cloud Monitoring envía una notificación cuando una serie temporal hace que se cumpla una condición. La notificación se envía a todos los canales de notificación. No puedes restringir una notificación a un canal específico o a un subconjunto de los canales de tu política.
Si configuras notificaciones repetidas, se volverá a enviar la misma notificación a canales de notificaciones específicos de tu política de alertas.
Es posible que recibas varias notificaciones únicas relacionadas con una política de alertas cuando se cumpla alguna de las siguientes condiciones:
Una condición supervisa varias series temporales.
Una política contiene varias condiciones. En este caso, las notificaciones que recibas dependerán del valor del activador de varias condiciones de la política de alertas:
Se cumplen todas las condiciones: Cuando se cumplen todas las condiciones, para cada serie temporal que genera el cumplimiento de una condición, la política de alertas envía una notificación y crea una alerta.
No puedes configurar Cloud Monitoring para que cree solo una alerta y envíe solo una notificación cuando la política de alertas contenga varias condiciones.
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 se cumple la condición y cuando deja de cumplirse. Las políticas de alertas creadas con la consola Google Cloud no envían una notificación cuando deja de cumplirse la condición, a menos que hayas habilitado ese comportamiento.
Cuándo Monitoring no envía notificaciones ni crea alertas
En las siguientes situaciones, Monitoring no crea alertas ni envía notificaciones cuando se cumplen las condiciones de una política de alertas:
- La política de alertas está inhabilitada.
- Se pospuso la política de alertas.
- El monitoreo alcanzó el límite de la cantidad máxima de alertas abiertas.
Políticas de alertas inhabilitadas
La supervisión no envía alertas de creación ni notificaciones para las políticas de alertas inhabilitadas. Sin embargo, Monitoring sigue evaluando las condiciones de una política de alertas inhabilitada.
Cuando habilitas una política inhabilitada, Monitoring evalúa los valores de todas las condiciones durante el período de nueva prueba más reciente. El período de nueva prueba más reciente puede incluir datos recopilados antes, durante y después de que se habilitó la política. Las condiciones de una política inhabilitada se pueden cumplir inmediatamente después de reanudar la política, incluso con grandes ventanas de nueva prueba.
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 falla y, como la política de alertas está inhabilitada, no recibes ninguna notificación. Si reinicias el proceso y habilitas la política de alertas de inmediato, Monitoring reconocerá que el proceso no se ejecutó durante los últimos cinco minutos y abrirá una alerta.
Las alertas relacionadas con una política de alertas inhabilitada permanecen abiertas hasta que vence la duración de cierre automático de la política.
Políticas de alertas pospuestas
La supervisión no envía notificaciones ni crea alertas para una política de alertas que está pospuesta. Te recomendamos que pospongas las políticas de alertas cuando quieras evitar que una política de alertas envíe notificaciones solo durante intervalos cortos. Por ejemplo, antes de realizar tareas de mantenimiento en una máquina virtual (VM), puedes crear una posposición y agregar a los criterios de posposición las políticas de alertas que supervisan la instancia.
Cuando pospones una política de alertas, Monitoring cierra todas las alertas abiertas relacionadas con la política. La supervisión puede abrir alertas nuevas después de que caduque la función de posponer. Para obtener más información, consulta Cómo posponer notificaciones y alertas.
Límites de notificaciones y alertas abiertas
Una política de alertas se puede aplicar a muchos recursos, y un problema que afecte a todos los recursos puede hacer que la política de alertas abra alertas para cada recurso. Se abre una alerta para cada serie temporal que cumple con una condición.
Para evitar sobrecargar el sistema, la cantidad de alertas que una sola política puede abrir de forma simultánea se limita a 1,000.
Por ejemplo, considera una política que se aplica a 2,000 instancias de Compute Engine, y cada instancia hace que se cumplan las condiciones de alerta. La supervisión limita la cantidad de alertas abiertas a 1,000. Se ignorarán las condiciones restantes que se cumplan hasta que se cierren algunas de las alertas abiertas para esa política.
Como resultado de este límite, un solo canal de notificación puede recibir hasta 1,000 notificaciones a la vez. Si tu política de alertas tiene varios canales de notificación, este límite se aplica a cada canal de notificación de forma independiente.
Latencia
La latencia se refiere a la demora entre el momento en que Monitoring muestrea una métrica y el momento en que el punto de datos de la métrica se vuelve visible 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á una alerta hasta 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 los datos de métricas.
Los siguientes eventos y parámetros de configuración contribuyen a la latencia:
Retraso en la recopilación de métricas: Es el tiempo que necesita Monitoring para recopilar los valores de las métricas. En el caso de 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, la demora depende de la métrica. Los cálculos de las políticas de alertas tienen una demora adicional de hasta 5 minutos y 30 segundos. En el caso de las métricas de AWS CloudWatch, la demora en la visibilidad puede ser de varios minutos. En el caso de las verificaciones de tiempo de actividad, puede ser un promedio de dos minutos (desde el final del período de nueva prueba).
Período para volver a probar: Es el período configurado para la condición. Las condiciones solo se cumplen cuando una condición es verdadera durante todo el período de nueva prueba. Por ejemplo, un parámetro de configuración de ventana de nueva prueba de cinco minutos provoca retrasos en la notificación de al menos cinco minutos desde que se produce el evento por primera vez.
Tiempo para que llegue la notificación: Los canales de notificación, como el correo electrónico y los SMS, pueden experimentar latencias de red o de otro tipo (no relacionadas con lo que se entrega), que a veces se acercan a los 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 documentos:
Para ver una selección de políticas de alertas, consulta Políticas de muestra.