Introducción
Cuando monitorizamos una máquina virtual solemos empezar por lo evidente: CPU, memoria, disco, disponibilidad… Sin embargo, monitorizar servicios Windows es igual de importante para garantizar que las aplicaciones y los servicios críticos de nuestra infraestructura funcionan correctamente. Una máquina encendida no significa necesariamente que el servicio que presta esté disponible
¿La aplicación o el servicio que realmente necesitamos está funcionando?
Una máquina puede estar encendida, responder perfectamente y mostrar unas métricas estupendas mientras uno de sus servicios críticos lleva diez minutos detenido. Desde el punto de vista de infraestructura, la máquina está UP; desde el punto de vista del usuario, probablemente esté Caída.
Algunos ejemplos bastantes habituales:
- Un servidor de impresión con Print Spooler detenido.
- Un servidor web con World Wide Web Publishing Service (W3SVC) parado.
- Un servidor SQL con SQL Server detenido.
- Un servidor con un agente corporativo o una aplicación propia ejecutándose como servicio de Windows.
Por eso, en este artículo vamos a ver cómo monitorizar servicios Windows con Azure Monitor, detectando cuándo un servicio crítico se detiene y generando una alerta para que podamos actuar antes de que sean los usuarios quienes nos avisen.
Para ello utilizaremos Azure Monitor Agent (AMA), Data Collection Rules, Log Analytics, KQL y Azure Monitor Alerts, montando paso a paso un pequeño laboratorio que podremos aplicar tanto a máquinas virtuales de Azure como a servidores híbridos incorporados mediante Azure Arc.
Y no nos quedaremos únicamente en detectar la caída: veremos también cómo hacer que Azure Monitor identifique cuándo el servicio vuelve a estar operativo y resuelva automáticamente la alerta.
¿Qué vamos a construir?
La arquitectura del laboratorio será bastante sencilla.
En el caso de una máquina virtual de Azure:
Para un servidor ubicado fuera de Azure:
La ubicación de la máquina deja así de ser lo importante.
Puede tratarse de una VM de Azure, un servidor de nuestro datacenter o incluso una máquina ejecutándose en otra nube. Una vez incorporado al modelo de monitorización, podremos centralizar sus eventos y aplicar sobre ellos las mismas consultas y reglas de alerta.
Para simplificar el laboratorio utilizaremos un servicio que prácticamente todos tenemos disponible en Windows: Print Spooler.
Después veremos cómo aplicar exactamente el mismo mecanismo a nuestros servicios realmente críticos.
¿Cómo sabe Windows que un servicio se ha detenido?
Aquí está una de las claves del laboratorio.
Windows registra los cambios de estado de sus servicios en el registro de eventos System.
Cuando un servicio cambia de estado, Service Control Manager genera diferentes eventos que podemos utilizar para conocer qué ha sucedido.
Para nuestro caso nos interesan especialmente los eventos: Event ID 7031,7034 y 7036:
7031→ servicio terminó inesperadamente.7034→ servicio terminó inesperadamente.7036→ servicio cambió de estado, por ejemplorunning → stopped.
En cuanto al evento 7036, indica que un servicio ha cambiado de estado.
Por ejemplo, cuando detenemos Print Spooler encontraremos un evento equivalente a:
The Print Spooler service entered the stopped state
Y cuando volvemos a iniciarlo:
The Print Spooler service entered the running state
Esto nos proporciona justamente las dos piezas de información que necesitamos: qué servicio ha cambiado de estado y cuál es su nuevo estado.
Nuestro trabajo consistirá en llevar estos eventos hasta Log Analytics y utilizar KQL para determinar cuál es el último estado conocido del servicio en cada máquina. Y este último detalle es importante, puesto que a la pregunta que queremos responde es: ¿Ha existido algún evento indicando que Spooler se ha detenido?
Requisitos previos
Para reproducir el laboratorio necesitaremos:
- Una suscripción de Azure.
- Un Log Analytics Workspace.
- Una máquina Windows que podamos utilizar para las pruebas.
- Azure Monitor Agent instalado en la máquina.
- Una Data Collection Rule (DCR) que envíe los eventos necesarios a Log Analytics.
- Si utilizamos un servidor externo a Azure, tendremos que incorporarlo previamente mediante Azure Arc.
No necesitamos montar una plataforma de monitorización enorme. La idea es empezar con algo pequeño y entender bien cada una de las piezas.
Recopilando los eventos de Windows
El primer paso será conseguir que los eventos generados por Service Control Manager lleguen a nuestro Log Analytics Workspace.
Para ello utilizaremos Azure Monitor Agent junto con una Data Collection Rule.
La DCR será la encargada de definir qué información queremos recopilar de nuestras máquinas y a qué destino queremos enviarla.
En nuestro caso necesitamos recopilar eventos del registro: System
y concretamente y en cuanto a los eventos que mencionábamos en el apartado anterior, solo necesitaríamos la siguiente expresión:
System!*[System[Provider[@Name=’Service Control Manager’] and (EventID=7031 or EventID=7034 or EventID=7036)]]
Una vez configurada la recopilación y asociados nuestros servidores a la DCR, podremos comprobar que los eventos están llegando al workspace:
Averiguando el estado actual del servicio con KQL
Para nuestro laboratorio vamos a monitorizar Print Spooler. Por tanto, podemos localizar sus eventos con:
Event
| where Source == "Service Control Manager"
| where EventID == 7036
| where RenderedDescription has "Print Spooler"
Esta consulta es correcta para listar los eventos relacionados con el servicio de impresión, pero no la podemos usar todavía para nuestra alerta, puesto que si detenemos dicho servicio y posteriormente lo iniciamos, tendremos ambos eventos almacenados:
Print Spooler → stopped
Print Spooler → runningNosotros realmente lo que necesitamos es saber cuál ha sido el último estado conocido del servicio para cada servidor y concretamente si ese estado es precisamente el de stopped:
Event
| where Source == "Service Control Manager"
| where EventID == 7036
| where RenderedDescription has "Print Spooler"
| extend ServiceState = case(
RenderedDescription has "stopped", "stopped",
RenderedDescription has "running", "running",
"other"
)
| where ServiceState in ("running", "stopped")
| summarize arg_max(TimeGenerated, ServiceState) by Computer
| where ServiceState == "stopped"Vamos a detenernos un momento aquí, porque esta consulta es realmente el corazón de nuestro laboratorio y tiene algo de «miga».
Primero buscamos únicamente los eventos generados por Service Control Manager con ID 7036. Después filtramos los correspondientes a Print Spooler. Con extend convertimos el texto del evento en algo mucho más fácil de manejar:
running
stoppedY finalmente utilizamos:
summarize arg_max(TimeGenerated, ServiceState) by Computerpara quedarnos con el último estado registrado en cada máquina. La última línea hace el resto:
| where ServiceState == "stopped"Sólo queremos saber si el servicio, en su último estado, se ha parado.
El comportamiento final es muy sencillo:
- Spooler funcionando -> 0 resultados
- Spooler detenido -> aparece la máquina afectada
Esto es exactamente lo que necesitamos para construir nuestra alerta.
Creando la alerta en Azure Monitor
Con la consulta funcionando podemos convertirla en una regla de alerta del espacio de trabajo de log analytics. La lógica será: si la consulta devuelve una o más filas, tenemos al menos una máquina cuyo último estado conocido para Print Spooler es «Stopped».
Por tanto, podemos utilizar como medida el número de filas devueltas y configurar la condición:
También tendremos que establecer la frecuencia de evaluación. Por ejemplo, Azure Monitor puede ejecutar nuestra consulta cada cinco minutos y comprobar si existe alguna máquina que cumpla la condición. Si la consulta devuelve 0, entonces todo está correcto. Sin embargo, si la consulta devuelve 1 tenemos una máquina afectada.+
Stateful: queremos conocer también cuándo se recupera
Existe otro detalle importante de Azure Monitor que merece la pena entender. No queremos recibir únicamente una notificación cuando el servicio se detiene. También queremos que Azure Monitor conozca el estado de la incidencia. Para esto existe el concepto de una alerta stateful.
El flujo sería:
Y ojo que aquí podemos encontrarnos con algo curioso durante las pruebas. Arrancamos nuevamente el servicio, ejecutamos nuestra consulta manualmente, obtenemos cero resultados… pero la alerta continúa apareciendo como activa durante unos minutos. Esto no significa que nuestra consulta esté mal lo que ocurre es que Azure Monitor evalúa periódicamente la condición y, en las alertas stateful, necesita confirmar que la condición que provocó la alerta ha dejado de cumplirse antes de resolverla. Esto evita que un servicio que esté entrando y saliendo continuamente de un estado de error genere un carrusel de alertas abiertas y cerradas.
Azure Monitor utiliza estos criterios de resolución automática:
| Frecuencia de evaluación | Condición para resolver |
| 1-15 minutos | 3 evaluaciones consecutivas sin incumplimiento |
| 30 minutos | 2 evaluaciones consecutivas sin incumplimiento |
| 1 hora o más | 1 evaluación sin incumplimiento |
Por tanto, para nuestro laboratorio, con una frecuencia de 5 minutos, la alerta stateful se resolverá después de tres evaluaciones consecutivas en las que la consulta no detecte el servicio detenido. Es decir, aproximadamente 10–15 minutos desde la recuperación, dependiendo del momento en que se produzca respecto al ciclo de evaluación.
Action Groups: alguien tiene que enterarse
Detectar el problema está muy bien. Que nadie se entere hasta el día siguiente, bastante menos. Para eso utilizaremos un Action Group.
Podemos asociar a nuestra regla diferentes mecanismos de notificación o automatización. Para el laboratorio podemos empezar simplemente con correo electrónico. Cuando Azure Monitor detecte que nuestra consulta supera el umbral definido, ejecutará el Action Group y recibiremos la correspondiente notificación. En un entorno real podríamos llevarlo bastante más lejos e integrar la alerta con otros mecanismos de respuesta operativa.
Probando nuestro laboratorio
Ya tenemos todas las piezas. Ahora toca romper algo a propósito. Desde nuestra máquina Windows podemos detener Print Spooler:
Windows generará el evento correspondiente. Azure Monitor Agent lo enviará a Log Analytics.
Nuestra consulta empezará a devolver la máquina afectada. Azure Monitor evaluará la condición y la alerta pasará a estado Fired:
Finalmente, nuestro Action Group enviará la notificación configurada:
Ahora volvemos a recuperar el servicio:
Se generará un nuevo evento 7036 indicando que el servicio ha pasado a running. En la siguiente ejecución de nuestra consulta, arg_max() seleccionará este nuevo evento como último estado conocido y la máquina dejará de aparecer entre los resultados.
Tras las evaluaciones necesarias, Azure Monitor considerará recuperada la condición y la alerta pasará a Resolved.
Y laboratorio completado.
De laboratorio a producción
Lo interesante empieza cuando sustituimos Print Spooler por algo que realmente nos importe. Podríamos aplicar el mismo mecanismo a servicios como:
W3SVC
MSSQLSERVER
frxsvco a cualquier servicio propio de nuestra organización.
Incluso podemos evolucionar la consulta para monitorizar varios servicios críticos simultáneamente, identificar qué servicio está detenido y en qué máquina, y utilizar esa información dentro de nuestras alertas. Esto nos permite empezar a construir una monitorización basada no solamente en la salud de la infraestructura, sino también en la salud del servicio que esa infraestructura proporciona. Esa diferencia es importante porque una VM con CPU al 10 %, memoria disponible y disco funcionando puede aparecer completamente saludable en nuestro dashboard, pero si el servicio que utilizan nuestors usuarios está detenido… tenemos una máquina sana prestando un servicio caído.
¿Y si el servidor no está en Azure?
Aquí es donde Azure Arc hace especialmente interesante este escenario. Una vez incorporamos un servidor Windows externo a Azure y desplegamos Azure Monitor Agent, podemos aplicar el mismo modelo de recopilación mediante DCR y centralizar sus eventos en Log Analytics. Eso significa que podemos utilizar una misma estrategia para monitorizar: VMs de Azure + servidores on-premises + servidores alojados en otras nubes.
No necesitamos construir un sistema de alertas completamente diferente dependiendo de dónde viva cada servidor. Para Azure Monitor, lo importante acaba siendo disponer de los datos necesarios para evaluar la condición.
Resumen
Monitorizar CPU, memoria, disco y disponibilidad sigue siendo necesario, pero no siempre nos dice si aquello que realmente utilizan nuestros usuarios está funcionando.
Los eventos de Service Control Manager, combinados con Azure Monitor Agent, Data Collection Rules, Log Analytics, KQL y Azure Monitor Alerts, nos permiten añadir una capa bastante sencilla de monitorización sobre los servicios críticos de nuestros servidores, además, en tiempo real. Y podemos hacerlo tanto para máquinas virtuales de Azure como para servidores híbridos incorporados mediante Azure Arc.
En nuestro laboratorio hemos utilizado Print Spooler, pero el patrón es exactamente el mismo para cualquier otro servicio:
Queremos enterarnos de que un servicio estaba detenido antes de que un usuario abra un ticket. Para ello, una buena estrategia de monitorización debería de habérnoslo contado antes.
Bibliografía
Bibliografía – Microsoft Learn
- Introducción a Azure Monitor
- Información general de Azure Monitor Agent
- Reglas de recopilación de datos (DCR)
- Recopilación de eventos de Windows
- Servidores habilitados para Azure Arc
- Consultas de registro en Azure Monitor
- Crear una regla de alerta de búsqueda de registros
- Información general de las alertas de Azure Monitor
- Grupos de acciones de Azure Monitor
Deja una respuesta
Lo siento, debes estar conectado para publicar un comentario.