Solución de problemas de rendimiento de IIS o errores de aplicación al usar LogParser

por Benjamin Perkins

Herramientas y conocimientos usados en este solucionador de problemas

Información general

Este solucionador de problemas le ayudará a analizar los archivos de registro de IIS con el fin de determinar la causa cuando una aplicación hospedada en IIS produce errores o experimenta problemas de rendimiento. Antes de comenzar, es importante tener en cuenta que todos los campos que IIS puede registrar no están habilitados de forma predeterminada. Por ejemplo, no se seleccionan bytes enviados y bytes recibidos , pero son muy útiles al solucionar un problema de rendimiento. Por lo tanto, el mejor momento para incluir estos campos adicionales es antes de experimentar problemas del sistema. Por lo tanto, si aún no lo ha hecho, seleccione estos campos adicionales, le ayudará a encontrar soluciones cuando se produzcan problemas.

En el blog siguiente se describe cómo realizar esto en IIS 7 y versiones posteriores:

Modificación de los datos de registro de IIS 7 en Windows 2008

Escenario

Como administrador de sistemas, comienza a escuchar informes de los usuarios del sistema hospedados en IIS que la respuesta es lenta. Hay algunas menciones que los exploradores web simplemente agota el tiempo de espera o dejan de responder completamente cuando acceden a su sitio web.

Entra en acción y recicla el proceso de trabajo; todo parece estar trabajando de nuevo, como es normal.

Sin embargo, no puede aceptarlo como solución y debe saber por qué sucedió esto, pero no sabe dónde empezar. No tiene detalles de los usuarios, como códigos de error, capturas de pantalla y peor, no tiene datos de rendimiento para comparar lo que acaba de suceder con el rendimiento normal. En muchos casos, otros problemas nuevos le quitan de cualquier análisis serio de causa principal.

LogParser de Microsoft es una buena herramienta que es rápida y fácil de usar. En muchas situaciones, la herramienta le ayudará a comprender rápidamente lo que sucedió en el servidor y puede ayudarle a identificar problemas. Puede tomar la información que recopile con LogParser y pasarla al equipo de base de datos, al equipo de red o a los desarrolladores para obtener más análisis.

Recopilación de datos

De forma predeterminada, los archivos de registro de IIS se encuentran en los directorios siguientes:

  • IIS 7 y versiones posteriores: %SystemDrive%\inetpub\logs\LogFiles
  • IIS 6 y versiones anteriores: %WinDir%\System32\LogFiles

En este solucionador de problemas, usaré IIS 8. Abra el Administrador de IIS y seleccione Sitios, como se muestra en la figura 1. Esto le mostrará el identificador de cada sitio web hospedado en el servidor. Necesitará este identificador para determinar qué directorio W3SVC* se va a analizar.

Captura de pantalla de la ventana I S Manager en la que se muestran sitios en el panel principal.
Figura 1: Obtención del identificador del sitio web

Abra el Explorador de Windows y vaya al directorio que contiene los archivos de registro de IIS del sitio web que experimentaron el problema de rendimiento. En la figura 2 se muestra el aspecto que podría tener.

Captura de pantalla del Explorador de Windows en la que se muestran las ubicaciones de los archivos.
Figura 2: Ubicación del archivo de registro de IIS

Los archivos de registro de IIS pueden ser bastante grandes; por ejemplo, en la figura 2, el archivo de registro u_ex12101858.log tiene casi 100 MB de tamaño. Dado que estos archivos de registro pueden ser enormes y contener cientos de miles de entradas de archivo de registro individuales, examinar manualmente cada uno de estos archivos para un error no es un buen enfoque y devuelve pocos resultados durante el tiempo invertido.

Esto es cuando LogParser se convierte en una herramienta indispensable en el arsenal de solución de problemas.

Análisis de datos

El primer paso consiste en determinar qué archivos de registro pueden contener errores. Por ejemplo, si los clientes se quejaban sobre el rendimiento el 3 de junio de 2012, el archivo de registro podría ser u_ex120603.log, donde:

  • "12" es el año abreviado para 2012
  • "06" hace referencia al sexto mes (junio)
  • "03" es el tercer día del mes

Nota: En el ejemplo anterior se supone que el registro de IIS está configurado para rotar los archivos de registro diariamente, que es el valor predeterminado. Si ha cambiado la configuración de IIS para rotar los archivos de registro en un intervalo de tiempo diferente, como semanal o por hora, los nombres de los archivos de registro serían diferentes. Para obtener más información sobre la sintaxis de los nombres de archivo de registro de IIS, consulte el artículo Sintaxis de nomenclatura de archivos de registro de IIS (https://support.microsoft.com/kb/242898).

Nota

De forma predeterminada, la fecha y hora de los registros de IIS se almacenan mediante GMT; Deberá tener esto en cuenta al determinar qué registros contienen errores. Dicho esto, puede ajustar las fechas y horas mediante la función de TO_LOCALTIME() LogParser, como se muestra en el ejemplo siguiente:

Nota

logparser.exe "SELECT TO_STRING(TO_LOCALTIME(TO_TIMESTAMP(date,time)),'yyyy-MM-dd hh:mm:ss') AS LocalTime,
COUNT(*) AS Hits FROM *.log WHERE date='2012-10-18'
GROUP BY LocalTime ORDER BY LocalTime" -i:w3c

Una vez que haya identificado los archivos de registro de IIS que contienen errores, debe copiarlos en una ubicación donde se puedan analizar. Este paso es opcional, pero no se recomienda analizar los registros en el servidor IIS, ya que las consultas logParser pueden tardar mucho tiempo en ejecutarse y, si los archivos de registro son grandes, el analizador de registros puede competir por los recursos del sistema.

Por ejemplo, puede copiar los registros de IIS en una carpeta del equipo personal en el que ya ha copiado los archivos LogParser, que es la forma en que normalmente se analizan mis archivos de registro. En la figura 3 se muestra un ejemplo de dónde los he almacenado para crear este artículo.

Captura de pantalla del Explorador de Windows que muestra la ubicación del ejecutable del analizador de registros.Figura 3: Archivos de registros de IIS hospedados localmente para su análisis mediante LogParser

Después de haber descargado LogParser, está listo para comenzar el análisis. La primera consulta que ejecuto se muestra en la figura 4. Los resultados proporcionan información general sobre cómo IIS ha respondido a las solicitudes.

logparser.exe "SELECT sc-status, sc-substatus, COUNT(*) FROM *.log GROUP BY sc-status, sc-substatus ORDER BY sc-status" -i:w3c
    
    sc-status sc-substatus COUNT(ALL *)
    --------- ------------ ------------
    200       0            3920658
    206       0            2096
    301       0            1031
    302       0            65386
    304       0            178705
    400       0            35
    401       2            692096
    404       0            2935
    404       11           7
    405       0            1
    406       0            36
    500       0            11418
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    12
    Execution time:     7.70 seconds

Figura 4: Consulta logParser (sc-status y sc-substatus)

Los puntos de interés dentro de los resultados son:

  • La proporción entre 200 y 304 códigos de estado HTTP (solicitudes correctas)
  • Número de 500 códigos de estado HTTP (solicitudes con error)

A continuación se explica la importancia de cada uno de estos códigos de estado.

La relación entre los códigos de estado HTTP 200 y 304 (analizando solicitudes correctas)

La relación entre los códigos de estado HTTP de 200 y 304 es importante porque muestra cuántas solicitudes se recuperan de la memoria caché de los clientes en lugar de directamente desde el servidor. Los resultados de la figura 4 muestran que hay 3 920 658 solicitudes que dieron lugar a un código de estado HTTP de 200. Esto significa que el archivo solicitado se ha servido desde el servidor cada vez. Por el contrario, había 178 705 solicitudes que dieron lugar a un código de estado HTTP 304. Esto significa que el archivo solicitado se recuperó de la memoria caché local. En otras palabras, el 95,5 % de las solicitudes se administran desde el servidor.

El almacenamiento en caché puede tener un impacto muy positivo en el rendimiento del sistema; consulte los detalles de la compresión estática y dinámica en el artículo Configuración de la compresión HTTP en IIS 7 .

Códigos de estado HTTP 500 (análisis de solicitudes con error)

Los códigos de estado HTTP 500 pueden indicar problemas graves en el sistema. El nivel de impacto que puede tener la causa principal de un error HTTP 500 en el sistema puede ir de nada al bloqueo de un proceso de trabajo. Por lo tanto, cuando los vea, debe ejecutar la consulta que se muestra en la figura 5 para encontrar qué solicitudes dieron lugar a un código de estado HTTP 500.

logparser.exe "SELECT cs-uri-stem, COUNT(*) FROM *.log WHERE sc-status=500 GROUP BY cs-uri-stem ORDER BY COUNT(*) DESC" -i:w3c
    
    cs-uri-stem                 COUNT(ALL *)
    --------------------------- ------------
    /ShoppingCart/ViewCart.aspx 1378
    /DataService.asmx           1377  
    /Start/default.aspx         949
    /GetDetailsView.aspx        753
    /Details/ImageUrls.asmx     722
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    5
    Execution time:     24.89 seconds

Figura 5: Consulta logParser (cs-uri-stem con un estado de 500 sc)

Estos resultados muestran la ruta de acceso y el nombre del archivo que, cuando se solicita, respondió con un código de estado HTTP 500. Este tipo de información sería valioso para el equipo de desarrollo. Por ejemplo, el equipo de desarrollo podría buscar más en ese código específico y buscar código que se ejecuta sin estar contenido en un try {...} catch {...} bloque de código, o está ejecutando consultas de datos de gran tamaño que deben optimizarse.

Vamos a dar este ejemplo un paso más adelante y centrarnos en el colaborador principal para los códigos de estado HTTP 500. Sería interesante saber cuándo se produjeron estos errores, ya que esta información se puede usar para comprobar si las dependencias tenían algún problema al mismo tiempo.

logparser.exe "SELECT TO_STRING(TO_TIMESTAMP(date,time),'yyyy-MM-dd hh') AS Hour,
COUNT(*) FROM *.log WHERE sc-status=500 AND cs-uri-stem='/Start/default.aspx' AND date='2012-10-18' GROUP BY Hour ORDER BY Hour" -i:w3c
    
    Hour          COUNT(ALL *)
    ------------- ------------
    2012-10-18 08 191
    2012-10-18 09 163
    2012-10-18 14 150
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    3
    Execution time:     6.36 seconds

Figura 6: Consulta logParser (cs-uri-stem con un estado de 500 sc)

El subconjunto de resultados de la figura 6 restringe el intervalo de fechas del problema. Esta información se puede pasar a la red, la base de datos, los administradores del sistema operativo y los equipos de desarrollo para comprobar si algo más estaba ocurriendo al mismo tiempo. Por ejemplo: ¿Hubo problemas adicionales entre las 08:00 y las 09:59:59 GMT y entre las 14:00:00 y las 14:59:59 GMT?

El siguiente conjunto de consultas de LogParser utiliza los siguientes campos, lo que puede proporcionar una mejor visión de los problemas de rendimiento:

Campo Descripción Habilitado de forma predeterminada
tiempo necesario El tiempo durante el que se realizó la acción, en milisegundos Yes
sc-bytes Número de bytes enviados por el servidor No
cs-bytes Número de bytes que recibió el servidor No

Como se mencionó anteriormente, tómese el tiempo ahora para solicitar que los campos sc-bytes y cs-bytes estén habilitados o, si es posible, habilite usted mismo. Proporcionan información valiosa sobre el sistema y su comportamiento. Tome la figura 7, por ejemplo. Ves que el tiempo medio es bastante bueno en unos cientos de milisegundos. Sin embargo, examine el tiempo máximo necesario, es decir, demasiado tiempo.

logparser.exe "SELECT  cs-method, COUNT(*) AS TotalCount, MAX(time-taken) AS MaximumTime, AVG(time-taken) AS AverageTime FROM *.log GROUP BY cs-method ORDER BY TotalCount DESC" -i:w3c
    
    cs-method TotalCount MaximumTime AverageTime
    --------- ---------- ----------- -----------
    GET       3172034    1366976     153
    POST      1011765    256539      359  
    HEAD      5363       26750       209  
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    3
    Execution time:     6.36 seconds

Figura 7: Consulta logParser ( tiempo máximo y promedio necesario)

Sé que te estás preguntando ya la siguiente pregunta que debe responderse. ¿Qué solicitud tarda tanto tiempo? En la figura 8 se muestra la respuesta a esa pregunta. Como observará, he seguido e incluido el campo sc-bytes en la consulta LogParser. Recuerde que sc-bytes representa el tamaño del archivo enviado desde el servidor de vuelta al cliente.

logparser.exe "SELECT cs-uri-stem, time-taken, sc-bytes FROM *.log WHERE time-taken > 250000 ORDER BY time-taken DESC" -i:w3c
    
    cs-uri-stem                 time-taken sc-bytes
    --------------------------- ---------- --------
    /ShoppingCart/ViewCart.aspx 1366976    256328
    /DataService.asmx           1265383    53860
    /Start/default.aspx         262796     8077
    /GetDetailsView.aspx        261305     5038
    /Details/ImageUrls.asmx     256539     2351
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    5
    Execution time:     8.98 seconds

Figura 8: Consulta logParser (tiempo máximo y promedio necesario)

Es probable que todos acepten que el tiempo necesario para las solicitudes supera un tiempo de respuesta "normal". Sin embargo, el tamaño de los archivos es algo que el administrador o desarrollador tendría que analizar para determinar si los tamaños están dentro de un intervalo aceptable.

La conclusión es que el archivo GetDetailsView.aspx ha producido un número de 500 códigos de estado HTTP y ha tardado mucho tiempo en completarse, aunque era un archivo relativamente pequeño. Es posible que desee examinar la fecha y hora en que se produzcan problemas para este archivo y examinar el código del archivo con cualquier problema que se haya producido. (Por ejemplo, los registros de IIS contienen una lista de variables que se pasaron en la cadena de consulta; podría comprobar esos valores de datos incorrectos).

Los ejemplos proporcionados en las figuras 4- 8 ayudan a comprender dónde puede existir la causa principal de un problema. Sin embargo, es probable que este análisis solo haya representado una mejor vista de la situación que llevará a más preguntas y análisis más profundos. Si ese es el caso, es posible que desee crear una representación de estos datos de una manera más presente. En la sección siguiente se trata con detalle.

Notificación

Capturas de pantalla de una ventana de comandos que contiene consultas logParser y sus resultados pueden estar bien durante la fase de análisis de un problema de rendimiento; sin embargo, si necesita ir delante de los directores o directores para explicar lo que ha ocurrido, es posible que no cumpla la marca.

Nota

Para que el gráfico funcione a través de LogParser, deberá instalar el Office Web Components. En los artículos siguientes se explica cómo hacerlo:

En la figura 9 se muestra la consulta LogParser para crear un gráfico circular 3D que contiene el número de solicitudes y su código de estado HTTP asociado. He quitado el estado 200, ya que son correctos. Lo que estoy después de aquí son las solicitudes que son algo que no es correcto.

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO status.gif FROM *.log WHERE sc-status > 200 GROUP BY Status ORDER BY Status" -i:w3c -o:CHART -chartType:PieExploded3D -ChartTitle:"Request Status"
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    10
    Execution time:     6.20 seconds

Figura 9: Consulta LogParser (Crear un gráfico circular 3D)

El resultado de la consulta se muestra en la figura 10. Hay una serie de parámetros adicionales que puede pasar a LogParser que afectan a la imagen. Por ejemplo, leyenda, groupSize, configuración, etc. Para obtener una lista completa, escriba: LogParser -h -o:CHART para obtener una lista de todos los parámetros. Este comando también proporcionará una lista de los diferentes tipos de gráfico.

Diagrama de un gráfico circular tridimensional que muestra las asignaciones de estado de la solicitud.
Figura 10: Gráfico circular 3D de LogParser

Otro gráfico útil es la relación entre las solicitudes almacenadas en caché y reales. Recuerde de la sección Análisis de datos, donde he explicado que un código de estado HTTP de 200 significa que los archivos solicitados se recuperan del servidor, sin embargo, se recupera un 304 del cliente. En la figura 11 se muestra la consulta LogParser para la creación de este gráfico. Observe que he usado el parámetro -values .

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO cache.gif FROM *.log WHERE sc-status=200 OR sc-status=304 GROUP BY Status ORDER BY Status" -i:w3c -o:CHART -chartType:PieExploded3D -ChartTitle:"Cache" -values:ON
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    2
    Execution time:     6.35 seconds

Figura 11: Consulta logParser (crear un gráfico circular 3D)

Aunque la diferencia entre el código de estado HTTP 200 y 304 son claramente visibles, pensé que podría agregar algún valor para incluir el número de aciertos de cada uno. En la figura 12 se muestra la salida de la consulta LogParser anterior.

Diagrama de un gráfico circular tridimensional que muestra la asignación de caché.
Figura 12: Gráfico circular 3D de LogParser

Creo que ahora está obteniendo la imagen sobre cómo trazar los registros de IIS mediante LogParser puede ayudar a transmitir lo que sucede mucho mejor que una tabla de datos. Pero antes de detener, quiero mostrar un ejemplo más con el tipo de gráfico Columna. La consulta LogParser que se muestra en la figura 13 genera un gráfico de columnas 3D que muestra el recuento de 500 códigos de estado HTTPS por hora.

logparser.exe "SELECT to_string(to_timestamp(date, time), 'yyyy-MM-dd hh') AS Hour, COUNT(*) AS Count INTO 500.gif FROM *.log WHERE sc-status=500 GROUP BY Hour ORDER BY Hour" -i:w3c -o:CHART -chartType:Column3D -ChartTitle:"500 Errors by Hour"
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    13
    Execution time:     6.32 seconds

Figura 13: Consulta logParser (crear un gráfico de columnas 3D)

El gráfico resultante se muestra en la figura 14.

Diagrama de un gráfico de columnas tridimensionales que muestra el número de errores 500 por hora por fecha.
Figura 14: Gráfico de columnas 3D de LogParser

Creación de gráficos mediante Excel y CSV

Al principio de esta sección he mencionado que la instalación del componente web de Office (OWC) es un requisito si desea usar las funcionalidades de gráficos de LogParser. En su organización, puede haber restricciones que prohíben esto o simplemente no desea instalarlo. Si alguno de los casos es así, considere la posibilidad de exportar el resultado de la consulta LogParser a un archivo CSV e importarlo en Excel.

En la figura 15 se muestra la consulta LogParser que extrae los códigos de estado HTTP para todas las solicitudes que no son de 200 a un archivo CSV.

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO status.csv FROM *.log WHERE sc-status > 200 GROUP BY Status ORDER BY Status" -i:w3c -o:csv
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    10
    Execution time:     6.20 seconds

Figura 15: Consulta logParser (crear un archivo CSV para la importación en Excel)

Observe en la figura 15 que he usado el parámetro -o para que LogParser cree la salida en formato CSV.

Para importar el archivo CSV en Excel para que se pueda crear un gráfico a partir de él, abra Excel, vaya a la pestaña DATOS y seleccione Desde texto. En la figura 16 se muestra el aspecto que tiene.

Captura de pantalla que muestra las opciones de menú de la pestaña Datos de Excel.Figura 16: Importación de un archivo CSV creado por LogParser en Excel

Seleccione el archivo status.csv creado por la consulta LogParser y navegue por el Asistente para importación. Importe el archivo CSV delimitado por comas y terminará con el estado de la columna A y el número de repeticiones de cada estado de la columna B. Esto supone que ha ejecutado la consulta LogParser que se muestra en la figura 15. Por último, seleccione todos los datos de la columna A y B, incluidos los encabezados y elija el tipo de gráfico circular que se va a crear. En la figura 17 se muestra cómo puede tener este aspecto.

Captura de pantalla que muestra las opciones de pestaña Insertar de Excel. Se seleccionan los datos de las columnas A y B.Figura 17: Crear un gráfico circular mediante un archivo CSV

El resultado final es un gráfico circular, figura 18 similar al que se mostró anteriormente en la figura 10. Hay muchas opciones en lo que respecta al color, el tipo de gráfico, las etiquetas, etc. Con un clic de un botón, puede cambiar el tipo de gráfico de Pie a Barra o Línea. Hay muchas opciones para crear gráficos de aspecto profesional en Excel.

Captura de pantalla de un gráfico circular tridimensional que muestra el estado de la solicitud.
Figura 18: Gráfico circular con un archivo CSV similar a la figura 10

Hay tantas opciones y posibilidades para analizar y presentar los resultados de ese análisis mediante LogParser. Para obtener algunas sugerencias y ejemplos adicionales, consulte estos artículos escritos por Robert McMurray. También hay un archivo de ayuda muy útil y muchos scripts preescritos proporcionados dentro del paquete de instalación de LogParser. En la sección siguiente se analizará esto y otros temas con más detalle.

Ayuda

Al instalar LogParser 2.2 en el equipo, se instala de forma predeterminada en el C:\Program Files (x86)\Log Parser 2.2 directorio . Vaya a esa ubicación y revise los directorios Samples\Queries y Samples\Scripts para obtener una abundante oferta de código preescrito que le permitirá moverse rápidamente.

También se dará cuenta de una gran ventaja leyendo el contenido dentro del archivo LogParser.chm.

Reducción del tamaño o división de archivos de registro de IIS

Es posible que encuentre una situación en la que el archivo de registro de IIS sea demasiado grande para que LogParser consulte. Esto es lo más probable en una máquina de 32 bits, pero también puede ocurrir en una máquina de 64 bits. Sin embargo, si experimenta errores de "memoria insuficiente" al ejecutar una consulta logParser, considere la posibilidad de ejecutar el comando que se muestra en la figura 19. La consulta extrae algunos campos esenciales de un archivo de registro iiS grande y los coloca en otro, lo que da como resultado un archivo de registro más pequeño.

logparser.exe "SELECT date, time, c-ip, cs-uri-stem, cs-uri-query, sc-status, sc-substatus, sc-win32-status, sc-bytes, cs-bytes, time-taken INTO u_exJUSTRIGHT.log FROM u_exTOOBIG.log" -i:w3c -o:w3c
    
    Statistics:
    -----------
    Elements processed: 19712301
    Elements output:    19712301
    Execution time:     3.07 seconds

Figura 19: Reducir el tamaño de un archivo de registro de IIS (quitando campos)

En este ejemplo, me di cuenta de una reducción del tamaño de archivo de aproximadamente el 45 %. En muchos casos esto puede ser suficiente, en otros quizás no. Depende del tamaño del archivo de registro original. Si observa que todavía necesita reducir el tamaño del archivo de registro de IIS, considere la posibilidad de agregar una restricción de fecha y hora a la consulta LogParser, como se muestra en la figura 20.

logparser.exe "SELECT date, time, c-ip, cs-uri-stem, cs-uri-query, sc-status, sc-substatus, sc-win32-status, sc-bytes, cs-bytes, time-taken INTO u_exJUSTRIGHT.log FROM u_exTOOBIG.log WHERE to_timestamp(date, time) >= timestamp('2012-11-09 00:00:00', 'yyyy-MM-dd hh:mm:ss')" -i:w3c -o:w3c
    
    Statistics:
    -----------
    Elements processed: 240123
    Elements output:    240123
    Execution time:     0.45 seconds

Figura 20: Reducir aún más el tamaño de un archivo de registro de IIS agregando una cláusula WHERE

Se trata de una técnica valiosa para reducir el tamaño del archivo, pero también resulta útil quitar entradas no deseadas del registro de IIS. Por ejemplo, al empezar a solucionar un problema, se da cuenta de que no se registraban los bytes sc, sc-bytes y cs-bytes. Las habilitó en IIS y quiere que la consulta solo analice esas entradas con los campos habilitados recientemente. Use la instrucción where para extraer los datos del archivo de registro de IIS desde el momento en que se han habilitado esos campos. Esto es importante cuando se usan los agregados AVG, MIN y MAX.

Conclusión

LogParser es una herramienta pequeña pero eficaz para analizar varios tipos de registro del sistema diferentes. Este artículo se centra en las consultas aplicables a los registros de IIS. Cuando se producen problemas de rendimiento o errores en el entorno de IIS, a veces es difícil saber dónde empezar.

LogParser se puede usar como punto de partida, ya que un administrador del sistema que tiene algunas aptitudes sql puede crear rápidamente algunas consultas LogParser muy sofisticadas. Estas consultas se pueden usar para ampliar el análisis de la causa principal del problema.

Estos son los vínculos a los que se hace referencia en este artículo, además de algunos vínculos con información adicional.

  • Last updated on