Delen via


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:
  • 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. 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.comde waarde van het veld HostName log. Als u het Azure Front Door-domein (contoso-123.z01.azurefd.net) gebruikt, is contoso-123.z01.azurefd.netde 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:
  • 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

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:

  1. Selecteer uw Front Door-exemplaar.

  2. Selecteer Activiteitenlogboek.

    Activiteitenlogboek

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

  1. Selecteer uw Azure Front Door-profiel (klassiek).

  2. Kies Diagnostische instellingen.

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