Problembehandlung von Webanwendungen

AppFabric stellt Funktionen zum Verwalten von IIS-gehosteten .NET Framework, Version 4 WCF- und WF-Diensten zur Verfügung. Diese Funktionen umfassen Zuverlässigkeitsmechanismen für das Hosten dauerhafter Workflowdienste, vereinfachte Anwendungskonfiguration sowie Tools zum Überwachen der Integrität der .NET Framework 4 WCF- und WF-Dienste. In diesem Abschnitt wird die Verwendung der Überwachungstools für die Problembehandlung der Dienste beschrieben.

Verwenden Sie das Dashboard, um mit der Problembehandlung der WCF- und WF-Dienste zu beginnen. Klicken Sie auf das Symbol Dashboard in der Gruppe AppFabric in IIS-Manager, um die Seite Dashboard anzuzeigen. Diese Verbundseite bietet eine Zusammenfassungsansicht der Integrität von in einem bestimmten Bereich in IIS bereitgestellten Webanwendungen und stellt Links für den Drilldownvorgang zur Verfügung, um spezifischere Problembehandlungsinformationen zu erhalten. Wenn in der vom Dashboard und den verwandten Seiten angezeigten Metrik nicht die ausführlichen Informationen bereitgestellt werden, die zum Beheben des Problems erforderlich sind, können Sie die AppFabric-Tools zum Aktivieren der System.Diagnostics-Ablaufverfolgung verwenden, um die Problembehandlung einer WCF- oder WF-Webanwendung auszuführen.

Problembehandlung mithilfe des Dashboards

Bei verteilten Webanwendungen genügt für die Isolation eines Problems nicht die Auswertung eines Leistungsindikators oder die Verwendung nur eines einzelnen Tools. Das Beheben von Problemen in einer verteilten Dienstumgebung beinhaltet dagegen häufig das Korrelieren von Daten aus verschiedenen Tools oder Leistungsindikatoren, um ein realistisches Bild von der wahren Ursache eines Problems zu gewinnen. Das Dashboard enthält drei Widgets: Persistente WF-Instanzen, WCF-Aufrufverlauf und WF-Instanzverlauf. Mit diesen können Sie Informationen für die Problembehandlung Ihrer Webanwendungen in Beziehung setzen. Die beiden letztgenannten Widgets stellen Verlaufsmetrik zur Verfügung. Dies bedeutet, dass die angezeigten Daten durch die Zeitauswahl Zeitraum oben im Dashboard (Letzte Minute, Letzte 24 Stunden usw.) beeinflusst werden.

Wenn Sie eines der drei Widgets erstmals öffnen oder anzeigen, wird eine Zusammenfassungsansicht des Status seiner Metrik auf hoher Ebene angezeigt. Sie können schnell erkennen, ob ein Problem auf der betreffenden Ebene vorliegt. Das Widget Persistente WF-Instanzen zeigt z. B. anfangs den Status von dauerhaften Liveworkflowinstanzen an, deren Status im Persistenzspeicher gespeichert wurde. Es gibt den Zusammenfassungsstatus der Anzahl der persistenten Instanzen an, die sich im Zustand Aktiv, Im Leerlauf und Angehalten befinden. Mithilfe dieser Angaben können Sie sich schnell informieren, ob ein Problem auf der persistenten Workflowebene vorliegt. Sie können auf der Zusammenfassungsseite auf Links klicken, um weitere Informationen zu dem betreffenden Zusammenfassungsleistungsindikator zu erhalten.

Verwenden der Metrik von „Persistente WF-Instanzen“

Das Widget Persistente WF-Instanzen zeigt anfangs den Status von Liveworkflowinstanzen an, deren Status im Persistenzspeicher gespeichert wurde. Es zeigt die Anzahl der persistenten Instanzen an, die sich im Zustand Aktiv, Im Leerlauf und Angehalten befinden. Jede Überschrift (wie auch die Zusammenfassungsanzahl selbst) ist ein Link zur Seite Persistente WF-Instanzen, die die Rohdaten enthält.

Zum besseren Verständnis des Problems bei der Problembehandlung angehaltener Instanzen klicken Sie im Dashboard auf den Link Angehaltene Instanzen. Die Seite Persistente WF-Instanzen zeigt alle angehaltenen Instanzen an. Wenn Sie eine von ihnen auswählen, wird der Detailbereich unten auf dem Bildschirm mit Zusammenfassungsinformationen zur angehaltenen Instanz aufgefüllt. Die Registerkarte Fehler zeigt den Grund an, warum die Instanz angehalten wurde. Wenn Sie weitere Informationen benötigen, können Sie mit der rechten Maustaste auf eine Instanz klicken und dann die Option Nachverfolgte Ereignisse anzeigen auswählen. Mithilfe dieser Aktion gelangen Sie zur Seite Nachverfolgte Ereignisse, auf der alle nachverfolgten Ereignisse für die angehaltene Workflowinstanz angezeigt werden. Die Ereignisse sind standardmäßig so sortiert, dass das aktuellste Ereignis ganz oben angezeigt wird.

Verwenden der Metrik „WCF-Aufrufverlauf“

Das Widget WCF-Aufrufverlauf zeigt die Anzahl der WCF-Aufrufe an, die im Überwachungsspeicher empfangen und aufgezeichnet wurden. Die Überschrift zeigt eine Zusammenfassungsanzahl der Aufrufe an, die abgeschlossen wurden bzw. für die Ausnahmen aufgetreten sind, sowie die Anzahl der Drosselungstreffer. In der ersten Spalte werden die fünf Dienste mit den meisten abgeschlossenen Aufrufen angezeigt. In der zweiten Spalte wird eine Aufschlüsselung der WCF-Fehler nach Fehlertyp gruppiert angezeigt. In der dritten Spalte werden die fünf Dienste mit den meisten Dienstausnahmen angezeigt. Jede Metrik ist mit der Seite Nachverfolgte Ereignisse verknüpft, auf der Sie die Rohdaten anzeigen können, die im Dashboard zusammengefasst werden.

Wenn Sie z. B. weitere Informationen zu einem Aufruffehler abrufen möchten, klicken Sie auf den Zusammenfassungsleistungsindikator Aufruffehler, und navigieren Sie dann zur Seite Nachverfolgte Ereignisse. Diese Seite enthält die aktuellsten WCF-Aufruffehler für den ausgewählten Bereich in der IIS-Hierarchie. Wenn Sie eines dieser Ereignisse auswählen, wird der Detailbereich im unteren Teil des Bildschirms mit Daten aufgefüllt. Die Registerkarte Fehler enthält Ausnahmeinformationen zum Fehler. Wenn Sie mehr Kontext zum Aufruffehler benötigen, können Sie mit der rechten Maustaste auf das Ereignis klicken und dann die Option Alle zugehörigen Ereignisse anzeigen auswählen. Durch diese Aktion wird die Seite Nachverfolgte Ereignisse aktualisiert und mit allen Ereignissen aufgefüllt, die sich auf das erste Ereignis beziehen.

Verwenden der Metrik „WF-Instanzverlauf“

Das Widget WF-Instanzverlauf zeigt die Anzahl der Workflowinstanzen an, die aktiviert oder abgeschlossen wurden bzw. fehlerhaft waren. In der ersten Spalte werden die fünf Dienste mit den meisten Aktivierungen angezeigt. In der zweiten Spalte werden die fünf Dienste mit den meisten Instanzfehlern angezeigt. Die dritte Spalte zeigt an, wie viele der Instanzfehler wiederhergestellt wurden. Wenn für eine Workflowinstanz z. B. ein Fehler aufgetreten ist, der zum Anhalten der Instanz geführt hat, und die Instanz später fortgesetzt und erfolgreich abgeschlossen wurde, wird die Anzahl eins in der Spalte Fehler und in der Spalte Wiederhergestellt angezeigt.

Die Problembehandlung mithilfe der Informationen aus dem Widget WF-Instanzverlauf ähnelt der Verwendung des Widgets Persistente WF-Instanzen. Klicken Sie auf eine der Überschriften, um zur Seite Nachverfolgte WF-Instanzen zu navigieren, auf der Sie Zusammenfassungsinformationen zur Workflowinstanz anzeigen können. Da das Widget WF-Instanzverlauf jedoch Workflowinstanzen anzeigt, die ggf. bereits abgeschlossen wurden, sehen Sie nicht die Instanzsteuerungsaktionen, die auf der Seite Persistente WF-Instanzen angezeigt werden. Auf der Seite Nachverfolgte WF-Instanzen können Sie mit der rechten Maustaste auf eine Instanz klicken und dann ihre nachverfolgten Ereignisse anzeigen, um Nachverfolgungsdaten auf niedriger Ebene für die Instanz zu überprüfen.

Problembehandlung mithilfe von „System.Diagnostics“-Ablaufverfolgung

AppFabric nutzt die Verbesserungen der WCF-Ablaufverfolgung und der WF-Nachverfolgung in .NET Framework 4, die Ereignisse an das Untersystem „Ereignisablaufverfolgung für Windows (ETW)“ ausgeben. ETW stellt eine schnelle Infrastruktur zur Ereignisablaufverfolgung zur Verfügung. Unter bestimmten Umständen müssen Sie jedoch alle verfügbaren Diagnoseinformationen anzeigen. In AppFabric können Sie System.Diagnostics-Ablaufverfolgung auf Anwendungs- oder Siteebene aktivieren. Diese Ablaufverfolgungsinformationen werden in Dateien auf dem Datenträger geschrieben und können mit dem Hilfsprogramm Dienstablaufverfolgungs-Viewer des Diensts angezeigt werden.

Problembehandlung einer verteilten ASP.NET-Anwendung

Sie können die Aktivitäts-ID (wie oben im Abschnitt Verwenden der Metrik „WCF-Aufrufverlauf“ beschrieben) verwenden, um eine dauerhafte Instanz-ID nachzuschlagen und die Problembehandlung einer ASP.NET-Anwendung auf diese Weise zu unterstützen, die über mehrere AppFabric-Servercomputer hinweg mit WCF-Diensten kommuniziert. Zu diesem Zweck muss die Überwachungsstufe mindestens auf End-To-End-Überwachung festgelegt sein, damit Aktivitätsablaufverfolgung konfiguriert werden kann. Das folgende Beispiel zeigt die Vorgehensweise.

Während der Überwachung der Webanwendung mithilfe von ASP- und IIS-Überwachungstools bemerkt der Administrator eine Zunahme von Timeoutfehlern für die ASP.NET-Anwendung bei der Kommunikation mit einem Dienst. Nach dem Überprüfen der Fehler ruft der Administrator die Aktivitäts-ID ab, die zum Zeitpunkt des Auftretens des Fehlers aktiv ist. Mithilfe des AppFabric-Dashboards erstellt der Administrator eine Abfrage für diese Aktivitäts-ID und führt sie dann aus. Ein Ereignis wird zurückgegeben – ein Empfangsereignis für die Instanz Y von Dienst X. Der Administrator zeigt die Nachrichtenübermittlung an, die diesem Ereignis zugeordnet ist, und bemerkt dabei ein Ereignis des Typs „Die Einschränkung der maximalen Anzahl gleichzeitiger Aufrufe wurde überschritten“. Der Administrator bemerkt bei der Untersuchung der Zusammenfassungsseiten des Diensts, dass der Leistungsindikator „WCF-Drosselungstreffer“ auf 20 festgelegt ist. Er überprüft außerdem die Aufrufe für den Zeitraum der letzten 24 Stunden und ermittelt eine Spitze innerhalb der letzten 30 Minuten. Er zeigt andere Tage an und stellt fest, dass das gleiche Phänomen zur gleichen Uhrzeit an jedem Tag aufgetreten ist. Er schließt daraus, dass die Last zu dieser Uhrzeit täglich zunimmt und die Einstellung für die Einschränkung der maximalen Anzahl gleichzeitiger Aufrufe auf den Wert 25 erhöht werden sollte. Durch sorgfältige Beobachtung stellt der Administrator fest, dass das Auftreten von Einschränkungsereignissen erheblich abnimmt. Gleiches gilt für die Timeoutfehler für die ASP.NET-Anwendung beim Aufrufen der WCF-Dienste.

Aufträge des Windows-Diensts SQL Server-Agent

Der Windows-Dienst SQL Server-Agent überwacht SQL Server-Vorgänge, automatisiert bestimmte Verwaltungsaufgaben, generiert bei Bedarf Warnungen und plant Aufträge und führt diese aus. Ein SQL Server-Auftrag ist eine angegebene Folge von Vorgängen, die sequenziell vom SQL Server-Agent ausgeführt werden und eine Vielzahl von datenbankbezogenen Aufgaben beinhalten. Wenn AppFabric für die Verwendung von SQL Server konfiguriert ist, wird der SQL Server-Agent zum Importieren von Ereignissen in den Überwachungsdatenspeicher sowie zum regelmäßigen Bereinigen alter Daten aus dem Informationsspeicher verwendet.

Wenn der SQL Server-Agent nicht ausgeführt wird, können die geplanten AppFabric-Aufträge nicht in der SQL Server-Installation ausgeführt werden. Mit den folgenden Schritten kann sichergestellt werden, dass diese Aufträge mithilfe des Windows-Diensts „SQL Server-Agent“ wie geplant ausgeführt werden:

1. Stellen Sie sicher, dass der Windows-Dienst SQL Server-Agent ausgeführt wird, indem Sie seinen Status überprüfen. Klicken Sie auf Verwaltung, wählen Sie Dienste aus, wählen Sie SQL Server-Agent (MSSQLSVR) aus, und vergewissern Sie sich dann, dass sein Status zurzeit als Gestartet angezeigt wird. Ist dies nicht der Fall, starten Sie den Dienst.

2. Vier SQL Server-Aufträge werden beim Initialisieren des Informationsspeichers erstellt:

   • Microsoft_ApplicationServer_Monitoring_AutoPurge_<Name_der_Überwachungsdatenbank>

   • Microsoft_ApplicationServer_Monitoring_ImportWfEvents_<Name_der_Überwachungsdatenbank>

   • Microsoft_ApplicationServer_Monitoring_ImportWcfEvents_<Name_der_Überwachungsdatenbank>

   • Microsoft_ApplicationServer_Monitoring_ImportTransferEvents_<Name_der_Überwachungsdatenbank>

   Wenn der Windows-Dienst SQL Server-Agent gestartet wurde und die AppFabric-Aufträge nicht ausgeführt werden, überprüfen Sie die bei der letzten Ausführung des Auftrags aufgetretenen Fehler.

3. Wenn die Auftragsinstanzen erfolgreich abgeschlossen wurden, die Ereignistabellen jedoch keine Ereignisse verzeichnen, suchen Sie im Überwachungsdatenbankspeicher in der Tabelle ASFailedStagingTable. Diese Tabelle enthält bestimmte Spalten, wie etwa ErrorNumber und ErrorMessage, die Sie beim Ermitteln der Ursache von Fehlern unterstützen können. Wenn kein Fehler aufgetreten ist, ist die Tabelle leer.

Die Windows-Identität (Besitzer), unter der ein Auftrag des AppFabric SQL Server-Agents ausgeführt wird, sollte nicht die Identität des angemeldeten Benutzers sein. Der Auftrag sollte stattdessen unter der Identität des vorkonfigurierten Windows-Sicherheitskontos AS_MonitoringDbJobsAdmin ausgeführt werden. Dieses Konto sollte idealerweise als Domänenkonto festgelegt werden. Ihm werden im Überwachungsspeicher die benötigten Berechtigungen erteilt, wenn das Cmdlet Initialize-ASMonitoringDatabase nach der Installation ausgeführt wird.

Der SQL Server-Agent verarbeitet die verschiedenen Besitzer eines übermittelten AppFabric Server-Auftrags auf die folgende Weise:

• Wenn der Besitzer eines SQL Server-Agent-Auftrags ein Domänenkonto ist, stellt SQL Server eine Verbindung mit dem Domänencontroller her und überprüft, ob das Konto gültig ist. In diesem Fall wird er unter dem Domänenkonto ausgeführt, andernfalls versucht er die Ausführung unter einem lokalen Konto.

• Wenn der Besitzer eines SQL Server-Agent-Auftrags ein lokales Systemadministratorkonto ist, berücksichtigt der SQL Server-Agent ordnungsgemäß die Identität RunAs des Auftragsschritts und gibt den Befehl Execute user as AS_MonitoringDbJobsAdmin aus. Dies bedeutet, dass der Auftrag unter der Identität des Kontos AS_MonitoringDbJobsAdmin ausgeführt wird.

  Hinweis

  Wenn Sie die Identität „RunAs“ für einen Auftrag in SQL Server Management Studio anzeigen möchten, klicken Sie mit der rechten Maustaste auf den Auftrag, klicken Sie auf Eigenschaften, und klicken Sie dann auf die Registerkarte Erweitert. Der Wert sollte auf das Konto AS_MonitoringDbJobsAdmin festgelegt sein.

• Wenn der Besitzer eines SQL Server-Agent-Auftrags ein lokales Konto (jedoch nicht das Systemadministratorkonto) ist, wird die für den Auftragsschritt bereitgestellte Identität RunAs ignoriert. In diesem Fall führt der SQL Server-Agent-Dienst den Auftrag als lokaler Besitzer aus.

• Wenn im Fall einer Trennung von der Domäne (z. B. auf einem Laptop) die Identität eines SQL Server-Überwachungsauftrags ein Domänenbenutzer ist, versucht der SQL Server-Agent, das Konto durch Herstellen einer Verbindung zum Domänencontroler zu überprüfen. Wenn der Computer, auf dem der Auftrag des SQL Server-Agents ausgeführt wird, von der Domäne getrennt ist, tritt bei diesem Versuch ein Fehler auf. Zum Abmildern dieses Fehlers bestehen zwei Optionen:

  1. Die erste (und einfachste) Option ist das Konfigurieren des Auftrags (d. h. Ausführen des Cmdlets Initialize-ASMonitoringDatabase) mithilfe eines lokalen Benutzerkontos.

  2. Wenn ein Auftrag durch einen Besitzer mithilfe eines Domänenkontos konfiguriert ist, kann der Benutzer als zweite Option den Auftragsbesitzer nachträglich als lokales Benutzerkonto mithilfe der gespeicherten SQL Server-Prozedur sp_update_job aktualisieren.

Eine bewährte Methode besteht im Konfigurieren des Windows-Diensts SQL Server-Agent für die Ausführung unter einem lokalen Anmeldekonto. Auf diese Weise kann der Dienst selbst dann auf einem Computer mit AppFabric ausgeführt werden, wenn seine Netzwerkverbindung beendet wurde. Wenn der Dienst unter einem Domänenkonto ausgeführt wird, und der Zugriff auf die Domäne nicht erfolgen kann, kann der Windows-Dienst SQL Server-Agent keine Anmeldeinformationen abrufen. Dies bedeutet, dass Überwachungsereignisse nicht ordnungsgemäß in ihre endgültigen Zieltabellen verschoben werden können. Als Ergebnis werden keine neuen Daten im Dashboard angezeigt.

SQL Server Express-Aufträge

Die Schritte zur Diagnose, warum ein Auftragsfehler aufgetreten ist, ähneln den Schritten in SQL Server sehr – für SQL Server Express müssen Sie jedoch die Tabelle JobsTable untersuchen. Diese Tabelle ist für eine Installation von SQL Server Express spezifisch und in einer Installation von SQL Server nicht vorhanden. In dieser Tabelle können Sie die Werte der Spalten LastRunOn und LastRunSuccess in einer bestimmten Auftragsreihe anzeigen, um zu ermitteln, ob ein Auftrag erfolgreich ausgeführt wurde oder ob ein Fehler aufgetreten ist.

SQL Server Express verwendet nicht den Windows-Dienst SQL Server-Agent. Stattdessen wird der SQL Service Broker genutzt. Es besteht eine Möglichkeit zur Zeitsteuerung im Service Broker-Feature, für das ein Timeoutwert auf das Intervall festgelegt ist, in dem die Ausführung des Auftrags Microsoft_ApplicationServer_Monitoring_AutoPurge_<Name_der_Überwachungsdatenbank> konfiguriert ist. Wenn dieses Timeoutintervall auftritt, wird eine Nachricht an die SQL Server-Auftragswarteschlange gesendet. Diese Nachricht aktiviert die gespeicherte Prozedur, die als Teil des Auftrags Microsoft_ApplicationServer_Monitoring_AutoPurge_<Name_der_Überwachungsdatenbank> ausgeführt wird. Die gespeicherte Prozedur führt ihrerseits die automatische Bereinigungsfunktion für einen SQL Server Express-Informationsspeicher aus.

Die folgenden Beispiele zeigen einige T-SQL-Abfragen, die Sie zum Überwachen des Status der automatischen Bereinigungsfunktion für den Informationsspeicher ausführen können:

• Zeigt die aktuell geplanten Aufträge an: SELECT * FROM ASJobsTable

• Untersucht die Spalte dialog_timer (UTC), um die nächste geplante Ausführung des Auftrags zu ermitteln: SELECT * FROM sys.conversation_endpoints

• Zeigt die Anzahl der aktuell ausgeführten Aktivierungsprozeduren an: SELECT * FROM sys.dm_broker_activated_tasks

• Ermittelt, wie viele Nachrichten noch in der Warteschlange enthalten sind. Wenn keine Aufträge ausgeführt werden, gibt diese Abfrage 0 zurück: SELECT * FROM ASScheduledJobQueue

Siehe auch

Verweis

Windows Server AppFabric-Dashboard (Seite)
Persistente WF-Instanzen (Seite)
Nachverfolgte WF-Instanzen (Seite)
Erfasste Ereignisse (Seite)

  2011-12-05