Problembehandlung bei Cacheelementen ARR V2
von Apurva Joshi
In dieser Problembehandlung verwendete Tools:
- ARR-Hilfsprogramm
- Fehlgeschlagene Anforderungsablaufverfolgung (FREB)
- IIS Advanced Logging
- Netzwerkmonitor
Dieses Material wird nur für Informationszwecke bereitgestellt. Microsoft übernimmt keine Garantie, weder ausdrücklich noch stillschweigend.
Übersicht
In dieser exemplarischen Vorgehensweise werden wir eine Anforderung nachverfolgen, während sie arr durchläuft und an den nächsten Server gesendet wird und die Daten untersuchen, die gesammelt werden können, um die Anforderung zu identifizieren, an die sie gesendet wurde und letztendlich wo sie bedient wurde.
Grundlegendes zur Architektur der Farm
Der erste Schritt besteht darin, die Architektur der Umgebung zu verstehen, einschließlich der folgenden. Ohne Kenntnis davon wäre es unmöglich, eine Art logischer Aktionsplan bei der Problembehandlung zu entwickeln.
- ARR-Farmtopologie (wie viele Server, wie Routing konfiguriert ist, andere Geräte)
- URL Rewrite-Regeln
Für die Zwecke dieser exemplarischen Vorgehensweise verwenden wir die folgende Konfiguration.
Datenträgercachekonfiguration:
Ein lokales Laufwerk mit einer maximalen Größe von 100 GB.
<diskCache>
<driveLocation path="E:\temp$\arrcache" maxUsage="100" />
</diskCache>
Regeln für die globale Cachesteuerung:
Diese Regel wird für 60 Minuten als Cache definiert, wenn keine Cachesteuerungsrichtlinie vorhanden ist.
<rule name="ARR_CacheControl_b5aec65d-6327-407f-a28c-b34e48c5cda2" enabled="true" patternSyntax="Wildcard">
<match url="*" />
<serverVariables>
<set name="ARR_CACHE_CONTROL_OVERRIDE" value="0,max-age=3600" />
</serverVariables>
</rule>
Erstellen eines Datensammlungsplans
In diesem Abschnitt werden wir schrittieren, obwohl der Fluss von Cachetreffern und Fehlern fehlschlägt, da dies durch ARR übergeht und Tools oder Protokolle identifiziert werden, die wir möglicherweise zum Überprüfen der Anforderungen verwenden. In den folgenden Schritten wird der Anforderungsfluss für Inhalte beschrieben, die nicht zuvor mithilfe der oben genannten Konfiguration zwischengespeichert wurden, als referenziert und die Tools, die wir in jedem Schritt verwenden würden.
Der angeforderte Inhalt wird nicht lokal gefunden (weder im Arbeitsspeicher noch auf dem Datenträger auf dem untergeordneten Knoten).
- Freb-Protokolle
- INTEGRIERTE IIS-Protokollierung
- Netzwerkmonitor
Die Anforderung wird an den nächsten Cacheknoten (übergeordneter Knoten) weitergeleitet.
- Freb-Protokolle
- IIS Advanced Logging Modul
- INTEGRIERTE IIS-Protokollierung
- Netzwerkmonitor
Der angeforderte Inhalt wird nicht im nächsten Cacheknoten der Ebene (weder im Arbeitsspeicher noch auf dem Datenträger) gefunden: Wiederholen Sie die Schritte 2 so oft wie je nach Cachehierarchie.
Die Anforderung wird an den Ursprungsserver weitergeleitet.
- Freb-Protokolle
- INTEGRIERTE IIS-Protokollierung
- Netzwerkmonitor
Sammeln der Daten
Der angeforderte Inhalt wird nicht lokal gefunden (weder im Arbeitsspeicher noch auf dem Datenträger).
Hier können wir einen Cachetreffer/Fehler in den IIS-Protokollen oder Freb-Protokollen identifizieren. Die Freb-Protokolle enthalten zusätzliche Details, z. B. wo die Anforderung weitergeleitet wurde, was wichtig ist, wenn mehrere Server auf Down Level vorhanden sind.
IIS-Protokolleintrag: Sie finden die folgenden Einträge im CS - uri-Query-Feld , das den Cachetreffer oder -miss identifiziert und die Guid für die Anforderung, mit der Sie die Anforderung auf Down Level-Servern identifizieren können.
X-ARR-CACHE-HIT=0
0 = Cache miss, 1 = Cache hit
X-ARR-LOG-ID=62a3161c-b4f5-408e-9ce7-55d25c018aea
Guid identifying this request. This can be used to track as the request is passed to Parent nodes.
FREB-Protokoll: Der Cachefehler wird durch den Eintrag ARR_DISK_CACHE_GET_FAILED gefunden.
| type | Eingabe | Details |
|---|---|---|
| r | ARR_DISK_CACHE_GET_FAILED Warnung | FilePath="\?\C:\ARRCache\localhost\iisstart.htm.full", ErrorCode="Das System kann die angegebene Datei nicht finden. (0x80070002)", IsRangeEntry="false", RangeOffset="0", RangeSegmentSize="0" |
Identifizieren Sie den Server, an den die Anforderung weitergeleitet wird. Hier können wir sehen, dass die Anforderung an den Server W2K8WEBSERVER2 gesendet wird, damit wir wissen, dass es sich um unsere nächste Serverebene für die Datenüberprüfung handeln wird.
| type | Eingabe | Details |
|---|---|---|
| i | ARR_SERVER_ROUTED | RoutingReason="LoadBalancing", Server="W2K8WEBSERVER2", State="Active", TotalRequests="8", FailedRequests="0", CurrentRequests="1", BytesSent="1127", BytesReceived="6441379", ResponseTime="31351" |
Die folgenden Header werden der Anforderung für die Weiterleitung hinzugefügt. Wenn einige Namen anders sind als die Standardeinstellungen "X-Forwarded-For", "X-ARR-ClientCert" und "X-ARR-LOG-ID" wurden sie möglicherweise in den Serverfarmproxyeinstellungen angepasst.
| Header | Details |
|---|---|
| GENERAL_SET_REQUEST_HEADER | HeaderName="Max-Forwards", HeaderValue="10", Replace="true" |
| GENERAL_SET_REQUEST_HEADER | HeaderName="X-Forwarded-For", HeaderValue="127.0.0.1:62489", Replace="true" |
| GENERAL_SET_REQUEST_HEADER | HeaderName="X-ARR-SSL", HeaderValue="", Replace="true" |
| GENERAL_SET_REQUEST_HEADER | HeaderName="X-ARR-ClientCert", HeaderValue=", Replace="true" |
| GENERAL_SET_REQUEST_HEADER | HeaderName="X-ARR-LOG-ID", HeaderValue="fe9d20da-a571-4451-8ef3-0e7faf1a463a", Replace="true" |
Die Anforderung wird an den nächsten Cacheknoten der Ebene weitergeleitet (übergeordneter Knoten)
Im vorherigen Schritt haben wir diesen Server als W2K8WEBSERVER2 identifiziert, sodass wir die folgenden Daten auf diesem Server untersuchen werden. Wie in den vorherigen Schritten gibt es mehrere Datenpunkte, die verwendet werden können. Mit der X-ARR-LOG-ID können wir die Anforderung identifizieren, die auf diesem Server erreicht wurde.
FREB-Protokolle: Die Anforderung kann durch die X-ARR-LOG-ID identifiziert werden, die vom untergeordneten Knoten gesendet wird. Wir haben dies im letzten Schritt als "fe9d20da-a571-4451-8ef3-0e7faf1a463a" identifiziert.
| Header | Details |
|---|---|
| GENERAL_REQUEST_HEADERS | Headers="Connection: Keep-Alive Accept: */* Host: localhost Max-Forwards: 10 X-Original-URL: /iisstart.htm X-Forwarded-For: 127.0.0.1:62489 X-ARR-LOG-ID: fe9d20da-a571-4451-8ef3-0e7faf1a463a |
IIS Advanced Logging Modul: Mithilfe der erweiterten Protokollierung können wir benutzerdefinierte Protokollierungsfelder basierend auf den Headern X-Forwarded-For und X-ARR-LOG-ID hinzufügen und dann zum Protokollieren verwendet werden, wenn diese Header vorhanden sind.
#Software: IIS Advanced Logging Module
#Version: 1.0
#Start-Date: 2009-10-16 18:42:51.494
#Filter: ((ARRLogID isPresent ) || (xforward isPresent ))
#Fields: date time cs-uri-stem cs-uri-query s-contentpath sc-status s-computername cs(Referer) sc-win32-status sc-bytes cs-bytes X-ARR-LOG-ID X-Forwarded-For
2009-10-16 18:51:29.983 /iisstart.htm - "C:\inetpub\wwwroot\iisstart.htm" 200 "W2K8WEBSERVER2" - 0 1680 219 "fe9d20da-a571-4451-8ef3-0e7faf1a463a" "127.0.0.1:62489"
Netzwerkmonitor: Erneut könnten wir die Ablaufverfolgung verwenden, um die X-ARR-LOG-ID und X-Forwarded-For zu identifizieren, wenn wir eine bestimmte Anforderung nachverfolgen.
ARR-Hilfsprogramm: Dieses Modul fügt das X-Forwarded-For dem C-IP-Feld und der X-ARR-LOG-ID dem cs-uri-query-Feld der Standard-IIS-Protokolle hinzu.
Hinweis
Der ArrHelper wird derzeit von Microsoft nicht unterstützt.
Wiederholen Sie die Schritte 1 und 2 für mehrere Cacheebenen.
Wenn der übergeordnete Serverknoten W2K8WEBSERVER2 auch mit ARR- und Zwischenspeicherungsfeatures konfiguriert ist, sehen wir uns erneut die IISLOGS/FREB an, um zu sehen, ob der Cache hit/Miss vorhanden ist und wo sie auf dieser Suche basieren.
Anforderung wird an den Origin Server weitergeleitet.
Dieser Schritt kann als normale HTTP/s-Anforderung behandelt werden und mit den folgenden Tools nachverfolgt werden.
- Netzwerkmonitor: Erfassen von Ablaufverfolgungen auf dem Origin-Server, um den Empfang der Anforderung zu überprüfen
- IIS-Protokolle: Überprüfen von IIS-Protokollen für Http-Antwortcodes für den Inhalt, den Sie nachverfolgen möchten
- IIS FREB-Protokolle: Wenn die Anforderung in der Netzwerkablaufverfolgung gefunden wurde und der Http-Antwortcode kein 200 war, sollten Sie FREBagain verwenden, um das Problem zu beheben.
Problembehandlung bei Cachefehlern
Überprüfen von Cache-Control Headern
Überprüfen Sie Cache-Control Header, die vom Client empfangen wurden. Dies kann in Verbindung mit der Überprüfung der Cachesteuerelementregeln erfolgen, da sie so konfiguriert werden können, dass Kopfzeilen überschreiben können.
Überprüfen Cache-Control Regeln in ARR
Überprüfen Sie die Cachesteuerungsregeln in ARR, um zu überprüfen, ob die ARR-Zwischenspeicherung aktiviert ist.
Überprüfen HTTP.SYS Einstellungen
Überprüfen der Gründe, warum Inhalte nicht von HTTP.sys im Kernel HIER zwischengespeichert werden
Datenträgercachefehler
Arr protokolliert Ereignisse im Anwendungsereignisprotokoll, wenn Datenträgerfehler auftreten und den Datenträger als ungesund kennzeichnen.
| Protokollname: Application |
|---|
| Quelle: Anwendungsanforderungsrouting |
| Datum: 11.2.2009 5:26:59 Uhr |
| Ereignis-ID: 1006 |
| Aufgabenkategorie: Keine |
| Ebene: Warnung |
| Schlüsselwörter: Klassisch |
| Benutzer: N/V |
| Computer: |
| Beschreibung: Laufwerk mit Pfad '\?\E:\temp$\arrcache' wird ungesund markiert. Die Daten enthalten den Fehlercode. |
| Ereignis-XML: |