Überwachen von Metriken und Protokollen in Azure Front Door
Azure Front Door bietet eine Reihe von Features, mit denen Sie Ihre Anwendung überwachen, Anforderungen nachverfolgen und Ihre Front Door-Konfiguration debuggen können.
Protokolle und Metriken werden von Azure Monitor gespeichert und verwaltet.
Berichte bieten Erkenntnisse zum Fluss Ihres Datenverkehrs über Azure Front Door und die Web Application Firewall (WAF) bis zu Ihrer Anwendung.
Metriken
Die Metriken von Azure Front Door werden in Intervallen von 60 Sekunden gemessen und gesendet. Die Verarbeitung der Metriken durch Azure Monitor kann bis zu 3 Minuten dauern, und sie werden möglicherweise erst angezeigt, wenn die Verarbeitung abgeschlossen ist. Metriken können auch in Diagrammen oder Rastern angezeigt werden und sind über das Azure-Portal, die Azure PowerShell, die Azure CLI und die Azure Monitor-APIs zugänglich. Weitere Informationen finden Sie unter Azure Monitor-Metriken.
Die in der folgenden Tabelle aufgeführten Metriken werden für einen begrenzten Zeitraum kostenlos aufgezeichnet und gespeichert. Gegen Aufpreis können Sie sie für einen längeren Zeitraum speichern.
| Metriken | BESCHREIBUNG | Dimensionen | Empfohlene Aggregationen |
|---|---|---|---|
| Bytetrefferquote | Der Prozentsatz des Datenverkehrs, der aus dem Azure Front Door-Cache bedient wurde, berechnet als Anteil des gesamten ausgehenden Datenverkehrs. Das Bytetrefferverhältnis ist niedrig, wenn der größte Teil des Datenverkehrs an den Ursprung weitergeleitet wird, statt aus dem Cache bedient zu werden. Bytetrefferquote = (vom Edge ausgehende Daten – vom Ursprung ausgehende Daten)/vom Edge ausgehende Daten Von der Berechnung der Bytetrefferquote ausgeschlossene Szenarien:
|
Endpunkt | Durchschn. Min |
| Prozentsatz der Ursprungsintegrität | Der Prozentsatz der erfolgreichen Integritätstests, die von Azure Front Door an die Ursprünge gesendet werden. | Ursprung, Ursprungsgruppe | Avg |
| Ursprüngliche Wartezeit | Azure Front Door berechnet die Zeit vom Senden der Anforderung an den Ursprung bis zum Empfang des letzten Antwortbytes vom Ursprung. WebSocket wurde von der Ursprungslatenz ausgeschlossen. | Endpunkt, Ursprung | Durchschn. Max |
| Anzahl der Ursprungsanforderungen | Die Anzahl der von Azure Front Door an die Ursprünge gesendeten Anforderungen. | Endpunkt, Ursprung, HTTP-Status, HTTP-Statusgruppe | Avg, Sum |
| Prozentsatz von 4xx | Der Prozentsatz aller Clientanforderungen, deren Antwortstatuscode 4XX lautet | Endpunkt, Land des Clients, Region des Clients | Durchschn. Max |
| Prozentsatz von 5xx | Der Prozentsatz aller Clientanforderungen, deren Antwortstatuscode 5XX lautet | Endpunkt, Land des Clients, Region des Clients | Durchschn. Max |
| Anzahl der Anforderungen | Die Anzahl der Clientanforderungen, die über Azure Front Door bedient werden, einschließlich der vollständig aus dem Cache bedienten Anforderungen. | Endpunkt, Land des Clients, Region des Clients, HTTP-Status, HTTP-Statusgruppe | Avg, Sum |
| Anforderungsgröße | Die Anzahl der von Clients als Anforderungen an Azure Front Door gesendeten Bytes. | Endpunkt, Land des Clients, Region des Clients, HTTP-Status, HTTP-Statusgruppe | Durchschn. Max |
| Antwortgröße | Die Anzahl der von Front Door Service als Antworten an Clients gesendeten Bytes. | Endpunkt, Land des Clients, Region des Clients, HTTP-Status, HTTP-Statusgruppe | Durchschn. Max |
| Gesamtlatenz | Azure Front Door empfängt die Clientanforderung und sendet das letzte Antwortbyte an den Client. Dies ist die gesamt benötigte Zeit. Bei WebSocket bezieht sich diese Metrik auf die Zeit, die zum Herstellen der WebSocket-Verbindung erforderlich ist. | Endpunkt, Land des Clients, Region des Clients, HTTP-Status, HTTP-Statusgruppe | Durchschn. Max |
| Anforderungsanzahl für die Web Application Firewall | Die Anzahl der Anforderungen, die von der Azure Front Door Web Application Firewall verarbeitet werden. | Aktion, Richtlinienname, Regelname | Avg, Sum |
Hinweis
Wenn bei einer Anforderung an den Ursprung ein Timeout besteht, ist der Wert der Http-Statusdimension0.
Protokolle
Protokolle verfolgen alle Anforderungen nach, die Azure Front Door durchlaufen. Die Verarbeitung und Speicherung von Protokollen kann einige Minuten in Anspruch nehmen.
Es gibt mehrere Front Door-Protokolle, die Sie für verschiedene Zwecke verwenden können:
- Zugriffsprotokolle können verwendet werden, um langsame Anforderungen zu identifizieren, Fehlerraten zu ermitteln und zu verstehen, wie das Zwischenspeicherungsverhalten von Front Door für Ihre Lösung funktioniert.
- WAF-Protokolle (Web Application Firewall) können verwendet werden, um potenzielle Angriffe und falsch positive Befunde zu erkennen, die einen Hinweis auf legitime Anforderungen darstellen können, die von der WAF blockiert wurden. Weitere Informationen zu WAF-Protokollen finden Sie unter Überwachung und Protokollierung von Azure Web Application Firewall.
- Integritätstestprotokolle können verwendet werden, um Ursprünge zu identifizieren, die fehlerhaft sind oder nicht auf Anforderungen von einigen der geografisch verteilten PoPs von Front Door reagieren.
- Aktivitätsprotokolle bieten Einblick in die Vorgänge, die für Ihre Azure-Ressourcen ausgeführt werden, etwa Konfigurationsänderungen an Ihrem Azure Front Door-Profil.
Zugriffsprotokolle und WAF-Protokolle beinhalten einen Nachverfolgungsverweis, der mithilfe des X-Azure-Ref-Headers auch in Anforderungen an Ursprünge und Clientantworten weitergegeben wird. Sie können den Nachverfolgungsverweis verwenden, um eine End-to-End-Ansicht ihrer Anwendungsanforderungsverarbeitung zu erhalten.
Zugriffsprotokolle, Integritätstestprotokolle und WAF-Protokolle sind standardmäßig nicht aktiviert. Informationen zum Aktivieren und Speichern Ihrer Diagnoseprotokolle finden Sie unter Konfigurieren von Azure Front Door-Protokollen. Aktivitätsprotokolleinträge werden standardmäßig gesammelt und können im Azure-Portal angezeigt werden.
Zugriffsprotokoll
Informationen zu den einzelnen Anforderungen werden im Zugriffsprotokoll protokolliert. Jeder Zugriffsprotokolleintrag enthält die in der folgenden Tabelle aufgeführten Informationen.
| Eigenschaft | BESCHREIBUNG |
|---|---|
| TrackingReference | Die eindeutige Verweiszeichenfolge, die eine von Azure Front Door verarbeitete Anforderung identifiziert. Der Nachverfolgungsverweis wird mithilfe der X-Azure-Ref-Header an den Client und an den Ursprung gesendet. Verwenden Sie den Nachverfolgungsverweis, wenn Sie in den Zugriffs- oder WAF-Protokollen nach einer bestimmten Anforderung suchen. |
| Time | Das Datum und die Uhrzeit, zu denen das Azure Front Door-Edge den angeforderten Inhalt an den Client gesendet hat (in UTC). Bei WebSocket-Verbindungen gibt die Zeit an, wann die Verbindung getrennt wird. |
| HttpMethod | Die von der Anforderung verwendete HTTP-Methode: DELETE, GET, HEAD, OPTIONS, PATCH, POST oder PUT. |
| HttpVersion | Die HTTP-Version, die der Client in der Anforderung angegeben hat. |
| RequestUri | Der URI der empfangenen Anforderung. Dieses Feld enthält das vollständige Schema, den Port, die Domäne, den Pfad und die Abfragezeichenfolge. |
| HostName | Der Hostname in der Anforderung vom Client. Wenn Sie benutzerdefinierte Domänen aktivieren und über eine Platzhalterdomäne (*.contoso.com) verfügen, lautet der Wert des HostName-Protokollfelds subdomain-from-client-request.contoso.com. Wenn Sie die Azure Front Door-Domäne (contoso-123.z01.azurefd.net) verwenden, lautet der Wert des HostName-Protokollfelds contoso-123.z01.azurefd.net. |
| RequestBytes | Die Größe der HTTP-Anforderungsnachricht in Byte, einschließlich Anforderungsheader und -text. Bei WebSocket-Verbindungen ist dies die Gesamtanzahl der Bytes, die vom Client über die Verbindung an den Server gesendet wurden. |
| ResponseBytes | Größe der HTTP-Antwortnachricht in Byte. Bei WebSocket-Verbindungen ist dies die Gesamtanzahl der vom Server an den Client über die Verbindung gesendeten Bytes. |
| UserAgent | Der Benutzer-Agent, den der Client verwendet hat. In der Regel identifiziert der Benutzer-Agent den Browsertyp. |
| ClientIp | Die IP-Adresse des Clients, der die ursprüngliche Anforderung gestellt hat. Wenn in der Anforderung ein X-Forwarded-For-Header vorhanden ist, wird die Client-IP-Adresse aus dem Header übernommen. |
| SocketIp | Die IP-Adresse der direkten Verbindung mit dem Azure Front Door-Edge. Wenn der Client einen HTTP-Proxy oder einen Lastenausgleich zum Senden der Anforderung verwendet hat, ist der Wert von „SocketIp“ die IP-Adresse des Proxys oder Lastenausgleichs. |
| TimeTaken | Die Dauer in Sekunden ab dem Zeitpunkt, an dem die Anforderung des Clients am Azure Front Door-Edge empfangen wurde, bis zu dem Zeitpunkt, an dem das letzte Byte der Antwort an den Client gesendet wurde. Diese Metrik schließt Netzwerklatenzen und die TCP-Pufferung aus. Bei WebSocket-Verbindungen ist dies die Verbindungsdauer von der Einrichtung bis zum Trennen. |
| RequestProtocol | Das vom Client in der Anforderung angegebene Protokoll. Die möglichen Werte sind HTTP, HTTPS. Bei WebSocket werden die Protokolle WS und WSS verwendet. Nur Anforderungen, die erfolgreich auf WebSocket aktualisiert wurden, bieten WS/WSS. |
| SecurityProtocol | Die TLS-/SSL-Protokollversion, die von der Anforderung verwendet wird, oder NULL, wenn keine Verschlüsselung verwendet wird. Mögliche Werte: SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
| SecurityCipher | Wenn der Wert für das Anforderungsprotokoll HTTPS lautet, gibt dieses Feld das vom Client und Azure Front Door ausgehandelte TLS/SSL-Verschlüsselungsverfahren an. |
| Endpunkt | Der Domänenname des Azure Front Door-Endpunkts, z. B contoso-123.z01.azurefd.net. |
| HttpStatusCode | Der von Azure Front Door zurückgegebene HTTP-Statuscode. Wenn bei einer Anforderung an den Ursprung ein Timeout eintritt, lautet der Wert für den HttpStatusCode 0. Wenn der Client die Verbindung geschlossen hat, lautet der Wert für das HttpStatusCode-Feld 499. |
| POP | Der Azure Front Door Edge Point of Presence (PoP), der auf die Benutzeranforderung reagiert hat. |
| Cachestatus | Art der Verarbeitung der Anforderung durch den Azure Front Door-Cache. Mögliche Werte sind:
|
| MatchedRulesSetName | Die Namen der Regeln, die von der Regel-Engine verarbeitet wurden. |
| RouteName | Der Name der Route, der die Anforderung entspricht. |
| ClientPort | Der IP-Port des Clients, der die Anforderung gestellt hat. |
| Referrer | Die URL der Website, von der die Anforderung stammt. |
| TimetoFirstByte | Die in Azure Front Door gemessene Zeitspanne in Sekunden zwischen dem Zeitpunkt, zu dem Azure Front Door die Anforderung erhielt, und dem Zeitpunkt, zu dem das erste Byte an den Client gesendet wurde. Mit dieser Eigenschaft werden nicht die Clientdaten gemessen. |
| ErrorInfo | Wenn während der Verarbeitung der Anforderung ein Fehler aufgetreten ist, enthält dieses Feld detaillierte Informationen zum Fehler. Mögliche Werte sind:
|
| OriginURL | Die vollständige URL des Ursprungs, an den die Anforderung gesendet wurde. Die URL besteht aus dem Schema, dem Hostheader, dem Port, dem Pfad und der Abfragezeichenfolge. URL-Neuschreibung: Wenn die Anforderungs-URL von der Regel-Engine neu geschrieben wurde, verweist der Pfad auf den umgeschriebenen Pfad. Zwischenspeichern auf Edge-PoP: Wenn die Anforderung aus dem Azure Front Door-Cache bedient wurde, ist der Ursprung N/A. Large request (Umfangreiche Anforderung): Wenn der angeforderte Inhalt groß ist und mehrere segmentierte Anforderungen zurück an den Ursprung gesendet werden, entspricht dieses Feld der ersten Anforderung an den Ursprung. Weitere Informationen finden Sie unter Objektblockerstellung. |
| OriginIP | Die IP-Adresse des Ursprungs, der die Anforderung bedient hat. Zwischenspeichern auf Edge-PoP: Wenn die Anforderung aus dem Azure Front Door-Cache bedient wurde, ist der Ursprung N/A. Large request (Umfangreiche Anforderung): Wenn der angeforderte Inhalt groß ist und mehrere segmentierte Anforderungen zurück an den Ursprung gesendet werden, entspricht dieses Feld der ersten Anforderung an den Ursprung. Weitere Informationen finden Sie unter Objektblockerstellung. |
| OriginName | Der vollständige Hostname (DNS-Name) des Ursprungs. Zwischenspeichern auf Edge-PoP: Wenn die Anforderung aus dem Azure Front Door-Cache bedient wurde, ist der Ursprung N/A. Large request (Umfangreiche Anforderung): Wenn der angeforderte Inhalt groß ist und mehrere segmentierte Anforderungen zurück an den Ursprung gesendet werden, entspricht dieses Feld der ersten Anforderung an den Ursprung. Weitere Informationen finden Sie unter Objektblockerstellung. |
| Ergebnis | SSLMismatchedSNI ist ein Statuscode, der eine erfolgreiche Anfrage mit einer Warnung über eine Fehlanpassung zwischen der Servernamensanzeige (Server Name Indication, SNI) und dem Host-Header anzeigt. Dieser Statuscode impliziert Domain Fronting, eine Technik, die gegen die Nutzungsbedingungen von Azure Front Door verstößt. Anfragen mit SSLMismatchedSNI werden nach dem 22. Januar 2024 abgelehnt. |
| Sni | Dieses Feld gibt die Servernamenanzeige (Server Name Indication, SNI) an, die während des TLS/SSL-Handshakes gesendet wird. Sie kann verwendet werden, um den genauen SNI-Wert zu identifizieren, wenn ein SSLMismatchedSNI-Statuscode vorhanden ist. Darüber hinaus kann sie mit dem Hostwert im requestUri-Feld verglichen werden, um das Problem der Fehlanpassung zu erkennen und zu beheben. |
Integritätstestprotokoll
Azure Front Door protokolliert jede fehlerhafte Integritätstestanforderung. Diese Protokolle können Ihnen helfen, Probleme bei einem Ursprung zu diagnostizieren. Die Protokolle enthalten Informationen, die Sie verwenden können, um den Fehlergrund zu untersuchen und dann den Ursprung wieder in einen fehlerfreien Status zu bringen.
Szenarien, in denen dieses Protokoll hilfreich sein kann:
- Sie haben bemerkt, dass Azure Front Door-Datenverkehr an eine Teilmenge der Ursprünge gesendet wurde. Beispielsweise könnte Ihnen aufgefallen sein, dass nur drei von vier Ursprüngen Datenverkehr empfangen. Sie möchten wissen, ob die Ursprünge Integritätstests empfangen und darauf reagieren, damit Sie wissen, ob die Ursprünge fehlerfrei sind.
- Sie haben festgestellt, dass die Prozentsatzmetrik der Ursprungsintegrität niedriger ist als erwartet. Sie möchten wissen, welche Ursprünge als fehlerhaft aufgezeichnet werden und warum die Integritätstestfehler auftreten.
Jedes Integritätstestprotokoll weist das folgende Schema auf:
| Eigenschaft | BESCHREIBUNG |
|---|---|
| HealthProbeId | Eine eindeutige ID zum Identifizieren der Integritätstestanforderung. |
| Time | Das Datum und die Uhrzeit, zu denen der Integritätstest gesendet wurde (in UTC). |
| HttpMethod | Die von der Integritätstestanforderung verwendete HTTP-Methode. Zu den Werten zählen GET und HEAD, abhängig von der Integritätstestkonfiguration. |
| Ergebnis | Der Status des Integritätstests. Der Wert ist entweder success oder eine Beschreibung des Fehlers, den der Test empfangen hat. |
| HttpStatusCode | Der HTTP-Statuscode, der vom Ursprung zurückgegeben wurde. |
| ProbeURL | Die vollständige Ziel-URL, an die die Testanforderung gesendet wurde. Die URL besteht aus dem Schema, dem Hostheader, dem Pfad und der Abfragezeichenfolge. |
| OriginName | Der Name des Ursprungs, an den der Integritätstest gesendet wurde. Dieses Feld unterstützt Sie bei der Suche nach Ursprüngen, wenn für den Ursprung die Verwendung eines FDQN konfiguriert ist. |
| POP | Der Edge-PoP, der die Testanforderung gesendet hat. |
| Ursprungs-IP-Adresse | Die IP-Adresse des Ursprungs, an den der Integritätstest gesendet wurde. |
| TotalLatency | Die Zeitspanne ab dem Zeitpunkt, als der Azure Front Door-Edge die Integritätstestanforderung an den Ursprung gesendet hat, bis zum Zeitpunkt, zu dem der Ursprung die letzte Antwort an Azure Front Door gesendet hat. |
| ConnectionLatency | Die für das Einrichten der TCP-Verbindung zum Senden der HTTP-Testanforderung an den Ursprung vergangene Zeitspanne. |
| DNSResolutionLatency | Die für die DNS-Auflösung aufgewendete Zeit. Dieses Feld weist nur einen Wert auf, wenn der Ursprung als FDQN anstelle einer IP-Adresse konfiguriert ist. Wenn der Ursprung für die Verwendung einer IP-Adresse konfiguriert ist, lautet der Wert N/V. |
Der folgende JSON-Beispielschnipsel zeigt einen Integritätstest-Protokolleintrag für eine fehlerhafte Integritätstestanforderung.
{
"records": [
{
"time": "2021-02-02T07:15:37.3640748Z",
"resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/MyProfile",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://www.example.com:80/",
"originName": "www.example.com",
"originIP": "PublicI:Port",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}
Web Application Firewall-Protokoll
Weitere Informationen zu den Web Application Firewall-Protokollen (WAF) von Front Door finden Sie unter Überwachung und Protokollierung von Azure Web Application Firewall.
Aktivitätsprotokolle
Aktivitätsprotokolle bieten Informationen zu den Verwaltungsvorgängen für Ihre Azure Front Door-Ressourcen. Die Protokolle enthalten Details zu jedem Schreibvorgang, der für eine Azure Front Door-Ressource ausgeführt wurde, einschließlich des Zeitpunkts des Vorgangs, der ausführenden Person und des Vorgangs.
Hinweis
Aktivitätsprotokolle beinhalten keine Lesevorgänge. Sie enthalten möglicherweise auch nicht alle Vorgänge, die Sie entweder über das Azure-Portal oder die klassischen Verwaltungs-API ausführen.
Weitere Informationen finden Sie unter Anzeigen Ihrer Aktivitätsprotokolle.
Nächste Schritte
Informationen zum Aktivieren und Speichern Ihrer Diagnoseprotokolle finden Sie unter Konfigurieren von Azure Front Door-Protokollen.
Wichtig
Azure Front Door (klassisch) wird am 31. März 2027 eingestellt. Um Dienstunterbrechungen zu vermeiden, ist es wichtig, dass Sie Ihre (klassischen) Azure Front Door-Profile bis März 2027 zur Azure Front Door Standard- oder Premium-Stufe migrieren. Weitere Informationen finden Sie unter Einstellung von Azure Front Door (klassisch).
Mit Azure Front Door (klassisch) können Sie Ressourcen auf die folgenden Arten überwachen:
- Metriken: Azure Front Door verfügt derzeit über acht Metriken, um Leistungsindikatoren anzuzeigen.
- Protokolle. Protokolle ermöglichen das Speichern und Nutzen von Leistungs-, Zugriffs- und anderen Daten einer Ressource zu Überwachungszwecken.
Metriken
Metriken sind ein Feature für bestimmte Azure-Ressourcen, mit dem Sie die Leistungsindikatoren im Portal anzeigen können. Die folgenden Front Door-Metriken stehen zur Verfügung:
| Metrik | Metrikanzeigename | Einheit | Dimensionen | BESCHREIBUNG |
|---|---|---|---|---|
| RequestCount | Anzahl der Anforderungen | Anzahl | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Die Anzahl der von Front Door Service bereitgestellten Clientanforderungen. |
| RequestSize | Anforderungsgröße | Byte | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Die Anzahl der von Clients als Anforderungen an Front Door Service gesendeten Bytes. |
| ResponseSize | Antwortgröße | Byte | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Die Anzahl der von Front Door Service als Antworten an Clients gesendeten Bytes. |
| TotalLatency | Gesamtlatenz | Millisekunden | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Die Gesamtzeit zwischen dem Empfang der Clientanforderung in Front Door und dem letzten von AFD an den Client gesendeten Antwortbyte. |
| BackendRequestCount | Back-End-Anforderungsanzahl | Anzahl | HttpStatus HttpStatusGroup Backend |
Die Anzahl der von Front Door Service an Back-Ends gesendeten Anforderungen. |
| BackendRequestLatency | Latenz der Back-End-Anforderung | Millisekunden | Back-End | Die Zeitspanne zwischen dem Senden der Anforderung durch Front Door Service an das Back-End und dem Empfang des letzten Antwortbytes durch Front Door Service vom Back-End. |
| BackendHealthPercentage | Prozentsatz der Back-End-Integrität | Percent | Backend BackendPool |
Der Prozentsatz der erfolgreichen Integritätstests von Front Door Service zu Back-Ends. |
| WebApplicationFirewallRequestCount | Anforderungsanzahl für die Web Application Firewall | Anzahl | PolicyName RuleName Action |
Die Anzahl der Clientanforderungen, die von der Anwendungssicherheitsschicht von Front Door Service verarbeitet werden. |
Aktivitätsprotokolle
Aktivitätsprotokolle bieten Informationen zu den in einem Profil von Azure Front Door (klassisch) durchgeführten Vorgängen. Damit können Sie auch die Antworten auf die Fragen „Was“, „Wer“ und „Wann“ für alle Schreibvorgänge (put, post oder delete) in Ihrem Profil von Azure Front Door (klassisch) ermitteln.
Hinweis
Wenn bei einer Anforderung an den Ursprung ein Timeout eintritt, wird der Wert für den HttpStatusCode auf 0 festgelegt.
Greifen Sie auf Aktivitätsprotokolle in Ihrer Front Door-Instanz oder alle Protokolle Ihrer Azure-Ressourcen in Azure Monitor zu. So zeigen Sie Aktivitätsprotokolle an:
Wählen Sie Ihre Front Door-Instanz aus.
Wählen Sie Aktivitätsprotokoll aus.
Wählen Sie einen Filterbereich und dann Übernehmen aus.
Hinweis
Das Aktivitätsprotokoll enthält keine Get-Vorgänge oder Vorgänge, die Sie ausführen, indem Sie das Azure-Portal oder die ursprüngliche Management-API verwenden.
Diagnoseprotokolle
Diagnoseprotokolle bieten umfassende Informationen zu Vorgängen und Fehlern, die zur Überwachung und Problembehandlung relevant sind. Diagnoseprotokolle unterscheiden sich von Aktivitätsprotokollen.
Aktivitätsprotokolle geben Einblick in die Vorgänge, die für Azure-Ressourcen ausgeführt wurden. Diagnoseprotokolle bieten Einblicke in Vorgänge, die Ihre Ressource ausgeführt hat. Weitere Informationen finden Sie unter Erfassen und Nutzen von Protokolldaten aus Ihren Azure-Ressourcen.
So konfigurieren Sie Diagnoseprotokolle für Ihre Instanz von Azure Front Door (klassisch):
Wählen Sie Ihr Profil für Azure Front Door (klassisch) aus.
Wählen Sie Azure-Diagnoseeinstellungen aus.
Wählen Sie Diagnose aktivieren. Archivieren Sie Diagnoseprotokolle zusammen mit Metriken in einem Speicherkonto, streamen Sie sie an einen Event Hub, oder senden Sie sie an Azure Monitor-Protokolle.
Front Door stellt derzeit Diagnoseprotokolle bereit. Diagnoseprotokolle enthalten einzelne API-Anforderungen, wobei jeder Eintrag folgendem Schema entspricht:
| Eigenschaft | BESCHREIBUNG |
|---|---|
| BackendHostname | Wenn die Anforderung an ein Back-End weitergeleitet wurde, stellt dieses Feld den Hostnamen des Back-Ends dar. Dieses Feld ist leer, wenn die Anforderung umgeleitet oder an einen regionalen Cache weitergeleitet wird (sofern Zwischenspeicherung für die Routingregel aktiviert wurde). |
| CacheStatus | Bei Zwischenspeicherungsszenarien definiert dieses Feld den Cachetreffer/Cachefehler im POP. |
| ClientIp | Die IP-Adresse des Clients, der die Anforderung gestellt hat. Wenn in der Anforderung ein X-Forwarded-For-Header vorhanden ist, wird die Client-IP daraus ausgewählt. |
| ClientPort | Der IP-Port des Clients, der die Anforderung gestellt hat. |
| HttpMethod | Von der Anforderung verwendete HTTP-Methode |
| HttpStatusCode | Der HTTP-Statuscode, der vom Proxy zurückgegeben wurde. Wenn bei einer Anforderung an den Ursprung ein Timeout eintritt, wird der Wert für den HttpStatusCode auf 0 festgelegt. |
| HttpStatusDetails | Resultierender Status in der Anforderung. Informationen zur Bedeutung dieses Zeichenfolgenwerts finden Sie in der Verweistabelle zum Status. |
| HttpVersion | Typ der Anforderung oder Verbindung. |
| POP | Kurzname des Edges, in dem die Anforderung gelandet ist. |
| RequestBytes | Die Größe der HTTP-Anforderungsnachricht in Byte, einschließlich Anforderungsheader und -text. |
| RequestUri | URI der empfangenen Anforderung |
| ResponseBytes | Die vom Back-End-Server als Antwort gesendeten Bytes. |
| RoutingRuleName | Der Name der Routingregel, der die Anforderung entspricht. |
| RulesEngineMatchNames | Die Namen der Regeln, mit denen die Anforderung übereinstimmte. |
| SecurityProtocol | Die TLS-/SSL-Protokollversion, die von der Anforderung verwendet wird, oder NULL, wenn keine Verschlüsselung verwendet wird. |
| SentToOriginShield (veraltet) * Hinweise dazu finden Sie im folgenden Abschnitt. |
Wenn der Wert TRUE ist, wurde die Anforderung vom Origin Shield-Cache anstelle des Edge-POP beantwortet. Origin Shield ist ein übergeordneter Cache zum Verbessern der Cachetrefferquote. |
| isReceivedFromClient | Wenn dies „true“ ergibt, stammte die Anforderung vom Client. Wenn dies „false“ ergibt, ist die Anforderung ein Fehler in der Edge (untergeordneter POP) und wird von Origin Shield (übergeordneter POP) beantwortet. |
| TimeTaken | Die Dauer vom ersten Byte der Anforderung an Front Door bis zum letzten Byte der Antwort in Sekunden. |
| TrackingReference | Die eindeutige Verweiszeichenfolge zur Identifizierung einer Anforderung, die von der Front Door-Instanz verarbeitet wird. Diese wird auch als X-Azure-Ref-Header an den Client gesendet. Sie ist für die Suche nach Informationen in den Zugriffsprotokollen für eine bestimmte Anforderung erforderlich. |
| UserAgent | Der vom Client verwendete Browsertyp |
| ErrorInfo | Dieses Feld enthält den spezifischen Fehlertyp zur weiteren Problembehandlung. Mögliche Werte sind: NoError: gibt an, dass kein Fehler gefunden wurde. CertificateError: generischer SSL-Zertifikatfehler CertificateNameCheckFailed: Der Hostname im SSL-Zertifikat ist ungültig oder stimmt nicht überein. ClientDisconnected: Anforderungsfehler aufgrund der Clientnetzwerkverbindung. UnspecifiedClientError: Generischer Clientfehler. InvalidRequest: Ungültige Anforderung. Dies kann aufgrund einer falschen Formatierung von Header, Text und URL auftreten. DNSFailure: DNS-Fehler. DNSNameNotResolved: Der Servername oder die Adresse konnte nicht aufgelöst werden. OriginConnectionAborted: Die Verbindung mit dem Ursprung wurde nicht ordnungsgemäß getrennt. OriginConnectionError: Generischer Fehler der Ursprungsverbindung. OriginConnectionRefused: Die Verbindung mit dem Ursprung konnte nicht hergestellt werden. OriginError: Generischer Ursprungsfehler. OriginInvalidResponse: Der Ursprung hat eine ungültige oder unbekannte Antwort zurückgegeben. OriginTimeout: Das Zeitlimit für die Ursprungsanforderung ist abgelaufen. ResponseHeaderTooBig: Der Ursprung hat einen zu großen Antwortheader zurückgegeben. RestrictedIP: Die Anforderung wurde aufgrund einer eingeschränkten IP-Adresse blockiert. SSLHandshakeError: Aufgrund eines Fehlers beim SSL-Handshake kann keine Verbindung mit dem Ursprung hergestellt werden. UnspecifiedError: Es ist ein Fehler aufgetreten, der keinem Fehler in der Tabelle entspricht. SSLMismatchedSNI: Die Anforderung war ungültig, da der HTTP-Nachrichtenheader nicht mit dem Wert in der TLS-SNI-Erweiterung während der SSL/TLS-Verbindungseinrichtung übereinstimmte. |
| Ergebnis | SSLMismatchedSNI ist ein Statuscode, der eine erfolgreiche Anfrage mit einer Warnung über eine Fehlanpassung zwischen der Servernamensanzeige (Server Name Indication, SNI) und dem Host-Header anzeigt. Dieser Statuscode impliziert Domain Fronting, eine Technik, die gegen die Nutzungsbedingungen von Azure Front Door verstößt. Anfragen mit SSLMismatchedSNI werden nach dem 22. Januar 2024 abgelehnt. |
| Sni | Dieses Feld gibt die Servernamenanzeige (Server Name Indication, SNI) an, die während des TLS/SSL-Handshakes gesendet wird. Sie kann verwendet werden, um den genauen SNI-Wert zu identifizieren, wenn ein SSLMismatchedSNI-Statuscode vorhanden ist. Darüber hinaus kann sie mit dem Hostwert im requestUri-Feld verglichen werden, um das Problem der Fehlanpassung zu erkennen und zu beheben. |
An eingestellte Unterstützung von Origin Shield gesendet
Die unformatierte Protokolleigenschaft isSentToOriginShield ist eingestellt und durch ein neues Feld, isReceivedFromClient, ersetzt. Verwenden Sie das neue Feld, wenn Sie bereits das veraltete Feld verwenden.
Unformatierte Protokolle umfassen Protokolle, die sowohl über CDN Edge (untergeordneter POP) als auch Origin Shield generiert wurden. Origin Shield bezieht sich auf übergeordnete Knoten, die strategisch über den Globus verteilt sind. Diese Knoten kommunizieren mit den Ursprungsservern und reduzieren den Datenverkehr am Ursprung.
Für jede an einen Origin Shield gesendete Anforderung gibt es zwei Protokolleinträge:
- Einen für Edgeknoten.
- Einen für Origin Shield.
Um die ausgehenden Daten oder Antworten von den Edgeknoten von denen von Origin Shield zu unterscheiden, können Sie das Feld isReceivedFromClient verwenden, um die richtigen Daten zu erhalten.
Wenn der Wert „false“ ergibt, bedeutet dies, dass die Anforderung von Origin Shield bis zu den Edgeknoten beantwortet wird. Dieser Ansatz ist effektiv, um unformatierte Protokolle mit Abrechnungsdaten zu vergleichen. Für die ausgehenden Daten von Origin Shield zu den Edgeknoten fallen keine Gebühren an. Es fallen Gebühren für ausgehende Daten von den Edgeknoten zu Clients an.
Beispiel für eine Kusto-Abfrage zum Ausschließen von Protokollen, die von Origin Shield in Log Analytics generiert werden.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Hinweis
Für verschiedene Routingkonfigurationen und Datenverkehrsverhalten können einige der Felder wie „backendHostname“, „cacheStatus“, „isReceivedFromClient“ und „POP“ mit unterschiedlichen Werten antworten. In der folgenden Tabelle werden die unterschiedlichen Werte erläutert, die diese Felder in verschiedenen Szenarien annehmen können:
| Szenarien | Anzahl der Protokolleinträge | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Routingregel ohne aktiviertes Zwischenspeichern | 1 | Edge-POP-Code | Das Back-End, an das die Anforderung weitergeleitet wurde | Richtig | CONFIG_NOCACHE |
| Routingregel mit aktiviertem Zwischenspeichern. Cachetreffer beim Edge-POP | 1 | Edge-POP-Code | Leer | Richtig | HIT |
| Routingregel mit aktiviertem Zwischenspeichern. Cachefehler bei Edge-POP, aber Cachetreffer beim übergeordneten Cache-POP | 2 | 1. Edge-POP-Code 2. POP-Code des übergeordneten Caches |
1. POP-Hostname des übergeordneten Caches 2. Leer |
1. True 2. Falsch |
1. MISS 2. HIT |
| Routingregel mit aktiviertem Zwischenspeichern. Cachefehler bei Edge-POP, aber teilweiser Cachetreffer beim übergeordneten Cache-POP | 2 | 1. Edge-POP-Code 2. POP-Code des übergeordneten Caches |
1. POP-Hostname des übergeordneten Caches 2. Back-End zum Auffüllen des Caches |
1. True 2. Falsch |
1. MISS 2. PARTIAL_HIT |
| Routingregel mit aktiviertem Zwischenspeichern. PARTIAL_HIT des Caches bei POP, aber Cachetreffer beim übergeordneten Cache-POP | 2 | 1. Edge-POP-Code 2. POP-Code des übergeordneten Caches |
1. Edge-POP-Code 2. POP-Code des übergeordneten Caches |
1. True 2. Falsch |
1. PARTIAL_HIT 2. HIT |
| Routingregel mit aktiviertem Zwischenspeichern. Cachefehler sowohl beim Edge als auch beim Parent Cache POP | 2 | 1. Edge-POP-Code 2. POP-Code des übergeordneten Caches |
1. Edge-POP-Code 2. POP-Code des übergeordneten Caches |
1. True 2. Falsch |
1. MISS 2. MISS |
| Fehler bei der Verarbeitung der Anforderung | – |
Hinweis
Für Zwischenspeicherungsszenarien ist der Wert für „Cachestatus“ partial_hit, wenn einige Bytes für eine Anforderung aus dem Azure Front Door-Edge- oder Origin Shield-Cache stammen, während einige Bytes aus dem Ursprung für große Objekte stammen.
Bei Azure Front Door kommt eine Technik namens Objektblockerstellung zum Einsatz. Wenn eine große Datei angefordert wird, ruft Azure Front Door kleinere Teile der Datei vom Ursprung ab. Nachdem der Azure Front Door-POP-Server die angeforderte Datei vollständig oder auf einen Bytebereich beschränkt empfangen hat, fordert der Azure Front Door-Edgeserver die Datei beim Ursprung in Blöcken zu jeweils 8 MB an.
Nachdem der Block im Azure Front Door-Edgebereich eingegangen ist, wird er zwischengespeichert und sofort für den Benutzer bereitgestellt. Azure Front Door ruft den nächsten Block dann parallel dazu ab. Durch diesen Vorababruf wird sichergestellt, dass der Inhalt dem Benutzer immer einen Block voraus ist, sodass sich die Wartezeit reduziert. Dieser Prozess wird fortgesetzt, bis die gesamte Datei heruntergeladen wurde (falls angefordert), alle Bytebereiche verfügbar sind (falls angefordert) oder der Client die Verbindung schließt. Weitere Informationen zur Bytebereichsanforderung finden Sie unter RFC 7233. Azure Front Door speichert alle Blöcke zwischen, sobald sie eingetroffen sind. Es ist nicht erforderlich, die gesamte Datei im Front Door-Cache zwischenzuspeichern. Nachfolgende Anforderungen für die Datei oder Bytebereiche werden über den Azure Front Door-Cache verarbeitet. Wenn nicht alle Blöcke in Azure Front Door zwischengespeichert werden, wird ein Vorababruf verwendet, um Blöcke vom Ursprung anzufordern. Diese Optimierung beruht auf der Fähigkeit des Ursprungsservers, Bytebereichsanforderungen zu unterstützen. Wenn der Ursprungsserver keine Anforderungen für Bytebereiche unterstützt, ist diese Optimierung nicht effektiv.
Nächste Schritte
- Erfahren Sie, wie Sie ein Profil für Azure Front Door (klassisch) erstellen.
- Erfahren Sie, wie Azure Front Door (klassisch) funktioniert.