Windbg es una herramienta de depuración tanto en modo kernel como en modo usuario, con ella analizaremos los volcados.

Repasemos:

Cuando pasa un error en modo kernel Windows nos saluda con una pantalla azul y la info sobre el código de stop. Esto puede modificarse, de manera que:

- Se puede asignar un depurador (como windbg o KD).
- Se grabe el archivo de volcado de memoria (dump).
- Se produzca un reinicio automático del sistema.
- Se grabe el volcado y reinicie el sistema inmediatamente después.

Aunque a nosotros de momento nos interesa más ver los volcados.

Los volcados.

Modo-kernel:

Completo: volcado de tamaño más grande, contendrá la memoria física del equipo en el momento del pete. Lo que implica que el archivo de paginación deba tener al menos el tamaño de la memoria real + 1MB.
El volcado se guarda en la raíz del sistema con el nombre de memory.dmp(Por ejemplo: C:\windows\MEMORY.DMP), y en el caso de volcados posteriores, irían sustituyendo al existente.

Memoria Kernel: Con un tamaño significativamente menor contiene la memoria ocupada por el kernel en el momento del pete. Es decir, ni memoria no asignada ni la que está asignada a aplicaciones en modo usuario, sólo la usada por el kernel, HAL, y la asignada a controladores y programas en modo kernel.
En general es el volcado más útil y se guarda en la raíz del sistema con el nombre memory.dmp. Los volcados posteriores, sean memoria kernel o completo, sustituyen al existente.

Volcado pequeño: Con un tamaño de 64KB es el más pequeño de todos y por tanto sólo requiere un archivo de paginación de ese tamaño.
Su contenido es:
- Mensaje del código de stop y sus parámetros.
- El contexto del procesador que ha cascado.
- La información del proceso y el contexto kernel, del proceso que ha petado.
- La información del hilo y el contexto kernel, del proceso que ha petado.
- La pila de llamadas en modo kernel para el hilo que ha petado. Sólo hasta 16KB, los de arriba de la pila.
- Una lista de los controladores cargados.
Además, si es Windows XP o posterior:
- Una lista de módulos cargados y descargados.
- El bloque de datos del depurador (información de depuración básica del sistema).
- Cualquier página de memoria que Windows crea que es útil en la depuración de errores. (Las páginas de datos a qué apuntan los registradores en el momento del pete y otras que hayan sido solicitadas específicamente por el componente que falla).

Este tipo de volcado puede ser útil en los casos que el espacio sea escaso, aunque su información limitada hará que errores cuya causa no sea un hilo en ejecución en el momento del pete sean imposibles de ver en su análisis.
Ante nuevos petes, la creación del volcado pequeño no sustituye a los anteriores, creándose con nombres cuyo formato incluye la fecha añadida a la palabra mini, y un valor numérico tras un guión si se producen varios en una misma fecha, al estilo de mini070209-01.dmp; el primer volcado pequeño del 7 de febrero de 2009.
Los minidump se guardan en una carpeta denominada Minidump dentro de la raíz del sistema.

* Kernel = Núcleo.

Análisis mediante Windbg

Como ya comentamos e independientemente del depurador a usar, necesitamos instalar los archivos de símbolos de la versión de Windows que ha generado el volcado. Los utilizará el depurador para el análisis del archivo, y puede configurarse en Windbg el uso de la ruta de descarga desde el servidor de MS.

Con Windbg abriremos el dump desde File/Open Crash Dump, navegaremos hasta el lugar donde tenemos el archivo, lo elegiremos y pulsaremos Abrir.

Se abrirá una ventana independiente, mostrándonos el proceso de carga del volcado.

Bajo Bugckeck Analysis encontraremos la primera información relevante, para obtener información detallada (aconsejable) podemos pulsar sobre el link !analyze –v o escribirlo tal cual en la barra de comandos abajo, el resultado es el mismo.

Podemos usar también otros comandos para ver información relacionada, como:

!memusage

!vm

!errlog

!process 0 0

!process 0 7

Como decía al principio el primer paso sería darle paso al comando !analyze junto a la opción -v, que nos dará información extensa.

Las opciones disponibles de !analyze son:

-v
Salida de info extendida por pantalla
-f
Genera información sobre la excepción. Se usa para ver un análisis de la excepción aún si el depurador no la ha detectado.
-hang
Genera información sobre el pete de la aplicación. 

-D BucketID
Sólo muestra aquéllos elementos que son relevantes al BucketID especificado.

-show
Muestra en pantalla la información sobre el código de stop especificado.

-c
Sigue con la depuración cuando el depurador se encuentra con un problema conocido. Si el problema no es uno conocido, el depurador permanecerá detenido.
Podemos usar -c con ciertos subparámetros, que configuran la lista de problemas conocidos y de porsí no se ejecutan, hasta que usemos !analyze -c -load al menos una vez. !analyze -c no tiene ningún efecto.

    -load Archivoconocidos
Carga un archivo de problemas conocidos. Archivoconocidos específica la ruta y el nombre del archivo a cargar. Debe estar en formato xml.  Se usará en todos los análisis posteriores con el parámetro !analyze -c hasta que se descargue el archivo o se cargue otro nuevo que sustituya al cargado.
    -unload
descarga la lista de problemas conocidos.
    -help
Muestra ayuda para la extensión !analyze -c en la ventana de comandos del depurador.

BugCheckCode
Específica el código de stop a mostrar.

BugParameters
Especifica hasta cuatro parámetros del código separados por espacios. Ese parámetro nos permite mayor refinamiento en la especificación de los cuatro parámetros.

analyze modo kernel:

se inicia...

El primer elemento que muestra el pantallazo es el código de stop y la información relacionada con el mismo.

Sus parámetros y breve descripción, en el argumento 3 el valor es 0 y a su lado una descripción sobre el valor.

Los siguientes elementos varían según la naturaleza del pete. En la imagen podemos ver los campos READ_ADDRESS y CURRENT_IRQL.
FAULTING_IP muestra el puntero en el momento de error.

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

Muestra la categoría general a la que pertenece este fallo.

BUGCHECK_STR: 0xD1

El código de stop, que a veces va seguido de información adicional.

El campo TRAP_FRAME nos muestra el cuadro trap del pete. (con el comando .trap seguido de la dirección del cuadro también se muestra la información)

LAST_CONTROL_TRANSFER: from 921ec579 to 8168cfb9

última llamada a la pila. Si usamos el comando Ln dirección, podemos ver el módulo y función de la dirección. En este caso:
kd> ln 8168cfb9
(8168ccd8)   nt!KiTrap0E+0x2e1   |  (8168cff8)   nt!Dr_kitf_a

STACK_TEXT muestra un seguimiento de la pila del componente que falla.

STACK_COMMAND el comando utilizado para obtener el STACK_TEXT, en este caso kb.

FOLLOWUP_IP muestra el desensamblado de la instrucción que probablemente ha causado el error.

SYMBOL_NAME, MODULE_NAME, IMAGE_NAME y DBG_FLR_IMAGE_TIMESTAMP muestran datos sobre la instrucción: símbolo, módulo, imagen y marcado de la imagen.

BUCKET_ID: 0xD1_myfault+579

La categoría específica de errores al que pertenece el error.

Para analizar el archivo de volcado que se genera al colgarse Windows necesitaremos un depurador y los símbolos pertenecientes al sistema operativo en el que se ha producido ese dump.

Los mini-dumps se almacenan en la carpeta "ruta_del_sistema\Minidump", y contienen la información del stop, los datos de la pila del modo kernel y una lista de los controladores cargados.

Desde Debugging Tools for Windows podremos descargar las herramientas de depuración de 32/64 bits y los paquetes de símbolos, sinó configuramos el depurador para que los use desde internet.

Yo descargo la versión de 32 bits puesto que mi Windows 7 actual es el de 32 bits (cosas de pruebas).

Install Debugging Tools for Windows 32-bit Version

Luego los símbolos respectivos,

Download Windows Symbol Packages

El tamaño de un paquete de símbolos ronda los 300Mb y cada uno servirá para el sistema en concreto, puede configurarse Windbg para usar el servidor de descarga de MS.

Instalando las herramientas

Lo primero dirigirme donde he descargado el paquete msi y desbloquearlo:

Luego proceder a la instalación:

*Casi con seguridad que UAC nos pedirá confirmar la acción de instalación después de elegir el modo en la tercera pantalla.

Ya nos aparecen en el menú:

 Vamos a abrir Windbg y a configurar donde tiene los símbolos o desde donde descargarlos:

Hay que elegir una carpeta en el equipo donde se descargarán los símbolos desde el servidor de descarga, por ejemplo y siguiendo el ejemplo (valga la redundancia) de la propia MS, yo he creado la carpeta c:\websymbols, y la ruta a utilizar en la configuración de Windbg sería: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

Podemos asimismo utilizar el botón Browse para buscar las rutas en el equipo.

Podemos establecer varias rutas de paquetes de símbolos.

Estaremos de acuerdo en que realizar un control rutinario del rendimiento nos servirá para propósitos como:

• Detectar y diagnosticar problemas de rendimiento
• Comprobar que los servicios cumplen con los niveles acordados
• Ayuda para poder prevenir escasez de recursos antes de ésta suponga un impacto al nivel de los servicios.

Saber que contadores registrar

Una rutina de control del rendimiento efectiva en la detección y diagnóstico, además de resolver los problemas de rendimiento comunes, debería reunir quizás cantidades enormes de datos, para editarlos, resumirlos y usarlos en informes y programación.

La primera de las cuestiones a determinar puede que verse sobre los contadores de rendimiento; entre todos los disponibles debemos reunir un conjunto básico.

Una monitorización diaria, con sesiones de registro de contadores en segundo plano, para reunir los datos de rendimiento según ese conjunto básico de contadores de forma continua que nos permita la posibilidad de resolver problemas comunes cuando surjan. Como no somos adivinos y nos es imposible conocer de antemano qué recursos clave están saturados en un equipo con problemas de rendimiento, quizás en un mundo perfecto deberíamos reunir datos de todos los recursos: procesador, memoria, disco y red; pero el sentido común nos dice que es una burrada, así qué nos queda la idea de ser selectivos en cuanto a los datos a reunir, su cantidad y con qué frecuencia. Es decir, un intento de encontrar un justo equilibrio entre la cantidad de datos a reunir para analizar y el costo asociado a este proceso.

La detección y diagnóstico de problemas comunes de rendimiento implica recursos sobrecargados, necesitamos reunir un gran rango de datos detallados del procesador, memoria, disco y uso de red y de las cargas que están soportando. Los datos deben incluir contadores que puedan indicar condiciones de error, en especial los que se dan como resultado de falta de recursos internos.

Procedimientos de control diario

Un procedimiento de control rutinario debe incluir:

• Recogida automática de una vista en detalle del rendimiento del sistema mediante los registros de contador.
• Control de los indicadores de errores de aplicaciones de servidor y del sistema.
• Configuración de alertas que provoquen registros de contador de diagnóstico e información detallada.
• Conservación resumida de estadísticas de rendimiento.
• Administración de los registros de contador generados automáticamente por estos procesos.

Registros de contador diarios.

Primer paso, establecer un registro automatizado de datos con Logman. Por ejemplo:

Logman create counter registro_diario –cf "ruta_del_archivo_de_configuracion\archivoconf.txt" –o ruta_archivo\diario\registrodiario –b 1/10/2009 00:00:00 –cnf 24:00:00 –si 1:00 –f BIN –v mmddhhmm

Después de la ejecución podemos verlo desde la interfaz gráfica de Rendimiento:

Descripción:

Se crea un contador llamado registro_diario, donde se registrarán los contadores especificados en C:\perflogs\archivoconf.txt.

El registro se iniciará automáticamente por el monitor del sistema, una vez reiniciada la máquina y sea el 5 de octubre de 2009.

Las muestras se toman cada minuto, el formato del archivo de registro es el Binario.

Los archivos llevaran en su nombre la fecha, en formato mmddhhmm.

El archivo de configuración nos servirá para indicar los contadores que deseamos registrar o si queremos añadir contadores de aplicaciones específicas.

Dependeeee… ¿de qué?. De las ganas que se tengan de encontrar solución, hay muchos que reinstalan el sistema pensando que así desaparecerá el problema, y yo digo que puede que no y puede que tampoco, tarde o temprano si tenemos los mismos dispositivos, el mismo sistema, los mismos controladores y las mismas aplicaciones… regresará. Otra cosa es si al mismo tiempo cambiamos cosas y no nos damos cuenta que estamos eliminando la causa, pero en fin, contra gustos no hay colores, ni el azul.

Yo sí tengo ganas de solucionarlos. Por ello, primero analizo si es cosa del sistema o de alguna aplicación, luego sigo unas premisas bastante básicas para ir poco a poco profundizando si fuese necesario.

Cuando uno o varios equipos se ponen pesados en mostrarnos BSOD’s puede que sea por diversas razones:

- que hayamos instalado nuevos dispositivos,

- nuevo software o,

- de verdad se ha roto algo.

Yo pienso que el azul no sale "porque sí", es decir, pienso que el desencadenante es reciente y no creo nunca eso de "no hemos hecho nada". Una nueva aplicación, un nuevo escáner, ratón, tarjeta, controladores,…

Si hemos actualizado o instalado un nuevo controlador y al reiniciar nos saluda con una pantalla azul… pues que te voy a contar: Reinicia de nuevo y pulsa la tecla de función F8 y escoge "la última configuración buena conocida". Esto lo que hará es volver hacia atrás, evitando el nuevo controlador instalado.

Al reiniciar después de una bsod, bootmgr automáticamente detecta que no se apagó correctamente y mostrará una pantalla similar a la anterior (Windows Error Recovery), que nos ofrece algunas opciones; en este caso reparar el inicio. (En este caso la bsod fue provocada en un windows 7 en español)

Si las pantallas azules nos aparecen después de haber pasado ya tiempo de cualquier instalación de soft o hard no nos quedará otro remedio que intentar buscarnos la vida de algún modo, si es que queremos encontrar solución.

Aquí tenemos el primer paso importante, para poder indagar necesitamos datos y creo recordar que comenté algo de DUMPS, es decir, archivos de volcado de memoria. Bien, lo primero es lo primero.

Archivos de volcado

De forma predeterminada todos los Windows están configurados para intentar la grabación de información relativa al estado del sistema durante un cuelgue. La configuración se encuentra en la pestaña avanzada de las propiedades del sistema:

Clic derecho Equipo –> Propiedades –> Configuración avanzada del sistema del árbol izquierdo –> Pestaña Opciones avanzadas –> Sección Inicio y recuperación –> Sección Error del sistema.

La configuración predeterminada con la que me encuentro en windows 7:

• Grabar un evento en el registro del sistema
• Reiniciar automáticamente
• Un Volcado de memoria del kernel
• La ruta del volcado es: %SYSTEMROOT%\MEMORY.DMP
• Sobrescribir cualquier archivo existente

Los volcados, son tres –aunque en la imagen de win7 sólo hay dos-:

1. Volcado de memoria del kernel
2. Volcado de memoria completo
3. Volcado de memoria pequeño (128KB)

¿Sus diferencias?

El tamaño del archivo final es concluyente.

1) Sólo contiene páginas de memoria presentes lectura/escritura en modo kernel y en la memoria física, todo ello en el momento del cuelgue. Por su tipo y debido a que sólo el código en modo kernel puede causar cuelgues, parece el más indicado, aunque habrá ocasiones que necesitaremos depurar los procesos de usuario.

2) Lo que contiene la memoria física en el momento del cuelgue.

3) Con un tamaño entre 128KB y 1MB, denominado mini-Dump también, contiene el código de stop y sus parámetros, la lista de controladores de dispositivo cargados, las estructuras de datos que describen el proceso actual y el hilo, la pila del kernel para el hilo que ha causado el cuelgue y aquélla porción de memoria considerada relevante para el caso, de forma heurística.

Yo lo dejo de forma que no reinicie automáticamente, así puedo leer los datos de la pantalla azul mientras se realiza el volcado, y el volcado del kernel (el minidump siempre lo hace).

Después de la pantalla que hemos visto en la primera imagen, desde el interfaz de Windows se nos informa que el sistema se ha recuperado de un error grave, ofreciéndonos algunas opciones (esto sería para un análisis online).

Ok. Tenemos los dumps. Pues ya veremos si hacemos algo con ellos. También podemos forzar un dump manualmente vía teclado.

Y, ¿podemos realizar dumps si es una aplicación o servicio (no se cae el sistema) el del Hang?

Sí por supuesto.

• Usando NTSD
• Con Userdump.exe, Cómo.
• Adjuntando y guardando el dump de forma interactiva via NTDS
• Adjuntando y guardando el dump de forma interactiva via WinDbg
• Usando ADPlus en modo Hang.

También necesitaremos los símbolos del sistema a analizar para usarlos con algún depurador.

El azul es mi color favorito, no sé si es por ser acuario. Tengo el mar a mi lado, tenemos un cielo azul la mayor parte del año, etc…

Eso sí, cuando lo veo mostrado por Windows se transforma! :-)))

Está claro que ese bonito color azul no es más ni menos que una BSOD (Blue Screen Of Death), la pantalla azul de la muerte.

Una de las primeras cosas que se me vienen a la cabeza es, simplemente, que el equipo ha petado. Y ya en lo de petar, una de las primeras confusiones al respecto es la diferencia entre petar y petar. ¿Ha petado porque ha petado? o ¿Simplemente ha petado? :-)

Me explico: En inglés hablan de Crash y de Hang, que a veces van relacionados, es decir, que a veces un Hang es una consecuencia directa de un Crash. Yo siempre digo que ha petado o ha petado, pero parece que no es lo mismo, me explico.

Petar (Crash): La cpu no puede llevar a cabo su trabajo por una instrucción (cálculo, lectura/escritura) incorrecta. En cuanto sucede esto, Windows es tan listo que inicia una recogida de datos y los guarda para analizarlos. Si el pete es del propio sistema operativo, además, nos regala con una pantalla azul llena de garabatos y la información de la memoria del kernel o de la totalidad de la memoria física(dependerá de la configuración) la guardará en un archivo denominado DUMP, un archivo de volcado de memoria. Si el pete ha sido de una aplicación o servicio el dump será de la memoria de usuario. Este último lo llaman muchas veces el archivo de volcado de memoria post-mortem y que podemos enviar a un depurador post-mortem, que aunque pueden ser varios los depuradores se ejecutará el especificado en el registro.

Petar (Hang): Este también podemos analizarlo con un dump. La primera diferencia es que se manifiestan de forma diferente (¿petar<>petar? Me pierdo.)

Veamos como peta (Crash) una aplicación (proceso): plas! peta y desaparece de la lista de procesos en ejecución;

¿y como peta (Hang)? Pues se queda ahí, como embobado, esperando no se sabe a qué, COLGADO vamos…

Los cuelgues de aplicaciones o sistema se producen por ciertos fenómenos de mala entrega de mensajes. Las aplicaciones, o componentes del propio sistema se relacionan entre sí por ese medio, se mandan mensajitos. Y claro, esperan respuesta, y aquí está el quid de la cuestión, que se quedan esperando, esperando, esperando…

Y no hay nada más colgado que dos aplicaciones en ejecución que se esperan una a otra.

El dilema de Windows: ¿Qué hacer ante una excepción ilegal? Alguien está intentando hacer algo que se supone que no debería hacer y para más inri dispone de privilegios de acceso elevados. ¿Entonces? ¿Por qué acaba colgándose? ¿No podría ignorar dicha excepción y permitir al controlador o subsistema seguir como si no hubiera pasado nada? De hecho podría hacerlo y pensar que el error es aislado y el componente, de alguna manera, podrá recuperarse. Pero, lo más probable es que acabe con problemas mayores y es un riesgo muy alto.

La pantalla azul

KeBugCheckEx, documentada en el WDK (Windows Driver Kit), es la encargada de dar el pantallazo.

KeBugCheckEx muestra en pantalla los garabatos que nos servirán para ir investigando. El código de stop y tras la palabra STOP muestra el código numérico y 4 parámetros.

En la imagen(provocada por cierto), el código que se muestra es: DRIVER_IRQL_NOT_LESS_OR_EQUAL, el equivalente al código numérico detrás del STOP: 0x000000D1. Cuando un parámetro contiene una dirección al código de parte del sistema operativo o controlador de dispositivo, Windows muestra la dirección base del módulo donde se presume el fallo, la fecha y el nombre del controlador. Con esta sola información ya podríamos localizar el componente que está fallando.

Aunque hay más de 300 códigos de stop, la mayoría no se suelen ver. No demasiados representan la mayoría de los cuelgues de Windows. El significado de los cuatro parámetros adicionales dependerá del código de stop (que no se dan en todos). Aún así con el código de stop y los parámetros (si los muestra) pueden, al menos, darnos la posibilidad de diagnosticar el componente que está fallando ( o el controlador de dispositivo que causa el cuelgue).

Podemos encontrar la información de los errores de stop en el archivo de ayuda de las herramientas de depuración para Windows, sección Bug Checks (Blue Screens) o, basándonos en el código del error o en el nombre del hardware o aplicación sospechosa, buscarla en la Knowledge Base. Siempre podemos encontrar información sobre alternativas, actualizaciones, services pack que arreglen el problema que se está padeciendo. El archivo Bugcodes.h del WDK contiene una lista completa de los aproximadamente 300 códigos de error de stop con detalles y razones adicionales en algunos casos.

Procesador

Processor(_Total)\% Processor Time Counter (\Procesador(*)\% de tiempo de procesador)

System\Processor Queue Lenght Counter (\Sistema\Longitud de la cola del procesador)

Los contadores disponibles en un equipo que ejecuta Windows Server 2003 son diversos y son utilizados para informar sobre el sistema, las aplicaciones y el rendimiento.

** Hay que tener en cuenta el idioma del sistema operativo. Yo suelo usarlo en inglés y le aplico el MUI en español para los usuarios que no se encuentran cómodos con este idioma. Lo digo por los nombres de contador, intentaremos poner el nombre usado en ambos idiomas pero prima siempre el original en inglés.

Disponibilidad del Sistema

System\System Up Time (\Sistema\Tiempo de actividad del sistema)

Process(n)\Elapsed Time (\Proceso(*)\Tiempo transcurrido)

Otras posibles mediciones que nos sirvan para ver la disponibilidad del sistema pueden ser los contadores: TCP\Connections Active (\TCPv4\Conexiones activas) y Server\Server Sessions (\Servidor\Sesiones del servidor), que indican el estado de la conectividad de red. Un sistema que está en ejecución y no puede comunicarse con otros equipos es más que probable que esté inutilizable. En caso de hosting web, habría que separar los contadores de FTP Service\FTP Service Uptime () y Web Service\Service Uptime ().

También podemos usar Logman para generar los archivos de seguimiento de sucesos.

Sintaxis:

Las colecciones creadas con Logman tienen las mismas propiedades de configuración que las creadas con el elemento de Alertas y registros de rendimiento, y desde el podemos ver cualquier colección que hayamos creado con Logman. Asimismo, si usamos el parámetro –query con Logman para ver una lista de colecciones en el equipo, también veremos los creados desde Alertas y registros de rendimiento.

El conmutador –ets se usa para establecer una sesión de seguimiento de sucesos interactiva. Sin él, Logman asume que la colección es programada. Cuando usamos –ets, Logman no verá ninguna configuración de sesión previamente guardada. Los parámetros se le pasan directamente a la sesión sin guardarse o programarse. Con el conmutador –ets podemos crear múltiples sesiones de seguimiento de sucesos por ventana de consola.

Un ejemplo de secuencia de comandos:

logman create trace "miseguimiento" –pf deIIS.txt –bs 64 –o miseguimiento.etl
logman start "miseguimiento" –ets
logman stop "miseguimiento" –ets

La sesión iniciada con el segundo comando NO es la única creada por el primero. El segundo comando iniciará la sesión miseguimiento con la configuración predeterminada ya que se ha especificado –ets sin otros argumentos. Sin embargo, este mismo comando no borrara la configuración guardada por el primer comando.

Por contra, si no se especifica –ets:

logman create trace "miseguimiento" –pf deIIS.txt –bs 64 –o miseguimiento.etl
logman start "miseguimiento"
logman stop "miseguimiento"

El segundo y tercer comando recuperan la configuración de la sesión guardada, inician y paran la sesión. Si observamos la secuencia ésta es como una sesión interactiva pero sin –ets, los comandos pasan por el servicio de programación, incluido su inicio/detención.

Proveedores

El subcomando –query providers nos permite determinar desde qué proveedores de seguimiento podemos reunir datos de seguimiento.

*Por supuesto si la aplicación o servicio asociado al proveedor no está activa en el equipo, el proveedor no está habilitado para recoger los sucesos correspondientes.

Algunos proveedores disponen de opciones adicionales que podemos seleccionar entre los sucesos que estos proveedores pueden seguir.

Parámetros de Logman para el seguimiento:

Marcas de hora de suceso

Si las entradas de sucesos aparecen como fuera de hora, podemos necesitar usar un reloj de alta resolución. Algunas veces, si usamos la hora del sistema como reloj, la resolución (10ms) puede no ajustarse lo suficiente para ciertas secuencias de sucesos. Cuando un conjunto de sucesos muestran el mismo valor de marca de hora, el orden en que aparecen en el visor de sucesos no garantiza que sea en el mismo orden en que sucedieron. Si observamos que algo de esto está pasando, usaremos perf –que tiene una resolución más ajustada (100ns). Con Logman, el parámetro –ct perf obliga al uso del reloj perf.

Comprobación del límite de tamaño del archivo.

Si especificamos un límite de tamaño de archivo con la opción –max, el sistema de archivos en el que queremos crear el archivo de seguimiento lo evalúa antes de iniciar la sesión para ver si existe el espacio suficiente para ejecutar adecuadamente el seguimiento. Este límite de tamaño sólo se lleva a cabo cuando el archivo se almacena en la unidad del sistema. Si éste tuviera espacio insuficiente, la sesión fallará, apareciendo un error genérico de smlogsvc en el visor de sucesos.

Informes del seguimiento de sucesos.

Con Tracerpt.exe podemos convertir uno o más archivos *.etl al formato *.csv y ver su contenido.

tracerpt archivo.etl –o archivo.csv

Estos archivos podemos abrirlos con Excel y ver, secuencialmente, lo grabado.

Si se usa la opción –report con alguno de los proveedores, windows kernel trace, IIS, spooler o AD, se generan tablas adicionales en el informe que contienen los datos relacionados con un pre-formato. Por ejemplo:

tracerpt archivo.etc archivo2.etl –report archivo.html –f html

En Windows disponemos de la posibilidad de seguimiento de eventos ETW (Event Tracing for Windows). Este seguimiento puede terminar en un informe relacionado a los eventos de rendimiento cuando estos ocurren, eventos como:

• Cambios de contexto
• Errores de página
• Solicitudes E/S de archivo
• Creación y finalización de procesos
• Creación y finalización de hilos
• Solicitudes de conexión, envíos y recepciones TCP.

Además, aplicaciones como IIS o el propio Directorio Activo también están preparados para ofrecernos un diagnóstico sobre el seguimiento de eventos. En IIS por ejemplo, el controlador HTTP, Inetinfo, filtro ISAPI, peticiones CGI e incluso peticiones ASP, que proporcionan eventos de inicio y fin de solicitudes específicas nos permiten seguir el camino seguido por una solicitud GET HTTP individual en diferentes etapas de su proceso por entre dichos componentes.

Seguimiento de eventos no sólo graba cuando ocurren los eventos, sino que también captura información especifica que puede usarse para identificar el propio evento y la aplicación que lo causa. Los eventos se registran en un archivo que podemos consultar. El seguimiento de eventos es una técnica que la podemos utilizar para diagnosticar problemas de rendimiento que no nos son fáciles de resolver mediante otras herramientas ya vistas.

Como gran beneficio tenemos a su gran precisión. Podemos saber exactamente que ha pasado y cuando. Aunque en su contra hay inconvenientes que debemos conocer. Uno de los  inconvenientes es la posibilidad de que se generen cantidades de datos muy grandes y que complican su propio análisis. Otro es que un análisis manual resulta complejo, aunque Windows Server 2003 incluye una herramienta llamada tracerpt.exe que simplifica la cosa. Si deseamos conocer un contador solamente de entre muchos eventos, lo normal sería usar el monitor del sistema, si por el contrario, necesitamos entender con detalle la secuencia de eventos asociados a un problema de rendimiento, entonces usar Seguimiento de eventos, que nos proporcionará una extensa variedad de eventos de sistema y aplicaciones.

Investigar datos en Windows Server 2003 se compone de recoger y reunirlos usando sesiones de registro que los graben en un archivo. Podemos crear y administrar las sesiones de seguimiento con Log manager. Contamos además con los registros de seguimiento facilitados por Alertas y registros de rendimiento en la consola de Rendimiento que nos ofrece ciertas facilidades interactivas para definir sesiones de seguimiento de eventos, iniciarlas o detenerlas. Aunque estas facilidades interactivas no sean más que un subconjunto de opciones de definición de seguimiento de las que dispone Logman. Logman tiene además la ventaja que puede usarse junto a scripts para automatizar todos los aspectos del registro de seguimiento de eventos. Tracerpt.exe formatea los datos y proporciona varios informes integrados.

En una sesión de seguimiento, nos comunicamos con los proveedores de datos de seguimiento seleccionados que son los responsables de informar siempre que ocurran los eventos. Cuando un evento ocurre, el proveedor devuelve información sobre el mismo evento a la sesión de seguimiento, normalmente el servicio de Alertas y registros de rendimiento y éste a su vez graba una entrada en el archivo de registro.

Los registros de seguimiento se guardan en formato binario y con la extensión *.etl. Podemos usar archivos de seguimiento circular o secuencial. Y como con los registros de contadores podemos establecer su límite de tamaño. Cuando un archivo circular alcanza el límite establecido el registro de eventos sigue, desde el inicio del archivo y reemplazando los datos antiguos, en uno secuencial la sesión de seguimiento finaliza.

Luego, para ver los archivos de una forma aceptable necesitamos una herramienta de análisis como Tracerpt.exe que procesa el archivo de registro de salida y transforma los datos binarios en CSV (separado por comas). Disponemos también de informes usando la opción –report de tracerpt.

Alertas y registros de rendimiento

Cuando abrimos el monitor de rendimiento observamos en el árbol del panel izquierdo la función de Alertas y registros de rendimiento y de ella cuelgan tres componentes: registros de contador, registros de seguimiento y alertas.

Podemos crear registros de seguimiento desde aquí cuando queramos, con capacidades similares a las que hay disponibles para los registros de contador, como:

• Administrar múltiples sesiones de registro de seguimiento desde una única consola(Aunque podemos tener definidas muchísimas más sesiones, hay un límite de 32 activas simultáneamente).
• Iniciar y detener manualmente, bajo demanda, automáticamente o programando el horario de cada registro de las sesiones.
• Detener cada registro según el tiempo transcurrido o del tamaño actual del archivo.
• Especificar esquemas de nombrado automático e indicar un programa que se ejecutará cuando un registro de seguimiento se detiene.

El proceso del servicio de Alertas y registros de rendimiento Smlogsvc.exe es el responsable de ejecutar las funciones del registro de seguimiento que hayamos definido.

Configurar un registro de rendimiento

1. Pulsamos en Registros de seguimiento en la consola (ver imagen anterior), en el panel derecho se nos mostrarán, si las hubiesen, las ya definidas. 
2. Clic derecho sobre el panel, el menú contextual nos muestras dos opciones de creación de nuevos registros:
   
3. Se nos pide un nombre para el registro:
   
   y se muestra el cuadro de configuración.
   
4. Elegiremos entre los eventos del proveedor del sistema o de alguno de los proveedores de aplicación disponibles. Clic en el botón de Estado de proveedores para ver aquéllos proveedores específicos que están instalados en el equipo.
   
5. Pasaremos por el resto de pestañas: Archivos de registro, Programación y Avanzadas para establecer las diferentes opciones.
   

Los proveedores de eventos

Los proveedores de eventos son los responsables del envío de información sobre un evento al servicio de alertas y registro de rendimiento en cuanto ocurre. De forma predeterminada, en la pestaña General, la opción Proveedores que no son de sistema está marcada para mantener el registro de seguimiento por encima de un mínimo. Pulsaremos en el botón Agregar para incluir datos desde estos proveedores en el registro de seguimiento. Entre los proveedores de aplicaciones están Active Directory, MMQ, IIS, y la cola de impresión.

Si pulsamos en Sucesos registrados por el proveedor del sistema, se usa un proveedor compilado para eventos del kernel de Windows para monitorizar los procesos, hilos y otras actividades. Marcaremos las casillas que deseamos definir para el seguimiento.

*Creación /eliminación de procesos y/o subprocesos.

*E/S de disco

*TCP/IP de red

*Errores de página

*Detalles de archivo

Antes de conectar el seguimiento de una clase de suceso debemos tener claro el impacto sobre el rendimiento que causará. Si queremos hacer una prueba, con el monitor del sistema podemos seguir algunos contadores que usen sucesos que el proveedor del kernel pueda seguir durante varios minutos, comprobaremos entonces el tamaño de los archivos producidos y el sobreuso consumido por el seguimiento, que será proporcional a los sucesos ocurridos.

\Sistema\Operaciones de lectura de archivo/s (\System\File Data Operations/sec)

\Sistema\Operaciones de control de archivo/s (\System\File Control Operations/sec)

\Memoria\Errores de página/s (\Memory\Page faults/sec)

\TCPv4\Segmentos/s (\TCPv4\Segments/sec)

Configuración de las propiedades del registro

Las hojas de propiedades nos permiten establecer el seguimiento automatizado. Las opciones de archivo y programación son similares a las disponibles para registro de contadores. La pestaña de archivos de registro se usa para seleccionar el tipo de archivo y las opciones de nombrado automático. En la de programación podremos escoger las opciones de inicio manual o automático, establecer la hora en la que queremos que termine la sesión, determinando una hora o especificando una duración en segundos, minutos, horas, o días; o también indicando que se detenga cuando el archivo de registro alcance su tamaño límite especificado.

Monitor del sistema, alertas y registros de rendimiento, Logman, Relog y Typeperf, todas sacan información de alguna parte: usando librerías dinámicas como intermediarias, las PDH(Performance Data Helper). Cada una de las herramientas citadas colecta contadores usando el interfaz PDH, luego es responsable ella misma de realizar los cálculos de conversión de los datos de los intervalos de contadores y de formatearlos para generar informes y archivos de salida.

Las *dll de rendimiento (Perflib) proporcionan los datos para todas las medidas de los contadores en el monitor del sistema. El sistema operativo provee de un conjunto básico de librerías de rendimiento para monitorizar el comportamiento de los recursos, como la memoria, procesador, discos, adaptadores de red y protocolos. Por supuesto hay muchas otras aplicaciones y servicios dentro de Windows Server 2003 que proporcionan sus propias *dll que instalan contadores y que podemos usar para montorizar sus operaciones. Todas estas librerías instaladas en el equipo están registradas en las sub-claves de Performance bajo la clave HKLM\SYSTEM\CurrentControlSet\Services\nombre_del_servicio.

Estos campos se usan por las rutinas PDH para cargar las *.dll, inicializarlas para su uso en la recogida de datos de rendimiento y cerrarlas cuando la sesión termina.

Para ahorrar espacio en el registro, las variables REG_MULTI_SZ de texto grandes que componen nombres y texto explicativo de los contadores de rendimiento se guardan en archivos de cadenas de texto fuera del registro. Estos archivos están mapeados dentro del registro, como si fuesen claves normales para usuarios y aplicaciones. Los archivos son:

• %windir%\system32\perfc009.dat
• %windir%\system32\perfh009.dat

Al guardarlos separadamente se indica el ID del lenguaje del país: 09 = inglés, 0A=español,…

El proceso de PDH al ser requerido por una aplicación de monitorización de rendimiento sería:

1. PDH accede a los archivos perfc00A.dat y perfh00A.dat (si el lenguaje es el español) que contiene el texto que define los objetos de rendimiento y los nombres de los contadores instalados en el equipo, junto con sus textos explicativos asociados.
2. PDH realiza inventario de la clave HKLM\SYSTEM\CurrentControlSet\Services\nombre_del_servicio\ para determinar que *.dll de Perflib están disponibles en el equipo.
3. Para cada clave hallada, PDH carga la *.dll Perflib.
4. Después de la carga de *.dlls, PDH llama a la rutina Open. La rutina devuelve la información que describe los objetos y contadores que la *.dll soporta. La aplicación de monitorización podrá usar esta información para montar un menú de selección de objetos y contadores como el formulario Añadir contadores del monitor del sistema.
   
5. En el primer intervalo de muestra, PDH llama a la rutina Collects para reunir los contadores de rendimiento, la aplicación puede realizar llamadas PDH adicionales para formatear estos contadores para mostrarlos por pantalla.
6. Cuando termina, PDH llama a la rutina Close para todas las Perflibs activas hasta que finalizan su procesamiento con corrección.

El procesamiento PDH oculta la mayoría de detalles de estos pasos en aplicaciones de monitorización, como el monitor del sistema y Log manager. La herramienta Extensible Counter List (exctrlst.exe, incluida en las Windows Support Tools de Windows Server 2003) ilustra el paso 2 del procesamiento. Si la iniciamos desde el símbolo del sistema (escribiendo exctrlst en una cmd) obtenemos:

Es decir, un completo inventario de librerías de rendimiento (DLLS) registradas en el equipo.

* Si una llamada a una función Perflib falla o devuelve error, las rutinas PDH añaden un campo opcional a la sub-clave Disable Performance Counters. Se genera un mensaje de error en el registro de eventos si PDH halla un error. Si se establece un marcador en la sub-clave, las rutinas PDH no intentarán cargar, ni recoger datos desde dicha librería hasta que se resuelva el fallo y se eliminen los marcadores mediante la herramienta Extensible Counter List siempre mejor que editando el registro.

* Aún así, disponemos de entradas en el registro en HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Perflib que pueden ayudarnos cuando suframos problemas dentro de las *.dll.

Una vez conocidos los contadores de rendimiento instalados en el equipo, podemos monitorizar el rendimiento. Para ello, iniciaremos Typeperf seguido de una lista de contadores, por ejemplo:

Typeperf "Memoria\Bytes disponibles"

*El sistema que yo uso es en español.

Typeperf comienza de inmediato la monitorización de los bytes disponibles de memoria y los va mostrando en la ventana en tiempo real; continuará hasta que usemos la secuencia de teclas CRTL+C para finalizar la sesión.

Si queremos monitorizar más de un contador sólo tenemos que añadirlos entrecomillados siguiendo al anterior,

Typeperf "Memoria\Bytes disponibles" "Memoria\Bytes de caché" "Memoria\Páginas/s"

Como alternativa, podemos tener las rutas en un archivo y referenciarlo en el comando usando el parámetro –cf, parecido a Relog.

Si queremos hacerlo a equipos remotos:

Typeperf "\\Equipo\Memoria\Bytes disponibles" o, Typeperf "Memoria\Bytes disponibles" –s Equipo

De forma predeterminada las medidas o muestras de los datos de rendimiento son de una vez por segundo hasta que se pulsa CRTL+C.

Nosotros no podemos hacer que el comando se ejecute durante dos horas y se detenga (al menos desde sus parámetros), pero si podemos especificar el número de muestras o medidas a tomar durante su sesión, alcanzado dicho número se cerrará. Para ello utilizaremos el parámetro –sc seguido del número, por ejemplo si queremos 100 muestras:

Typeperf "Memoria\Bytes disponibles" –sc 100

Lo que supone 100 segundos.

También podemos modificar la frecuencia de muestreo, sabemos que es una por segundo, 86400 en un día. Así que para hacerlo usaremos el parámetro –si seguido del nuevo muestro en segundos, si lo queremos cada 5 minutos entonces 5*60=300:

Typeperf "Memoria\Bytes disponibles" –si 300

Y finalmente un par de cuestiones: dirigir la salida hacia un archivo de registro y/o cambiar el formato del mismo.

Redirigir la salida puede hacerse, como siempre hemos hecho desde el propio símbolo del sistema:

Typeperf "Memoria\Bytes disponibles" > ruta\nombre_archivo

o, y mejorándolo creo, usar el parámetro del comando –o junto al –f y así redirigir y establecer el formato del archivo de salida.

Typeperf "Memoria\Bytes disponibles" -o ruta\nombre_archivo.extension –f tipo_formato

Donde extensión irá en consonancia(*.csv, *.tsv, *.log) con el tipo_formato (bin, csv, tsv, SQL)

Una vez conocidos los contadores de rendimiento instalados en el equipo, podemos monitorizar el rendimiento. Para ello, iniciaremos Typeperf seguido de una lista de contadores, por ejemplo:

Typeperf "Memoria\Bytes disponibles"

*El sistema que yo uso es en español.

Typeperf comienza de inmediato la monitorización de los bytes disponibles de memoria y los va mostrando en la ventana en tiempo real; continuará hasta que usemos la secuencia de teclas CRTL+C para finalizar la sesión.

Si queremos monitorizar más de un contador sólo tenemos que añadirlos entrecomillados siguiendo al anterior,

Typeperf "Memoria\Bytes disponibles" "Memoria\Bytes de caché" "Memoria\Páginas/s"

Como alternativa, podemos tener las rutas en un archivo y referenciarlo en el comando usando el parámetro –cf, parecido a Relog.

Si queremos hacerlo a equipos remotos:

Typeperf "\\Equipo\Memoria\Bytes disponibles" o, Typeperf "Memoria\Bytes disponibles" –s Equipo

De forma predeterminada las medidas o muestras de los datos de rendimiento son de una vez por segundo hasta que se pulsa CRTL+C.

Nosotros no podemos hacer que el comando se ejecute durante dos horas y se detenga (al menos desde sus parámetros), pero si podemos especificar el número de muestras o medidas a tomar durante su sesión, alcanzado dicho número se cerrará. Para ello utilizaremos el parámetro –sc seguido del número, por ejemplo si queremos 100 muestras:

Typeperf "Memoria\Bytes disponibles" –sc 100

Lo que supone 100 segundos.

También podemos modificar la frecuencia de muestreo, sabemos que es una por segundo, 86400 en un día. Así que para hacerlo usaremos el parámetro –si seguido del nuevo muestro en segundos, si lo queremos cada 5 minutos entonces 5*60=300:

Typeperf "Memoria\Bytes disponibles" –si 300

Y finalmente un par de cuestiones: dirigir la salida hacia un archivo de registro y/o cambiar el formato del mismo.

Redirigir la salida puede hacerse, como siempre hemos hecho desde el propio símbolo del sistema:

Typeperf "Memoria\Bytes disponibles" > ruta\nombre_archivo

o, y mejorándolo creo, usar el parámetro del comando –o junto al –f y así redirigir y establecer el formato del archivo de salida.

Typeperf "Memoria\Bytes disponibles" -o ruta\nombre_archivo.extension –f tipo_formato

Donde extensión irá en consonancia(*.csv, *.tsv, *.log) con el tipo_formato (bin, csv, tsv, SQL)

Antes de poder monitorizar el rendimiento en un equipo necesitamos conocer qué contadores se encuentran disponibles en el mismo. Aunque un juego predeterminado de contadores de rendimiento se instala junto al sistema operativo, los contadores actuales en un determinado equipo dependerá de muchas cosas: sistema operativo instalado, ya que cada uno instala un juego distinto de contadores predeterminados; servicios y aplicaciones instaladas, ya que muchas de ellas puede que proporcionen su propio juego de contadores en el momento de instalarlas; si los contadores se han deshabilitado o se han corrompido.

Recuperar una lista de todos los contadores (sin instancias) disponibles en un equipo es tan sencillo como usar Typeperf con el parámetro –q.

Typeperf –q  NOTA: Os recomiendo redirigirlo a un archivo, sea con Typeperf –q > ruta\typeperf.txt o Typeperf –q –o  ruta\typeperf.txt

De forma sucesiva, Typeperf muestra en pantalla las rutas de los contadores de rendimiento instalados en el equipo. Extraídas de la ejecución del comando en un Win7:

Si queremos incluir las instancias usaremos el parámetro –qx.

Typeperf –qx  NOTA: Os recomiendo redirigirlo a un archivo, sea con Typeperf –qx > ruta\typeperf.txt o Typeperf –qx –o  ruta\typeperf.txt

La lista ya puede ser grande con el –q así que el –qx es mucho mayor, por ello si lo redirigimos a un archivo de texto los tendremos todos.

También podemos recuperar la lista de contadores desde equipos remotos, para ello usaremos la ruta UNC:

Typeperf –q \\Equiporemoto  Typeperf –q \\Equiporemoto\Memory

Typeperf no proporciona ninguna vía de conexión con usuario y contraseña alternativos, pero podemos conectar con el equipo remoto primero usando

net use \\Equiporemoto\ipc$ /user:USUARIO CONTRASEÑA y usar el comando en el equipo remoto.

La herramienta Typeperf proporciona una alternativa desde la línea de comandos al monitor del sistema. Puede proporcionarnos una lista de valores de contador de rendimiento en ejecución, dándonos un control detallado del rendimiento en tiempo-real. También supone menor sobrecarga que el monitor del sistema, lo que puede ser importante si el equipo que estamos controlando es ya lento o bajo rendimiento.

Para asistir en la construcción de procedimientos de control automatizados, Typeperf dispone de una manera fácil de recuperar una lista de todos los contadores de rendimiento instalados sobre un determinado equipo.(Aunque es posible ver el conjunto de contadores de rendimiento instalados con el monitor del sistema, no hay forma de revisarlos o de guardar la lista entera.) Con Typeperf, podemos listarlos y guardar la lista en un archivo de texto que puede editarse después para usarse como archivo de configuración con Logman o Relog. Este diseño es un complemento pues a Logman y Relog.

Typeperf es compatible con un conjunto de parámetros en tiempo de ejecución para la definición de consultas de registro de contador,y junto a opciones, reunir contadores en tiempo-real. Los parámetros utilizan una sintaxis y llevan a cabo funciones similares a Logman y Relog.

Relog nos permite reducir el tamaño de los archivos de salida creados mediante la escritura de uno de cada n registros, donde n es un parámetro que nosotros especificamos usando la opción –t. Esto tiene el efecto de resumir el intervalo y las medias de contadores. Los intervalos son algo como \Processor\Interrupts/sec y \Process\% Processor Time que informan un ratio de actividad sobre la medida del intervalo. Las medias como \Physical Disk\Avg.Disk sec/transfer son las que informan un valor de media sobre la medida.

El parámetro –t nos permite extraer cada enésimo registro desde los registros de contador de entrada y pasarlos al archivo de salida. –t 40 selecciona cada 40 registros; –t 4 selecciona cada 4 registros. Si el registro de contador de entrada original se guardó con una muestra de intervalo de una vez cada 15 segundos, usando Relog con el parámetro –t 4 resulta en un archivo de salida con datos grabados en intervalos de un minuto. El mismo archivo de salida con –t 240 resulta en datos grabados en intervalos de 1 hora.

Resumiendo usando Relog supone un nuevo muestreo del archivo de entrada. El archivo resultante no es sólo más conciso además contiene valores de contador resumidos sobre intervalos largos. Podemos esperar que algunos datos se han atenuado como resultado de este orden de resumen, pero nada que distorsionaría la normalidad de la distribución subrayada y sea difícil de interpretar.

No todos los contadores que reunimos pueden resumirse con este estilo, sin embargo, para un contador instantáneo como \Memory\Available Bytes, relog simplemente baja las observaciones de muestra. Si usamos relog con contadores instantáneos con extensión suficientemente larga, podríamos encontrarnos con un archivo de salida con tan pocas observaciones que no tendríamos una muestra lo suficientemente grande para interpretar las mediciones de manera significativa. En este punto es probablemente mejor usar una lista de contadores con relog para disminuir los contadores instantáneos desde el archivo de salida.

Unión de registros de contador con Relog

Podemos utilizar Relog para unir datos de múltiples registros de rendimiento en un único archivo. Se especifica la ruta y los nombres de archivos de los diversos registros de rendimiento como parte del parámetro inicial:

relog c:\registros\registro1.blg c:\registros\registro2.blg c:\registros\registro3.blg –o c:\misRegistros\RegistroDestino.blg –a

Usamos el parámetro –a para indicarle a Relog que debe añadir la salida de cualesquiera datos al archivo de salida cuando se unen datos de múltiples registros.

Los registros almacenados en equipos remotos también pueden unirse mediante el uso de la ruta UNC en lugar de la ruta local.

relog \\servidor01\registros\reg1.blg \\servidor02\registros\reg2.blg \\servidor03\registros\reg3.blg –o c\misRegistros\RegDestino.blg –a –f blg

Las rutas individuales no deben superar los 1024 caracteres.

Formato del archivo de salida de Relog

Relog es compatible con los mismos formatos de archivos de entrada y salida como Logman a excepción del binario circular y de establecer tamaños límite de archivo. Si se crea un nuevo archivo de salida éste tendrá el formato binario de forma predeterminada. Relog sólo puede añadir datos sobre archivos existentes, y los archivos de entrada y salida están en formato binario.

Cuando creamos un nuevo archivo de salida podemos usar el parámetro –f para especificar uno de los formatos: bin (formato binario, predeterminado), csv (valores separados por comas), tsv (Valores separados por tabulación) o SQL (formato SQL).

Filtrar archivos de registro con Relog

Relog tiene capacidad de filtrado, que puede usarse para la extracción de datos de rendimiento desde un registro de contador de entrada basado en los siguientes criterios:

• Una lista de contadores, especificados con sus rutas.
• Un rango especificado de fecha y hora.

Sólo los contadores que cumplan los criterios especificados se escribirán en el archivo de salida que Reglog cree.

Filtrado por contador   Se basa en una lista de contadores, especificados en la la línea de comandos o en un archivo de configuración. Relog grabará en el archivo designado de salida sólo aquéllos valores de los contadores especificados.

relog c:\registros\reg01.txt –o c:\registros\nuevoreg.txt –f csv –c "\Memory\Available Bytes"

Para la extracción de datos de más de un contador, se incluye cara ruta del contador como parte del parámetro –c.

relog c:\registros\reg01.txt –o c:\registros\nuevoreg.txt –f csv –c "\Memory\Available Bytes" "\Memory\Pages/sec" "\Memory\Cache Bytes"

Si nuestro registro de entrada contiene datos de múltiples equipos, se incluye el nombre del equipo como parte de la ruta del contador.

relog c:\registros\reg01.txt –o c:\registros\nuevoreg.txt –f csv –c "\\EQUIPO\Memory\Available Bytes"

En lugar de escribir una gran cantidad de contadores de rendimiento como parte del comando, podemos usar un archivo de configuración, un simple archivo de texto conteniendo las rutas de cada contador en una fila.

Para filtrar los archivos de entrada que sólo tengan aquéllos contadores que estén en el de salida, usar el parámetro –cf seguido de la ruta del archivo de configuración.

Filtrado por fecha   Relog proporciona la habilidad de extraer subconjuntos de datos basados en fecha y hora. Para ello se especifica la hora de comienzo (parámetro –b) y la hora final (parámetro –e) como parte de nuestro comando. Tanto uno como otro parámetros expresan fechas y horas usando el formado mm-dd-yyyy hh:mm:ss, més día año, hora, minuto y segundos, la hora se expresa en formato 24 horas.

relog c:\registros\reg01.txt –f csv –o c:\registros\Nuevoreg.txt –b 07-07-2009 09:30:00 –e 07-08-2009 11:00:00

Si sólo indicamos las horas, se asume la fecha del día actual.

relog c:\registros\reg01.txt –o c:\registros\Nuevoreg.txt –b 09:30:00 –e 11:00:00

Tanto Las Alertas y registros de rendimiento como Logman nos permiten cierta flexibilidad en la recogida de estadísticas de rendimiento. La herramienta Relog (relog.exe) es una herramienta de línea de comandos que nos permite administrar los registros de contador que hemos creado. Con Relog podemos llevar a cabo las siguientes tareas:

• Combinar múltiples registros de contador en un único archivo de registro. Podemos listar los nombres de archivo de todos los contadores que queremos que Relog procese separadamente, o podemos usar caracteres comodín (como *) para identificarlos. Los registros que combinemos pueden contener contadores de un sólo equipo o de varios.
• Crear resúmenes de archivos de salida desde un archivo o archivos de entrada.
• Editar el contenido de un registro contador, permitiendo saltar los contadores por nombre o todos aquéllos que no han recogido datos durante un intervalo de tiempo determinado.
• Convertir datos de contador de un formato a otro.

Nota: Logman puede recoger datos de rendimiento en múltiples equipos y guardarlos en un sólo archivo de registro. Sin embargo, esto puede resultar en una cantidad de tráfico considerable e indeseado. Relog nos permite monitorizar el rendimiento localmente, y entonces recuperar los datos según se necesiten. Colocando los comando de Relog en un archivo de lotes, los datos pueden recuperarse de forma programada, en momentos que el tráfico de la red es bajo.

La herramienta Relog

Relog necesita dos parámetros: la ruta de un archivo existente (de entrada) y la ruta para un archivo (de salida) nuevo(parámetro –o).

relog C:\archivodeentrada.blg –o C:\archivonuevodesalida.blg

Relog reune datos desde uno o más registros de rendimiento y los combina en un archivo de salida único. Podemos especificar un archivo de entrada único o una cadena de archivos de entrada.

relog C:\archivodeentrada.blg c:\archivodeentrada2.blg c:\archivodeentrada3.blg –o c:\archivonuevodesalida.blg

Sintaxis

Con Logman podemos programar opciones que nos permitan la programación de la recogida de datos en horas específicas durante el día. Mediante intervalos de muestra diferentes podemos tener también a Logman recogiendo datos en intervalos regulares. Lo que no podemos hacer es programar la recogida de datos de en horarios irregulares. Por ejemplo: los 10 primeros minutos de cada hora.

Podemos con Typeperf hacerlo. Creamos un archivo de lotes que configure Typeperf  para tomar muestras sólo 10 minutos y luego programamos que el archivo de lotes se ejecute una vez cada hora con el Administrador de tareas.

Sin embargo, ya que Logman es scriptable, podemos combinar WSH y Logman para programar la recogida de datos usando intervalos irregulares. Un script:

   1: Set WshShell = WScript.CreateObject("WScript.Shell")

   2: Do

   3:     WshShell.Run "%COMPSEC% /c logman -start dns_log"

   4:     Script.Sleep 300000

   5:     WshShell.Run "%COMPSEC% /c logman -stop dns_log"

   6:     WScript.Sleep 3300000

   7: Loop

Inicia Logman y se para por cinco minutos, tiempo que Logman recoge datos, luego lo detiene y permanece 55 minutos inactiva hasta volver a activar el Ciclo(Loop).

   1: Set WshShell = WScript.CreateObjetc("WScript.Shell")

   2: For i = 1 to 24

   3:     WshShell.Run "%COMPSEC /c logman -start dns_log"

   4:     WScript.Sleep 300000

   5:     WshShell.Run "%COMPSEC /c logman -stop dns_log"

   6:     WScript.Sleep 3300000

   7: Next i

   8: WScript.Quit

Este hace lo mismo pero se ejecuta 24 veces, una vez cada hora.

Antes de usar Log manager debemos crear una colección –conjunto de instrucciones que especifica que equipo monitorizar, que contadores recogerán información, con qué frecuencia la obtendrán y cualesquiera otros parámetros de recolección de datos de rendimiento.

Una colección se crea utilizando el parámetro create counter, seguido del nombre de la colección y una lista de los contadores de rendimiento a monitorizar. Por ejemplo:

logman create counter dns_server_log

Esto creará un contador llamado dns_server_log, pero no especifica ningún contador de rendimiento. Para ello hemos de usar el parámetro –c para indicar los contadores que tomarán muestras.

logman create counter dns_server_log –c “\Memory\Available Bytes”

Aquí le hemos añadido un contador, aunque podrían ser varios.

Como una alternativa a listar uno a uno los contadores, si estos fueran muchos, podemos crear un archivo de texto con un contador específico por línea y usarlo en el comando.

Un archivo que contenga:

Le damos un nombre, por ejemplo: basico.config

Una vez tenemos el archivo, utilizamos logman para:

logman create counter BASICO -f bincirc -max 500 -si 2 --v -o "e:\perflogs\SERVIDORBASE" –cf \basico.config">\\<SERVIDOR>\basico.config

• logman create counter BASICO: Esto crea la colección BASICO en el equipo local.
• -f bincirc -max 500 -si 2: Aquí especificamos que estamos creando un archivo binario circular con un tamaño máximo de 500 MB, estableciendo el intervalo de captura en 2 horas.
• --v -o "e:\perflogs\SERVIDORBASE": Desconectamos la información de versión y establecemos la ubicación de salida y el nombre del archivo. El registro se creará con la extensión .BLG.
• –cf \basico.config">\\<SERVIDOR>\basico.config: Finalmente la ubicación del archivo de configuración estándar de contadores.

Una vez ejecutado el comando podemos ver si efectivamente se ha creado nuestra colección con el parámetro query,

Finalmente para iniciarlo:

logman start BASICO

Suponiendo que queremos monitorizar la medida de tráfico de red generado por un programa de copias de seguridad, ¿aplicación que se ejecuta a las 2 de la madrugada?. Un registro de contador en Alertas y registros de rendimiento nos permite registrar los datos de rendimiento en un archivo, de ese modo obtenemos una monitorización desatendida. Pero aún siendo una excelente herramienta para llevar a cabo estas tareas tiene ciertas limitaciones:

• Cada configuración de registro de contador ha de crearse mediante el interfaz gráfico. Aunque esto hace que usuarios novatos puedan crear seguimientos de rendimiento, los usuarios experimentados pueden encontrar el proceso lento y menos eficiente que crearlo desde la línea de comandos.
• La configuración del registro de rendimiento creado con el snap-in no puede ser accedido desde scripts o archivos batch.

La herramienta Logman nos ayuda a superar esas limitaciones. Además, Logman está diseñado para trabajar con otras herramientas de línea de comando como Relog y Typeperf lo que nos permite la construcción fiable de procedimientos de monitorización del rendimiento automatizados.

Más info sobre Logman: http://technet.microsoft.com/es-es/library/bb490956(en-us).aspx

Visión general

Log Manager (Logman.exe) es una herramienta de línea de comandos que complementa al snap-in de Alertas y registros de rendimiento. Logman replica toda la funcionalidad en una única herramienta. Entre otras cosas, podemos:

• Crear con rapidez configuraciones de registros de rendimiento desde la línea de comandos.
• Creación y uso de archivos de configuración personalizados que nos permitirán copiar la configuración de monitorización y reutilizarla en otros equipos.
• Llamar al registro de rendimiento desde archivos batch o scripts. Estos batch o scripts pueden copiarse y usarse en otros equipos.
• Recoger datos desde múltiples equipos simultáneamente.

Los datos que Logman reune se guardan en un archivo de registro de contador de rendimiento usando el formato que especifiquemos. Con system monitor podemos ver y analizar cualquier registros de contador que haya creado Logman.

Sintaxis

Logman funciona en uno de dos modos, modo interactivo, podemos ejecutar Logman desde la línea de comandos e interactuar con la sesión de registro. O en segundo plano, Logman crea configuraciones de registros de contador que son programadas y procesadas por el mismo servicio de Alertas y registros de contador que usa la misma consola.

Subcomandos

Parámetros