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

Aktualisiert: November 2007

Mit der ASP.NET-Systemüberwachung können Systemadministratoren den Status von bereitgestellten Webanwendungen überwachen.

Hinweis:
Zum Auslösen eines Systemüberwachungsereignisses ist eine mittlere oder höhere Vertrauensebene erforderlich.

Dieses Thema enthält folgende Abschnitte:

• Szenarien

• Features der ASP.NET-Systemüberwachung

• Hintergrund

• Codebeispiele

• Klassenreferenz

Szenarien

Mithilfe der ASP.NET-Systemüberwachung können Sie die folgenden Aufgaben ausführen:

• Überwachen der Leistung einer Anwendung, um sicherzustellen, dass sie fehlerfrei ist.

• Schnelle Diagnose von fehlerhaften Anwendungen und Systemen.

• Auswerten von bedeutenden Ereignissen während des Lebenszyklus einer Anwendung.

• Überwachen von Live-ASP.NET-Anwendungen, entweder einzeln oder über eine Webfarm.

• Protokollieren von Ereignissen, die sich nicht unbedingt auf Fehler in einer ASP.NET-Anwendung beziehen.

Zurück nach oben

Features

Die ASP.NET-Systemüberwachung enthält:

• Ereignistypen, von denen Pakete mit Informationen über den Zustand einer Anwendung erstellt werden.

• Anbietertypen, von denen Ereignisinformationen verarbeitet werden.

• Zusätzliche Typen, die hilfreich beim Verwalten von Systemereignissen sind.

Zurück nach oben

Hintergrund

Mit der ASP.NET-Systemüberwachung können Sie auf einfache Weise den ordnungsgemäßen Ablauf einer ASP.NET-Anwendung überwachen sowie detaillierte Laufzeitinformationen über ASP.NET-Ressourcen anzeigen, um die Anwendung zu instrumentieren. Die Systemüberwachung enthält fertige Ereignisklassen zur Websystemüberwachung (Webereignisse) sowie Systemüberwachungsanbieter (Listener). Von Webereignissen werden Pakete mit Systemereignisinformationen erstellt.

Von Anbietern werden Ereignisse überwacht und die Ereignisinformationen verarbeitet, normalerweise indem die Informationen protokolliert und ein Administrator benachrichtigt wird. Das Verbinden eines Webereignisses mit einem Anbieter wird als Aktivieren des Ereignisses bezeichnet. Sie können dies ausführen, indem Sie die Einstellungen in der Konfigurationsdatei der Anwendung festlegen.

Die ASP.NET-Systemüberwachung wird mithilfe der Klassen im System.Web.Management-Namespace implementiert.

Konfigurieren der ASP.NET-Systemüberwachung

Sie können Anwendungen für die Verwendung von integrierten oder benutzerdefinierten Überwachungsanbietern konfigurieren, von denen Informationen über die Systemüberwachung verarbeitet und Berichte über den Systemstatus sowie die Leistungsmerkmale der instrumentierten Anwendung erstellt werden.

Sie können einer Anwendung Webereignisse und Anbieter hinzufügen, indem Sie den Abschnitt healthMonitoring in der Konfigurationsdatei konfigurieren. Verwenden Sie integrierte oder benutzerdefinierte Klassen, um die Ereignisdaten zu überwachen und zu verarbeiten.

Weitere Informationen zu Konfigurationsdateien finden Sie unter ASP.NET-Konfigurationsdateien.

Webereignisklassen-Hierarchie

Beim Auslösen eines Webereignisses wird eine Instanz der zugeordneten Webereignisklasse erstellt. Ereignisdaten werden in den Eigenschaften dieses Objekts gesammelt. Ereignisanbieter verarbeiten diese Daten.

Webereignisse können Informationen über den Workerprozess, die Anwendungsdomäne, Anforderungsdaten, Antwortdaten, Anwendungsfehler, Konfigurationsfehler und Überwachungsereignisse enthalten. In einer übergeordneten Ereignisklasse enthaltene Systemüberwachungsinformationen werden von allen untergeordneten Ereignisklassen geerbt.

Die Beziehungen zwischen den Webereignisklassen werden in der folgenden Illustration veranschaulicht.

Webereignisklassen-Hierarchie

Je weiter unten ein Ereignis in der Hierarchie die Webereignisklassen steht, desto spezifischer sind die Daten für die ASP.NET-Anwendung. Abgeleitete Klassen können beispielsweise Stapelüberwachungen, Client-IPs sowie Thread- und Prozessinformationen bereitstellen.

Webereignisinformationen

In der folgenden Tabelle sind Informationen aufgeführt, die hilfreich sind, um zu entscheiden, welche Webereignisklasse verwendet oder geerbt werden soll. Die Zeilen verweisen auf die Webereignisklassen. Die Spalten verweisen auf die Informationsklassen, die normalerweise als Eigenschaften in den Webereignisklassen verfügbar sind.

Wenn die Anwendung nicht mit voller Vertrauenswürdigkeit ausgeführt wird, kann nur die WebBaseEvent-Klasse vererbt werden. Hierdurch kann vermieden werden, dass vertrauliche Informationen über die in der Tabelle aufgelisteten Informationsklassen verfügbar gemacht werden.

Webereignisklassen	WebApplicationInformation	WebProcessInformation	WebProcessStatistics	WebRequestInformation	WebThreadInformation
WebBaseEvent	Von dieser Klasse generierte Daten	Nicht verfügbar	Nicht verfügbar	Nicht verfügbar	Nicht verfügbar
WebManagementEvent	Von der übergeordneten Klasse generierte Daten.	Von dieser Klasse generierte Daten	Nicht verfügbar	Nicht verfügbar	Nicht verfügbar
WebHeartbeatEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Von dieser Klasse generierte Daten	Nicht verfügbar	Nicht verfügbar
WebRequestEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Von dieser Klasse generierte Daten	Nicht verfügbar
WebApplicationLifetimeEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Nicht verfügbar	Nicht verfügbar
WebBaseErrorEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Nicht verfügbar	Nicht verfügbar
WebErrorEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Von dieser Klasse generierte Daten	Von dieser Klasse generierte Daten
WebRequestErrorEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.
WebAuditEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Von dieser Klasse generierte Daten	Nicht verfügbar
WebSuccessAuditEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar
WebAuthenticationSuccessAuditEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar
WebFailureAuditEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar
WebAuthenticationFailureAuditEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar
WebViewStateFailureAuditEvent	Von der übergeordneten Klasse generierte Daten.	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar	Von der übergeordneten Klasse generierte Daten.	Nicht verfügbar

Anbieterklassenhierarchie

ASP.NET enthält integrierte Anbieter, mit denen Sie Webereignisse verarbeiten können. Sie können zum Erstellen eines benutzerdefinierten Anbieters auch integrierte Klassen erben, die den folgenden Vererbungseinschränkungen unterliegen:

• Die WebEventProvider-Klasse kann von Anwendungen geerbt werden, die mit beliebiger Vertrauensebene ausgeführt werden.

• Die BufferedWebEventProvider-Klasse kann von Anwendungen geerbt werden, die mit beliebiger Vertrauensebene ausgeführt werden.

• Die SqlWebEventProvider-Klasse kann nur von Anwendungen geerbt werden, die mit voller Vertrauenswürdigkeit ausgeführt werden.

Andere Klassen können unabhängig von der Vertrauensebene nicht von Anwendungen geerbt werden. Weitere Informationen finden Sie in den Klassenübersichten für die jeweiligen Anbieterklassen.

In der folgenden Illustration werden die Beziehungen zwischen den Webanbieterklassen des System.Web.Management-Namespaces veranschaulicht.

Webanbieterklassen-Hierarchie

Verwenden von ASP.NET-Systemüberwachungsereignissen

Sie haben die folgenden Möglichkeiten, um mit ASP.NET-Systemüberwachungsereignissen zu arbeiten:

• Verwenden von integrierten Webereignis- und Anbieterklassen. Normalerweise müssen Sie keine benutzerdefinierten Implementierungen von ASP.NET-Webereignisklassen bereitstellen. Beachten Sie, dass diese Ereignisse nicht von der Anwendung ausgelöst werden, sondern durch .NET Framework. Sie müssen jedoch konfiguriert werden, wie weiter unten in diesem Thema erläutert. Weitere Informationen hierzu finden Sie unter Gewusst wie: Senden von E-Mail für Systemüberwachungsbenachrichtigungen.

• Erstellen benutzerdefinierter Klassen für Webereignisse und Anbieter. Normalerweise erstellen Sie benutzerdefinierte Webereignisse, wenn Sie benutzerdefinierte Informationen an die Informationen anfügen müssen, die von den integrierten Webereignissen bereitgestellt werden. In der Regel erstellen Sie benutzerdefinierte Anbieter, wenn Sie Ereignisdaten anhand eines anderen Mechanismus als des Mechanismus bereitstellen möchten, der mit den integrierten Anbietern verfügbar ist. Weitere Informationen hierzu finden Sie unter Erweitern von ASP.NET-Systemüberwachungsereignissen.

Verwenden von integrierten Webereignissen und Anbietern

Normalerweise werden integrierte Webereignisse und Anbieter für die Systemüberwachung verwendet. Hierfür muss die Anwendung lediglich für die Verwendung der erforderlichen Ereignisse und Anbieter konfiguriert werden. Sie müssen Folgendes ausführen:

• Fügen Sie dem eventMappings-Element des healthMonitoring-Abschnitts in der Konfigurationsdatei der Anwendung die benötigte integrierte ASP.NET-Webereignisklasse hinzu.

• Fügen Sie dem providers-Element des healthMonitoring-Abschnitts den Anbieter hinzu, der das Ereignis behandelt.

• Fügen Sie dem rules-Element, das die Zuordnung zwischen Ereignis und Anbieter definiert, ein Element hinzu.

Standardmäßig werden die integrierten ASP.NET-Systemüberwachungsklassen im healthMonitoring-Abschnitt der Stammdatei Web.config konfiguriert. Im healthMonitoring-Abschnitt wird die folgende Standardkonfiguration festgelegt:

• Alle von WebBaseEvent abgeleiteten Webereignisklassen werden im eventMappings-Element angegeben. In diesem Abschnitt wird einer Gruppe von Ereignisklassen ein angezeigter Name zugeordnet.

• Alle von WebBaseEvent abgeleiteten Ereignisklassen sind in mindestens einer der Gruppen enthalten, die im eventMappings-Element definiert sind.

EventLogWebEventProvider-Ereignisanbieter, WmiWebEventProvider-Ereignisanbieter und SqlWebEventProvider-Ereignisanbieter werden im providers-Element angegeben. Sie können andere integrierte Anbieter im providers-Element angeben, z. B. die Klassen SimpleMailWebEventProvider, TemplatedMailWebEventProvider oder TraceWebEventProvider.

Die Regeln, nach denen den EventLogWebEventProvider-Klassen die Webfehler- und Überwachungsfehlerereignisse zugeordnet werden, sind im rules-Element festgelegt. Sie können andere Webereignisse und Anbieter aktivieren, indem Sie weitere rules-Elemente hinzufügen. Ein Ereignis wird als aktiviert betrachtet, wenn es im rules-Element einem Ereignisanbieter zugeordnet wurde. Das eventMappings-Element und das providers-Element müssen für das Ereignis konfiguriert werden. Solange diese beiden Elemente nicht im rules-Element verknüpft sind, ist das Ereignis jedoch nicht aktiviert.

Sie können Parameterwerte für die konfigurierten Elemente festlegen. Sie können beispielsweise Parameter zum Begrenzen der Anzahl an Ereignissen, die auftreten können, zum Festlegen des Intervalls zwischen zwei Ereignissen oder zum Festlegen der Ereignispufferungsoptionen für SQL- und E-Mail-Anbieter angeben.

Konfigurieren eines benutzerdefinierten Anbieters

Wenn eine benutzerdefinierte Verarbeitung der Webereignisinformationen erforderlich ist, können Sie einen benutzerdefinierten Systemereignisanbieter erstellen. Der Anbieter ist eine Klasse, die von der WebEventProvider-Klasse oder der BufferedWebEventProvider-Klasse erbt. Ein Beispiel finden Sie unter Gewusst wie: Beispiel für das Implementieren eines benutzerdefinierten Systemüberwachungsanbieters. Die häufigste Anpassung der Systemüberwachung ist das Erstellen eines benutzerdefinierten Anbieters. Sie müssen die Konfigurationsdatei hierfür folgendermaßen ändern:

• Fügen Sie dem providers-Element des healthMonitoring-Abschnitts in der Konfigurationsdatei den benutzerdefinierten Anbieter hinzu, der das Ereignis verarbeitet.

• Fügen Sie dem rules-Element, das die Zuordnung zwischen Ereignis und Anbieter definiert, ein Element hinzu.

• Legen Sie die Assembly, die die Implementierung des benutzerdefinierten Anbieters enthält, im Unterverzeichnis Bin der Anwendung ab. Die Quellcodedatei des Anbieters kann nicht im Unterverzeichnis App_Code abgelegt werden, da die Systemüberwachung konfiguriert und erstellt wird, bevor die Codedateien im Unterverzeichnis App_Code kompiliert werden.

Das type-Attribut des providers-Elements erfordert mindestens den Klassennamen. Wenn sich die Assembly nicht im Verzeichnis Bin der Anwendung befindet, muss sie mit einem starken Namen versehen und im globalen Assemblycache installiert werden. In diesem Fall erfordert das type-Attribut des providers-Elements den vollständigen starken Namen. Dies wird im folgenden Beispiel veranschaulicht, in dem die Werte Version und PublicKeyToken mit der Assembly übereinstimmen:

type="Microsoft.Samples.Web.Management.SampleCustomEventProvider, Sample.SampleCustomEventProvider,Version=n.n.n.n,Culture=neutral, PublicKeyToken=xxxx"

Im folgenden Beispiel ist dargestellt, wie dem SampleCustomEventProvider-Anbieter das WebHeartbeatEvent-Ereignis zugeordnet wird. Das Heartbeats-Ereignis wurde in der Stammdatei Web.config bereits konfiguriert.

<healthMonitoring 
  heartBeatInterval="1" 
  enabled="true">
  <rules>
    <add 
      name="Heartbeat Events" 
      eventName="Heartbeats" 
      provider="Sample Custom Event Provider"
      profile="Default" 
      minInstances="1" 
      maxLimit="Infinite" 
      minInterval="00:01:00"
      custom="" 
    />
  </rules>
  <providers>
    <add 
      name="Sample Custom Event Provider" 
      type="Microsoft.Samples.Web.Management.SampleCustomEventProvider, Sample.SampleCustomEventProvider,Version=1.0.0.0,Culture=neutral, PublicKeyToken=xxxxxxxxxxxx" 
    />
  </providers>
</healthMonitoring>

Konfigurieren eines benutzerdefinierten Ereignisses

Wenn Sie benutzerdefinierte Systemereignisinformationen benötigen, können Sie ein benutzerdefiniertes Systemereignis erstellen. Ein Beispiel finden Sie unter Gewusst wie: Implementieren und Auslösen von benutzerdefinierten ASP.NET-Systemüberwachungsereignissen. Das Erstellen eines benutzerdefinierten Webereignisses ist weniger gebräuchlich als das Erstellen eines benutzerdefinierten Anbieters. Sie müssen hierfür die Konfigurationsdatei ändern. Außerdem müssen Sie das benutzerdefinierte Ereignis zum geeigneten Zeitpunkt explizit auslösen.

Zum Konfigurieren des Ereignisses sind folgende Schritte erforderlich:

• Fügen Sie dem eventMappings-Element des healthMonitoring-Abschnitts die benutzerdefinierte Systemereignisklasse hinzu.

• Fügen Sie ein rules-Element hinzu, das die Zuordnung zwischen Ereignis und Anbieter definiert.

• Fügen Sie die Assembly, die die benutzerdefinierte Webereignisimplementierung enthält, dem Unterverzeichnis Bin der ASP.NET-Anwendung hinzu. Alternativ können Sie die Datei mit dem Ereignisquellcode auch dem Unterverzeichnis App_Code hinzufügen.

Wenn Sie eine Assembly verwenden, erfordert das type-Attribut des eventMappings-Elements mindestens den Klassennamen und den Dateinamen der Assembly, wie im folgenden Codebeispiel gezeigt:

type="System.Web.Management.SampleCustomWebEvent, Sample.SampleCustomWebEvent"

Wenn Sie eine Quellcodedatei verwenden, müssen Sie lediglich den Klassennamen angeben.

Im folgenden Beispiel ist dargestellt, wie der EventLogWebEventProvider-Ereignisanbieter einem benutzerdefinierten Ereignis mit dem Namen SampleCustomWebEvent zugeordnet wird. Der EventLogProvider-Ereignisanbieter wurde bereits in der Stammdatei Web.config konfiguriert.

<healthMonitoring 
  heartBeatInterval="0" 
  enabled="true">
  <rules>
    <add 
      name="Sample Custom Events" 
      eventName="SampleCustomWebEvent" 
      provider="EventLogProvider"
      profile="Default" 
      minInstances="1" 
      maxLimit="Infinite" 
      minInterval="00:01:00"
      custom="" 
    />
  </rules>
  <eventMappings>
    <add 
      name="SampleCustomWebEvent" 
      type="System.Web.Management.SampleCustomWebEvent, Sample.SampleCustomWebEvent,Version=1.0.0.0,Culture=neutral, PublicKeyToken=xxxxxxxxxxxx" "
      startEventCode="0" 
      endEventCode="2147483647" 
    />
  </eventMappings>
</healthMonitoring>

Absichern der ASP.NET-Systemüberwachung

In der Standardeinstellung ist das Systemüberwachungsfeature für ASP.NET-Anwendungen aktiviert. Sie können es deaktivieren, indem Sie das enabled-Attribut des healthMonitoring-Elements auf false festlegen. Die Standardkonfigurationseinstellungen sind auf die sichersten verfügbaren Werte festgelegt. Weitere Informationen zu den Konfigurationseinstellungen für die Systemüberwachung finden Sie unter healthMonitoring. Es empfiehlt sich, die Konfigurationseinstellungen für die Systemüberwachung mit dem location-Element zu sperren.

Hinweis:
Wenn Sie benutzerdefinierte Ereignisconsumer oder benutzerdefinierte Ereignisanbieter implementieren, sollten Sie Ereignisinhalte verschlüsseln oder überprüfen, um siteübergreifende Skriptfehler zu vermeiden.

Absichern von Konfigurationswerten

Wenn vertrauliche Informationen in der Konfigurationsdatei einer Anwendung gespeichert werden, müssen Sie die vertraulichen Werte mithilfe der geschützten Konfiguration verschlüsseln. Zu den besonders vertraulichen Informationen gehören die Verschlüsselungsschlüssel, die im machineKey-Konfigurationselement gespeichert sind sowie die im connectionStrings-Konfigurationselement gespeicherten Verbindungszeichenfolgen zu einer Datenquelle. Weitere Informationen finden Sie unter Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration.

Auf den healthMonitoring-Konfigurationsabschnitt kann nur von Code zugegriffen werden, vom dem die mittlere oder eine höhere Vertrauensebene verwendet wird. Dies verhindert, dass benutzerdefinierte Typen von Anwendungen auf niedrigen Vertrauensebenen registriert werden.

Sicherheit zum Erweitern der Systemüberwachung

Die Systemüberwachungstypen im System.Web.Management-Namespace haben folgende Eigenschaften:

• Basisklassenkonstruktoren werden als protectedinternal gekennzeichnet. Instanzen von Basisklassen-Ereignistypen können daher nicht direkt durch Benutzercode erstellt werden.

• Der Zugriff auf Webereignisinstanzen ist auf durch die Konfiguration angegebene Anbieter, Filter und Vorlagenseiten beschränkt.

• Durch Vererbungsverknüpfungsaufrufe für Ereignisse mit geschütztem Inhalt kann sichergestellt werden, dass nur vollständig vertrauenswürdige benutzerdefinierte Ereignisse abgeleitet werden.

• Benutzerdefinierte vertrauenswürdige Ereignisse, die vertrauliche Daten von geschützten Ereigniseigenschaften bereitstellen, müssen Codezugriffssicherheit für sich selbst durchsetzen, um Täuschungsmanöver zu vermeiden. Weitere Informationen zu Codezugriffssicherheit finden Sie unter ASP.NET-Codezugriffssicherheit oder Grundlagen der Codezugriffssicherheit.

• Die WMI-Typen (Windows Management Instrumentation – Windows-Verwaltungsinstrumentation), mit denen Webereignisse angezeigt werden, sind gesperrt, sodass die Benutzer nicht auf die Ereignisdaten zugreifen können.

  Hinweis:
  Wenn Sie benutzerdefinierte Ereignisconsumer oder benutzerdefinierte Ereignisanbieter implementieren, sollten Sie Ereignisinhalte verschlüsseln oder überprüfen, um siteübergreifende Skriptfehler zu vermeiden.

Absichern von Verbindungen mit Datenquellen

Sie können benutzerdefinierte Anbieter für Systemüberwachungsereignisse erstellen, um Ereignisdaten in einer Datenbank zu protokollieren. In ASP.NET ist ein SQL-Anbieter enthalten. Weitere Informationen zum Protokollieren von Ereignisdaten finden Sie unter Sichern des Datenzugriffs.

Um die Verbindung zum Datenbankserver zu sichern, sollten Sie die Informationen über Verbindungszeichenfolgen in der Konfigurationsdatei mithilfe von geschützter Konfiguration verschlüsseln. Weitere Informationen hierzu finden Sie unter Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration.

Wenn Sie einen SQL-Anbieter verwenden, müssen Sie die Datenbank mithilfe von Authentifizierung entsprechend absichern. Microsoft SQL Server Express Edition-Dateien müssen durch Zugriffssteuerungslisten (ACLs) und SQL-Authentifizierung gesichert werden.

Hinweis:
SQL Server Express Edition sollte zur Protokollierung von Ereignissen auf einer Datenbank nicht unter einem Konto ohne Berechtigungen ausgeführt werden.

Absichern gegen Denial-of-Service-Angriffe

Webereignisse können von einer HTTP-Anforderung oder einem Anwendungscode ausgelöst werden, der Ausnahmen oder Ereignisse generiert. Die Kapazität des Ereignisanbieters kann durch eine hohe Anzahl von Ereignissen oder große Ereignisse überschritten werden. In diesem Fall kann die ASP.NET-Anwendung oder der Server überlastet werden. Dies kann sich auf die Speicherverwendung, den Festplattenspeicherplatz und den Netzwerkdatenverkehr auswirken.

Um die Anfälligkeit der Anwendung für einen Denial-of-Service-Angriff zu verringern, wird von ASP.NET in der Standardeinstellung das folgende Design verwendet:

• In ASP.NET ist eine Instanz eines Ereignisses pro Minute zulässig. Diese Drosselungsfrequenz ist im profiles-Element konfiguriert und Ereignissen und Anbietern im rules-Element zugeordnet.

• Die Ereignispufferung ist für jeden Anbietertyp isoliert, um ein Konkurrieren um Pufferplatz zu verhindern. Puffereinstellungen sind im bufferModes-Element konfiguriert. Die Anbieter können für die Verwendung einer bestimmten Gruppe von Puffereinstellungen konfiguriert werden, indem das bufferModes-Element festgelegt wird, das die entsprechenden Einstellungen enthält.

• Um ein benutzerdefiniertes Ereignis auszulösen, ist die mittlere oder eine höhere Vertrauensebene erforderlich.

Als Systemadministrator können Sie Drosselungs- und Pufferungseinstellungen konfigurieren, um den Überlauf zu vermeiden, insbesondere für Ereignisse, die durch HTTP-Anforderungen ausgelöst werden. Zusätzlich können Sie separate Puffermodi einrichten, um wichtige und unwichtige Ereignisse zu verarbeiten.

Sicherheit für Fehlermeldungen und Ereignisse

Um zu verhindern, dass vertrauliche Informationen unerwünschten Quellen verfügbar gemacht werden, konfigurieren Sie die Anwendung so, dass keine ausführlichen Fehlermeldungen angezeigt werden. Sie können die Anwendung auch so konfigurieren, dass ausführliche Fehlermeldungen nur angezeigt werden, wenn es sich bei dem Client selbst um den Webserver handelt. Weitere Informationen finden Sie unter customErrors.

Standardmäßig protokolliert ASP.NET umfangreiche, außergewöhnliche und durch Anforderungen ausgelöste Webereignisse im Leistungsüberwachungssystem. Dies bedeutet, dass in der Standardkonfiguration bei fehlgeschlagenen Anmeldeversuchen der Benutzername und andere Diagnoseinformationen im Anwendungsereignisprotokoll aufgezeichnet werden. Diese Daten können in der Windows-Ereignisanzeige angezeigt werden. Wenn vom Server ein Microsoft Windows Server-Produkt ausgeführt wird, können Sie die Sicherheit der Anwendung erhöhen, indem Sie das Ereignisprotokoll sichern. Darüber hinaus können Sie indirekte Denial-of-Service-Angriffe verhindern, indem Sie Parameter für Größe, Aufbewahrungszeit und andere Merkmale des Ereignisprotokolls festlegen.

Sperren der ASP.NET-Systemüberwachungskonfiguration

Beim Anwendungshosting empfiehlt es sich häufig, einige Einstellungen für eine Site sperren, um Änderungen zu unterbinden. Beispielsweise können Sie die Systemüberwachungseinstellungen für gehostete Anwendungen sperren, um die Gefahr versehentlicher Änderungen an der Konfiguration der Webanwendung zu verringern.

Sie können Konfigurationseinstellungen sperren, indem Sie ein allowOverride="false"-Attribut in einem <location>-Tag hinzufügen. Hierdurch wird vom Konfigurationssystem ein Fehler ausgelöst, wenn eine Konfigurationsdatei auf einer niedrigeren Ebene der Hierarchie versucht, einen im location-Element definierten Konfigurationsabschnitt zu überschreiben.

In der folgenden Beispielkonfigurationsdatei ist dargestellt, wie der healthMonitoring-Abschnitt der ASP.NET-Anwendung mit der Bezeichnung application1 gesperrt werden kann. Die Einstellungen können entweder auf Serverebene in der Datei machine.config oder auf Siteebene gespeichert werden.

<configuration>
  <location path="application1" allowOverride="false">
    <system.web>
      <healthMonitoring
        enabled="true"
        heartBeatInterval="60">
        <bufferModes>
          <add name="Logging"
            maxBufferSize="1000"
            maxFlushSize="200"
            urgentFlushThreshold="800"
            regularFlushInterval="00:30:00"
            urgentFlushInterval="00:05:00"
            maxBufferThreads="1"
          />
        </bufferModes>
        <providers>
           <add name="EventLogProvider"
            type="System.Web.Management.EventLogWebEventProvider, System.Web, Version=%ASSEMBLY_VERSION%, Culture=neutral, PublicKeyToken=%MICROSOFT_PUBLICKEY%"
            buffer="true"
            bufferMode="Logging"
          />
        </providers>
        <eventMappings>
          <add name="All Errors"
            type="System.Web.Management.WebBaseErrorEvent, System.Web, Version=%ASSEMBLY_VERSION%, Culture=neutral, PublicKeyToken=%MICROSOFT_PUBLICKEY%" 
          />
        </eventMappings>
        <profiles>
          <add name="Default"
            minInstances="1"
            maxLimit="Infinite"
            minInterval="00:10:00"
          />
        </profiles>
        <rules>
          <add name="All Errors Default"
            eventName="All Errors"
            provider="EventLogProvider"
            profile="Default"
            minInterval="00:01:00" 
          />
        </rules>
      </healthMonitoring>
    </system.web>
  </location>
</configuration>

Mit zusätzlichen Attributen wie lockItem, lockAttributes oder lockElements können Elemente mit höherer Granularität gesperrt werden. Weitere Informationen finden Sie unter Allgemeine von Abschnittselementen geerbte Attribute.

Zurück nach oben

Codebeispiele

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

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

Gewusst wie: Senden von E-Mail für Systemüberwachungsbenachrichtigungen.

Exemplarische Vorgehensweise: Überwachen von WMI-Ereignissen in der ASP.NET-Systemüberwachung

Zurück nach oben

Klassenreferenz

• System.Web.Management
  Der Namespace, der Typen zum Verwalten und Überwachen des Systemzustands von Webanwendungen enthält.

• System.Management
  Der Namespace, der Typen zum Herstellen einer Verbindung mit der WMI-Infrastruktur (Windows Management Instrumentation – Windows-Verwaltungsinstrumentation) enthält.

• System.Management.Instrumentation
  Der Namespace, der Typen zum Instrumentieren von Anwendungen für potenzielle WMI-Consumer enthält.

• HealthMonitoringSection
  Der Typ, der die healthMonitoring-Konfigurationsattribute programmgesteuert abruft oder festlegt.

Zurück nach oben

Siehe auch

Aufgaben

Gewusst wie: Sperren von ASP.NET-Konfigurationseinstellungen

Konzepte

Erweitern von ASP.NET-Systemüberwachungsereignissen

Übersicht über die ASP.NET-Konfiguration

Referenz

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

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