Freigeben über

Erweitern von ASP.NET-Systemüberwachungsereignissen

  • Artikel

Aktualisiert: November 2007

Sie können die folgenden Aufgaben ausführen, um ASP.NET-Systemüberwachungsfunktionen zu erweitern.

Puffern von ASP.NET-Systemüberwachungsereignissen

Sie können die Anbieter von SQL- und Mail-Systemüberwachungsereignissen (SqlWebEventProvider, SimpleMailWebEventProvider und TemplatedMailWebEventProvider) für die Verwendung von Ereignispufferung konfigurieren. Dadurch können die negativen Auswirkungen auf die Anwendungsleistung reduziert werden, die das häufige Senden von E-Mails und das häufige Durchführen von SQL Server-Einfügungen sonst verursachen. Zusätzlich schützt die Pufferung von Systemüberwachungsereignissen den SMTP-Server und SQL Server vor der hohen Auslastung durch große Ereignismengen.

Pufferung durch den SQL-Ereignisanbieter

Wenn Sie die Pufferung für den SQL-Ereignisanbieter aktivieren, puffert der Anbieter Ereignisinformationen gemäß dem angegebenen Puffermodus und fügt die Ereignisinformationen später als Batch in die Datenbank ein.

Standardmäßig ist der SqlWebEventProvider-Anbieter nicht für die Pufferung konfiguriert. Jedes Mal wenn ein Ereignis ausgelöst wird, werden seine Informationen sofort in die Datenbank eingefügt. Sie können diese Standardeinstellung überschreiben, indem Sie die Pufferung im providers-Element der Datei Web.config aktivieren, in der der SQL-Anbieter angegeben ist. Dazu setzen Sie das buffer-Attribut des add-Elements auf true. Wenn Sie Ihren eigenen SQL-Anbieter konfigurieren (wenn Sie SqlWebEventProvider also nicht verwenden) und für das buffer-Attribut keinen Wert angeben, ist standardmäßig true festgelegt.

Sie können das Pufferungsverhalten anpassen, indem Sie einen vordefinierten Puffermodus auswählen. Alternativ können Sie der bufferModes-Auflistung benutzerdefinierte Elemente hinzufügen. Die einzelnen Elemente definieren Eigenschaften wie die Puffergröße und die Häufigkeit der Pufferleerung. Sie können dann den Anbieter für die Verwendung des von Ihnen definierten Puffermodus konfigurieren.

Das Beispiel zeigt die Konfigurationseinstellungen für den SQL-Ereignisanbieter mit aktivierter Pufferung.

Hinweis:

Das AnalysisbufferModes-Element ist bereits in der Stammdatei Web.config konfiguriert und muss in der Datei Web.config auf Anwendungsebene nicht mehr deklariert werden. Das SqlWebEventProviderproviders-Element ist ebenfalls in der Stammdatei Web.config konfiguriert, doch das buffer-Attribut ist auf false festgelegt und das bufferMode-Attribut ist auf Notification festgelegt. Aus diesem Grund muss das providers-Element, das im Beispiel gezeigt wird, in einer Web.config-Datei auf Anwendungsebene deklariert werden. Sie müssen außerdem ein clear- oder remove-Element verwenden, um die Konfiguration auf höherer Ebene für den SqlWebEventProvider-Anbieter zu entfernen.

Der SQL-Ereignisanbieter ist in dem Beispiel durch entsprechende Festlegung des bufferModes-Elements so konfiguriert, dass er bei aktivierter Pufferung den Puffermodus Analysis verwendet. In diesem Modus leert der Anbieter die Ereignisinformationen alle 5 Minuten. Pro Benachrichtigung werden bis zu 100 Ereignisse geleert, und bei einem plötzlichen Anstieg der Ereignishäufigkeit können bis zu 1000 Ereignisse gepuffert werden. Der Anbieter garantiert, Ereignisse nicht öfter als einmal pro Minute zu senden.

<healthMonitoring>
  <providers>
    <clear/>
    <add 
      ConnectionStringName="LocalSqlServer" 
      maxEventDetailsLength="1073741823"
      buffer="true" 
      bufferMode="Analysis" 
      name="SqlWebEventProvider"
      type="System.Web.Management.SqlWebEventProvider,System.Web, Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" 
    />
  </providers>
  <bufferModes>
    <add 
      name="Analysis" 
      maxBufferSize="1000" 
      maxFlushSize="100"
      urgentFlushThreshold="100" 
      regularFlushInterval="00:05:00"
      urgentFlushInterval="00:01:00" 
      maxBufferThreads="1"
    />
  </bufferModes>
</healthMonitoring>

Pufferung durch die E-Mail-Ereignisanbieter

Wenn Sie die Pufferung für die E-Mail-Ereignisanbieter aktivieren, werden die Ereignisse von den Anbietern vor dem Senden von E-Mail-Nachrichten als Ereignisbenachrichtigungen gepuffert. Wenn Sie einen E-Mail-Ereignisanbieter konfigurieren und für das buffer-Attribut des add-Elements für den E-Mail-Ereignisanbieter keinen Wert angeben, gilt standardmäßig true. Sie können die Pufferung deaktivieren, indem Sie das buffer-Attribut auf false festlegen.

Sie können das Pufferungsverhalten anpassen, indem Sie einen vordefinierten Puffermodus auswählen. Alternativ können Sie der bufferModes-Auflistung benutzerdefinierte Elemente hinzufügen. Die einzelnen Elemente definieren Eigenschaften wie die Puffergröße und die Häufigkeit der Pufferleerung. Sie können dann den Anbieter für die Verwendung des von Ihnen definierten Puffermodus konfigurieren. Es wird empfohlen, den CriticalNotification-Modus zu verwenden.

Das folgende Beispiel zeigt die Konfigurationseinstellungen für die E-Mail-Ereignisanbieter, wobei die Pufferung für die SimpleMailWebEventProvider-Klasse deaktiviert und für die TemplatedMailWebEventProvider-Klasse aktiviert ist. Der TemplatedMailWebEventProvider-Anbieter ist für die Verwendung des Puffermodus CriticalNotification konfiguriert, der bereits in der Stammdatei Web.config konfiguriert ist. Im CriticalNotification-Modus versucht der Anbieter, alle Ereignisinformationen zu leeren, sobald Ereignisse empfangen werden. Der Leerungsversuch ist jedoch höchstens eine Minute erfolgreich, da sonst die Belastung für den E-Mail-Server unnötig steigen würde. Die Meldungen sind von überschaubarer Größe. Es sind Informationen für höchstens 20 Ereignisse vorhanden.

Falls die Systemüberwachung mehr Ereignisinformationen empfängt als maximal zulässig, werden bei Generierung neuer Ereignisse die ältesten Ereignisse verworfen. Das Überwachungssystem versucht, das Verwerfen von Ereignissen zu vermeiden, indem es einen voller werdenden Puffer häufiger leert. Es wird aber nicht versucht, Informationen für bereits verworfene Ereignisse zu senden. (Die nächste Leerung enthält jedoch eine Benachrichtigung, dass Ereignisse verworfen wurden.) Bei hoher Auslastung des Anbieters werden neuere Ereignisse bis zu fünf Minuten verzögert – vorausgesetzt, dass sie nicht wegen vollem Puffer verworfen werden.

<healthMonitoring>
  <providers>
    <!-- mail provider with attributes that are always relevant -->
    <add 
      name="SimpleMailWebEventProvider" 
      type="System.Web.Management.SimpleMailWebEventProvider"
      to="SystemAdministrator@contoso.com"
      from="HealthMonitoring@contoso.com"
      buffer="false" 
    />
    <!-- mail provider with attributes that are relevant only 
         when buffering is enabled -->
    <add 
      name="SampleTemplatedMailWebEventProvider" 
      type="System.Web.Management.TemplatedMailWebEventProvider"
      to="SystemAdministrator@contoso.com" 
      from="HealthMonitoring@contoso.com" 
      buffer="true" 
      bufferMode="Critical Notification"
      template="Template.aspx" />
  </providers>
  <bufferModes>
    <add 
      name="Critical Notification" 
      maxBufferSize="100" maxFlushSize="20"
      urgentFlushThreshold="1" 
      regularFlushInterval="Infinite" 
      urgentFlushInterval="00:01:00"
      maxBufferThreads="1"
    />
  </bufferModes> 
</healthMonitoring>

Damit das Beispiel funktioniert, müssen Sie in der Konfigurationsdatei einen SMTP-Server konfigurieren. Dies ist im folgenden Beispiel gezeigt.

<system.net>
  <mailSettings>
    <smtp deliveryMethod="Network">
      <network 
        defaultCredentials="true" 
        host="127.0.0.1" 
        port="25" 
        username="username" 
        password="password" />
    </smtp>
  </mailSettings>
</system.net>

Weitere Informationen finden Sie unter <mailSettings>-Element (Netzwerkeinstellungen).

Hinweis:

Das Speichern von Klartext-Kennwörtern in einer Konfigurationsdatei birgt gewisse Sicherheitsrisiken. Wenn Sie in der Konfigurationsdatei Anmeldeinformationen vorhalten, sollten Sie den Inhalt des <mailSettings>-Konfigurationselements mithilfe einer geschützten Konfiguration verschlüsseln. Weitere Informationen finden Sie unter Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration.

Einstellungen für den Puffermodus

Sie können die folgenden Attribute des add-Elements im bufferModes-Element festlegen, um das Pufferverhalten anzugeben:

  • regularFlushInterval   Das reguläre Intervall zum Leeren von Ereignisinformationen.

  • urgentFlushThreshold   Die Anzahl der Ereignisse, deren Informationen gepuffert werden, bevor der Puffer geleert wird.

Die folgenden Einstellungen geben die Garantien an, die der Anbieter dem Ereignisempfänger gibt.

  • maxBufferSize   Die maximale Anzahl der Ereignisse, von denen der Puffer Informationen enthält. Wenn die Ereignisanzahl im Puffer diesen Wert übersteigt, werden ältere Ereignisse verworfen.

  • maxFlushSize   Die maximale Anzahl der Ereignisse, deren Informationen der Anbieter bei einem Mal leert.

  • urgentFlushInterval   Die Mindestzeit, die der Anbieter bis zur Ausführung einer weiteren dringlichen Leerung abwartet. Wenn seit der letzten Leerung die in der urgentFlushInterval-Eigenschaft angegebene Zeit noch nicht abgelaufen ist, der Puffer jedoch voll ist, ersetzt der Puffer Informationen älterer Ereignisse. Der Anbieter kontrolliert, wie viele Ereignisse verworfen werden, und fügt der nächsten Ereignisbenachrichtigung, die gesendet wird, eine Warnung hinzu.

Verwenden von WMI zum Verfolgen von ASP.NET-Systemüberwachungsereignissen

Eine Möglichkeit zum Überwachen der ASP.NET-Systemüberwachungsereignisse besteht in der Verwendung des WMI-Ereignisanbieters (Windows Management Instrumentation – Windows-Verwaltungsinstrumentation), der WmiWebEventProvider-Klasse. Dieser Anbieter konvertiert Webereignisse für die Systemüberwachung (Webereignisse) in WMI-Ereignisse. WMI bietet ein Standardobjektmodell, in dem die zu überwachenden Entitäten als Objekte dargestellt werden können. Diese Entitäten stellen Computer, Netzwerkkarten, Drucker, Softwareanwendungen usw. dar. Die Entitäten werden einem WMI-Objektmodell zugeordnet, sodass sie von benutzerdefinierten Anwendungen überwacht werden können. In der folgenden Abbildung wird die Beziehung zwischen den ASP.NET-Webereignissen, WMI und einer Consumeranwendung, die WMI-Ereignisse überwacht, veranschaulicht.

Beziehung zwischen ASP.NET und WMI

Verbindung zwischen Systemüberwachungsereignissen und WMI

Die ASP.NET-Systemüberwachung stellt die Infrastruktur für die Verbindung zwischen Systemüberwachungsereignissen und WMI bereit. Dabei werden diese Ereignisse den WMI-Klassen zugeordnet, sodass sie als WMI-Objekte behandelt werden können. Es unterstützt auch die Verarbeitung von Systemüberwachungsereignissen und deren Weiterleitung zum WMI-System. Ausführliche Informationen zum Zuordnen von ASP.NET-Ereignissen zu WMI finden Sie unter Exemplarische Vorgehensweise: Überwachen von WMI-Ereignissen in der ASP.NET-Systemüberwachung. Weitere Informationen zu WMI finden Sie unter Windows Management Instrumentation (möglicherweise in englischer Sprache) auf der MSDN-Website.

In der folgenden Liste werden die Schritte beschrieben, die zum Überwachen von Systemüberwachungsereignissen mithilfe von WMI erforderlich sind:

  1. Definieren Sie die Zuordnung zwischen den Webereignisklassen und den WMI-Objekten. Dieser Schritt wurde für die einzelnen standardmäßigen Webereignisklassen bereits für Sie ausgeführt. Diese Zuordnungen sind in der MOF-Datei (Managed Object Format) für ASP.NET enthalten: %Systemstamm%\Microsoft.NET\Framework\<version>\aspnet.mof.

    Hinweis:

    Alle benutzerdefinierten Ereignisse werden dem Basisereignistyp in WMI zugeordnet. Ein benutzerdefiniertes ASP.NET-Systemüberwachungsereignis kann nicht einem beliebigen WMI-Ereignis zugeordnet werden.

    Im folgenden Code wird beispielsweise die Definition der WMI-Klasse veranschaulicht, die dem WebHeartbeatEvent-Typ zugeordnet ist.

    class HeartbeatEvent : ManagementEvent {
    /*
     * ProcessStatistics    
     */
    DATETIME    ProcessStartTime;
    sint32      ThreadCount;
    sint64      WorkingSet;
    sint64      PeakWorkingSet;
    sint64      ManagedHeapSize;
    sint32      AppdomainCount;    
    sint32      RequestsExecuting;
    sint32      RequestsQueued;
    sint32      RequestsRejected;
};

    Weitere Informationen zu MOF-Dateien finden Sie unter Managed Object Format im WMI-SDK (möglicherweise in englischer Sprache) auf der MSDN-Website.

  2. Definieren Sie einen ASP.NET-Systemüberwachungsanbieter für die Verarbeitung von Ereignissen.

    Der Standardanbieter ist die WmiWebEventProvider-Klasse. Standardmäßig ist dies bereits im healthMonitoring-Abschnitt der Web.config-Stammdatei konfiguriert, indem das folgende Element verwendet wird:

    <providers>
  <add 
    name="WmiWebEventProvider" 
    type="System.Web.Management.WmiWebEventProvider,System.Web, Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" 
  />
</providers>

  3. Geben Sie geeignete Einstellungen im healthMonitoring-Abschnitt der Konfigurationsdatei ein, um eine Zuordnung zwischen Webereignisklassen und dem WMI-Ereignisanbieter, der WmiWebEventProvider-Klasse, zu erstellen.

    Standardmäßig abonniert der WMI-Ereignisanbieter keine Webereignisse. Sie können die folgenden Elemente in einer Web.config-Datei auf Anwendungsebene verwenden, sodass alle Webereignisse vom WMI-Ereignisanbieter abonniert werden. Standardmäßig wird der All Events-Ereignistyp in der Web.config-Stammdatei im eventMappings-Element konfiguriert. Dieser ist der WebBaseEvent-Klasse zugeordnet.

    <rules>
  <add 
    name="Testing Wmi"
    eventName="All Events" 
    provider="WmiWebEventProvider" 
    profile="Critical"
  />
</rules>

  4. Erstellen Sie eine Anwendung, um WMI-Ereignisse zu überwachen, oder verwenden Sie eine Anwendung eines Drittanbieters.

    Im Codebeispiel in Exemplarische Vorgehensweise: Überwachen von WMI-Ereignissen in der ASP.NET-Systemüberwachung wird eine Konsolenanwendung erstellt, die Ereignisinformationen anzeigt, sobald ein Webereignis ausgelöst wird.

Anpassen der Infrastruktur für WMI-Systemüberwachungsereignisse

Wenn ein Webereignis eintritt, sendet die ASP.NET-Systemüberwachung es an das WmiWebEventProvider-Objekt. Das Anbieterobjekt verarbeitet das Ereignis und gibt die Daten gemäß der verknüpften MOF-Klassendefinition ein. Der Anbieter sendet die Daten dann mithilfe eines Aufrufs von nicht verwaltetem Code an das WMI-System.

Die einzige Anpassungsmöglichkeit zum Senden von Webereignissen an WMI besteht darin, eine benutzerdefinierte Anwendung zu erstellen, die ASP.NET-Systemüberwachungsereignisse verwendet, nachdem diese als WMI-Ereignisse ausgegeben wurden. In diesem Fall besteht die einzige erforderliche Konfigurationsänderung darin, ein neues rules-Element wie oben beschrieben zu konfigurieren. Das System überwacht ASP.NET-Systemüberwachungsereignisse in Form von WMI-Ereignissen, wie sie vom Betriebssystem ausgegeben werden. Weitere Informationen finden Sie unter Exemplarische Vorgehensweise: Überwachen von WMI-Ereignissen in der ASP.NET-Systemüberwachung.

Hinweis:

Die WmiWebEventProvider-Klasse kann nicht erweitert werden. Die einzigen erweiterbaren Ereignisanbieterklassen sind die WebEventProvider-Klasse und die BufferedWebEventProvider-Klasse.

Implementieren von benutzerdefinierten Ereignissen und Anbietern zur ASP.NET-Systemüberwachung

Standardmäßig werden einige Ereignisse bereits in Leistungsindikatoren oder im Ereignisprotokoll erfasst oder an das ASP.NET-Ablaufverfolgungssystem gesendet. Sie können weitere Ereignisse aktivieren, indem Sie sie vorhandenen Anbietern zuordnen. Weitere Informationen finden Sie unter Übersicht über die ASP.NET-Systemüberwachung im Abschnitt "Verwenden von Webereignissen mit Ereignisanbietern".

Wenn keine der vorhandenen Webereignis- oder Anbieterklassen Ihren Bedürfnissen entspricht, können Sie sie erweitern. In der folgenden Tabelle sind die Möglichkeiten zum Anpassen der ASP.NET-Systemüberwachung aufgeführt.

Aufgabe

Implementierung

Beispiel

Erstellen Sie eine benutzerdefinierte Webereignisklasse.

Erstellen Sie eine Klasse, die von WebBaseEvent erbt und die virtuelle Raise-Methode implementiert. Um einem benutzerdefinierten Ereignis benutzerdefinierte Daten hinzuzufügen, überschreiben Sie die FormatCustomEventDetails-Methode.

Gewusst wie: Implementieren und Auslösen von benutzerdefinierten ASP.NET-Systemüberwachungsereignissen

Erstellen Sie einen benutzerdefinierten Ereignisanbieter, um ein integriertes oder benutzerdefiniertes Webereignis zu verarbeiten.

Erstellen Sie eine Klasse, die von der WebEventProvider-Klasse (oder einer der abgeleiteten Klassen) erbt. Wenn der Anbieter Protokolle erstellt, sollte die entsprechende Klasse auch von der WebEventFormatter-Klasse erben.

Gewusst wie: Beispiel für das Implementieren eines benutzerdefinierten Systemüberwachungsanbieters

Siehe auch

Aufgaben

Gewusst wie: Sperren von ASP.NET-Konfigurationseinstellungen

Konzepte

Übersicht über die ASP.NET-Systemüberwachung

Übersicht über die ASP.NET-Konfiguration

Referenz

bufferModes-Element für healthMonitoring (ASP.NET-Einstellungsschema)

providers-Element für healthMonitoring (ASP.NET-Einstellungsschema)