Acerca de las cookies de este sitio Nuestros sitios web necesitan algunas cookies para funcionar correctamente (necesarias). Además, se pueden utilizar otras cookies con su consentimiento para analizar el uso del sitio, para mejorar la experiencia del usuario y para publicidad. Para obtener más información, consulte sus opciones de. Al visitar nuestro sitio web, acepta que procesemos la información tal y como se describe en ladeclaración de privacidad de IBM. Para facilitar la navegación, sus preferencias de cookies se compartirán entre los dominios web de IBM que se muestran aquí.
Trabajar con alertas y sucesos
En el servicio IBM Cloud Monitoring, puede configurar alertas individuales y alertas multicondición para notificar los problemas que pueden requerir atención. Cuando se desencadena una alerta, se le puede notificar mediante de 1 o más canales de notificación. Una definición de alerta puede generar notificaciones multicanal.
Una alerta es un suceso de notificación que puede utilizar para advertir acerca de situaciones que requieren atención. Cada alerta tiene un estado de gravedad. Este estado le informa acerca de la importancia de la información que notifica.
Cuando defina una alerta, debe definir la condición que desencadena la notificación y uno o varios canales de notificación a través de los cuales desea que se le notifique. También debe definir la gravedad de la alerta y el tipo de alerta. Para obtener más información sobre cómo configurar una alerta, consulte Configuración de una alerta.
De forma predeterminada, la gravedad se establece en warning. Puede establecer los siguientes valores para la gravedad de una alerta: emergency, alert, critical, error, warning, notice, informational, debug*
Puede definir una alerta en una sola métrica o en un conjunto de métricas para notificar los sucesos o los problemas que desea supervisar.
- Puede definir una alerta de condición única.
- Puede definir una alerta multicondición. El umbral de alerta se configura utilizando condiciones complejas.
- Puede definir cómo se agregan los datos.
- Puede utilizar la lógica booleana para definir alertas que informan sobre varias métricas.
- Obtendrá una notificación cuando se cumpla la condición de alerta.
- Puede configurar varios canales de notificación por alerta.
- Las alertas se ejecutan en 1 minuto o menos desde la recepción, con la opción de configurar el tiempo de espera de activación por horas o por días.
- Opcionalmente, solo para las alertas de PromQL, puede configurar un tiempo de espera de 0 minutos.
Puede habilitar alertas predefinidas, modificar alertas y crear alertas personalizadas en la interfaz de usuario web y mediante la API de IBM Cloud Monitoring.
Las alertas se gestionan en la vista Alertas de la interfaz de usuario web. Puede configurar las columnas de la tabla que se mostrarán en la vista Alertas. Las opciones de columna válidas son Nombre, Ámbito, Alerta cuándo, Segmentar por, Notificaciones, Activado, Modificado, Capturas, Canales, Creado, Descripción, Destinatarios de correo electrónico, Para al menos, OpsGenie, PagerDuty, Gravedad, Slack, WebHook, Tipo y VictorOps.
Tipos de alertas
El servicio IBM Cloud Monitoring incluye alertas predefinidas que puede habilitar. Además, puede configurar alertas personalizadas desde paneles en un panel de control, utilizando la API REST o en la sección Alertas de la interfaz de usuario web.
En el servicio IBM Cloud Monitoring, puede definir cualquiera de los siguientes tipos de alertas:
-
Tiempo de inactividad: utilice este tipo de alerta para supervisar los orígenes y las alertas cuando estén inactivos, por ejemplo, un nativo.
-
Métrica: utilice este tipo de alerta para supervisar métricas y alertas de series temporales cuando alcancen los umbrales definidos.
-
PromQL: utilice este tipo de métrica para supervisar las métricas utilizando una consulta PromQL.
-
Suceso: Utilice este tipo de alerta para supervisar las apariciones de sucesos y alertas específicos cuando alcancen los umbrales definidos. Por ejemplo, puede utilizar esta alerta para supervisar cuándo se notifican varias solicitudes de acceso sin autorización.
-
Detección de anomalías: utilice este tipo de alerta para supervisar hosts basados en comportamientos históricos y alertas cuando se desvíen del patrón esperado.
Este tipo de alerta está obsoleto. Sólo puede gestionar alertas existentes de este tipo.
-
Valor atípico de grupo: utilice este tipo de alerta para supervisar hosts y que se le notifique cuando 1 actúa de forma distinta al resto.
Este tipo de alerta está obsoleto. Sólo puede gestionar alertas existentes de este tipo.
Canales de notificación
Un canal de notificación define dónde desea recibir información cuando se desencadena una alerta.
Cuando configura una alerta, puede especificar 1 o más canales de notificación.
De forma predeterminada, cuando se desencadena una alerta, obtiene una notificación en la sección Sucesos.
Puede configurar cualquiera de los canales de notificación siguientes:
- Correo electrónico
- IBM Event Notifications
- Microsoft Teams
- OpsGenie
- PagerDuty
- Slack
- Correo electrónico de equipos
- VictorOps
- WebHook
Sucesos
Un suceso es una notificación que informa sobre algo que ocurre en cualquiera de los nodos que reenvían datos a la instancia de Monitoring. Utilice sucesos para revisar, realizar el seguimiento y resolver problemas.
La lista siguiente muestra distintos tipos de sucesos:
- Los sucesos de alerta son sucesos que se desencadenan mediante alertas configuradas por el usuario.
- Los sucesos basados en infraestructura son sucesos que se recopilan de los nodos Docker y Kubernetes. De forma predeterminada, el agente de supervisión descubre y recopila automáticamente datos de un grupo de sucesos seleccionado. Puede editar el archivo de configuración del agente para habilitar más sucesos.
- Sucesos personalizados que se configuran a través de cualquiera de las siguientes integraciones: Slackbot, scripts Python previamente creados, scripts Python personalizados creados por el usuario o solicitudes cURL.
De forma predeterminada, un suceso tiene un estado:
- Activo: este estado indica que las circunstancias que han desencadenado el suceso siguen en vigor; por ejemplo, un sigue estando inactivo.
- Correcto: este estado indica que la situación ha vuelto a la normalidad; por ejemplo, un nodo está activo y en ejecución.
Los sucesos se gestionan en la sección Sucesos de la interfaz de usuario web.
- Puede ver los sucesos de alerta a través del separador Sucesos de alerta.
- Puede ver los sucesos basados en infraestructura a través del separador Sucesos personalizados.
- Puede ver los sucesos personalizados a través del separador Sucesos personalizados.
- Puede enviar sucesos personalizados a cualquiera de sus equipos mediante la señal de API correspondiente a dicho equipo. Para obtener más información, consulte Sucesos personalizados).
- Puede establecer el suceso como resuelto (Resolved) para notificar a otros usuarios que el problema se ha resuelto en lugar de esperar a que el estado se establezca en OK.