Monitorizar los Servicios 2

Monitorizar la fiabilidad de los servicios

Monitorizar la fiabilidad de los servicios nos ayudará en su seguimiento y en la medición del tiempo medio existente entre fallos. Este tiempo medio nos indica el tiempo de espera desde que falla un servicio hasta que vuelve a estar operativo. Conociéndolo, tal vez seamos capaces de impedir que ocurran problemas antes de producirse.  Por ejemplo, si sabemos que un servicio falla cada 10 días, más que esperar a que falle (momento que podría ser inconveniente para los usuarios) podemos programarlo para que se detenga y reinicie periódicamente; además podemos seguirlo para ver si la solución nos sirve (a veces hay que echar mano de lo que sea).

Este seguimiento también nos puede indicar el tiempo que tarda un servicio en recuperarse del fallo.

Los métodos para seguir la fiabilidad:

  • Suscripción a sucesos. Podemos crear una suscripción a un suceso que notifique cada x tiempo si un servicio cambia de estado. Si además guarda la información en una BD o archivo que podamos contrastar, podremos realizar un cálculo del tiempo medio entre los fallos y el tiempo necesario para restaurar su funcionalidad completamente.
  • Registro de sucesos (Event Log). En Windows Server 203 los cambios en el estado de un servicio se guardan en el Registro del Sistema (System Log visible con el Event viewer). Extrayendo periódicamente estos eventos, también podemos calcular la fiabilidad de nuestros servicios.

Si lo hacemos mediante script podemos usar: Shell script (EventQuery.vbs (es), EventTriggers.exe(es), WMI (Colecciones Win32_Service y Win32_NTLogEvent).

 

  • Usando una suscripción de sucesos temporal o permanente.
  • Usando el registro de sucesos.

Monitorizar los cambios en el estado de un servicio con una suscripción de suceso temporal

   1: 'Este script sirve para comprobar cambios de estado de los servicios
   2: ' usando una suscripción temporal a event log y volcado en un archivo de texto
   3:  
   4: '(c) Juansa 29-11-2008
   5:  
   6:  
   7:  
   8: Const ForReading = 1, ForWriting = 2
   9: Dim TabStop, NewLine
  10: TabStop = Chr(9)
  11: NewLine = Chr(10)
  12: Set objFSO = CreateObject("Scripting.FileSystemObject")
  13: Set objFile = objFSO.OpenTextFile("C:scriptsCambio_Servicios.txt", ForWriting, True)
  14:  
  15:  
  16: StrComputer = "."
  17: Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=Impersonate}!\" & strComputer & "rootcimv2")
  18: Set objwmiEventSource = objWMIService.ExecNotificationQuery ("SELECT * FROM __InstanceModificationEvent " & "WITHIN 3 WHERE TargetInstance  ISA 'Win32_Service'")
  19:  
  20:   Do
  21:     Set objService = objwmiEventSource.NextEvent
  22:       If objService.TargetInstance.State <> objService.PreviousInstance.State Then
  23:         objFile.WriteLine Date & TabStop & objService.TargetInstance.DisplayName & " está " & objService.TargetInstance.State & ". Anteriormente  estaba " & objService.PreviousInstance.State & "."
  24:       end if
  25:   Loop
  26:  

 

Este script se ejecuta de continuo, para detenerlo hay que abrir el Administrador de Tareas y matar el proceso wscript.exe que se crea al ejecutarlo.

Se ejecuta y no escribe nada en el archivo, pero yo hago una prueba manual: abro services.msc desde inicio->ejecutar y detengo el servicio (el que sea) Background Intelligent Transfer Service(BITS) y luego lo vuelvo a iniciar. Al echar un vistazo al archivo donde le he dicho que me guarde los cambios, veo:

cambio_servicios

¿Qué hace el script?

Su cuerpo, ya conocemos la creación y preparación del archivo donde guardará la info, Creamos la variable para el equipo local (StrComputer), Usamos GetObject y conectamos con el espacio de nombres rootcimv2 con nivel impersonate.

Usamos el método ExecNotificationQuery para registrar la notificación de cada vez que una instancia se modifica. Como sólo queremos los cambios en los servicios, usamos una cláusula WHERE para limitar la monitorización de los datos que nos devuelve la clase Win32_Service.

Creamos un bucle que ejecutará el script indefinidamente (podemos detenerlo como he indicado arriba, o con Taskkill.exe, Cerrando la sesión también se detiene).

Usamos el método NextEvent para recuperar el suceso cuando ocurre.

Así, cada vez que un servicio se modifica de alguna forma, el script comprueba el estado actual con el estado anterior, si no ha cambiado sigue a la espera, si es diferente lo graba en el archivo Cambios_servicios.txt.

3 comentarios sobre “Monitorizar los Servicios 2”

  1. Tengo una duda Juansa

    WMI está siempre operativo? Es decir, ¿se instala y «activa» con las instalaciones de windows tanto particulares como ORM? ¿Desde que versión de windows se puede usar WMI? ¿Que seguridad se debe habilitar para poder pe. suscribirse a eventos de mi maquina o de otra de un woprkgroup u de una red con dominio?

    Todo lo que explicas está genial para auditar sistemas y necesitaria ponerlom en practica pero quisiera conocer las «pegas» que pueda encontrar.

  2. Otra pregunta Juansa

    Si en lugar de usar el código de suscripción bajo un script lo metemos en un proyecto vb.net generamos su ensamblado, lo firmamos adecuadamente y lo instalamos como otro servicio más de la máquina ¿crees que será mejor que la ejecución de scripts? Lo digo por tener una herramienta que pase las «barreras» de seguridad (firmamos el ensamblado) entre las que quizás pudieramos tener bloqueadas las ejecuciones de scripts.

  3. WMI está incluído desde Windows 2000.
    Los permisos son cosa de los privilegios de la cuenta que lance el script, tanto a nivel local como remoto. Ya puse en un script anterior un enlace, éste: http://urpiano.wordpress.com/2007/04/26/vbscript-como-conectar-a-wmi-con-credenciales-alternativas/ donde mi colega y amigo Fernando explicaba como lanzar los scripts con credenciales alternativas.
    No soy un desarrollador demasiado entendido, pero tanto el script como el programita que harías en vb.net si se ha de ejecutar en un equipo, dependerá de la cuenta con que se lance. Por lo que, imagino que no hay problemas con la ejecución de nuestros propios scripts, ni si es un servicio implantado corretamente en un lenguaje de programación.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *