Metrische gegevens en logboeken in Azure Front Door bijhouden
Azure Front Door biedt verschillende functies waarmee u uw toepassing kunt bewaken, aanvragen kunt bijhouden en fouten in uw Front Door-configuratie kunt opsporen.
Logboeken en metrische gegevens worden opgeslagen en beheerd door Azure Monitor.
Rapporten bieden inzicht in hoe uw verkeer stroomt via Azure Front Door, de Web Application Firewall (WAF) en uw toepassing.
Metrische gegevens
Azure Front Door meet en verzendt de metrische gegevens in intervallen van 60 seconden. Het kan tot 3 minuten duren voordat de metrische gegevens worden verwerkt door Azure Monitor. Ze worden mogelijk pas weergegeven als de verwerking is voltooid. Metrische gegevens kunnen ook worden weergegeven in grafieken of rasters en zijn toegankelijk via Azure Portal, Azure PowerShell, de Azure CLI en de Azure Monitor-API's. Zie metrische gegevens van Azure Monitor voor meer informatie.
De metrische gegevens die in de volgende tabel worden vermeld, worden gedurende een beperkte periode vastgelegd en gratis opgeslagen. Voor extra kosten kunt u een langere periode opslaan.
Metrische gegevens voor | Beschrijving | Dimensies | Aanbevolen aggregaties |
---|---|---|---|
Byte Hit Ratio | Het percentage verkeer dat is geleverd vanuit de Azure Front Door-cache, berekend op basis van het totale uitgaande verkeer. De byte hit ratio is laag als het grootste deel van het verkeer wordt doorgestuurd naar de oorsprong in plaats van geleverd vanuit de cache. Byte Hit Ratio = (uitgaand verkeer vanaf rand - uitgaand van oorsprong)/uitgaand verkeer vanaf rand. Scenario's die zijn uitgesloten van berekeningen van de verhouding van bytes:
|
Eindpunt | Gem, Min |
Oorsprongsstatuspercentage | Het percentage geslaagde statustests dat is verzonden van Azure Front Door naar origins. | Origin, Origin Group | Gem |
Latentie van oorsprong | Azure Front Door berekent de tijd van het verzenden van de aanvraag naar de oorsprong tot het ontvangen van de laatste reactie-byte van de oorsprong. WebSocket wordt uitgesloten van de oorspronkelijke latentie. | Eindpunt, oorsprong | Gem, Max |
Aantal oorsprongsaanvragen | Het aantal aanvragen dat vanuit Azure Front Door naar origins wordt verzonden. | Eindpunt, oorsprong, HTTP-status, HTTP-statusgroep | Gem, Som |
Percentage van 4XX | Het percentage van alle clientaanvragen waarvoor de antwoordstatuscode 4XX is. | Eindpunt, clientland, clientregio | Gem, Max |
Percentage van 5XX | Het percentage van alle clientaanvragen waarvoor de antwoordstatuscode 5XX is. | Eindpunt, clientland, clientregio | Gem, Max |
Aantal aanvragen | Het aantal clientaanvragen dat wordt verwerkt via Azure Front Door, inclusief aanvragen die volledig vanuit de cache worden verwerkt. | Eindpunt, clientland, clientregio, HTTP-status, HTTP-statusgroep | Gem, Som |
Aanvraaggrootte | Het aantal bytes dat wordt verzonden in aanvragen van clients naar Azure Front Door. | Eindpunt, clientland, clientregio, HTTP-status, HTTP-statusgroep | Gem, Max |
Antwoordgrootte | Het aantal bytes dat is verzonden als antwoorden van Front Door naar clients. | Eindpunt, clientland, clientregio, HTTP-status, HTTP-statusgroep | Gem, Max |
Totale latentie | Azure Front Door ontvangt de clientaanvraag en verzendt de laatste reactie-byte naar de client. Dit is de totale tijd die nodig is. Voor WebSocket verwijst deze metrische waarde naar de tijd die nodig is om de WebSocket-verbinding tot stand te brengen. | Eindpunt, clientland, clientregio, HTTP-status, HTTP-statusgroep | Gem, Max |
Aantal Web Application Firewall-aanvragen | Het aantal aanvragen dat door de Firewall van de Azure Front Door-webtoepassing wordt verwerkt. | Actie, beleidsnaam, regelnaam | Gem, Som |
Notitie
Als er een time-out optreedt voor een aanvraag naar de oorsprong, is de waarde van de dimensie Http-status 0.
Logboeken
Logboeken houden alle aanvragen bij die via Azure Front Door worden doorgegeven. Het kan enkele minuten duren voordat logboeken worden verwerkt en opgeslagen.
Er zijn meerdere Front Door-logboeken die u voor verschillende doeleinden kunt gebruiken:
- Toegangslogboeken kunnen worden gebruikt om trage aanvragen te identificeren, foutpercentages te bepalen en te begrijpen hoe het cachegedrag van Front Door werkt voor uw oplossing.
- WaF-logboeken (Web Application Firewall) kunnen worden gebruikt om mogelijke aanvallen te detecteren en fout-positieve detecties die kunnen duiden op legitieme aanvragen die door de WAF zijn geblokkeerd. Zie Bewaking en logboekregistratie van Azure Web Application Firewall voor meer informatie over de WAF-logboeken.
- Statustestlogboeken kunnen worden gebruikt om oorsprongen te identificeren die beschadigd zijn of die niet reageren op aanvragen van sommige geografisch gedistribueerde PoPs van Front Door.
- Activiteitenlogboeken bieden inzicht in de bewerkingen die worden uitgevoerd op uw Azure-resources, zoals configuratiewijzigingen in uw Azure Front Door-profiel.
Access-logboeken en WAF-logboeken bevatten een traceringsverwijzing, die ook wordt doorgegeven in aanvragen naar oorsprongen en clientreacties met behulp van de X-Azure-Ref
header. U kunt de traceringsverwijzing gebruiken om een end-to-end weergave te krijgen van de verwerking van uw toepassingsaanvragen.
Toegangslogboeken, statustestlogboeken en WAF-logboeken zijn niet standaard ingeschakeld. Zie Azure Front Door-logboeken configureren om uw diagnostische logboeken in te schakelen en op te slaan. Activiteitenlogboekitems worden standaard verzameld en kunnen in de Azure-portal worden bekeken.
Toegangslogboek
Informatie over elke aanvraag wordt aangemeld bij het toegangslogboek. Elke vermelding in het toegangslogboek bevat de informatie die wordt vermeld in de volgende tabel.
Eigenschappen | Beschrijving |
---|---|
TrackingReference | De unieke referentietekenreeks die een aanvraag identificeert die wordt geleverd door Azure Front Door. De traceringsreferentie wordt naar de client en naar de oorsprong verzonden met behulp van de X-Azure-Ref headers. Gebruik de traceringsreferentie bij het zoeken naar een specifieke aanvraag in de toegangs- of WAF-logboeken. |
Tijd | De datum en tijd waarop de Azure Front Door-edge aangevraagde inhoud aan de client heeft geleverd (in UTC). Voor WebSocket-verbindingen geeft de tijd aan wanneer de verbinding wordt gesloten. |
HttpMethod | HTTP-methode die wordt gebruikt door de aanvraag: DELETE, GET, HEAD, OPTIONS, PATCH, POST of PUT. |
HttpVersion | De HTTP-versie die de client heeft opgegeven in de aanvraag. |
RequestUri | De URI van de ontvangen aanvraag. Dit veld bevat het volledige schema, de poort, het domein, het pad en de querytekenreeks. |
HostName | De hostnaam in de aanvraag van de client. Als u aangepaste domeinen inschakelt en een domein met jokertekens hebt (*.contoso.com ), is subdomain-from-client-request.contoso.com de waarde van het veld HostName log. Als u het Azure Front Door-domein (contoso-123.z01.azurefd.net ) gebruikt, is contoso-123.z01.azurefd.net de waarde van het veld HostName-logboek . |
RequestBytes | De grootte van het HTTP-aanvraagbericht in bytes, inclusief de aanvraagheaders en de aanvraagbody. Voor WebSocket-verbindingen is dit het totale aantal bytes dat van de client naar de server wordt verzonden via de verbinding. |
ResponseBytes | De grootte van het HTTP-antwoordbericht in bytes. Voor WebSocket-verbindingen is dit het totale aantal bytes dat vanaf de server naar de client wordt verzonden via de verbinding. |
UserAgent | De gebruikersagent die de client heeft gebruikt. Normaal gesproken identificeert de gebruikersagent het browsertype. |
ClientIp | Het IP-adres van de client die de oorspronkelijke aanvraag heeft ingediend. Als de aanvraag een X-Forwarded-For header bevat, wordt het IP-adres van de client uit de header gehaald. |
SocketIp | Het IP-adres van de directe verbinding met de Edge van Azure Front Door. Als de client een HTTP-proxy of een load balancer heeft gebruikt om de aanvraag te verzenden, is de waarde van SocketIp het IP-adres van de proxy of load balancer. |
TimeTaken | De duur van het moment waarop de Azure Front Door Edge de aanvraag van de client heeft ontvangen tot wanneer de laatste byte van het antwoord naar de client is verzonden, gemeten in seconden. Deze metrische waarde sluit netwerklatentie en TCP-buffering uit. Voor WebSocket-verbindingen vertegenwoordigt deze de verbindingsduur van de instelling tot de sluiting. |
RequestProtocol | Het protocol dat is opgegeven door de client in de aanvraag. Mogelijke waarden zijn: HTTP, HTTPS. Voor WebSocket zijn de protocollen WS, WSS. Alleen aanvragen die een upgrade naar WebSocket hebben, hebben WS/WSS. |
SecurityProtocol | De TLS/SSL-protocolversie die wordt gebruikt door de aanvraag of null als de aanvraag geen versleuteling heeft gebruikt. Mogelijke waarden zijn: SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
SecurityCipher | Wanneer de waarde voor het aanvraagprotocol HTTPS is, geeft dit veld de TLS/SSL-codering aan die is onderhandeld door de client en Azure Front Door. |
Eindpunt | De domeinnaam van het Azure Front Door-eindpunt, zoals contoso-123.z01.azurefd.net . |
HttpStatusCode | De HTTP-statuscode die is geretourneerd door Azure Front Door. Als er een time-out optreedt voor de aanvraag voor de oorsprong, is de waarde voor het veld HttpStatusCode 0. Als de client de verbinding heeft gesloten, is de waarde voor het veld HttpStatusCode 499. |
Pop | Het Azure Front Door Edge-punt van aanwezigheid (PoP) dat heeft gereageerd op de gebruikersaanvraag. |
Cachestatus | Hoe de aanvraag is verwerkt door de Azure Front Door-cache. Mogelijke waarden zijn:
|
MatchedRulesSetName | De namen van de regelengineregels die zijn verwerkt. |
RouteName | De naam van de route die overeenkomt met de aanvraag. |
ClientPort | De IP-poort van de client die de aanvraag heeft ingediend. |
Referrer | De URL van de site die afkomstig is van de aanvraag. |
TimetoFirstByte | De tijdsduur, in seconden, vanaf het moment waarop de Edge van Azure Front Door de aanvraag heeft ontvangen tot de tijd dat de eerste byte naar de client werd verzonden, zoals gemeten door Azure Front Door. Met deze eigenschap worden de clientgegevens niet gemeten. |
ErrorInfo | Als er een fout is opgetreden tijdens de verwerking van de aanvraag, bevat dit veld gedetailleerde informatie over de fout. Mogelijke waarden zijn:
|
OriginURL | De volledige URL van de oorsprong waar de aanvraag is verzonden. De URL bestaat uit het schema, de hostheader, de poort, het pad en de querytekenreeks. URL herschrijven: als de aanvraag-URL is herschreven door de regelengine, verwijst het pad naar het herschreven pad. Cache op edge PoP: als de aanvraag is verwerkt vanuit de Azure Front Door-cache, is de oorsprong N/B. Grote aanvraag: Als de aangevraagde inhoud groot is en er meerdere gesegmenteerde aanvragen teruggaan naar de oorsprong, komt dit veld overeen met de eerste aanvraag voor de oorsprong. Zie Objectsegmenting voor meer informatie. |
OriginIP | Het IP-adres van de oorsprong die de aanvraag heeft geleverd. Cache op edge PoP: als de aanvraag is verwerkt vanuit de Azure Front Door-cache, is de oorsprong N/B. Grote aanvraag: Als de aangevraagde inhoud groot is en er meerdere gesegmenteerde aanvragen teruggaan naar de oorsprong, komt dit veld overeen met de eerste aanvraag voor de oorsprong. Zie Objectsegmenting voor meer informatie. |
OriginName | De volledige hostnaam (DNS-naam) van de oorsprong. Cache op edge PoP: als de aanvraag is verwerkt vanuit de Azure Front Door-cache, is de oorsprong N/B. Grote aanvraag: Als de aangevraagde inhoud groot is en er meerdere gesegmenteerde aanvragen teruggaan naar de oorsprong, komt dit veld overeen met de eerste aanvraag voor de oorsprong. Zie Objectsegmenting voor meer informatie. |
Resultaat | SSLMismatchedSNI is een statuscode waarmee een geslaagde aanvraag wordt aangegeven met een waarschuwing over niet-overeenkomende waarden tussen de SNI en de hostheader. Deze statuscode impliceert domeinfronting, een techniek die de servicevoorwaarden van Azure Front Door schendt. Aanvragen met SSLMismatchedSNI worden geweigerd na 22 januari 2024. |
Sni | Dit veld geeft de servernaamindicatie (SNI) op die wordt verzonden tijdens de TLS/SSL-handshake. Deze kan worden gebruikt om de exacte SNI-waarde te identificeren als er een SSLMismatchedSNI statuscode is. Daarnaast kan het worden vergeleken met de hostwaarde in het requestUri veld om het probleem met niet-overeenkomende items te detecteren en op te lossen. |
Statustestlogboek
Azure Front Door registreert elke mislukte statustestaanvraag. Deze logboeken kunnen u helpen bij het vaststellen van problemen met een oorsprong. De logboeken bevatten informatie die u kunt gebruiken om de reden van de fout te onderzoeken en de oorsprong vervolgens weer in orde te brengen.
In sommige scenario's kan dit logboek handig zijn:
- U hebt gemerkt dat Azure Front Door-verkeer is verzonden naar een subset van de oorsprongen. U hebt bijvoorbeeld gemerkt dat slechts drie van de vier oorsprongen verkeer ontvangen. U wilt weten of de oorsprongen statustests ontvangen en erop reageren, zodat u weet of de oorsprong in orde is.
- U hebt gezien dat de metrische waarde voor het oorspronkelijke statuspercentage lager is dan verwacht. U wilt weten welke oorsprongen worden geregistreerd als beschadigd en de reden voor de mislukte statustests.
Elke vermelding in het statustestlogboek heeft het volgende schema:
Eigenschappen | Beschrijving |
---|---|
HealthProbeId | Een unieke id om de statustestaanvraag te identificeren. |
Tijd | De datum en tijd waarop de statustest is verzonden (in UTC). |
HttpMethod | De HTTP-methode die wordt gebruikt door de statustestaanvraag. Waarden zijn GET en HEAD, op basis van de configuratie van de statustest. |
Resultaat | De status van de statustest. De waarde is geslaagd of een beschrijving van de fout die de test heeft ontvangen. |
HttpStatusCode | De HTTP-statuscode die wordt geretourneerd door de oorsprong. |
ProbeURL | De volledige doel-URL naar de locatie waar de testaanvraag is verzonden. De URL bestaat uit het schema, de hostheader, het pad en de querytekenreeks. |
OriginName | De naam van de oorsprong waarnaar de statustest is verzonden. Dit veld helpt u bij het vinden van nuttige origins als origin is geconfigureerd voor het gebruik van een FDQN. |
POP | De Edge PoP die de testaanvraag heeft verzonden. |
IP-adres van bron | Het IP-adres van de oorsprong waarnaar de statustest is verzonden. |
TotalLatency | De tijd vanaf het moment waarop de Azure Front Door-edge de statustestaanvraag naar de oorsprong heeft verzonden wanneer de oorsprong het laatste antwoord naar Azure Front Door heeft verzonden. |
ConnectionLatency | De tijd die is besteed aan het instellen van de TCP-verbinding om de HTTP-testaanvraag naar de oorsprong te verzenden. |
DNSResolution-latentie | De tijd die is besteed aan DNS-omzetting. Dit veld heeft alleen een waarde als de oorsprong is geconfigureerd als een FDQN in plaats van een IP-adres. Als de oorsprong is geconfigureerd voor het gebruik van een IP-adres, is de waarde N/B. |
In het volgende voorbeeld van JSON-fragment ziet u een vermelding in het statustestlogboek voor een mislukte statustestaanvraag.
{
"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-logboek
Zie Bewaking en logboekregistratie van Azure Web Application Firewall voor meer informatie over de WAF-logboeken (Front Door Web Application Firewall).
Activiteitenlogboeken
Activiteitenlogboeken bieden informatie over de beheerbewerkingen in uw Azure Front Door-resources. De logboeken bevatten details over elke schrijfbewerking die is uitgevoerd op een Azure Front Door-resource, inclusief wanneer de bewerking heeft plaatsgevonden, wie deze heeft uitgevoerd en wat de bewerking was.
Notitie
Activiteitenlogboeken bevatten geen leesbewerkingen. Ze bevatten mogelijk ook niet alle bewerkingen die u uitvoert met behulp van de Azure-portal of klassieke beheer-API's.
Zie Uw activiteitenlogboeken weergeven voor meer informatie.
Volgende stappen
Zie Azure Front Door-logboeken configureren om uw diagnostische logboeken in te schakelen en op te slaan.
Belangrijk
Azure Front Door (klassiek) wordt op 31 maart 2027 buiten gebruik gesteld. Om serviceonderbrekingen te voorkomen, is het belangrijk dat u uw Azure Front Door-profielen (klassiek) tegen maart 2027 migreert naar de Azure Front Door Standard- of Premium-laag. Zie De buitengebruikstelling van Azure Front Door (klassiek) voor meer informatie.
Wanneer u Azure Front Door (klassiek) gebruikt, kunt u resources op de volgende manieren bewaken:
- Metrische gegevens. Azure Front Door heeft momenteel acht metrische gegevens om prestatiemeteritems weer te geven.
- Logboeken. Met activiteiten- en diagnostische logboeken kunnen prestaties, toegang en andere gegevens worden opgeslagen of gebruikt vanuit een resource voor bewakingsdoeleinden.
Metrische gegevens
Metrische gegevens zijn een functie voor bepaalde Azure-resources waarmee u prestatiemeteritems in de portal kunt weergeven. Hieronder vindt u metrische gegevens van Front Door:
Metrische gegevens | Weergavenaam van metrische gegevens | Eenheid | Afmetingen | Beschrijving |
---|---|---|---|---|
RequestCount | Aantal aanvragen | Tellen | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Het aantal clientaanvragen dat door Front Door wordt verwerkt. |
RequestSize | Aanvraaggrootte | Bytes | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Het aantal bytes dat wordt verzonden als aanvragen van clients naar Front Door. |
ResponseSize | Antwoordgrootte | Bytes | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Het aantal bytes dat is verzonden als antwoorden van Front Door naar clients. |
TotalLatency | Totale latentie | Milliseconden | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
De totale tijd van de clientaanvraag die door Front Door is ontvangen tot het laatste antwoord byte dat van AFD naar de client is verzonden. |
BackendRequestCount | Aantal back-endaanvragen | Tellen | HttpStatus HttpStatusGroup-back-end |
Het aantal aanvragen dat van Front Door naar back-ends wordt verzonden. |
BackendRequestLatency | Latentie van back-endaanvraag | Milliseconden | Back-end | De tijd die wordt berekend vanaf het moment waarop de aanvraag door Front Door naar de back-end is verzonden totdat Front Door het laatste antwoord-byte van de back-end heeft ontvangen. |
BackendHealthPercentage | Percentage back-endstatus | Procent | Back-endpool |
Het percentage geslaagde statustests van Front Door naar back-ends. |
WebApplicationFirewallRequestCount | Aantal Web Application Firewall-aanvragen | Tellen | PolicyName RuleName Action |
Het aantal clientaanvragen dat wordt verwerkt door de beveiliging van de toepassingslaag van Front Door. |
Activiteitenlogboeken
Activiteitenlogboeken bevatten informatie over de bewerkingen die worden uitgevoerd op een Azure Front Door-profiel (klassiek). Ze bepalen ook wat, wie en wanneer voor schrijfbewerkingen (put, post of delete) zijn uitgevoerd op basis van een Azure Front Door-profiel (klassiek).
Notitie
Als er een time-out optreedt voor een aanvraag voor de oorsprong, wordt de waarde voor HttpStatusCode ingesteld op 0.
Krijg toegang tot activiteitenlogboeken in uw Front Door of alle logboeken van uw Azure-resources in Azure Monitor. Activiteitenlogboeken weergeven:
Selecteer uw Front Door-exemplaar.
Selecteer Activiteitenlogboek.
Kies een filterbereik en selecteer vervolgens Toepassen.
Notitie
Activiteitenlogboek bevat geen GET-bewerkingen of bewerkingen die u uitvoert met behulp van Azure Portal of de oorspronkelijke Management-API.
Diagnostische logboeken
Diagnostische logboeken bieden uitgebreide informatie over bewerkingen en fouten die belangrijk zijn voor controle en probleemoplossing. Diagnostische logboeken verschillen van activiteitenlogboeken.
Activiteitenlogboeken bieden inzicht in de bewerkingen die worden uitgevoerd op Azure-resources. Diagnostische logboeken bieden inzicht in bewerkingen die uw resource heeft uitgevoerd. Zie diagnostische logboeken van Azure Monitor voor meer informatie.
Diagnostische logboeken configureren voor uw Azure Front Door (klassiek):
Selecteer uw Azure Front Door-profiel (klassiek).
Kies Diagnostische instellingen.
Selecteer Diagnostische gegevens inschakelen. Archiveer diagnostische logboeken samen met metrische gegevens naar een opslagaccount, stream ze naar een Event Hub of verzend ze naar Azure Monitor-logboeken.
Front Door biedt momenteel diagnostische logboeken. Diagnostische logboeken bieden afzonderlijke API-aanvragen met elk item met het volgende schema:
Eigenschappen | Beschrijving |
---|---|
BackendHostname | Als de aanvraag wordt doorgestuurd naar een back-end, vertegenwoordigt dit veld de hostnaam van de back-end. Dit veld is leeg als de aanvraag wordt omgeleid of doorgestuurd naar een regionale cache (wanneer caching wordt ingeschakeld voor de routeringsregel). |
CacheStatus | Voor cachescenario's definieert dit veld de cachetreffer/miss in de POP |
ClientIp | Het IP-adres van de client die de aanvraag heeft ingediend. Als er een X-Forwarded-For-header in de aanvraag was, wordt het CLIENT-IP-adres uit hetzelfde gekozen. |
ClientPort | De IP-poort van de client die de aanvraag heeft ingediend. |
HttpMethod | De HTTP-methode die wordt gebruikt door de aanvraag. |
HttpStatusCode | De HTTP-statuscode die is geretourneerd door de proxy. Als er een time-out optreedt voor een aanvraag voor de oorsprong, wordt de waarde voor HttpStatusCode ingesteld op 0. |
HttpStatusDetails | Resulterende status van de aanvraag. De betekenis van deze tekenreekswaarde vindt u in een statusreferentietabel. |
HttpVersion | Type aanvraag of verbinding. |
POP | Korte naam van de rand waar de aanvraag is geland. |
RequestBytes | De grootte van het HTTP-aanvraagbericht in bytes, inclusief de aanvraagheaders en de aanvraagbody. |
RequestUri | URI van de ontvangen aanvraag. |
ResponseBytes | Bytes die door de back-endserver worden verzonden als antwoord. |
RoutingRuleName | De naam van de routeringsregel die overeenkomt met de aanvraag. |
RulesEngineMatchNames | De namen van de regels die overeenkomen met de aanvraag. |
SecurityProtocol | De TLS/SSL-protocolversie die wordt gebruikt door de aanvraag of null als er geen versleuteling is. |
SentToOriginShield (afgeschaft) * Zie de opmerkingen over afschaffing in de volgende sectie. |
Als waar, betekent dit dat de aanvraag is beantwoord vanuit de origin shield-cache in plaats van de edge pop. Origin Shield is een bovenliggende cache die wordt gebruikt om de verhouding tussen cachetreffers te verbeteren. |
isReceivedFromClient | Indien waar, betekent dit dat de aanvraag afkomstig is van de client. Als dit onwaar is, is de aanvraag een misser in de rand (onderliggende POP) en wordt er gereageerd vanaf het oorspronkelijke schild (bovenliggende POP). |
TimeTaken | De tijdsduur van de eerste byte van aanvraag in Front Door tot laatste byte van reactie, in seconden. |
TrackingReference | De unieke referentietekenreeks die een aanvraag identificeert die wordt geleverd door Front Door, ook verzonden als X-Azure-Ref-header naar de client. Vereist voor het zoeken naar details in de toegangslogboeken voor een specifieke aanvraag. |
UserAgent | Het browsertype dat de client heeft gebruikt. |
ErrorInfo | Dit veld bevat het specifieke type fout voor verdere probleemoplossing. Mogelijke waarden zijn: NoError: Geeft aan dat er geen fout is gevonden. CertificateError: Algemene SSL-certificaatfout. CertificateNameCheckFailed: de hostnaam in het SSL-certificaat is ongeldig of komt niet overeen. ClientDisconnected: aanvraagfout vanwege clientnetwerkverbinding. UnspecifiedClientError: Algemene clientfout. InvalidRequest: Ongeldige aanvraag. Dit kan optreden vanwege ongeldige headers, hoofdteksten en URL's. DNSFailure: DNS-fout. DNSNameNotResolved: de servernaam of het adres kan niet worden omgezet. OriginConnectionAborted: De verbinding met de oorsprong is plotseling gestopt. OriginConnectionError: Algemene verbindingsfout voor oorsprong. OriginConnectionRefused: De verbinding met de oorsprong kon niet tot stand worden gebracht. OriginError: Algemene oorsprongsfout. OriginInvalidResponse: Origin heeft een ongeldig of niet-herkend antwoord geretourneerd. OriginTimeout: de time-outperiode voor de oorspronkelijke aanvraag is verlopen. ResponseHeaderTooBig: De oorsprong heeft te groot geretourneerd van een antwoordheader. RestrictedIP: de aanvraag is geblokkeerd vanwege een beperkt IP-adres. SSLHandshakeError: kan geen verbinding maken met de oorsprong vanwege een SSL-handshakefout. UnspecifiedError: er is een fout opgetreden die niet in een van de fouten in de tabel past. SSLMismatchedSNI: de aanvraag is ongeldig omdat de HTTP-berichtkop niet overeenkomt met de waarde die wordt weergegeven in de TLS SNI-extensie tijdens het instellen van de SSL/TLS-verbinding. |
Resultaat | SSLMismatchedSNI is een statuscode waarmee een geslaagde aanvraag wordt aangegeven met een waarschuwing over niet-overeenkomende waarden tussen de SNI en de hostheader. Deze statuscode impliceert domeinfronting, een techniek die de servicevoorwaarden van Azure Front Door schendt. Aanvragen met SSLMismatchedSNI worden geweigerd na 22 januari 2024. |
Sni | Dit veld geeft de servernaamindicatie (SNI) op die wordt verzonden tijdens de TLS/SSL-handshake. Deze kan worden gebruikt om de exacte SNI-waarde te identificeren als er een SSLMismatchedSNI statuscode is. Daarnaast kan het worden vergeleken met de hostwaarde in het requestUri veld om het probleem met niet-overeenkomende items te detecteren en op te lossen. |
Verzonden naar afschaffing van oorsprongsschild
De onbewerkte logboekeigenschap isSentToOriginShield is afgeschaft en vervangen door een nieuw veld isReceivedFromClient. Gebruik het nieuwe veld als u het afgeschafte veld al gebruikt.
Onbewerkte logboeken bevatten logboeken die zijn gegenereerd op basis van zowel CDN Edge (onderliggende POP) als origin shield. Oorsprongsschild verwijst naar bovenliggende knooppunten die strategisch over de hele wereld zijn gelegen. Deze knooppunten communiceren met oorspronkelijke servers en verminderen de belasting van het verkeer op de oorsprong.
Voor elke aanvraag die naar een oorsprongsschild gaat, zijn er twee logboekvermeldingen:
- Eén voor edge-knooppunten
- Een voor oorsprongsschild.
U kunt het veld isReceivedFromClient gebruiken om de juiste gegevens op te halen om het uitgangspunt of de antwoorden van de edge-knooppunten te onderscheiden van de edge-knooppunten versus het oorsprongsschild.
Als de waarde onwaar is, betekent dit dat de aanvraag wordt gereageerd van oorsprongsschild naar edge-knooppunten. Deze methode is effectief om onbewerkte logboeken te vergelijken met factureringsgegevens. Er worden geen kosten in rekening gebracht voor uitgaand verkeer van oorsprongsschild naar de edge-knooppunten. Er worden kosten in rekening gebracht voor uitgaand verkeer van de edge-knooppunten naar clients.
Kusto-queryvoorbeeld voor het uitsluiten van logboeken die zijn gegenereerd op het oorspronkelijke schild in Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Notitie
Voor verschillende routeringsconfiguraties en verkeersgedrag kunnen sommige velden, zoals backendHostname, cacheStatus, isReceivedFromClient en POP-veld reageren met verschillende waarden. In de volgende tabel worden de verschillende waarden voor deze velden voor verschillende scenario's uitgelegd:
Scenario's | Aantal logboekvermeldingen | POP | BackendHostname | isReceivedFromClient | CacheStatus |
---|---|---|---|---|---|
Routeringsregel zonder caching ingeschakeld | 1 | Edge POP-code | Back-end waar de aanvraag is doorgestuurd | Waar | CONFIG_NOCACHE |
Routeringsregel waarvoor caching is ingeschakeld. Cache bereikt op de edge POP | 1 | Edge POP-code | Leeg | Waar | HIT |
Routeringsregel waarvoor caching is ingeschakeld. Cache mist bij edge POP, maar cache raakt op bovenliggende cache POP | 2 | 1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Bovenliggende cache POP-hostnaam 2. Leeg |
1. Waar 2. Onwaar |
1. MISS 2. HIT |
Routeringsregel waarvoor caching is ingeschakeld. Caches missen bij edge POP, maar GEDEELTELIJKE cache hit bij bovenliggende cache POP | 2 | 1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Bovenliggende cache POP-hostnaam 2. Back-end waarmee de cache wordt gevuld |
1. Waar 2. Onwaar |
1. MISS 2. PARTIAL_HIT |
Routeringsregel waarvoor caching is ingeschakeld. Cache PARTIAL_HIT bij edge POP, maar cache hit bij bovenliggende cache POP | 2 | 1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Waar 2. Onwaar |
1. PARTIAL_HIT 2. HIT |
Routeringsregel waarvoor caching is ingeschakeld. Cache mist zowel edge- als bovenliggende cache POP | 2 | 1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Waar 2. Onwaar |
1. MISS 2. MISSEN |
Fout bij het verwerken van de aanvraag | N.v.t. |
Notitie
Voor cachescenario's wordt de waarde voor cachestatus partial_hit wanneer sommige van de bytes voor een aanvraag worden geleverd vanuit de Azure Front Door-rand of de cache van het origin-schild terwijl sommige bytes worden geleverd vanuit de oorsprong voor grote objecten.
Azure Front Door maakt gebruik van een techniek die objectsegmentering wordt genoemd. Wanneer een groot bestand wordt aangevraagd, haalt De Azure Front Door kleinere stukken van het bestand op uit de oorsprong. Nadat de Azure Front Door POP-server een volledige of bytebereiken van het aangevraagde bestand heeft ontvangen, vraagt de Azure Front Door Edge-server het bestand aan bij de oorsprong in segmenten van 8 MB.
Nadat het segment aan de Rand van Azure Front Door aankomt, wordt het in de cache opgeslagen en onmiddellijk aan de gebruiker geleverd. De Azure Front Door prefetchest vervolgens het volgende segment parallel. Deze prefetch zorgt ervoor dat de inhoud één segment voor de gebruiker blijft, waardoor de latentie wordt verminderd. Dit proces wordt voortgezet totdat het hele bestand wordt gedownload (indien aangevraagd), alle bytebereiken beschikbaar zijn (indien aangevraagd), of de client sluit de verbinding. Zie RFC 7233 voor meer informatie over de bytebereikaanvraag. De Azure Front Door slaat eventuele segmenten in de cache op terwijl ze worden ontvangen. Het hele bestand hoeft niet in de cache van de Front Door-cache te worden opgeslagen. Het verzenden van aanvragen voor het bestand of bytebereiken wordt geleverd vanuit de Azure Front Door-cache. Als niet alle segmenten in de cache worden opgeslagen in de Azure Front Door, wordt prefetch gebruikt om segmenten van de oorsprong aan te vragen. Deze optimalisatie is afhankelijk van de mogelijkheid van de oorspronkelijke server ter ondersteuning van bytebereikaanvragen. Als de oorspronkelijke server geen ondersteuning biedt voor bytebereikaanvragen, is deze optimalisatie niet effectief.
Volgende stappen
- Meer informatie over het maken van een Azure Front Door-profiel (klassiek)
- Meer informatie over hoe Azure Front Door (klassiek) werkt