En este documento se describen los aplazamientos, que te permiten evitar que Cloud Monitoring cree incidentes y envíe notificaciones durante periodos específicos. Puedes crear y gestionar tus aplazamientos mediante la Google Cloud consola, la CLI de Google Cloud y la API de Cloud Monitoring.
Cuándo posponer políticas de alertas
Crea un periodo de inactividad cuando quieras evitar temporalmente que se creen incidentes y que se envíen notificaciones, o para evitar que se envíen notificaciones repetidas de un incidente abierto. Por ejemplo, puedes crear una alarma para dormir en las siguientes situaciones:
- Tienes un mantenimiento programado.
- Tienes una interrupción que va en aumento y quieres evitar que se produzcan más incidentes y notificaciones.
Cómo funcionan las alarmas pospuestas
Cuando está activa la suspensión de una política de alertas, Monitoring no envía notificaciones ni crea incidentes para la política de alertas suspendida. Cuando apliques una suspensión a una política de alertas basada en métricas o en SQL, Monitoring también cerrará todos los incidentes relacionados con la política de alertas.
Para crear una repetición, puedes hacer lo siguiente:
Para aplicar el aplazamiento a varias políticas de alertas, créalo en la página Alertas, en la CLI de gcloud o en la API Cloud Monitoring. También puedes elegir cuándo empieza la repetición y definir su duración.
Aplicar la suspensión a varias políticas de alertas puede ser útil cuando tienes previsto realizar tareas de mantenimiento y necesitas que la suspensión empiece a una hora concreta y dure un periodo determinado.
Para posponer un incidente concreto, crea la posposición desde la página Detalles del incidente de un incidente abierto. En este caso, todos los campos de la opción de posponer están preconfigurados, excepto la duración.
Aplicar la suspensión de una incidencia específica puede ser útil cuando tienes una interrupción que va en aumento y necesitas suspender inmediatamente una política de alertas hasta que se resuelvan los problemas relacionados.
Componentes de las posposiciones
Una posposición tiene los siguientes componentes:
Un nombre. Te recomendamos que uses este campo para describir el propósito de la suspensión.
Periodo que determina cuándo está activa la repetición. Se especifica mediante una hora de inicio y una duración. Una suspensión activa impide que la monitorización cree incidentes y emita notificaciones de las políticas de alertas que coincidan con los criterios de la suspensión. Fuera del periodo activo, la opción de posponer está inactiva. Una repetición inactiva no afecta al momento en que se crean los incidentes ni en que se envían las notificaciones.
Criterios para la posposición, que incluyen lo siguiente:
Lista de políticas de alertas a las que se aplica la opción de posponer.
Filtro opcional basado en etiquetas que se puede usar cuando la suspensión se aplica a una sola política de alertas. Define las etiquetas del filtro para aplazar las incidencias que coincidan con ellas. Por ejemplo, supongamos que un filtro incluye una etiqueta para un ID de instancia de máquina virtual específico y que la opción de posponer está activa. La política de alertas puede seguir creando incidentes para todas las máquinas virtuales, excepto para la que se indica en el filtro.
Un filtro basado en etiquetas puede incluir etiquetas de recursos y métricas. Si la política de alertas no se basa en PromQL, el filtro también puede incluir etiquetas de metadatos.
Cómo afectan las posposiciones a las condiciones de las políticas de alertas
En la siguiente tabla se describe la relación entre el estado de una condición de una política de alertas de una sola condición y el momento en el que se crean incidentes y se envían notificaciones:
| Estado | Acción |
|---|---|
| Condición no cumplida | Comportamiento actual Cuando un incidente esté abierto, ciérralo y envía notificaciones de cierre del incidente. |
| Se cumple la condición y La política no está asociada a una suspensión activa |
Comportamiento actual Si no existe ningún incidente, crea uno y envía notificaciones. |
| Condición cumplida y La política está asociada a una alarma pospuesta activa |
|
Cuando se aplica una suspensión a una política de alertas que contiene varias condiciones, primero se aplican las reglas para combinar las condiciones. A continuación, se aplican las reglas asociadas a las posposiciones.
Diferencias entre crear una suspensión y inhabilitar una política
Para evitar que se envíen notificaciones de una colección de políticas de alertas durante un breve periodo, puedes inhabilitar manualmente cada política de alertas o crear una alerta pospuesta:
Si decides inhabilitar manualmente las políticas de alertas, debes recordar habilitar manualmente cada política de alertas inhabilitada al final del intervalo. Además, solo puedes programar estas acciones si usas la API Cloud Monitoring y configuras algo para que emita la llamada a la API a una hora específica.
Si creas una suspensión, puedes programar el periodo activo y la suspensión se puede aplicar a varias políticas de alertas. Cuando la posposición está inactiva o cuando finaliza una posposición activa, las políticas de alerta asociadas a la posposición se comportan con normalidad. Es decir, estas políticas de alertas pueden crear incidentes y enviar notificaciones.
Si tienes ventanas de mantenimiento periódicas, puedes habilitar y deshabilitar manualmente las políticas de alertas que no deban enviar notificaciones en cada ventana. Sin embargo, si creas una suspensión para una ventana de mantenimiento, puedes copiarla y actualizar la hora de inicio y la duración de la copia. Es decir, si creas una suspensión y la copias, puedes programar una serie de suspensiones para la misma colección de políticas de alertas.
Para ver un registro de cuándo se habilitan o inhabilitan las políticas de alertas, debes consultar los registros de auditoría del proyecto Google Cloud . Sin embargo, cuando creas una posposición, esta se añade al registro histórico de posposiciones de tu proyecto Google Cloud . Puedes ver el historial, que muestra las alarmas pospuestas anteriores, activas y futuras, en la Google Cloud consola.
Restricciones
La duración de una repetición debe ser un intervalo único que sea un múltiplo de minutos.
Solo se pueden posponer 16 políticas de alertas.
Los criterios de una posposición no se pueden modificar.
Cuando apliques una suspensión a una política de alertas con una condición basada en PromQL, no podrás usar etiquetas de metadatos en el filtro.