Search results for 'app:weblogs' matching tag 'Windows Server'

Análisis del dump I –Preparando las herramientas

juansa — Sun, 11 Oct 2009 05:00:00 GMT

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.

Controlar el rendimiento I

juansa — Sun, 04 Oct 2009 05:00:00 GMT

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.

La pantalla azul II- Ha petado o petado, ¿pero hay solución?

juansa — Tue, 29 Sep 2009 05:00:00 GMT

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-:

Volcado de memoria del kernel
Volcado de memoria completo
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.

! Four mistakes that can kill virtual machine performance

Petizme — Mon, 28 Sep 2009 05:00:00 GMT

Hi,

From SeachVirtualization site, see below:

1: Virtual machine screensavers
Screensavers are an absolute requirement for desktops in the hallways of our brick-and-mortar offices. They ensure that a user who walks away from his computer returns to one that has been secured against prying eyes. Screensavers can also provide protection in data centers. If screensavers on servers activate and lock the console after a few minutes of inactivity, they can protect that environment from an intruder who gains physical access.

But screensavers are a quiet consumer of processor resources. No matter how insignificant that screensaver seems, the processor power required to draw the pipes crawling across the screen or to scroll your favorite company slogan consume a percentage points of overall processor power. While that might not seem like much, consolidated virtual environments might have 10 or 15 virtual machines (VMs) running on a single virtual host. These percentage points add up when they are multiplied by the number of VMs. Even worse, if your environment uses hosted desktops through a virtual desktop implementation, this practice likely costs even more.

So turn them off. Remember that many environments enforce screensavers through group policies, which may mean an exclusion from existing group and corporate security policies.

2: Managing from the console
As with screensavers, this practice is a big no-no in virtualized environments because of the level of resources required to create and maintain an instance of the Explorer shell. Just logging into a virtual machine is hard on that VM's processor utilization. The process of creating a shell for the console can spike processor utilization during the login and logout process. Actually using any of the consoles on that server further consumes valuable resources. Logging in and accomplishing activity on your VMs' desktops increases the amount of memory they consume.

Microsoft provides the Remote Systems Administration Toolkit, PowerShell and VBScript, as well as many other tools for efficient virtual machine management. All these lightweight tools require much less VM capacity than a traditional login. So use them, and avoid wasting processing power and memory like an amateur.

3: Antivirus and anti-malware scanning of VM disk files
Your corporate security policy might not allow for the exclusion of Virtual Hard Disk or Virtual Machine Disk Format (VMDK) files from antivirus and anti-malware scans. But be aware that the real-time scans of such products can substantially reduce the overall performance of these files -- and, thus, their virtual machines. Since a VM's processing is highly dependent on its disk subsystem, any extra activities that slow down that process slow it down as well.

That's not to say that VM disk files shouldn't be subject to security scanning. Scheduled scans of such files can ensure that they don't get infected, without the processing overhead of real-time scans. Also, some of today's more advanced scanning products are beginning to incorporate virtualization awareness to reduce their overall impact. If your security policy will allow it -- or if you can bribe your security officer to look the other way -- definitely consider excluding these files from your real-time scans.

4: Windows Server's power options
At conferences around the country, I've encountered the final mistake repeatedly. The default power option of Windows Server 2008 upon installation is set to "Balanced." Of the three options available -- Balanced, Power Saver and High-Performance -- this is the second of the three in terms of overall system performance. You might save a few dollars on energy, but at the cost of wasting some of the server's processing power. Resetting the radio button to the high-performance option has a noticeable effect on how well VMs will perform.

More information and source here.

Eduardo Petizme.com
Microsoft MVP – Most Valuable Professional
MCSA Security 2000 & 2003 | MCITP Server 2008
Blogs: http://blog.petizme.com ( USA | BRA )
Twitter: http://twitter.com/petizme

La pantalla azul de la muerte BSOD

juansa — Sun, 27 Sep 2009 05:00:00 GMT

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.

Clarifications of a stopped Active Directory

UlfBSimon-Weidner — Tue, 15 Sep 2009 05:00:00 GMT

In Windows Server 2008 you are able to stop Active Directory-Domain Services using the services snap-in or by typing

net stop ntds

However, this is for servicing only and not a state where the DC is intended to be kept for a longer period. Stopping AD is intended for servicing NTDS where there is a need of a stopped AD (such as in Directory Services Restore Mode, DSRM) but where is no need of a completely flushed Memory and stopped dependencies. So what you can do are things like offline defragmentation of the database or moving the database a.s.o.

I think, this is a good feature. Yes, it would be great to do other things. Yes, it would be great to restore AD without going in DRSM. There are things which would be nice. However … it’s better than before, and that’s what is important.

I love to do things using scripts. I love to use a toolbox, some script I’ve used before. Imagine – in the past doing offline defrags of the Active Directory database would require to reboot into Directory Service Restore Mode, log on as local admin (=DSRM-admin) then run ntdsutil with the options to do offline defrag into new files, then copy the new files over the old ones, reboot again into full more.

However, in Windows Server 2008 and above it is as easy as stopping NTDS, offline defrag, moving, starting NTDS.

It is urgent that you keep in mind that you can stop NTDS, however it’s not ment to be there for a longer period.

However, three things which made me worry if this feature is not well understood:

It’s not a state to keep for a longer period, not a replacement for recovery-DCs (which are turned off in the closet).
Not a replacement for DSRM when it comes to System State Recovery / Authoritative Restore which a Backup restored. If you need to restore a system state backup, the only supported way is to do it in DSRM.
Authoritative marking object which haven’t been replicated to the DC in question is OK, same goes for file-management operations other than restoring a backup (the content of the dit basically needs to remain the same)
You can’t logon with the DSRM-Admin when NTDS is stopped. This was hitting – in the beta-timeframe – someone who had a single DC, stopped NTDS, speared some time (screen saver kicked in) and couldn’t log on. DSRM-logon is not possible by default with a stopped NTDS when there are not other logon-servers available (if they are, e.g. you have a second DC, they are authenticating you on the DC with the stopped NTDS).
DSRM-Admin (which equals to local admin on a DC) is only available on Small Business Server (by default) or if you modified the following registry-key:
HKLM\System\CurrentControlSet\Control\Lsa\DSRMAdminLogonBehavior
Value 0: DSRM-Logon only when in DSRM (default)
Value 1: DSRM-Logon only when NTDS stopped (or DSRM) (default in
Value 2: DSRM-Logon always

HTH, Ulf

Los contadores de rendimiento: Procesador

juansa — Mon, 24 Aug 2009 05:00:00 GMT

Procesador

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

Tipo de contador:	Intervalo (% Ocupado)
Descripción:	Media de uso global del procesador en el intervalo. Cada intervalo en el que el procesador no ejecuta el hilo IDLE se supone que está ocupado por alguna carga de trabajo real.
Medición:	Se toma una muestra del estado del procesador una vez cada periodo del intervalo por una función de medida del sistema. El contador % de tiempo de procesador se computa desde un ratio de muestras comparadas entre su ejecución e IDLE. (100% – ((Muestras – Idle) / Muestras 100)*
Uso:	Indicador del uso global del procesador.
Rendimiento:	Indicador para determinar si el procesador es un cuello de botella.
Programación:	Tendencia y previsión del uso del procesador.
Que hace:	Periodos sostenidos de uso del 100% pueden significar un proceso fuera de control.
Alerta de umbral:	80/90%
Medidas relacionadas:	Processor(_Total)\% Privileged Time (\Procesador()\% de tiempo privilegiado) Processor(_Total)\% User Time* (\Procesador()\% de tiempo de usuario) Processor(n)\% Processor Time* (\Procesador()\% de tiempo de procesador) Process(n)\% Processor Time* (\Proceso()\% de tiempo de procesador) Thread(n/Index#)\% Processor Time (\Subproceso()\% de tiempo de procesador)

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

Tipo de contador:	Instantáneo
Descripción:	Número de subprocesos que se han observado como retrasados en la cola del procesador y que esperan para su programación de ejecución. Se ordenan por prioridad, la mayor prioridad se programa para ejecutarse en cuanto el procesador entra en el subproceso IDLE.
Medición:	Se toma una muestra cada periodo de tiempo de un intervalo. La muestra informa el valor último visto en la medida, obtenido por la función de medida del procesador que se ejecuta periódicamente.
Uso:	Muchos procesos de programas están dormidos en estados voluntarios de espera. El subconjunto de subprocesos activos establece un límite superior práctico de la longitud de la cola del procesador que puede observarse.
Rendimiento:	Indicador secundario para determinar si el procesador es un cuello de botella.
Programación:
Que hace:	Una indicación de la limitación de la capacidad del procesador por causa de excesivos retrasos de aplicaciones.
Alerta de umbral:	Longitud mayor de 5.
Medidas relacionadas:	Thread(parent-process\Index#)\Thread State (\Subproceso(*)\Estado de subproceso)

Los contadores de rendimiento: el sistema

juansa — Tue, 18 Aug 2009 05:00:00 GMT

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)

Tipo de contador:	Tiempo transcurrido
Descripción:	Nos muestra el tiempo, en segundos, que el equipo lleva activo desde el último inicio/reinicio.
Medición:	Sus valores son acumulados hasta que se reinicia el sistema.
Uso:	Indicador primario de la disponibilidad del sistema.
Rendimiento:
Programación:
Que hace:	Informa de la disponibilidad del sistema.
Alerta de umbral:
Medidas relacionadas:	Process(n)\Elapsed Time (\Proceso(*)\Tiempo transcurrido)

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

Tipo de contador:	Tiempo transcurrido
Descripción:	Nos muestra el tiempo, en segundos, que el proceso lleva activo desde el último inicio/reinicio.
Medición:	La instancia de proceso sólo existe durante un intervalo en el cual se encontró al proceso en ejecución al final del intervalo. Los valores son acumulados a través de intervalos medidos mientras el proceso se está ejecutando.
Uso:	Indicador primario de la disponibilidad de la aplicación. En el caso de servicios del sistema, comparándolo con System\System Up Time (\Sistema\Tiempo de actividad del sistema) nos servirá para determinar si la aplicación ha estado disponible continuamente desde que el equipo se inició/reinició.
Rendimiento:
Programación:
Que hace:	Informa de la disponibilidad del sistema.
Alerta de umbral:
Medidas relacionadas:	System\System Up Time (\Sistema\Tiempo de actividad del sistema)

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 ().

Configurar archivos seguimiento con Logman

juansa — Fri, 14 Aug 2009 05:00:00 GMT

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

Sintaxis:

Comando de logman	Qué hace
create trace <nombre>	Crea una colección de consultas o de registro de contador o de sesión de seguimiento.
update <nombre>	Actualiza una colección existente modificando los parámetros.
delete <nombre>	Elimina una colección existente.
query <nombre>	Lista las colecciones definidas y su estado sin el <nombre> con él mostrará las propiedades de la colección especificada. Si es en equipos remotos añadiremos la opción –s.
query providers <proveedor>	Mostrará en pantalla una lista de los parámetros que pueden establecerse para el proveedor especificado, sus valores y descripciones de lo que habilitan. Esto depende del proveedor.
start <nombre>	Inicia una sesión manualmente.
stop <nombre>	Detiene una sesión manualmente.

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:

*Parámetro*	*Sintaxis*	*Función*	*Observaciones*
Activar proveedor(es) de seguimiento	-p {GUID} [(flags[,flags…])] Level \|	Proveedores a utilizar en la sesión.	Con –pf archivo para usar los de un archivo de configuración.
Tamaño búfer	-bf valor	Tamaño en KB del búfer de la sesión.	En caso de ocurrir sucesos más rápido que su guardado en disco y para evitar su pérdida, un tamaño grande de búfer será de gran ayuda.
Número de búferes	nb min max	Cantidad mínima/máxima de búferes para la sesión.	El mínimo predeterminado es el número de procesadores más 2 y como máximo 25.
Establecer opciones de modo de seguimiento	-mode [modo[modo…]]	El modo puede ser globalsequence, localsequence o pagedmemory.	La opción pagedmemory utiliza búferes de memoria paginable.
Resolución del reloj	-ct {system \| perf \| ciclo}	perf y ciclo usan 100 ns de temporizador contra un ms del reloj del sistema.	ciclo usa menos tiempo de proceso. perf proporciona una resolución de temporizador más exacto.
Creación e inicio de sesión de seguimiento	-ets	Iniciar una sesión usando los parámetros definidos en el símbolo del sistema para esta sesión.
Equipo	-s Equipo	Especifica el equipo del que se quieren recoger los contadores.	Si no se especifica se toma el equipo local.
Sesión en tiempo real	-rt	Muestra en pantalla los datos en tiempo real. No los guarda en ningún archivo.
Seguimiento en modo usuario	-ul	El seguimiento se realiza en modo usuario.	En este modo, un proveedor puede habilitarse para la sesión de seguimiento de sucesos.
Nombre archivo de salida	-o {Ruta \|	Se especifica el archivo de salida, si no existe, se crea.	Es obligatorio. Los archivos son en formato binario con la extensión *.etl.
Nombrado archivos	- v {NNNNNN \| MMDDHHMM}	Genera archivos con nombres únicos sea numerándolos consecutivamente o añadiendo la hora y la fecha al nombre.
Vaciado de búferes	-ft [[HH]:MM:]SS	Los búferes se vacían después del tiempo especificado.
Límite tamaño archivo	-max valor	Tamaño máximo del archivo o BD en MB.	El registro finaliza al alcanzar el tamaño.
LoggerName	ln LoggerName	Un nombre definido de usuario para la sesión.	Predeterminadamente este nombre es el de la colección.
Añadir	-a	Añade los datos de salida a un archivo existente.
Comienzo sesión	-b M/D/YYYY H:MM:SS [{AM \| PM}]	Inicia la sesión en la fecha y hora designada.
Fin de sesión	-e M/D/YYYY H:MM:SS [{AM \| PM}]	Finaliza la sesión en la fecha y hora designada.	Con –r se establece la duración de sesión.
duración	-rf [[HH:]MM:]SS	Finaliza la sesión pasado el tiempo especificado.	Con –e se establece la fecha y hora de finalización.
Repetir	-r	Repetición cada día a la misma hora. El periodo de tiempo se basa en alguna de las opciones –b con –rf, o –b con –e.	uso conjuntamente con las opciones –cnf, –v y –rc.
Inicio y detención de colección	-m [start] [stop]	Inicio y detención de la sesión interactiva manualmente.
Usuario y contraseña	-u usuario contraseña	Se especifica usuario y contraseña para acceso a equipo remoto.

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

Investigación de eventos

juansa — Tue, 11 Aug 2009 05:00:00 GMT

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

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.
Clic derecho sobre el panel, el menú contextual nos muestras dos opciones de creación de nuevos registros:
Se nos pide un nombre para el registro:

y se muestra el cuadro de configuración.
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.
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.

Pestaña	Configuración	Notas
General	Selección de proveedores Cuenta y contraseña.	Podemos reunir datos desde el equipo local únicamente. Configura los sucesos del proveedor del sistema. Podemos usar Ejecutar como (Run As) para proporcionar usuario y contraseña en caso de equipos remotos.
Archivos de registro	Tipo de archivo. Nombrado automático.	Los archivos de seguimiento son archivos binarios con la extensión *.etl. Podemos seleccionar o binarios circulares –cuando llegan al final comienzan de nuevo por el principio del archivo sobrescribiendo los existentes-, o binarios secuenciales. Configuración de ubicación, nombre y tamaño de archivo. Podemos elegir una secuencia de números a añadir o la hora y la fecha, para identificar al archivo.
Programación	Métodos de inicio/detención manual o automáticos. Horas de inicio/detención automáticos. Detención automática cuando el archivo alcanza su límite de tamaño. Proceso cuando el archivo se cierra.	Podemos especificar que se detenga la recogida de datos cuando el archivo esté lleno. Inicio y detención según la hora del día, o especificar la hora de inicio y su duración. En casos de recogida de datos continua, iniciar un archivo nuevo en cuanto el archivo se cierra. También podemos iniciar automáticamente la ejecución de un comando al cerrarse el archivo.
Avanzada	Tamaño de búfer. Búferes mínimos y máximos. Transferencia de datos desde el búfer al archivo de registro.	Aumentar el número de búferes en caso de seguimiento de demasiados sucesos. El tiempo máximo en segundos, que las entradas de seguimiento se mantienen en memoria sin transferirse al archivo de seguimiento en el disco.