En este documento se describe cómo determinan los periodos de alineación y las ventanas de repetición de pruebas cuándo se cumple una condición, cómo combinan las políticas de alertas varias condiciones y cómo sustituyen las políticas de alertas los puntos de datos que faltan. También se describe el número máximo de incidentes abiertos por política, el número de notificaciones por incidente y los motivos por los que se producen retrasos 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 el artículo Monitorizar los registros.
Periodos de alineación y ventanas de repetición de pruebas
Cloud Monitoring evalúa el periodo de alineación y la ventana de repetición de pruebas para determinar si se ha cumplido la condición de una política de alertas.
Periodo de alineación
Para que una política de alertas pueda monitorizar los datos de serie temporal, estos deben regularizarse de forma que la política de alertas tenga datos con intervalos regulares para evaluarlos. El proceso de regularización se denomina alineación.
La alineación consta de dos pasos:
Dividir la serie temporal en intervalos de tiempo regulares, lo que también se denomina "agrupar los datos en contenedores". El intervalo es el periodo de alineación.
Calcula un solo valor para los puntos del periodo de alineación. Tú eliges cómo se calcula ese punto único: puedes sumar todos los valores, calcular su media o usar el 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, si el periodo de alineación es de cinco minutos, a las 13:00, el periodo de alineación contiene las muestras recibidas entre las 12:55 y las 13:00. A las 13:01, el periodo de alineación se desplaza un minuto y contiene las muestras recibidas entre las 12:56 y las 13:01.
La monitorización configura un periodo de alineación de la siguiente manera:
Google Cloud consola
Para configurar el periodo de alineación, elija un valor para los siguientes campos en la página Condiciones de alerta:
- Ventana de tiempo: especifica el intervalo de tiempo que se va a evaluar.
- Función de ventana móvil: especifica la función matemática que se va a 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 de alineación alinean los datos y los convierten de un tipo o clase de métrica a otro. Para obtener una explicación detallada, consulta Clases, tipos y conversiones.
API
Para configurar el periodo de alineación, debe definir 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 de alineación alinean los datos y los convierten de un tipo o clase de métrica a otro. Para obtener una explicación detallada, consulta Clases, tipos y conversiones.
Para ilustrar el efecto del periodo de alineación en una condición de una política de alertas, vamos a analizar una condición de umbral de métrica que monitoriza una métrica con un periodo de muestreo de un minuto. Supongamos que el periodo de alineación es de cinco minutos y que el alineador está configurado como sum. Además, supongamos que la condición se cumple 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 periodo de repetición de la 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 única evaluación de la condición. Se muestran los datos de la serie temporal. Los puntos del periodo de alineación se muestran con puntos azules, mientras que los puntos más antiguos son negros. Cada fila muestra el valor alineado y si este valor es mayor que el umbral de dos. En la fila etiquetada como start, el valor alineado es uno, que es inferior al umbral.
En la siguiente evaluación, la suma de las muestras del periodo de alineación es dos.
En la tercera evaluación, la suma es tres y, como este valor es superior al umbral, se inicia un temporizador para la ventana de repetición de la prueba.
Ventanas de repetición de pruebas
La condición de una política de alertas tiene una ventana de repetición de pruebas, que evita que se cumpla la condición debido a una sola medición o previsión. Por ejemplo, supongamos que el periodo de repetición de una prueba de una condición es de 15 minutos. A continuación, se describe el comportamiento de la condición en función de su tipo:
- Las condiciones de umbral de métrica se cumplen cuando, en una sola serie temporal, todas las mediciones alineadas de un intervalo de 15 minutos superan el umbral.
- Las condiciones de ausencia de métricas se cumplen cuando no llegan datos de una serie temporal en un intervalo de 15 minutos.
- Las condiciones de previsión se cumplen cuando cada previsión generada durante un periodo de 15 minutos predice que la serie temporal superará el umbral en el periodo 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 cumple la condición. Estos incidentes permanecen abiertos mientras se siga cumpliendo la condición.
Google Cloud consola
Para configurar el periodo de repetición de la prueba, usa el campo Periodo de repetición de la prueba del paso Configurar activador de alerta.
API
Para configurar la ventana de repetición de la prueba, define el campo duration en las estructuras MetricThreshold y MetricAbsence.
En la figura anterior se muestran tres evaluaciones de una condición de umbral de métrica. En el momento start + 2 minutes, el valor alineado es superior al umbral, pero no se cumple la condición porque la ventana de repetición de la prueba es de tres minutos. En la siguiente figura se muestran los resultados de las siguientes evaluaciones de la condición:
Aunque el valor alineado es superior al umbral en el momento start + 2 minutes, la condición no se cumple hasta que el valor alineado es superior al umbral durante tres minutos. Ese evento se produce a las
start + 5 minutes.
Una condición restablece su ventana de repetición de pruebas cada vez que 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 periodo de repetición de pruebas de cinco minutos.
Si la latencia de respuesta HTTP es superior a dos segundos
y la latencia es superior al umbral durante cinco minutos,
abre un incidente y envía un correo a tu equipo de Asistencia.En la siguiente secuencia se ilustra cómo afecta la ventana de repetición de pruebas a la evaluación de la condición:
- La latencia HTTP es inferior a dos segundos.
- Durante los próximos tres minutos consecutivos, la latencia 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 la ventana de repetición de la prueba.
Durante los cinco minutos consecutivos siguientes, la latencia 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.
Define la ventana de repetición de pruebas de forma que sea lo suficientemente larga como para minimizar los falsos positivos, pero lo suficientemente corta como para verificar que los incidentes se abren a tiempo.
Prácticas recomendadas para definir el periodo de alineación y la ventana de repetición de la prueba
El periodo de alineación determina cuántas muestras se combinan con el alineador:
El valor mínimo del periodo de alineación de un tipo de métrica es el periodo de muestreo de ese tipo de métrica. Por ejemplo, si el tipo de métrica se muestrea cada 300 segundos, el periodo de alineación debe ser de al menos 300 segundos. Sin embargo, si quieres combinar 5 muestras, define el periodo de alineación en 5 * 300 segundos o 1500 segundos.
El valor máximo del periodo de alineación es de 24 horas menos el retraso de ingestión del tipo de métrica. Por ejemplo, si la latencia de ingestión de una métrica es de 6 horas, el valor máximo del periodo de alineación es de 18 horas.
Usa la ventana de repetición de pruebas para especificar la capacidad de respuesta de la alerta. Por ejemplo, si define una ventana de repetición de la prueba de 20 minutos para una condición de ausencia de métrica, no debe haber datos durante 20 minutos para que se cumpla la condición. Para que la política de alertas responda mejor, asigna un valor más pequeño a la ventana de repetición de pruebas. En las condiciones de umbral de métrica, para que la política de alertas responda lo más rápido posible, define la ventana de repetición de pruebas en cero. Un solo valor alineado hace que se cumplan estos tipos de condiciones.
Las condiciones de las políticas de alertas se evalúan con una frecuencia fija. Las opciones que elijas para el periodo de alineación y la ventana de repetición de la 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 Cloud Monitoring o tu política de alertas tiene varias condiciones, debes especificar cuándo se abre un incidente. Para configurar cómo se combinan varias condiciones, haz una de las siguientes acciones:
Google Cloud consola
Las opciones de combinador se configuran en el paso Activador de varias condiciones.
API
Las opciones de combinador se configuran con el campo combiner de la estructura AlertPolicy.
En esta tabla se indican los ajustes de la consola Google Cloud , el valor equivalente en la API de Cloud Monitoring y una descripción de cada ajuste:
| Valor deGoogle Cloud console Policy triggers |
Valor de combiner de la API de Cloud Monitoring |
Significado |
|---|---|---|
| Se cumple alguna condición | OR |
Se abre un incidente si algún recurso provoca que se cumpla alguna de las condiciones. |
| Se cumplen todas las condiciones , incluso para diferentes recursos de cada condición (opción predeterminada) |
AND |
Se abre un incidente por cada condición que se cumpla cuando se cumplan todas las condiciones, aunque un recurso diferente provoque que se cumplan esas condiciones. |
| Se cumplen todas las condiciones | AND_WITH_MATCHING_RESOURCE |
Se abre un incidente por cada condición que se cumpla cuando se cumplan todas las condiciones, solo si el mismo recurso hace que se cumpla cada condición. Este ajuste es la opción de combinación más estricta. |
En este contexto, el término cumplida significa que la configuración de la condición se evalúa como verdadera. 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 true, se cumple la condición.
Ejemplo
Imagina un Google Cloud proyecto que contiene dos instancias de VM, vm1 y vm2. Supongamos que creas una política de alertas con dos condiciones:
- La condición llamada
CPU usage is too highmonitoriza 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 llamada
Excessive utilizationmonitoriza el uso de la CPU de las instancias. Esta condición se cumple cuando la utilización de la CPU de cualquier instancia es superior al 60% durante 1 minuto.
Al principio, se supone que ambas condiciones se evalúan como falsas.
A continuación, supongamos que el uso de CPU de vm1 supera los 100 ms/s durante 1 minuto. Como el uso de la 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 alguna condición, se crea un incidente 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 en cada condición, no se crea ningún incidente. Para que se cumplan estas opciones de combinador, se deben cumplir ambas condiciones.
A continuación, supongamos que el uso de la CPU de vm1 sigue siendo superior a 100 ms/s y que la utilización de la CPU de vm2 supera el 60% durante 1 minuto. El resultado es que se cumplen ambas condiciones. A continuación, se describe lo que ocurre en función de cómo se combinen las condiciones:
Se cumple alguna condición: se crea un incidente cuando un recurso provoca que se cumpla una condición. En este ejemplo, vm2 hace que se cumpla la condición
Excessive utilization.Si vm2 provoca 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ónCPU usage is too high, son eventos distintos.Se cumplen todas las condiciones, incluso si se trata de recursos diferentes para cada condición: se crea un incidente porque se cumplen ambas condiciones.
Se cumplen todas las condiciones: no se crea ningún incidente porque este combinador requiere que el mismo recurso provoque que se cumplan todas las condiciones. En este ejemplo, no se crea ningún incidente porque vm1 provoca que se cumpla la condición
CPU usage is too high, mientras que vm2 provoca que se cumpla la condiciónExcessive utilization.
Datos de métricas parciales
Cuando los datos de serie temporal dejan de llegar o se retrasan, la monitorización los clasifica como faltantes. Si faltan datos, no se podrán cerrar los incidentes. Los retrasos en la llegada de datos de proveedores de servicios en la nube de terceros pueden ser de hasta 30 minutos, aunque lo más habitual es que sean de entre 5 y 15 minutos. Si se produce un retraso prolongado (superior al periodo de repetición de la prueba), las condiciones pueden pasar a un estado "desconocido". Cuando los datos llegan finalmente, es posible que Monitoring haya perdido parte del historial reciente de las condiciones. Es posible que, al inspeccionar los datos de la serie temporal más adelante, no se detecte este problema porque no hay pruebas de que se produzcan retrasos una vez que llegan los datos.
Google Cloud consola
Puede configurar cómo evalúa Monitoring una condición de umbral de métrica cuando dejan de llegar datos. Por ejemplo, cuando se abre un incidente y no se recibe una medición esperada, ¿quieres que la monitorización deje el incidente abierto o que lo cierre inmediatamente? Del mismo modo, si los datos dejan de llegar y no hay ningún incidente abierto, ¿quieres que se abra un incidente? Por último, ¿cuánto tiempo debe permanecer abierto un incidente después de que dejen de llegar datos?
Hay dos campos configurables que especifican cómo evalúa Monitoring las condiciones de umbral de métricas cuando dejan de llegar datos:
Para configurar cómo determina Monitoring el valor de sustitución de los datos que faltan, utilice el campo Evaluación de datos que faltan, que se define en el paso Activador de condición. Este campo se inhabilita cuando la ventana de repetición de la prueba se define como Sin repetición de la prueba.
El periodo de repetición es el campo llamado "duration" en la API de Cloud Monitoring.
Para configurar el tiempo que espera Monitoring antes de cerrar un incidente abierto después de que dejen de llegar datos, usa el campo Duración del cierre automático de incidentes. Puedes definir 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 del campo de datos que faltan:
| Google Cloud console Campo "Evaluación de datos que faltan" |
Resumen | Detalles |
|---|---|---|
| Faltan datos (vacío) | Los incidentes abiertos permanecen abiertos. No se abren incidentes nuevos. |
En el caso de las condiciones que se cumplen, estas se siguen cumpliendo cuando dejan de llegar datos. Si hay un incidente abierto para esta condición, permanecerá abierto. Cuando se abre un incidente y no llegan datos, el temporizador de cierre automático se inicia tras una demora de al menos 15 minutos. Si el temporizador caduca, la incidencia se cierra. En el caso de las condiciones que no se cumplen, estas seguirán sin cumplirse cuando dejen de llegar datos. |
| Los puntos de datos que faltan se tratan como valores que infringen la condición de la política | Los incidentes abiertos permanecen abiertos. Se pueden abrir incidentes nuevos. |
En el caso de las condiciones que se cumplen, estas se siguen cumpliendo cuando dejan de llegar datos. Si hay un incidente abierto para esta condición, permanecerá abierto. Cuando un incidente está abierto y no llegan datos durante el periodo de cierre automático más 24 horas, el incidente se cierra. En el caso de las condiciones que no se cumplen, esta configuración hace que la condición de umbral de métrica se comporte como un |
| Los puntos de datos que faltan se tratan como valores que no infringen la condición de la política | Los incidentes abiertos se cierran. No se abren incidentes nuevos. |
En el caso de las condiciones que se cumplen, dejan de cumplirse cuando dejan de llegar datos. Si hay una incidencia abierta para esta condición, se cierra. En el caso de las condiciones que no se cumplen, estas seguirán sin cumplirse cuando dejen de llegar datos. |
API
Puede configurar cómo evalúa Monitoring una condición de umbral de métrica cuando dejan de llegar datos. Por ejemplo, cuando se abre un incidente y no se recibe una medición esperada, ¿quieres que la monitorización deje el incidente abierto o que lo cierre inmediatamente? Del mismo modo, si los datos dejan de llegar y no hay ningún incidente abierto, ¿quieres que se abra un incidente? Por último, ¿cuánto tiempo debe permanecer abierto un incidente después de que dejen de llegar datos?
Hay dos campos configurables que especifican cómo evalúa Monitoring las condiciones de umbral de métricas cuando dejan de llegar datos:
Para configurar cómo determina Monitoring el valor de sustitución de los datos que faltan, usa el campo
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 dejen de llegar datos, use el campo
autoClosede la estructuraAlertStrategy.
A continuación, se describen las diferentes opciones del campo de datos que faltan:
| API Campo evaluationMissingData |
Resumen | Detalles |
|---|---|---|
EVALUATION_MISSING_DATA_UNSPECIFIED |
Los incidentes abiertos permanecen abiertos. No se abren incidentes nuevos. |
En el caso de las condiciones que se cumplen, estas se siguen cumpliendo cuando dejan de llegar datos. Si hay un incidente abierto para esta condición, permanecerá abierto. Cuando se abre un incidente y no llegan datos, el temporizador de cierre automático se inicia tras una demora de al menos 15 minutos. Si el temporizador caduca, la incidencia se cierra. En el caso de las condiciones que no se cumplen, estas seguirán sin cumplirse cuando dejen de llegar datos. |
EVALUATION_MISSING_DATA_ACTIVE |
Los incidentes abiertos permanecen abiertos. Se pueden abrir incidentes nuevos. |
En el caso de las condiciones que se cumplen, estas se siguen cumpliendo cuando dejan de llegar datos. Si hay un incidente abierto para esta condición, permanecerá abierto. Cuando un incidente está abierto y no llegan datos durante el periodo de cierre automático más 24 horas, el incidente se cierra. En el caso de las condiciones que no se cumplen, esta configuración hace que la condición de umbral de métrica se comporte como un |
EVALUATION_MISSING_DATA_INACTIVE |
Los incidentes abiertos se cierran. No se abren incidentes nuevos. |
En el caso de las condiciones que se cumplen, dejan de cumplirse cuando dejan de llegar datos. Si hay una incidencia abierta para esta condición, se cierra. En el caso de las condiciones que no se cumplen, estas seguirán sin cumplirse cuando dejen de llegar datos. |
Para minimizar los problemas debidos a la falta de datos, puede hacer lo siguiente:
- Ponte en contacto con tu proveedor de servicios en la nube externo para identificar formas de reducir la latencia de recogida de métricas.
- Usa ventanas de repetición de pruebas más largas en tus condiciones. Si usas una ventana de repetición de pruebas más larga, tus políticas de alertas serán menos sensibles.
Elige métricas que tengan un retraso de recogida menor:
- Métricas del agente de monitorización, sobre todo cuando el agente se ejecuta en instancias de máquina virtual de nubes de terceros.
- Métricas personalizadas, cuando escribes sus datos directamente en Monitoring.
- Métricas basadas en registros, si la recogida de entradas de registro no se retrasa.
Para obtener más información, consulta los artículos Información general sobre el agente de monitorización, Información general sobre las métricas definidas por el usuario y Métricas basadas en registros.
Cuándo envía notificaciones y crea incidentes Monitoring
Cloud Monitoring envía una notificación cuando una serie temporal provoca 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 ni 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 notificación específicos de tu política de alertas.
Puede que recibas varias notificaciones únicas relacionadas con una política de alertas cuando se cumpla alguna de las siguientes condiciones:
Una condición monitoriza 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, por cada serie temporal que dé como resultado que se cumpla una condición, la política de alertas envía una notificación y crea un incidente.
No puedes configurar Cloud Monitoring para que cree solo un incidente y envíe solo una notificación cuando la política de alertas contenga varias condiciones.
Se cumple alguna 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 Cloud Monitoring también te avisan cuando se cumple la condición y cuando deja de cumplirse. Las políticas de alertas creadas mediante la consola de Google Cloud no envían una notificación cuando se deja de cumplir la condición, a menos que hayas habilitado ese comportamiento.
Cuando Monitoring no envía notificaciones ni crea incidentes
En las siguientes situaciones, Monitoring no crea incidentes ni envía notificaciones cuando se cumplen las condiciones de una política de alertas:
- La política de alertas está inhabilitada.
- La política de alertas se ha pospuesto.
- La monitorización ha alcanzado el límite del número máximo de incidentes abiertos.
Políticas de alertas inhabilitadas
La monitorización no crea incidentes ni envía notificaciones de 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, la monitorización evalúa los valores de todas las condiciones durante el periodo de repetición de pruebas más reciente. La ventana de repetición de la prueba más reciente puede incluir datos obtenidos antes, durante y después de que se habilitara la política. Las condiciones de una política inhabilitada se pueden cumplir inmediatamente después de reanudar la política, incluso con ventanas de repetición de pruebas grandes.
Por ejemplo, supongamos que tienes una política de alertas que monitoriza un proceso específico y que la inhabilitas. 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 inmediatamente, Monitoring reconocerá que el proceso no ha estado activo durante los últimos cinco minutos y abrirá un incidente.
Los incidentes relacionados con una política de alertas inhabilitada permanecen abiertos hasta que caduca la duración de cierre automático de la política.
Políticas de alertas pospuestas
La monitorización no envía notificaciones ni crea incidentes para una política de alertas que esté en pausa. Te recomendamos que pospongas las políticas de alertas cuando quieras evitar que envíen notificaciones durante intervalos cortos. Por ejemplo, antes de realizar el mantenimiento de una máquina virtual (VM), puedes crear una suspensión y añadir a los criterios de suspensión las políticas de alertas que monitorizan la instancia.
Cuando aplazas una política de alertas, Monitoring cierra todos los incidentes abiertos relacionados con la política. La monitorización puede abrir nuevos incidentes una vez que finalice el periodo de aplazamiento. Para obtener más información, consulta Posponer notificaciones e incidentes.
Límites de notificaciones e incidentes abiertos
Una política de alertas se puede aplicar a muchos recursos, y un problema que afecte a todos los recursos puede provocar que la política de alertas abra incidentes para cada recurso. Se abre un incidente por cada serie temporal que cumpla una condición.
Para evitar sobrecargar el sistema, el número de incidencias que puede abrir una sola política simultáneamente está limitado a 1000.
Por ejemplo, supongamos que tienes una política que se aplica a 2000 instancias de Compute Engine y que cada instancia hace que se cumplan las condiciones de alerta. La monitorización limita el número de incidencias abiertas a 1000. Las condiciones restantes que se cumplan se ignorarán hasta que se cierren algunos de los incidentes abiertos de esa política.
Como resultado de este límite, un solo canal de notificaciones puede recibir hasta 1000 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 por separado.
Latencia
La latencia es el tiempo que transcurre desde que Monitoring toma una muestra de una métrica hasta que el punto de datos de la métrica se muestra como datos de serie temporal. La latencia afecta al momento en que se envían las notificaciones. Por ejemplo, si una métrica monitorizada tiene una latencia de hasta 180 segundos, Monitoring no creará un incidente 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 ajustes contribuyen a la latencia:
Retraso en la recogida de métricas: el tiempo que necesita Monitoring para recoger los valores de las métricas. En el caso de los valores de Google Cloud , la mayoría de las métricas no se muestran durante 60 segundos después de la recogida. Sin embargo, el retraso depende de la métrica. Los cálculos de las políticas de alertas tardan hasta 5 minutos y 30 segundos. En el caso de las métricas de AWS CloudWatch, el retraso de visibilidad puede ser de varios minutos. En el caso de las comprobaciones de tiempo de actividad, puede ser una media de dos minutos (desde el final del periodo de repetición de la prueba).
Ventana de repetición de la prueba: la ventana configurada para la condición. Las condiciones solo se cumplen cuando una condición es verdadera durante todo el periodo de repetición de la prueba. Por ejemplo, si se configura un periodo de repetición de cinco minutos, las notificaciones se retrasarán al menos cinco minutos desde que se produzca el evento.
Tiempo que tarda en llegar la notificación: los canales de notificación, como el correo electrónico y los SMS, pueden experimentar latencias de red u otras latencias (que no están relacionadas con el contenido que se envía), que a veces pueden ser de varios minutos. En algunos canales, como los SMS y Slack, no hay ninguna garantía de que los mensajes se entreguen.
Siguientes pasos
Para obtener información sobre cómo crear una política de alertas, consulta los siguientes documentos:
Para ver una variedad de políticas de alertas, consulta Políticas de ejemplo.