Überwachen von Metriken und Protokollen in Azure Front Door

  • Artikel

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
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:
  • Sie deaktivieren das Zwischenspeichern explizit, entweder über die Regel-Engine oder das Verhalten beim Zwischenspeichern von Abfragezeichenfolgen.
  • Sie konfigurieren explizit eine Cache-Control-Anweisung mit der Cacheanweisung no-store oder private.
 Endpunkt
Prozentsatz der Ursprungsintegrität Der Prozentsatz der erfolgreichen Integritätstests, die von Azure Front Door an die Ursprünge gesendet werden. Ursprung, Ursprungsgruppe
Ursprüngliche Wartezeit Azure Front Door berechnet die Zeit vom Senden der Anforderung an den Ursprung bis zum Empfang des letzten Antwortbytes vom Ursprung. Endpunkt, Ursprung
Anzahl der Ursprungsanforderungen Die Anzahl der von Azure Front Door an die Ursprünge gesendeten Anforderungen. Endpunkt, Ursprung, HTTP-Status, HTTP-Statusgruppe
Prozentsatz von 4xx Der Prozentsatz aller Clientanforderungen, deren Antwortstatuscode 4XX lautet Endpunkt, Land des Clients, Region des Clients
Prozentsatz von 5xx Der Prozentsatz aller Clientanforderungen, deren Antwortstatuscode 5XX lautet Endpunkt, Land des Clients, Region des Clients
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
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
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
Gesamtlatenz Azure Front Door empfängt die Clientanforderung und sendet das letzte Antwortbyte an den Client. Dies ist die gesamt benötigte Zeit. Endpunkt, Land des Clients, Region des Clients, HTTP-Status, HTTP-Statusgruppe
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

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).
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.
ResponseBytes Größe der HTTP-Antwortnachricht in Byte.
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 Zeitspanne in Sekunden von dem Zeitpunkt, an dem der Azure Front Door-Edge die Anforderung des Clients empfangen hat, bis zu dem Zeitpunkt, zu dem Azure Front Door das letzte Byte der Antwort an den Client gesendet hat. In diesem Feld werden Netzwerklatenz und TCP-Pufferung nicht berücksichtigt.
RequestProtocol Das Protokoll, das der Client in der Anforderung angegeben hat. Die möglichen Werte sind HTTP, HTTPS.
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:
  • HIT und REMOTE_HIT: Die HTTP-Anforderung wurde vom Azure Front Door-Cache bedient.
  • MISS: Die HTTP-Anforderung wurde vom Ursprung bereitgestellt.
  • PARTIAL_HIT: Einige der Bytes wurden aus dem Front Door-Cache bedient, während andere Bytes vom Ursprung bereitgestellt wurden. Dieser Status zeigt ein Szenario der Objektblockerstellung an.
  • CACHE_NOCONFIG: Die Anforderung wurde ohne Einstellungen für das Zwischenspeichern (einschließlich Umgehung) weitergeleitet.
  • PRIVATE_NOSTORE: In den Zwischenspeicherungseinstellungen des Kunden wurde kein Cache konfiguriert.
  • N/V: Die Anforderung wurde von einer signierten URL oder der Regel-Engine abgelehnt.
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:
  • NoError: Gibt an, dass kein Fehler gefunden wurde.
  • CertificateError: Generischer SSL-Zertifikatsfehler.
  • CertificateNameCheckFailed: Der Hostname im SSL-Zertifikat ist ungültig oder stimmt nicht mit der angeforderten URL überein.
  • ClientDisconnected: Fehler bei der Anforderung aufgrund eines Clientnetzwerk-Verbindungsproblems.
  • ClientGeoBlocked: Der Client wurde aufgrund des geografischen Standorts der IP-Adresse blockiert.
  • UnspecifiedClientError: Generischer Clientfehler.
  • InvalidRequest: Ungültige Anforderung. Diese Antwort weist auf einen fehlerhaften Header, Textkörper oder eine falsch formatierte URL hin.
  • DNSFailure: Während der DNS-Auflösung ist ein Fehler aufgetreten.
  • DNSTimeout: Timeout bei der DNS-Abfrage zum Auflösen der Ursprungs-IP-Adresse.
  • 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 wurde nicht hergestellt.
  • OriginError: Generischer Ursprungsfehler.
  • ResponseHeaderTooBig: Der Ursprung hat einen zu großen Antwortheader zurückgegeben.
  • 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: Azure Front Door konnte aufgrund eines SSL-Handshakefehlers keine Verbindung mit dem Ursprung herstellen.
  • SSLInvalidRootCA: Das Zertifikat der Stammzertifizierungsstelle war ungültig.
  • SSLInvalidCipher: Die HTTPS-Verbindung wurde mithilfe einer ungültigen Verschlüsselung hergestellt.
  • OriginConnectionAborted: Die Verbindung mit dem Ursprung wurde nicht ordnungsgemäß getrennt.
  • OriginConnectionRefused: Die Verbindung mit dem Ursprung wurde nicht hergestellt.
  • UnspecifiedError: Es ist ein Fehler aufgetreten, der keinem Fehler in der Tabelle entspricht.
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/27CAFCA8-B9A4-4264-B399-45D0C9CCA1AB/RESOURCEGROUPS/AFDXPRIVATEPREVIEW/PROVIDERS/MICROSOFT.CDN/PROFILES/AFDXPRIVATEPREVIEW-JESSIE",
      "category": "FrontDoorHealthProbeLog",
      "operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
      "properties": {
        "healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
        "POP": "MAA",
        "httpVerb": "HEAD",
        "result": "OriginError",
        "httpStatusCode": "400",
        "probeURL": "http://afdxprivatepreview.blob.core.windows.net:80/",
        "originName": "afdxprivatepreview.blob.core.windows.net",
        "originIP": "52.239.224.228:80",
        "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 Dienstebene Azure Front Door Standard oder Premium 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:

  1. Wählen Sie Ihre Front Door-Instanz aus.

  2. Wählen Sie Aktivitätsprotokoll aus.

    Aktivitätsprotokoll

  3. 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.

Diagnoseprotokolle

So konfigurieren Sie Diagnoseprotokolle für Ihre Instanz von Azure Front Door (klassisch):

  1. Wählen Sie Ihr Profil für Azure Front Door (klassisch) aus.

  2. Wählen Sie Azure-Diagnoseeinstellungen aus.

  3. 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.
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 übereinstimmt, der in der TLS-SNI-Erweiterung während der SSL/TLS-Verbindungseinrichtung angezeigt wurde.
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