Sugerencia
El modo guiado de condición NRQL ofrece una experiencia curada para crear condiciones NRQL de infraestructura "que no informa el host" (HNR). Esta es la alternativa preferida para crear condiciones de "sin reportes de host" en la infraestructura.
Utilice la condición Host not reporting del monitoreo de infraestructura para notificarle cuando dejemos de recibir datos de un agente de infraestructura. Esta característica le permite alertar dinámicamente sobre grupos de hosts, configurar la ventana de tiempo de cinco a 60 minutos y aprovechar al máximo la notificación .
Característica
Puede definir condiciones basadas en los conjuntos de hosts más importantes para usted y configurar el umbral apropiado para cada conjunto de hosts filtrado. El evento Host not reporting se activa cuando los datos del agente de infraestructura no llegan a nuestro recolector dentro del plazo que usted especifica.
Advertencia
Si ha filtrado su condición Host Not Reporting usando etiqueta o etiquetas y luego elimina una etiqueta o etiqueta crítica de un host objetivo, el sistema abrirá un incidente Host Not Reporting, ya que caracterizará a ese host como si hubiera perdido su conexión.
La flexibilidad de esta característica le permite personalizar fácilmente qué monitor y cuándo notificar a personas o equipos seleccionados. Además, la notificación por correo electrónico incluye enlaces para ayudarle a solucionar rápidamente la situación.
Host not reporting condition | Features |
|---|---|
Que monitor | Puede utilizar la barra de filtro de entidad para seleccionar qué hosts desea monitorear con la condición de alerta. La condición también se aplicará automáticamente a cualquier host que agregue en el futuro y que coincida con estos filtros. |
Como notificar | Las condiciones están contenidas en las pólizas. Puede seleccionar una política existente o crear una nueva política con notificación por correo electrónico desde la UI de monitoreo de infraestructura. Si desea crear una nueva política con otros tipos de canal de notificación, utilice la UI. |
Cuando notificar | Las direcciones de correo electrónico (identificadas en la política) recibirán una notificación automática sobre el incidente umbral para cualquier host que coincida con los filtros que haya aplicado, según las preferencias de incidentes de la política. |
Dónde solucionar problemas | El enlace en la parte superior de la notificación por correo electrónico lo llevará a la página de infraestructura Events centrada en el momento en que el host se desconectó. Los enlaces adicionales en el correo electrónico lo llevarán a detalles adicionales. |
Crear una condición de "host no informa"
Para definir los criterios de condición Host not reporting :
- Crear una condición de infraestructura.
- Para Alert type, seleccione Host not reporting.
- Define el umbral Critical para activar una notificación: entre 5 y 60 minutos de inactividad del host.
- (Opcional) Habilite la opción Don't trigger alerts for hosts that perform a clean shutdown para evitar alertas falsas cuando los hosts se apagan intencionalmente a través de la línea de comando. Esta opción actualmente es compatible con Windows y sistemas Linux basados en systemd.
Sugerencia
Para evitar incidentes falsos "Host not reporting" en hosts apagados intencionalmente, considere estas estrategias:
- Etiqueta del host: agrega la etiqueta
hostStatus: shutdownotermination: expecteda la entidad del host. Obtenga más información sobre etiqueta. - Etiqueta el host y habilita la configuración Don't trigger alerts : agrega la etiqueta
hostStatus: shutdowna tu host junto con la marcación de la opción mencionada anteriormente. Esto evitará que todos Host not reporting incidentes se abran para ese host, siempre que esa etiqueta esté en él, independientemente de la versión del agente o del sistema operativo. Si quita la etiqueta, New Relic comenzará a abrir Host not reporting incidente.
Dependiendo de las preferencias de incidente de la política, definirá qué canal de notificación usar cuando pase el umbral Critical definido para la condición. Para evitar el "falso positivo", el anfitrión debe dejar de informar durante todo el período de tiempo antes de que se abra un incidente.
Example: Crea una condición para abrir un incidente cuando cualquiera de los hosts filtrados deja de informar datos durante seven minutos.
- Si algún host deja de informar durante cinco minutos y luego los reanuda, la condición does not abre un incidente.
- Si algún host deja de informar durante siete minutos, incluso si los demás están bien, la condición does abre un incidente.
Investigar el problema
Para investigar más a fondo por qué un host no informa datos:
- Revise los detalles en la notificación por correo electrónico.
- Utilice el enlace de la notificación por correo electrónico para monitor los cambios continuos en su entorno desde la páginaEvents en nuestra UI de infraestructura. Por ejemplo, utilice la página Events para ayudar a determinar si un host se desconectó justo después de que un usuario raíz realizó un cambio de configuración en el host.
- Opcional: utilice el enlaceAcknowledge de la notificación por correo electrónico para verificar que conoce el incidente de alerta y se hace cargo del mismo.
- Utilice los enlaces de correo electrónico para examinar detalles adicionales en la páginaIncident details .
Cortes intencionales
Podemos distinguir entre situaciones inesperadas y situaciones planificadas con la opción Don't trigger alerts for hosts that perform a clean shutdown. Utilice esta opción para situaciones como:
- El anfitrión se ha desconectado intencionalmente.
- El anfitrión ha planificado un tiempo de inactividad por mantenimiento.
- El host ha sido cerrado o dado de baja.
- Escalado automático de hosts o cierre de instancias en una consola en la nube.
Dependemos de las señales de apagado de Linux y Windows para marcar un apagado limpio.
Hemos confirmado que el agente detecta estos escenarios:
- Evento de escalado automático AWS con instancias EC2 que usan systemd (Amazon Linux, CentOs/RedHat 7 y posteriores, Ubuntu 16 y posteriores, Suse 12 y posteriores, Debian 9 y posteriores)
- Apagado de sistemas Windows iniciado por el usuario
- Apagado iniciado por el usuario de sistemas Linux que usan systemd (Amazon Linux, CentOs/RedHat 7 y posteriores, Ubuntu 16 y posteriores, Suse 12 y posteriores, Debian 9 y posteriores)
Sabemos que el agente no detecta estos escenarios:
- Apagado iniciado por el usuario de sistemas Linux que no usan systemd (CentOs/RedHat 6 y anteriores, Ubuntu 14, Debian 8). Esto incluye otros sistemas Linux modernos que todavía usan sistemas de inicio Upstart o SysV.
- Evento de escalado automático AWS con instancias EC2 que no usan systemd (CentOs/RedHat 6 y anteriores, Ubuntu 14, Debian 8). Esto incluye otros sistemas Linux más modernos que todavía usan sistemas de inicio Upstart o SysV.