Seguimiento

 

Rob Howard
Microsoft Corporation

25 de enero de 2001

Siempre que doy una presentación en ASP.NET, siempre es divertido watch el público cuando se demuestra la nueva funcionalidad de seguimiento. Para aquellos de nosotros que han creado soluciones con ASP, el seguimiento es un malditos!

En la columna de este mes, veremos la característica de seguimiento en ASP.NET. Comencemos por analizar la técnica de seguimiento común para ASP, Response.Write().

Seguimiento con ASP

Si es como yo, al codificar una aplicación ASP, se usan instrucciones Response.Write() cuando se desseca una sección problemática del código.

Este es un pseudocódigo para ilustrar este punto:

<%
On Error Resume Next 
Response.Write("About to do data access...")
Set objDB = Server.CreateObject("Custom.DataAccess")
objDB.Open("PersonalizationData")
user = objDB.Get("username")
Response.Write("Done calling data access. Value of username is:" + user)
%>

Las llamadas Response.Write() en el código anterior deben ser bastante familiares, es decir, tenemos un error con el comportamiento de nuestro código. El error no es necesariamente una aplicación o un error del sistema, como un error al cargar el objeto, sino un error de codificación en el que el código se ejecuta según lo esperado, pero no devuelve el valor esperado.

Por supuesto, también podemos usar un depurador, pero a veces es más rápido obtener una salida de seguimiento para averiguar lo que hace el código o simplemente dejarnos saber cómo se ejecuta una sección determinada del código.

Aunque las instrucciones Repsonse.Write() facilitan la depuración de la aplicación con bastante rapidez, introducen código innecesario en una aplicación que puede producir errores reales que interrumpen las aplicaciones implementadas. Por ejemplo, por lo general, no se considera algo bueno cuando olvidamos quitar una instrucción Response.Write() más colorida que podría expresar nuestros verdaderos sentimientos sobre el código en el que estamos trabajando.

Por supuesto, la misma funcionalidad de las instrucciones Response.Write() se admite en ASP.NET. De hecho, todavía me encuentro usando Response.Write() aunque ahora tengamos una característica de seguimiento. Los viejos hábitos son difíciles de romper.

Sin embargo, todos debemos intentar romper esos hábitos antiguos porque la nueva funcionalidad de seguimiento nos proporciona algo que no existía en el modo de depuración de ASP.

Seguimiento con ASP.NET

Las nuevas características de seguimiento de ASP.NET nos permiten simular instrucciones Response.Write(), pero no preocuparse por quitar las instrucciones antes de implementar nuestras aplicaciones. En su lugar, imagine que escribe el mismo código que antes, pero en lugar de usar Response.Write(), usamos Trace.Write().

El objeto Trace ahora es un objeto de página intrínseco, similar a Solicitud, Respuesta, Servidor, etc. Es accesible directamente con nuestro código de página.

Echemos un breve vistazo a la clase Trace .

Trace (clase)

El seguimiento se expone como una propiedad pública dentro de ASP.NET páginas. Cuando se usa la propiedad Trace , estamos trabajando con una instancia de la clase TraceContext definida en el espacio de nombres System.Web .

La clase Trace expone dos métodos sobrecargados y dos propiedades. Los dos métodos Warn() y Write(), ambos admiten dos prototipos idénticos:

VB.NET

Public Sub [Warn | Write](category As String, 
                          message As String, 
                          errorInfo As Exception)
End Sub
Public Sub [Warn | Write](category As String, 
                          message As String)
End Sub

C#

public void [Warn | Write](String category, 
                           String message, 
                           Exception errorInfo)
public void [Warn | Write](String category, 
                           String message)

El parámetro category se usa para identificar el nombre de categoría en el que escribir el valor del mensaje . Esto será más evidente cuando se usa el método Write() en un ejemplo siguiente. El tercer parámetro que admiten Warn() y Write() en sus métodos sobrecargados es errorInfo. Esto nos permite pasar detalles de excepción al sistema de seguimiento.

Propiedades

La clase TraceContext admite dos propiedades públicas: IsEnabled y TraceMode.

• IsEnabled indica si el seguimiento está habilitado en la página o en la aplicación.
• TraceMode establece o devuelve el modo de ordenación que usa el seguimiento. Veremos cómo configurar el modo de seguimiento cuando analicemos el seguimiento en el nivel de aplicación siguiente.

Ahora que hemos visto el aspecto de la clase y los métodos y las propiedades admitidos por la clase TraceContext, echemos un vistazo a un ejemplo de Trace.Write().

<Script runat=server>
Public Function Add(a As Integer, b As Integer) As Integer
  Trace.Write("Inside Add() a: ", a.ToString())
  Trace.Write("Inside Add() b: ", b.ToString())
  return a + b
End Function
</Script>
Call the Add routine: 4 + 5 = <%=Add(4,5)%>

Cuando se ejecuta este código, la salida es:

Figura 1. Ejemplo del método Trace.Write()

Obviamente se llama al método Add(). Sin embargo, a diferencia de las instrucciones Repsonse.Write(), las instrucciones Trace.Write() no aparecen dentro de la salida resultante. Para ver los resultados de las instrucciones Trace.Write(), es necesario habilitar el seguimiento de esta página o para la aplicación.

Para habilitar el seguimiento, podemos usar una directiva de página o una opción de configuración. Echemos un vistazo a ambos.

Directiva de seguimiento de página

Las directivas page son instrucciones especiales que ASP.NET usan al procesar una solicitud de un recurso de ASP.NET. Las directivas de página se pueden usar para invalidar o aplicar opciones de configuración para una página de ASP.NET.

Una directiva debe ser el primer elemento de una página. Se declara mediante la sintaxis siguiente:

<%@ Directive Attribute="[Value]" %>

Con la sintaxis anterior, esta es la forma en que se indica ASP.NET que nos gustaría habilitar el seguimiento en una página:

<%@ Page Trace="true" %>

Si agregamos la directiva anterior al código de ejemplo, la salida de la página tiene un aspecto bastante diferente:

Ilustración 2. Seguimiento habilitado

Ahora obtenemos la salida de seguimiento agregada a la parte inferior de la página. La salida de seguimiento siempre se agrega al final de la página.

A continuación, veamos cómo se habilita el seguimiento en un nivel de aplicación. A continuación, analizaremos lo que contiene la salida de seguimiento.

Seguimiento de aplicaciones

ASP.NET usa archivos de configuración XML para establecer opciones de configuración para ASP.NET aplicaciones. Cada ASP.NET instalación instala un archivo de configuración en el directorio [unidad del sistema]\WinNt\Microsoft.NET\Framework\[versión]\ denominado config.web.

El archivo de configuración establece la configuración predeterminada ASP.NET y en Beta 1 se conoce como archivo de configuración raíz. Los cambios realizados en este archivo afectan a todas nuestras ASP.NET aplicación web. También podemos usar archivos de configuración en nuestras aplicaciones web para agregar o quitar valores adquiridos de config.web predeterminados.

Trataré la configuración con más detalle en una columna futura. Por ahora, usaremos el archivo de configuración raíz para aplicar la configuración de seguimiento para todas las aplicaciones de ASP.NET.

Sección seguimiento

Si se abre el archivo config.web raíz, encontrará una sección de seguimiento:

<configuration>
    <trace
        enabled="false"
        requestlimit="10"
        pageoutput="false"
        tracemode="SortByTime"
    />
</configuration>

Hay cuatro atributos para el elemento de seguimiento :

• enabled = "[true/false]"— Podemos establecer la opción habilitada en true o false. El seguimiento está habilitado en un nivel de aplicación o está deshabilitado en el nivel de aplicación. Si establecemos enabled=false, el seguimiento de páginas sigue siendo compatible con la directiva Trace descrita anteriormente.
• requestlimit = " [int]": el número total de solicitudes de seguimiento para mantener almacenadas en caché la memoria por aplicación. El seguimiento expone un recurso especial( Trace.axd, que veremos momentáneamente) que se usa para ver la salida de seguimiento cuando pageoutput está establecido en false.
• pageoutput = " [true/false]"— Cuando el seguimiento está habilitado a través del archivo de configuración, el administrador puede habilitar o deshabilitar el seguimiento en cada página. El seguimiento de pageoutput habilita los detalles de seguimiento de cada página dentro de una aplicación. Sin embargo, el seguimiento de pageoutput puede desactivarse mientras el seguimiento en el nivel de aplicación todavía está habilitado (habilitado = "true"). Esto mantiene las solicitudes de seguimiento en la memoria, de modo que están disponibles a través de trace.axd, que veremos momentáneamente, pero no se mostrarán dentro de la salida de una página.
• tracemode = "[SortByTime | SortByCategory]": la configuración de tracemode nos proporciona control sobre cómo se genera la información detallada del seguimiento. Los datos se pueden ordenar por hora o categoría, donde la categoría se diferencia entre la configuración realizada por el sistema y la configuración Trace.Write() habilitada por el desarrollador. Por ejemplo, en nuestro ejemplo hemos usado lo siguiente: Trace.Write("Inside Add() a:", a.ToString()). El primer parámetro de la instrucción Trace.Write() es la categoría. En este caso, definimos la categoría como "Inside Add() a:". Si ordenamos por categoría (tracemode = "SortByCategory"), este elemento se ordenaría antes de que la función de página normal llame a en la salida de seguimiento. La ordenación por tiempo, por otro lado, se ordena por la cantidad de tiempo invertido en la llamada.

Uso del seguimiento de aplicaciones

Con el mismo código de ejemplo anterior, podríamos quitar la directiva de página y habilitar la misma funcionalidad modificando la configuración config.web de seguimiento.

<configuration>
    <trace
        enabled="true"
        requestlimit="10"
        pageoutput="true"
        tracemode="SortByTime"
    />
</configuration>

Ahora podemos llamar a nuestra aplicación de ejemplo, quitar la directiva Page y obtener la misma salida:

Figura 3. Seguimiento habilitado, sin directiva Page

Pero, ¿qué ocurre si queremos usar la característica mencionada anteriormente, en la que se habilita el seguimiento pero se deshabilita la salida en la página?

<configuration>
    <trace
        enabled="true"
        requestlimit="10"
        pageoutput="false"
        tracemode="SortByTime"
    />
</configuration>

Si solicitamos la aplicación de ejemplo con las opciones de configuración anteriores, no obtendríamos ninguna salida de seguimiento, aunque el seguimiento todavía está habilitado. Para ver la salida del seguimiento, usamos una aplicación especial denominada trace.axd.

Trace.axd

Trace.axd es un controlador Http. Un controlador http es una opción de codificación que nos permite controlar las solicitudes y respuestas en el nivel más básico. Los controladores HTTP son el equivalente de las extensiones ISAPI. Sin embargo, a diferencia de ISAPI, se pueden crear mediante cualquier lenguaje .NET. Analizaré los controladores http con más detalle en una columna posterior.

Trace.axd es un controlador Http que podemos usar para solicitar los detalles del seguimiento de la aplicación. Cuando se solicite, se le proporcionará un registro de seguimiento de las últimas n solicitudes; n viene determinado por el valor establecido por requestlimit="[int]" en nuestro archivo de configuración.

Para usar trace.axd, basta con solicitar trace.axd en el mismo directorio de aplicación que se realizó la solicitud de la aplicación de ejemplo:

Figura 4. Solicitudes de seguimiento de aplicaciones

Como puede ver en la captura de pantalla, se presenta una lista de seguimientos que podemos ver. Estas vistas de seguimiento son idénticas a los detalles que el seguimiento agregaría a la página, sin la salida de la página incluida:

Figura 5. Detalles de la solicitud

Ahora que hemos visto cómo configuramos y usamos el seguimiento, vamos a analizar la salida del seguimiento.

Interpretación de la salida de seguimiento

La salida proporcionada por la vista de seguimiento, ya sea a través de Trace.axd o en una página, proporciona seis secciones de detalle:

• Detalles de la solicitud: se trata de información básica, como el identificador de sesión, la hora de la solicitud, el tipo de solicitud Http y el código de estado de respuesta Http.
• Información de seguimiento: en esta sección se proporciona una vista de tabla de categorías y mensajes. Si usamos instrucciones Trace.Write() en nuestro código, los dos parámetros que Acepta Trace.Write() se usan como valores Category y Message , respectivamente. Además, se proporciona la hora del primer al último byte.
• Árbol de control: aunque aún no se ha analizado en esta columna, ASP.NET usa controles de servidor para permitirnos compilar aplicaciones mediante declaración. La sección Árbol de control nos proporciona información sobre los controles de nuestra página. Se proporcionan con el identificador, el tipo, el tamaño de representación y el tamaño de estado de vista del control. Esta información nos proporciona una idea de qué controles usamos, así como el costo asociado (tamaño de representación y estado de vista).
• Recopilación de cookies: se analizan las cookies que el cliente envía en los encabezados de solicitud y se muestran sus nombres, valores y tamaños.
• Colección Headers: los encabezados HTTP presentados por el cliente al servidor se proporcionan en esta sección. Se trata de una tabla simple que enumera nombre/valor.
• Variables de servidor: la sección variables de servidor presenta una tabla de pares nombre/valor de variables de servidor.

Uso del seguimiento

Como puede ver claramente, el seguimiento es una nueva característica de ASP.NET eficaz diseñada para facilitar el desarrollo de aplicaciones web. Sin embargo, pensé que también valdría la pena mencionar cuándo deberías y no deberías usar el seguimiento.

Aplicaciones implementadas

El seguimiento agrega sobrecarga adicional a las solicitudes y no debe habilitarse para las aplicaciones implementadas. Sin embargo, las instrucciones Trace.Write() se pueden dejar porque se omiten cuando el seguimiento no está habilitado.

En el caso de las aplicaciones implementadas en las que queremos capturar datos, sugeriría usar las clases que se encuentran en el espacio de nombres System.Diagnostics . Estas clases, que intentaré tratar en una columna futura, nos permiten escribir directamente en el registro de eventos de Windows.

Sin duda, deberíamos usar el seguimiento al compilar una aplicación, pero deshabilitarla cuando esté listo para implementar la aplicación, igual que habríamos quitado esas instrucciones Response.Write().

Deshabilitar Trace.axd

Si ha instalado ASP.NET en un servidor web de producción, se recomienda deshabilitar explícitamente Trace.axd. Abra el archivo config.web raíz, busque la <httphandlers> sección y agregue la entrada siguiente:

<configuration>
        <add verb="*" 
             path="trace.axd"
             type="System.Web.Handlers.TraceHandler" />
        <remove verb="*" path="trace.axd"/>
</configuration>

Nota: También podríamos cortar toda <add/> la entrada, pero la <remove> opción es mejor porque deja el código en nuestro archivo de configuración y logra el mismo objetivo, deshabilitando trace.axd. Esto se resolverá en la versión beta 2 de ASP.NET.

Resumen

La característica de seguimiento de ASP.NET es una nueva forma eficaz de realizar un seguimiento de lo que hace nuestra aplicación. En el pasado, usamos instrucciones Response.Write() para realizar un seguimiento de la aplicación mientras se ejecutaba, pero ahora podemos usar instrucciones Trace.Write() y dejar estas instrucciones en nuestro código implementado. Esto provoca menos errores porque no se quita código cuando estamos listos para implementar la aplicación.

recursos de ASP.NET

Por último, quería llamar a algunos de los nuevos recursos de ASP.NET disponibles. https://www.asp.net Visite para obtener más información sobre los recursos de ASP.NET.

• Eraserver.net ofrece hospedaje para ASP.NET.

Rob Howard es administrador de programas para ASP.NET en el equipo de .NET Framework. Pasa cualquier tiempo libre que tenga con su familia o con la pesca en el este de Washington.