Metrische gegevens en logboeken in Azure Front Door bijhouden

Artikel
12/20/2023

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 voor

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: U schakelt caching expliciet uit via de regelengine of het cachegedrag van queryreeksen. U configureert expliciet een `Cache-Control` instructie met de `no-store` of `private` cache-instructies.	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.	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.	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).
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.
ResponseBytes	De grootte van het HTTP-antwoordbericht in bytes.
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 tijdsduur vanaf het moment waarop de Edge van Azure Front Door de aanvraag van de client heeft ontvangen tot het tijdstip waarop Azure Front Door de laatste byte van het antwoord naar de client heeft verzonden, in seconden. In dit veld wordt geen rekening gehouden met netwerklatentie en TCP-buffering.
RequestProtocol	Het protocol dat de client heeft opgegeven in de aanvraag. Mogelijke waarden zijn: HTTP, HTTPS.
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: HIT en REMOTE_HIT: De HTTP-aanvraag is geleverd vanuit de Azure Front Door-cache. MISS: De HTTP-aanvraag is vanaf oorsprong geleverd. PARTIAL_HIT: Sommige van de bytes werden geleverd vanuit de Front Door Edge PoP-cache en andere bytes werden geleverd vanaf de oorsprong. Deze status geeft een objectsegmenteringsscenario aan. CACHE_NOCONFIG: de aanvraag is doorgestuurd zonder cache-instellingen, waaronder bypassscenario's. PRIVATE_NOSTORE: er is geen cache geconfigureerd in de cache-instellingen van de klant. N.v.: de aanvraag is geweigerd door een ondertekende URL of de regelengine.
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: 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 met de aangevraagde URL. ClientDisconnected: de aanvraag is mislukt vanwege een probleem met de clientnetwerkverbinding. ClientGeoBlocked: De client is geblokkeerd vanwege de geografische locatie van het IP-adres. UnspecifiedClientError: Algemene clientfout. InvalidRequest: Ongeldige aanvraag. Dit antwoord geeft een onjuiste header, hoofdtekst of URL aan. DNSFailure: er is een fout opgetreden tijdens de DNS-omzetting. DNSTimeout: er is een time-out opgetreden voor de DNS-query om het ip-adres van oorsprong op te lossen. DNSNameNotResolved: de servernaam of het adres kan niet worden omgezet. OriginConnectionAborted: De verbinding met de oorsprong is abnormaal verbroken. OriginConnectionError: Algemene verbindingsfout voor oorsprong. OriginConnectionRefused: De verbinding met de oorsprong is niet tot stand gebracht. OriginError: Algemene oorsprongsfout. ResponseHeaderTooBig: De oorsprong heeft een te grote antwoordheader geretourneerd. OriginInvalidResponse: de oorsprong heeft een ongeldig of niet-herkend antwoord geretourneerd. OriginTimeout: de time-outperiode voor de oorspronkelijke aanvraag is verlopen. ResponseHeaderTooBig: De oorsprong heeft een te grote antwoordheader geretourneerd. RestrictedIP: de aanvraag is geblokkeerd vanwege een beperkt IP-adres. SSLHandshakeError: Azure Front Door kan geen verbinding maken met de oorsprong vanwege een SSL-handshakefout. SSLInvalidRootCA: het certificaat van de basiscertificeringsinstantie is ongeldig. SSLInvalidCipher: de HTTPS-verbinding is tot stand gebracht met behulp van een ongeldige codering. OriginConnectionAborted: De verbinding met de oorsprong is abnormaal verbroken. OriginConnectionRefused: De verbinding met de oorsprong is niet tot stand gebracht. UnspecifiedError: er is een fout opgetreden die niet in een van de fouten in de tabel past.
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 voor

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

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-berichtheader niet overeenkomt met de waarde die tijdens het instellen van de SSL/TLS-verbinding wordt weergegeven in de TLS-SNI-extensie.
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

Share via

Metrische gegevens en logboeken in Azure Front Door bijhouden

Metrische gegevens voor

Logboeken

Toegangslogboek

Statustestlogboek

Web Application Firewall-logboek

Activiteitenlogboeken

Volgende stappen

Metrische gegevens voor

Activiteitenlogboeken

Diagnostische logboeken

Verzonden naar afschaffing van oorsprongsschild

Volgende stappen

Feedback

Aanvullende resources