Ablaufverfolgung

 

Rob Howard
Microsoft Corporation

25. Januar 2001

Immer wenn ich eine Präsentation über ASP.NET gebe, macht es immer Spaß, das Publikum zu watch, wenn die neue Ablaufverfolgungsfunktion gezeigt wird. Für diejenigen von uns, die Lösungen mit ASP erstellt haben, ist die Ablaufverfolgung ein Glücksfall!

In der Spalte dieses Monats werden wir uns das Ablaufverfolgungsfeature in ASP.NET ansehen. Beginnen wir mit der allgemeinen Ablaufverfolgungstechnik für ASP, Response.Write().

Ablaufverfolgung mit ASP

Wenn Sie wie ich sind, verwenden Sie beim Programmieren einer ASP-Anwendung Response.Write() -Anweisungen, wenn Sie einen problematischen Codeabschnitt seziert.

Hier sehen Sie einen Pseudocode, um diesen Punkt zu veranschaulichen:

<%
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)
%>

Die Response.Write() -Aufrufe im obigen Code sollten ziemlich vertraut aussehen, d. h. wir haben einen Fehler mit dem Verhalten unseres Codes. Der Fehler ist nicht unbedingt ein Anwendungs- oder Systemfehler, z. B. ein Fehler beim Laden des Objekts, sondern vielmehr ein Codierungsfehler, bei dem der Code wie erwartet ausgeführt wird, aber nicht den erwarteten Wert zurückgibt.

Natürlich können wir auch einen Debugger verwenden, aber manchmal ist es einfach schneller, eine Ablaufverfolgungsausgabe zu erhalten, um herauszufinden, was der Code tut, oder um uns einfach mitzuteilen, wie ein bestimmter Codeabschnitt ausgeführt wird.

Repsonse.Write()-Anweisungen erleichtern zwar das schnelle Debuggen der Anwendung, führen jedoch unnötigen Code in eine Anwendung ein, der zu echten Fehlern führen kann, die bereitgestellte Anwendungen unterbrechen. Beispielsweise wird es im Allgemeinen nicht als eine gute Sache betrachtet, wenn wir vergessen, eine farbenfrohere Response.Write() -Anweisung zu entfernen, die unsere wahren Gefühle über den Code, an dem wir arbeiten, ausdrücken könnte.

Natürlich wird die gleiche Funktionalität von Response.Write()- Anweisungen in ASP.NET unterstützt. Tatsächlich verwende ich immer noch Response.Write(), obwohl wir jetzt eine Ablaufverfolgungsfunktion haben. Alte Gewohnheiten sind schwer zu durchbrechen.

Wir sollten jedoch alle versuchen, diese alten Gewohnheiten zu durchbrechen, da die neue Ablaufverfolgungsfunktion uns etwas bietet, das im ASP:-Debugmodus nicht vorhanden war.

Ablaufverfolgung mit ASP.NET

Die neuen Ablaufverfolgungsfeatures von ASP.NET ermöglichen es uns, Response.Write()- Anweisungen zu simulieren, sich aber keine Gedanken über das Entfernen der Anweisungen zu machen, bevor wir unsere Anwendungen bereitstellen. Stellen Sie sich stattdessen vor, sie schreiben denselben Code wie oben, aber anstatt Response.Write()zu verwenden, verwenden wir Trace.Write().

Das Trace-Objekt ist jetzt ein intrinsisches Seitenobjekt, ähnlich wie Anforderung, Antwort, Server usw. Es ist direkt mit unserem Seitencode zugänglich.

Werfen wir einen kurzen Blick auf die Trace-Klasse .

Trace-Klasse

Die Ablaufverfolgung wird als öffentliche Eigenschaft auf ASP.NET Seiten verfügbar gemacht. Wenn wir die Trace-Eigenschaft verwenden, arbeiten wir mit einer instance der TraceContext-Klasse, die im System.Web-Namespace definiert ist.

Die Trace-Klasse macht zwei überladene Methoden und zwei Eigenschaften verfügbar. Die beiden Methoden Warn()Write(), unterstützen zwei identische Prototypen:

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)

Der Category-Parameter wird verwendet, um den Kategorienamen zu identifizieren, in den der Nachrichtenwert geschrieben werden soll. Dies wird deutlicher, wenn wir die Write() -Methode in einem folgenden Beispiel verwenden. Der dritte Parameter, den Sowohl Warn() als auch Write() in ihren überladenen Methoden unterstützen, ist errorInfo. Dadurch können wir Ausnahmedetails an das Ablaufverfolgungssystem übergeben.

Eigenschaften

Die TraceContext-Klasse unterstützt zwei öffentliche Eigenschaften: IsEnabled und TraceMode.

  • IsEnabled gibt an, ob die Ablaufverfolgung auf der Seite oder für die Anwendung aktiviert ist.
  • TraceMode legt den Sortiermodus, den die Ablaufverfolgung verwendet, fest oder gibt diesen zurück. Wir betrachten die Konfiguration des Ablaufverfolgungsmodus, wenn wir unten die Ablaufverfolgung auf Anwendungsebene erläutern.

Nachdem wir nun gesehen haben, wie die Klasse und die von der TraceContext-Klasse unterstützten Methoden und Eigenschaften aussehen, sehen wir uns ein Beispiel für Trace.Write()an.

<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)%>

Wenn dieser Code ausgeführt wird, lautet die Ausgabe:

Abbildung 1. Beispiel für die Trace.Write()-Methode

Offensichtlich wird die Add() -Methode aufgerufen. Im Gegensatz zu den Repsonse.Write()- Anweisungen werden die Trace.Write()- Anweisungen jedoch nicht in der resultierenden Ausgabe angezeigt. Zum Anzeigen der Ergebnisse der Trace.Write() -Anweisungen müssen wir die Ablaufverfolgung für diese Seite oder für die Anwendung aktivieren.

Zum Aktivieren der Ablaufverfolgung können wir entweder eine Seitendirektive oder eine Konfigurationsoption verwenden. Sehen wir uns beides an.

Seitenablaufverfolgungsdirektive

Seitenanweisungen sind spezielle Anweisungen, die ASP.NET beim Verarbeiten einer Anforderung für eine ASP.NET Ressource verwendet. Seitendirektiven können zum Überschreiben oder Anwenden von Konfigurationseinstellungen für eine ASP.NET Seite verwendet werden.

Eine Direktive muss das erste Element auf einer Seite sein. Sie wird mit der folgenden Syntax deklariert:

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

Mithilfe der obigen Syntax wird ASP.NET erläutert, dass die Ablaufverfolgung auf einer Seite aktiviert werden soll:

<%@ Page Trace="true" %>

Wenn wir die obige Anweisung zu unserem Beispielcode hinzufügen, sieht die Seitenausgabe etwas anders aus:

Abbildung 2. Ablaufverfolgung aktiviert

Nun wird die Ablaufverfolgungsausgabe am unteren Rand der Seite hinzugefügt. Die Ablaufverfolgungsausgabe wird immer am Ende der Seite hinzugefügt.

Als Nächstes sehen wir uns an, wie wir die Ablaufverfolgung auf Anwendungsebene aktivieren. Anschließend wird erläutert, was die Ablaufverfolgungsausgabe enthält.

Anwendungsablaufverfolgung

ASP.NET verwendet XML-Konfigurationsdateien, um Konfigurationseinstellungen für ASP.NET Anwendungen festzulegen. Bei jeder ASP.NET Installation wird eine Konfigurationsdatei im Verzeichnis [Systemlaufwerk]\WinNt\Microsoft.NET\Framework\[version]\ mit dem Namen config.web installiert.

Die Konfigurationsdatei legt die Standardkonfiguration ASP.NET fest und wird in Beta 1 als Stammkonfigurationsdatei bezeichnet. Änderungen, die in dieser Datei vorgenommen werden, wirken sich auf alle unsere ASP.NET-Webanwendung aus. Wir können auch Konfigurationsdateien in unseren Webanwendungen verwenden, um Einstellungen hinzuzufügen oder zu entfernen, die aus der Standardkonfiguration "config.web" abgerufen wurden.

Ich werde die Konfiguration in einer zukünftigen Spalte ausführlicher behandeln. Vorerst verwenden wir die Stammkonfigurationsdatei, um Ablaufverfolgungseinstellungen für alle ASP.NET Anwendungen anzuwenden.

Abschnitt "Ablaufverfolgung"

Wenn wir die Stammdatei config.web öffnen, finden Sie einen Ablaufverfolgungsabschnitt:

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

Es gibt vier Attribute für das Ablaufverfolgungselement :

  • aktiviert = "[true/false]": Wir können die option enabled auf true oder false festlegen. Die Ablaufverfolgung ist entweder auf Anwendungsebene aktiviert oder auf Anwendungsebene deaktiviert. Wenn wir enabled=false festlegen, wird die Seitenablaufverfolgung weiterhin mithilfe der weiter oben erläuterten Ablaufverfolgungsdirektive unterstützt.
  • requestlimit = " [int]"– Die Gesamtanzahl der Ablaufverfolgungsanforderungen, die pro Anwendung im Arbeitsspeicher zwischengespeichert werden sollen. Die Ablaufverfolgung macht eine spezielle Ressource verfügbar – Trace.axd, die wir uns im Moment ansehen werden –, die verwendet wird, um die Ablaufverfolgungsausgabe anzuzeigen, wenn pageoutput auf false festgelegt ist.
  • pageoutput = " [true/false]"– Wenn die Ablaufverfolgung über die Konfigurationsdatei aktiviert wird, kann der Administrator die Ablaufverfolgung auf jeder Seite aktivieren oder deaktivieren. Die PageOutput-Ablaufverfolgung ermöglicht die Ablaufverfolgung für jede Seite innerhalb einer Anwendung. Die PageOutput-Ablaufverfolgung kann jedoch deaktiviert werden, während die Ablaufverfolgung auf Anwendungsebene weiterhin aktiviert ist (aktiviert = "true"). Dadurch bleiben Ablaufverfolgungsanforderungen im Arbeitsspeicher erhalten, sodass sie über trace.axd verfügbar sind, was wir zwar vorübergehend betrachten, aber nicht in der Ausgabe einer Seite angezeigt werden.
  • tracemode = "[SortByTime | SortByCategory]" – Die Ablaufverfolgungsmoduseinstellung gibt uns die Kontrolle darüber, wie Ablaufverfolgungsdetails ausgegeben werden. Daten können nach Zeit oder Kategorie sortiert werden, wobei kategorie zwischen den vom System vorgenommenen Einstellungen und den vom Entwickler aktivierten Trace.Write() -Einstellungen unterschieden wird. In unserem Beispiel haben wir beispielsweise Folgendes verwendet: Trace.Write("Inside Add() a:", a.ToString()). Der erste Parameter der Trace.Write()- Anweisung ist die Kategorie. In diesem Fall haben wir kategorie als "Inside Add() a:"definiert. Wenn wir nach Kategorie sortiert sind (tracemode = "SortByCategory""), wird dieses Element sortiert, bevor die normale Seitenfunktion in der Ablaufverfolgungsausgabe aufruft. Die Sortierung nach Zeit hingegen wird nach der Zeit sortiert, die für den Anruf aufgewendet wird.

Verwenden der Anwendungsablaufverfolgung

Mit dem gleichen Beispielcode aus dem obigen Beispiel könnten wir die Seitendirektive entfernen und dieselbe Funktionalität aktivieren, indem wir die Einstellungen für die Ablaufverfolgung config.web ändern.

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

Wir können jetzt unsere Beispielanwendung aufrufen, die Page-Anweisung entfernen und dieselbe Ausgabe erhalten:

Abbildung 3. Ablaufverfolgung aktiviert, keine Seitendirektive

Aber was ist, wenn wir das zuvor erwähnte Feature verwenden möchten, in dem wir die Ablaufverfolgung aktivieren, aber die Ausgabe auf der Seite deaktivieren?

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

Wenn wir die Beispielanwendung mit den oben genannten Konfigurationseinstellungen angefordert haben, erhalten wir keine Ablaufverfolgungsausgabe, obwohl die Ablaufverfolgung weiterhin aktiviert ist. Zum Anzeigen der Ablaufverfolgungsausgabe verwenden wir eine spezielle Anwendung namens trace.axd.

Trace.axd

Trace.axd ist ein Http-Handler. Ein HTTP-Handler ist eine Codierungsoption, die es uns ermöglicht, Anforderungen/Antworten auf der einfachsten Ebene zu verarbeiten. Http-Handler entsprechen ISAPI-Erweiterungen. Im Gegensatz zu ISAPI können sie jedoch mit jeder .NET-Sprache erstellt werden. Ich werde Http-Handler in einer späteren Spalte ausführlicher erläutern.

Trace.axd ist ein HTTP-Handler, mit dem Wir Details zur Anwendungsablaufverfolgung anfordern können. Auf Anfrage erhalten wir ein Ablaufverfolgungsprotokoll der letzten n Anforderungen; n wird durch den Wert bestimmt, der von requestlimit="[int]" in unserer Konfigurationsdatei festgelegt wird.

Um trace.axd zu verwenden, fordern Sie einfach trace.axd im gleichen Anwendungsverzeichnis an, in dem die Anforderung für die Beispielanwendung gestellt wurde:

Abbildung 4. Anwendungsablaufverfolgungsanforderungen

Wie Sie im Screenshot sehen können, wird uns eine Liste mit Ablaufverfolgungen angezeigt, die wir anzeigen können. Diese Ablaufverfolgungsansichten sind mit den Details identisch, die die Ablaufverfolgung der Seite hinzufügen würde, ohne dass die Ausgabe der Seite enthalten ist:

Abbildung 5. Anforderungsdetails

Nachdem wir nun erläutert haben, wie wir die Ablaufverfolgung konfigurieren und verwenden, gehen wir auf die Ablaufverfolgungsausgabe ein.

Interpretieren der Ablaufverfolgungsausgabe

Die von der Ablaufverfolgungsansicht bereitgestellte Ausgabe, entweder über Trace.axd oder auf einer Seite, enthält sechs Detailabschnitte:

  • Anforderungsdetails: Dies sind grundlegende Informationen, z. B. die Sitzungs-ID, die Uhrzeit der Anforderung, der Http-Anforderungstyp und die HTTP-Antwort status Code.
  • Ablaufverfolgungsinformationen: Dieser Abschnitt enthält eine Tabellenansicht von Kategorien und Nachrichten. Wenn wir Trace.Write()- Anweisungen in unserem Code verwenden, werden die beiden Parameter, die Trace.Write() akzeptiert, als Category - bzw . Message-Werte verwendet. Zusätzlich erhalten wir die Zeit vom ersten bis zum letzten Byte.
  • Steuerungsstruktur: Obwohl in dieser Spalte noch nicht erläutert, verwendet ASP.NET Serversteuerelemente, um es uns zu ermöglichen, Anwendungen deklarativ zu erstellen. Der Abschnitt Steuerungsstruktur enthält Informationen zu Steuerelementen auf unserer Seite. Wir erhalten die ID, den Typ, die Rendergröße und die Ansichtszustandsgröße des Steuerelements. Diese Informationen geben uns eine Vorstellung davon, welche Steuerelemente wir verwenden, sowie die zugehörigen Kosten (Rendergröße und Viewstate).
  • Cookiessammlung: Alle Cookies, die der Client in den Anforderungsheadern sendet, werden analysiert, und ihre Namen, Werte und Größen werden angezeigt.
  • Headersammlung: Http-Header, die vom Client für den Server angezeigt werden, werden in diesem Abschnitt bereitgestellt. Es handelt sich um eine einfache Tabelle, in der Name/Wert aufgelistet sind.
  • Servervariablen: Im Abschnitt Servervariablen wird eine Name-Wert-Paartabelle mit Servervariablen angezeigt.

Verwenden der Ablaufverfolgung

Wie Sie deutlich sehen können, ist die Ablaufverfolgung ein leistungsstarkes neues ASP.NET Feature, das die Entwicklung von Webanwendungen vereinfacht. Ich dachte jedoch, dass es sich auch lohnen würde, die Ablaufverfolgung zu Erwähnung.

Bereitgestellte Anwendungen

Die Ablaufverfolgung verursacht zusätzlichen Mehraufwand für Anforderungen und sollte für bereitgestellte Anwendungen nicht aktiviert werden. Trace.Write() -Anweisungen können jedoch in belassen werden, da sie ignoriert werden, wenn die Ablaufverfolgung nicht aktiviert ist.

Für bereitgestellte Anwendungen, in denen Daten erfasst werden sollen, würde ich vorschlagen, die Klassen im System.Diagnostics-Namespace zu verwenden. Diese Klassen, die ich in einer zukünftigen Spalte behandeln möchte, ermöglichen es uns, direkt in das Windows-Ereignisprotokoll zu schreiben.

Wir sollten unbedingt die Ablaufverfolgung verwenden, wenn wir eine Anwendung erstellen, aber sie deaktivieren, wenn wir bereit sind, die Anwendung bereitzustellen, genauso wie wir diese Response.Write()- Anweisungen entfernt hätten.

Deaktivieren von Trace.axd

Wenn Sie ASP.NET auf einem Produktionswebserver installiert haben, empfiehlt es sich, Trace.axd explizit zu deaktivieren. Öffnen Sie die Stammdatei config.web , suchen Sie den <httphandlers> Abschnitt, und fügen Sie den folgenden Eintrag hinzu:

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

Hinweis: Wir könnten auch den gesamten <add/> Eintrag ausschneiden, aber die <remove> Option ist besser, da sie den Code in unserer Konfigurationsdatei belässt und das gleiche Ziel erreicht, indem trace.axd deaktiviert wird. Dies wird in Beta 2 von ASP.NET behoben.

Zusammenfassung

Die Ablaufverfolgungsfunktion in ASP.NET ist eine leistungsstarke neue Möglichkeit, die Aktivitäten unserer Anwendung nachzuverfolgen. In der Vergangenheit haben wir Response.Write() -Anweisungen verwendet, um die Ausführung der Anwendung zu verfolgen, aber wir können jetzt Trace.Write() -Anweisungen verwenden und diese Anweisungen in unserem bereitgestellten Code belassen. Dies führt zu weniger Fehlern, da wir keinen Code entfernen, wenn wir bereit sind, die Anwendung bereitzustellen.

ASP.NET Ressourcen

Abschließend möchte ich einige der neuen ASP.NET verfügbaren Ressourcen nennen. Weitere Informationen zu ASP.NET Ressourcen finden Sie unter https://www.asp.net .

Rob Howard ist Programmmanager für ASP.NET im .NET Framework Team. Er verbringt jede Freizeit, die er hat, entweder mit seiner Familie oder fliegen angeln im Osten Washingtons.