Überwachen der Azure Front Door
Azure Monitor sammelt und aggregiert Metriken und Protokolle von Ihrem System, um die Verfügbarkeit, Leistung und Ausfallsicherheit zu überwachen und Sie über Probleme zu informieren, die Ihr System betreffen. Sie können das Azure-Portal, PowerShell, die Azure CLI, die REST-API oder Clientbibliotheken verwenden, um Überwachungsdaten einzurichten und anzuzeigen.
Für unterschiedliche Ressourcentypen stehen unterschiedliche Metriken und Protokolle zur Verfügung. In diesem Artikel werden die Arten von Überwachungsdaten beschrieben, die Sie für diesen Dienst sammeln können, sowie die Möglichkeiten, diese Daten zu analysieren.
Berichte bieten Erkenntnisse zum Fluss Ihres Datenverkehrs über Azure Front Door und die Web Application Firewall (WAF) bis zu Ihrer Anwendung.
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).
Sammeln von Daten mit Azure Monitor
In dieser Tabelle wird beschrieben, wie Sie Daten sammeln können, um Ihren Dienst zu überwachen, und was Sie mit den gesammelten Daten tun können:
| Zu erfassende Daten | Beschreibung | Sammeln und Weiterleiten der Daten | Orte zum Anzeigen der Daten | Unterstützte Daten |
|---|---|---|---|---|
| Metrikdaten | Metriken sind numerische Werte, die einen Aspekt eines Systems zu einem bestimmten Zeitpunkt beschreiben. Metriken können mithilfe von Algorithmen aggregiert, mit anderen Metriken verglichen und auf Trends im Laufe der Zeit analysiert werden. | – Automatisch in regelmäßigen Abständen gesammelt. – Sie können einige Plattformmetriken an einen Log Analytics-Arbeitsbereich weiterleiten, um andere Daten abzufragen. Überprüfen Sie die DS-Exporteinstellung für jede Metrik, um festzustellen, ob Sie eine Diagnoseeinstellung verwenden können, um die Metrikdaten weiterzuleiten. |
Metrik-Explorer | Von Azure Monitor unterstützte Azure Front Door-Metriken |
| Ressourcenprotokolldaten | Protokolle sind aufgezeichnete Systemereignisse mit einem Zeitstempel. Protokolle können verschiedene Arten von Daten enthalten, und in strukturierter Form oder als Freitext vorliegen. Sie können Ressourcenprotokolldaten zur Abfrage und Analyse an Log Analytics-Arbeitsbereiche weiterleiten. | Erstellen Sie eine Diagnoseeinstellung zum Sammeln und Weiterleiten von Ressourcenprotokollen. | Log Analytics | Von Azure Monitor unterstützte Azure Front Door-Ressourcenprotokolldaten |
| Aktivitätsprotokolldaten | Das Azure Monitor-Aktivitätsprotokoll bietet Erkenntnisse zu Ereignissen auf Abonnementebene. Es enthält Informationen wie den Zeitpunkt, zu dem eine Ressource geändert oder ein virtueller Computer gestartet wurde. | – Automatisch gesammelt. - Erstellen Sie kostenlos eine Diagnoseeinstellung für einen Log Analytics-Arbeitsbereich. |
Aktivitätsprotokoll |
Eine Liste aller von Azure Monitor unterstützten Daten finden Sie unter:
Integrierte Überwachung für Azure Front Door
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 dieser Wert 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 dieser Wert die Gesamtanzahl der Bytes, die vom Server über die Verbindung an den Client gesendet wurden. |
| 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-Rewrite: Wenn das Regelmodul die Anforderungs-URL umschreibt, 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 auffallen, 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 FQDN 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 FQDN 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.
Bei der klassischen Azure Front Door-Version umfasst die integrierte Überwachung Diagnoseprotokolle.
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 ausführt. 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-Zertifikatsfehler. 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: Der Timeoutzeitraum 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-Nachrichtenkopf 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 Datenverkehrsverhaltensweisen 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:
| 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.
Verwenden von Azure Monitor-Tools zum Analysieren der Daten
Diese Azure Monitor-Tools stehen im Azure-Portal zur Verfügung, um Überwachungsdaten zu analysieren:
Einige Azure-Dienste verfügen über ein integriertes Überwachungsdashboard im Azure-Portal. Diese Dashboards werden als Erkenntnisse bezeichnet, und Sie finden sie im Bereich Insights von Azure Monitor im Azure-Portal.
Mit dem Metriken-Explorer können Sie Metriken für Azure-Ressourcen anzeigen und analysieren. Weitere Informationen finden Sie unter Analysieren von Metriken mit dem Azure Monitor-Metrik-Explorer.
Mit Log Analytics können Sie Protokolldaten mithilfe der Kusto-Abfragesprache (KQL) abfragen und analysieren. Weitere Informationen finden Sie unter Erste Schritte mit Protokollabfragen in Azure Monitor.
Das Azure-Portal hat eine Benutzeroberfläche, mit der Sie das Aktivitätsprotokoll anzeigen und darin suchen können. Um ausführlichere Analysen durchzuführen, leiten Sie die Daten an Azure Monitor-Protokolle weiter und führen Sie komplexere Abfragen in Log Analytics aus.
Application Insights überwacht die Verfügbarkeit, Leistung und Nutzung Ihrer Webanwendungen, sodass Sie Fehler identifizieren und diagnostizieren können, ohne darauf zu warten, dass ein Benutzer sie meldet.
Application Insights beinhaltet Verbindungspunkte zu verschiedenen Entwicklungstools und lässt sich zur Unterstützung Ihrer DevOps-Prozesse in Visual Studio integrieren. Weitere Informationen finden Sie unter Anwendungsüberwachung für App Service.
Zu den Tools, die eine komplexere Visualisierung ermöglichen, gehören:
- Dashboards, mit denen Sie verschiedene Typen von Daten in einen einzelnen Bereich im Azure-Portal kombinieren können.
- Arbeitsmappen, anpassbare Berichte, die Sie im Azure-Portal erstellen können. Arbeitsmappen können Text, Metriken und Protokollabfragen enthalten.
- Grafana, ein Tool auf einer offenen Plattform, das für operationale Dashboards ideal ist. Sie können Grafana verwenden, um Dashboards zu erstellen, die Daten aus mehreren anderen Quellen als Azure Monitor enthalten.
- Power BI ist ein Geschäftsanalysedienst, der interaktive Visualisierungen für verschiedene Datenquellen bereitstellt. Sie können Power BI für den automatischen Import von Protokolldaten aus Azure Monitor konfigurieren, um diese Visualisierungen zu nutzen.
Exportieren von Azure Monitor-Daten
Sie können Daten aus Azure Monitor in andere Tools exportieren:
Metriken: Verwenden Sie die REST-API für Metriken, um Metrikdaten aus der Azure Monitor-Metrikendatenbank zu extrahieren. Weitere Informationen finden Sie in der Referenz zur Azure Monitor-REST-API.
Protokolle: Verwenden Sie die REST-API oder die zugeordneten Clientbibliotheken.
Informationen zu den ersten Schritten mit der Azure Monitor REST-API finden Sie unter Exemplarische Vorgehensweise für die Azure Monitor-REST-API.
Verwenden von Kusto-Abfragen zum Analysieren von Protokolldaten
Sie können Azure Monitor Protokolldaten mit der Kusto-Abfragesprache (KQL) analysieren. Weitere Informationen finden Sie unter Protokollabfragen in Azure Monitor.
Verwenden von Azure Monitor-Warnungen, um Sie über Probleme zu benachrichtigen
Azure Monitor-Warnungen ermöglichen es Ihnen, Probleme in Ihrem System zu identifizieren und zu beheben. Außerdem werden Sie proaktiv benachrichtigt, wenn bestimmte Bedingungen in Ihren Überwachungsdaten gefunden werden, bevor Ihre Kunden sie bemerken. Sie können zu jeder Metrik oder Protokolldatenquelle der Azure Monitor-Datenplattform Warnungen erhalten. Es gibt verschiedene Typen von Azure Monitor-Warnungen, abhängig von den Diensten, die Sie überwachen, und den Überwachungsdaten, die Sie sammeln. Weitere Informationen finden Sie unter Auswählen des richtigen Warnungsregeltyps.
Beispiele für häufige Warnungen für Azure-Ressourcen finden Sie in den Beispielabfragen für Protokollwarnungen.
Implementieren von Warnungen im großen Maßstab
Einige Dienste können Sie im großen Stil überwachen, indem Sie dieselbe Metrikwarnungsregel auf mehrere Ressourcen desselben Typs anwenden, die sich in derselben Azure-Region befinden. Azure Monitor-Baselinewarnungen (AMBA) stellen eine halbautomatisierte Methode für die Implementierung wichtiger Metrikwarnungen der Plattform, Dashboards und Richtlinien im großen Stil bereit.
Erhalten von personalisierten Empfehlungen mit Azure Advisor
Wenn in einigen Diensten während eines Ressourcenvorgangs kritische Bedingungen oder unmittelbar bevorstehende Änderungen auftreten, wird auf der Dienstseite Übersicht im Portal eine Warnung angezeigt. Weitere Informationen und empfohlene Korrekturen für die Warnung finden Sie in Advisor-Empfehlungen unter Überwachung im linken Menü. Während des normalen Betriebs werden keine Advisor-Empfehlungen angezeigt.
Weitere Informationen zu Azure Advisor finden Sie unter Azure Advisor – Übersicht.