Övervaka mått och loggar i Azure Monitor
Azure Front Door innehåller flera funktioner som hjälper dig att övervaka ditt program, spåra begäranden och felsöka Front Door-konfigurationen.
Loggar och mått lagras och hanteras av Azure Monitor.
Rapporter ger insikter om hur trafiken flödar genom Azure Front Door, brandväggen för webbprogram (WAF) och till ditt program.
Mått
Azure Front Door mäter och skickar sina mått i 60 sekunders intervall. Måtten kan ta upp till 3 minuter att bearbetas av Azure Monitor, och de kanske inte visas förrän bearbetningen har slutförts. Mått kan också visas i diagram eller rutnät och är tillgängliga via Azure Portal, Azure PowerShell, Azure CLI och Azure Monitor-API:er. Mer information finns i Azure Monitor-mått.
Måtten som anges i följande tabell registreras och lagras kostnadsfritt under en begränsad tidsperiod. För en extra kostnad kan du lagra under en längre tidsperiod.
| Metrics | beskrivning | Dimensioner | Rekommenderade sammansättningar |
|---|---|---|---|
| Byte träffförhållande | Procentandelen trafik som betjänades från Azure Front Door-cachen, beräknad mot den totala utgående trafiken. Byteträffsförhållandet är lågt om merparten av trafiken vidarebefordras till ursprunget i stället för att hanteras från cachen. Byte Hit Ratio = (utgående från kant - utgående från ursprung)/utgående från kant. Scenarier som undantas från beräkningar av bytes träffkvot:
|
Slutpunkt | Genomsnittligt, min |
| Hälsoprocent för ursprung | Procentandelen lyckade hälsoavsökningar som skickas från Azure Front Door till ursprung. | Ursprung, ursprungsgrupp | Gmsn |
| Svarstid för ursprung | Azure Front Door beräknar tiden från att skicka begäran till ursprunget till att ta emot senaste svarsbyte från ursprunget. WebSocket undantas från svarstiden för ursprunget. | Slutpunkt, Ursprung | Genomsnittlig, Max |
| Antal ursprungsbegäranden | Antalet begäranden som skickas från Azure Front Door till ursprung. | Slutpunkt, Ursprung, HTTP-status, HTTP-statusgrupp | Genomsnittlig, summa |
| Procentandel av 4XX | Procentandelen av alla klientbegäranden som svarsstatuskoden är 4XX för. | Slutpunkt, klientland, klientregion | Genomsnittlig, Max |
| Procentandel av 5XX | Procentandelen av alla klientbegäranden som svarsstatuskoden är 5XX för. | Slutpunkt, klientland, klientregion | Genomsnittlig, Max |
| Antal begäranden | Antalet klientbegäranden som hanteras via Azure Front Door, inklusive begäranden som hanteras helt från cacheminnet. | Slutpunkt, klientland, klientregion, HTTP-status, HTTP-statusgrupp | Genomsnittlig, summa |
| Begärandestorlek | Antalet byte som skickas i begäranden från klienter till Azure Front Door. | Slutpunkt, klientland, klientregion, HTTP-status, HTTP-statusgrupp | Genomsnittlig, Max |
| Svarsstorlek | Antalet byte som skickas som svar från Front Door till klienter. | Slutpunkt, klientland, klientregion, HTTP-status, HTTP-statusgrupp | Genomsnittlig, Max |
| Total svarstid | Azure Front Door tar emot klientbegäran och skickar det sista svarsbytet till klienten. Det här är den totala tid det tar. För WebSocket refererar det här måttet till den tid det tar att upprätta WebSocket-anslutningen. | Slutpunkt, klientland, klientregion, HTTP-status, HTTP-statusgrupp | Genomsnittlig, Max |
| Antal begäranden för brandvägg för webbaserade program | Antalet begäranden som bearbetas av Azure Front Door-brandväggen för webbprogrammet. | Åtgärd, principnamn, regelnamn | Genomsnittlig, summa |
Kommentar
Om en begäran till ursprunget överskrider tidsgränsen är värdet för http-statusdimensionen 0.
Loggar
Loggar spårar alla begäranden som passerar genom Azure Front Door. Det kan ta några minuter innan loggar bearbetas och lagras.
Det finns flera Front Door-loggar som du kan använda för olika ändamål:
- Åtkomstloggar kan användas för att identifiera långsamma begäranden, fastställa felfrekvenser och förstå hur Front Door cachelagring fungerar för din lösning.
- WAF-loggar (Web Application Firewall) kan användas för att identifiera potentiella attacker och falska positiva identifieringar som kan tyda på legitima begäranden som WAF blockerade. Mer information om WAF-loggarna finns i Övervakning och loggning av Azure Web Application Firewall.
- Hälsoavsökningsloggar kan användas för att identifiera ursprung som inte är felfria eller som inte svarar på begäranden från vissa av Front Door geografiskt distribuerade IP-adresser.
- Aktivitetsloggar ger insyn i de åtgärder som utförs på dina Azure-resurser, till exempel konfigurationsändringar i Din Azure Front Door-profil.
Åtkomstloggar och WAF-loggar innehåller en spårningsreferens som också sprids i begäranden till ursprung och till klientsvar med hjälp X-Azure-Ref av huvudet. Du kan använda spårningsreferensen för att få en slutpunkt till slutpunkt-vy över bearbetningen av programbegäran.
Åtkomstloggar, hälsoavsökningsloggar och WAF-loggar är inte aktiverade som standard. Information om hur du aktiverar och lagrar diagnostikloggar finns i Konfigurera Azure Front Door-loggar. Aktivitetsloggposter samlas in som standard, och du kan visa dem i Azure Portal.
Åtkomstlogg
Information om varje begäran loggas in i åtkomstloggen. Varje åtkomstloggpost innehåller den information som anges i följande tabell.
| Property | beskrivning |
|---|---|
| TrackingReference | Den unika referenssträngen som identifierar en begäran som hanteras av Azure Front Door. Spårningsreferensen skickas till klienten och till ursprunget med hjälp av rubrikerna X-Azure-Ref . Använd spårningsreferensen när du söker efter en specifik begäran i åtkomst- eller WAF-loggarna. |
| Tid | Datum och tid då Azure Front Door-gränsen levererade begärt innehåll till klienten (i UTC). För WebSocket-anslutningar representerar tiden när anslutningen stängs. |
| HttpMethod | HTTP-metod som används av begäran: DELETE, GET, HEAD, OPTIONS, PATCH, POST eller PUT. |
| HttpVersion | DEN HTTP-version som klienten angav i begäran. |
| RequestUri | URI:n för den mottagna begäran. Det här fältet innehåller det fullständiga schemat, porten, domänen, sökvägen och frågesträngen. |
| HostName | Värdnamnet i begäran från klienten. Om du aktiverar anpassade domäner och har jokerteckendomän (*.contoso.com) är subdomain-from-client-request.contoso.comvärdet för värdnamnsloggfältet . Om du använder Azure Front Door-domänen (contoso-123.z01.azurefd.net) är contoso-123.z01.azurefd.netvärdnamnsloggfältets värde . |
| RequestBytes | Storleken på HTTP-begärandemeddelandet i byte, inklusive begärandehuvudena och begärandetexten. För WebSocket-anslutningar är detta det totala antalet byte som skickas från klienten till servern via anslutningen. |
| ResponseBytes | Storleken på HTTP-svarsmeddelandet i byte. För WebSocket-anslutningar är detta det totala antalet byte som skickas från servern till klienten via anslutningen. |
| UserAgent | Den användaragent som klienten använde. Vanligtvis identifierar användaragenten webbläsartypen. |
| ClientIp | IP-adressen för klienten som gjorde den ursprungliga begäran. Om det fanns en X-Forwarded-For rubrik i begäran tas klientens IP-adress från huvudet. |
| SocketIp | IP-adressen för direktanslutningen till Azure Front Door-gränsen. Om klienten använde en HTTP-proxy eller en lastbalanserare för att skicka begäran är värdet för SocketIp IP-adressen för proxyn eller lastbalanseraren. |
| TimeTaken | Varaktigheten från när Azure Front Door-gränsen tog emot klientens begäran till när den sista byte av svaret skickades till klienten, mätt i sekunder. Det här måttet exkluderar nätverksfördröjning och TCP-buffring. För WebSocket-anslutningar representerar den anslutningens varaktighet från etablering till stängning. |
| RequestProtocol | Det protokoll som anges av klienten i begäran. Möjliga värden är: HTTP, HTTPS. För WebSocket är protokollen WS, WSS. Endast begäranden som har uppgraderats till WebSocket har WS/WSS. |
| SecurityProtocol | TLS/SSL-protokollversionen som används av begäran eller null om begäran inte använde kryptering. Möjliga värden är: SSLv3, TLSv1, TLSv1.1, TLSv1.2. |
| SecurityCipher | När värdet för begärandeprotokollet är HTTPS anger det här fältet det TLS/SSL-chiffer som förhandlats fram av klienten och Azure Front Door. |
| Slutpunkt | Domännamnet för Azure Front Door-slutpunkten, till exempel contoso-123.z01.azurefd.net. |
| HttpStatusCode | HTTP-statuskoden som returneras från Azure Front Door. Om tidsgränsen för begäran till ursprunget överskrids är värdet för fältet HttpStatusCode 0. Om klienten stängde anslutningen är värdet för fältet HttpStatusCode 499. |
| Pop | Den Azure Front Door-gränspunkt (PoP) som svarade på användarbegäran. |
| Cachestatus | Hur begäran hanterades av Azure Front Door-cachen. Möjliga värden är:
|
| MatchedRulesSetName | Namnen på regelmotorns regler som bearbetades. |
| RouteName | Namnet på den väg som begäran matchade. |
| ClientPort | IP-porten för klienten som gjorde begäran. |
| Hänvisningsadress | URL:en för webbplatsen som kom från begäran. |
| TimetoFirstByte | Hur lång tid, i sekunder, från när Azure Front Door-gränsen tog emot begäran till den tidpunkt då den första byte skickades till klienten, mätt med Azure Front Door. Den här egenskapen mäter inte klientdata. |
| ErrorInfo | Om ett fel uppstod under bearbetningen av begäran innehåller det här fältet detaljerad information om felet. Möjliga värden är:
|
| OriginURL | Den fullständiga URL:en för ursprunget där begäran skickades. URL:en består av schemat, värdrubriken, porten, sökvägen och frågesträngen. URL-omskrivning: Om begärande-URL:en skrevs om av regelmotorn refererar sökvägen till den omskrivna sökvägen. Cache on edge PoP: Om begäran har hanterats från Azure Front Door-cachen är ursprunget N/A. Stor begäran: Om det begärda innehållet är stort och det finns flera segmenterade begäranden som går tillbaka till ursprunget motsvarar det här fältet den första begäran till ursprunget. Mer information finns i Objektsegmentering. |
| OriginIP | IP-adressen för det ursprung som hanterade begäran. Cache on edge PoP: Om begäran har hanterats från Azure Front Door-cachen är ursprunget N/A. Stor begäran: Om det begärda innehållet är stort och det finns flera segmenterade begäranden som går tillbaka till ursprunget motsvarar det här fältet den första begäran till ursprunget. Mer information finns i Objektsegmentering. |
| OriginName | Ursprungets fullständiga värdnamn (DNS-namn). Cache on edge PoP: Om begäran har hanterats från Azure Front Door-cachen är ursprunget N/A. Stor begäran: Om det begärda innehållet är stort och det finns flera segmenterade begäranden som går tillbaka till ursprunget motsvarar det här fältet den första begäran till ursprunget. Mer information finns i Objektsegmentering. |
| Result | SSLMismatchedSNI är en statuskod som innebär en lyckad begäran med en felmatchningsvarning mellan SNI och värdhuvudet. Den här statuskoden innebär domänfronting, en teknik som strider mot Azure Front Door-användarvillkoren. Begäranden med SSLMismatchedSNI avvisas efter den 22 januari 2024. |
| Sni | Det här fältet anger den servernamnsindikator (SNI) som skickas under handskakningen för TLS/SSL. Den kan användas för att identifiera det exakta SNI-värdet om det fanns en SSLMismatchedSNI statuskod. Dessutom kan det jämföras med värdvärdet i requestUri fältet för att identifiera och lösa felmatchningsproblemet. |
Hälsoavsökningslogg
Azure Front Door loggar varje misslyckad begäran om hälsoavsökning. Dessa loggar kan hjälpa dig att diagnostisera problem med ett ursprung. Loggarna ger dig information som du kan använda för att undersöka orsaken till felet och sedan återställa ursprunget till en felfri status.
Vissa scenarier som loggen kan vara användbara för är:
- Du har märkt att Azure Front Door-trafik skickades till en delmängd av ursprunget. Du kanske till exempel har märkt att endast tre av fyra ursprung tar emot trafik. Du vill veta om ursprunget tar emot och svarar på hälsoavsökningar så att du vet om ursprunget är felfritt.
- Du har märkt att måttet för ursprungshälsa är lägre än förväntat. Du vill veta vilket ursprung som registreras som felfritt och orsaken till hälsoavsökningsfelen.
Varje hälsoavsökningsloggpost har följande schema:
| Property | beskrivning |
|---|---|
| HealthProbeId | Ett unikt ID för att identifiera hälsoavsökningsbegäran. |
| Tid | Datum och tid då hälsoavsökningen skickades (i UTC). |
| HttpMethod | HTTP-metoden som används av hälsoavsökningsbegäran. Värdena inkluderar GET och HEAD, baserat på hälsoavsökningens konfiguration. |
| Result | Status för hälsoavsökningen. Värdet är antingen lyckat eller en beskrivning av felet som avsökningen tog emot. |
| HttpStatusCode | HTTP-statuskoden som returneras av ursprunget. |
| ProbeURL | Den fullständiga mål-URL:en till där avsökningsbegäran skickades. URL:en består av schemat, värdrubriken, sökvägen och frågesträngen. |
| OriginName | Namnet på ursprunget som hälsoavsökningen skickades till. Det här fältet hjälper dig att hitta ursprung av intresse om ursprunget har konfigurerats för att använda ett FDQN. |
| POP | Edge PoP som skickade avsökningsbegäran. |
| Ursprungligt IP | IP-adressen för det ursprung som hälsoavsökningen skickades till. |
| TotalLatency | Tiden från när Azure Front Door-gränsen skickade hälsoavsökningsbegäran till ursprunget till när ursprunget skickade det sista svaret till Azure Front Door. |
| ConnectionLatency | Den tid som ägnas åt att konfigurera TCP-anslutningen för att skicka HTTP-avsökningsbegäran till ursprunget. |
| DNSResolution-svarstid | Den tid som ägnas åt DNS-matchning. Det här fältet har bara ett värde om ursprunget har konfigurerats för att vara ett FDQN i stället för en IP-adress. Om ursprunget har konfigurerats för att använda en IP-adress är värdet N/A. |
I följande exempel visar JSON-kodfragment en hälsoavsökningsloggpost för en misslyckad hälsoavsökningsbegäran.
{
"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"
}
}
]
}
Brandväggslogg för webbprogram
Mer information om LOGGARna för Front Door-brandväggen (WAF) finns i Övervakning och loggning av Azure Web Application Firewall.
Aktivitetsloggar
Aktivitetsloggar innehåller information om hanteringsåtgärderna på dina Azure Front Door-resurser. Loggarna innehåller information om varje skrivåtgärd som utfördes på en Azure Front Door-resurs, inklusive när åtgärden inträffade, vem som utförde den och vad åtgärden var.
Kommentar
Aktivitetsloggar innehåller inte läsåtgärder. De kanske inte heller innehåller alla åtgärder som du utför med hjälp av antingen Azure Portal eller klassiska hanterings-API:er.
Mer information finns i Visa dina aktivitetsloggar.
Nästa steg
Information om hur du aktiverar och lagrar diagnostikloggar finns i Konfigurera Azure Front Door-loggar.
Viktigt!
Azure Front Door (klassisk) dras tillbaka den 31 mars 2027. För att undvika avbrott i tjänsten är det viktigt att du migrerar dina Azure Front Door-profiler (klassiska) till Azure Front Door Standard- eller Premium-nivån senast i mars 2027. Mer information finns i Azure Front Door (klassisk) tillbakadragning.
När du använder Azure Front Door (klassisk) kan du övervaka resurser på följande sätt:
- Mått. Azure Front Door har för närvarande åtta mått för att visa prestandaräknare.
- Loggar. Med aktivitets- och diagnostikloggar kan prestanda, åtkomst och andra data sparas eller förbrukas från en resurs i övervakningssyfte.
Mått
Mått är en funktion för vissa Azure-resurser som gör att du kan visa prestandaräknare i portalen. Följande är tillgängliga Front Door-mått:
| Mått | Måttvisningsnamn | Enhet | Dimensioner | beskrivning |
|---|---|---|---|---|
| RequestCount | Antal begäranden | Antal | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Antalet klientbegäranden som hanteras av Front Door. |
| RequestSize | Begärandestorlek | Byte | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Antalet byte som skickas som begäranden från klienter till Front Door. |
| ResponseSize | Svarsstorlek | Byte | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Antalet byte som skickas som svar från Front Door till klienter. |
| TotalLatency | Total svarstid | Millisekunder | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Den totala tiden från klientbegäran som tagits emot av Front Door till det senaste svarsbytet som skickades från AFD till klienten. |
| BackendRequestCount | Antal serverdelsbegäranden | Antal | HttpStatus HttpStatusGroup-serverdel |
Antalet begäranden som skickas från Front Door till serverdelar. |
| BackendRequestLatency | Svarstid för serverdelsbegäran | Millisekunder | Serverdel | Den tid som beräknades från när begäran skickades av Front Door till serverdelen tills Front Door tog emot det sista svarsbytet från serverdelen. |
| BackendHealthPercentage | Procent för serverdelshälsa | Procent | Backend BackendPool |
Procentandelen lyckade hälsoavsökningar från Front Door till serverdelar. |
| WebApplicationFirewallRequestCount | Antal begäranden för brandvägg för webbaserade program | Antal | PolicyName RuleName-åtgärd |
Antalet klientbegäranden som bearbetas av programnivåsäkerheten i Front Door. |
Aktivitetsloggar
Aktivitetsloggar innehåller information om de åtgärder som utförs i en Azure Front Door-profil (klassisk). De avgör också vad, vem och när för skrivåtgärder (placera, publicera eller ta bort) som görs mot en Azure Front Door-profil (klassisk).
Kommentar
Om en begäran till ursprunget överskrider tidsgränsen anges värdet för HttpStatusCode till 0.
Åtkomst till aktivitetsloggar i din Front Door eller alla loggar för dina Azure-resurser i Azure Monitor. Så här visar du aktivitetsloggar:
Välj din Front Door-instans.
Välj Aktivitetslogg.
Välj ett filtreringsomfång och välj sedan Använd.
Kommentar
Aktivitetsloggen innehåller inga GET-åtgärder eller åtgärder som du utför med hjälp av antingen Azure Portal eller det ursprungliga hanterings-API:et.
Diagnostikloggar
Diagnostikloggar innehåller omfattande information om åtgärder och fel som är viktiga för granskning och felsökning. Diagnostikloggar skiljer sig från aktivitetsloggar.
Aktivitetsloggar ger insikter om de åtgärder som utförs på Azure-resurser. Diagnostikloggar ger insikter om åtgärder som resursen har utfört. Mer information finns i Diagnostikloggar för Azure Monitor.
Så här konfigurerar du diagnostikloggar för Azure Front Door (klassisk):
Välj din Azure Front Door-profil (klassisk).
Välj Diagnostikinställningar.
Välj Aktivera diagnostik. Arkivera diagnostikloggar tillsammans med mått till ett lagringskonto, strömma dem till en händelsehubb eller skicka dem till Azure Monitor-loggar.
Front Door tillhandahåller för närvarande diagnostikloggar. Diagnostikloggar tillhandahåller enskilda API-begäranden med varje post med följande schema:
| Property | beskrivning |
|---|---|
| BackendHostname | Om begäran vidarebefordrades till en serverdel representerar det här fältet serverdelens värdnamn. Det här fältet är tomt om begäran omdirigeras eller vidarebefordras till en regional cache (när cachelagring aktiveras för routningsregeln). |
| CacheStatus | För cachelagringsscenarier definierar det här fältet cacheträffen/-missen på POP |
| ClientIp | IP-adressen för klienten som gjorde begäran. Om det fanns ett X-Forwarded-For-huvud i begäran, väljs klient-IP från samma. |
| ClientPort | IP-porten för klienten som gjorde begäran. |
| HttpMethod | HTTP-metod som används av begäran. |
| HttpStatusCode | HTTP-statuskoden som returneras från proxyn. Om en begäran till ursprunget överskrider tidsgränsen anges värdet för HttpStatusCode till 0. |
| HttpStatusDetails | Resulterande status för begäran. Innebörden av det här strängvärdet finns i en statusreferenstabell. |
| HttpVersion | Typ av begäran eller anslutning. |
| POP | Kort namn på gränsen där begäran landade. |
| RequestBytes | Storleken på HTTP-begärandemeddelandet i byte, inklusive begärandehuvudena och begärandetexten. |
| RequestUri | URI för den mottagna begäran. |
| ResponseBytes | Byte som skickas av serverdelsservern som svar. |
| RoutingRuleName | Namnet på routningsregeln som begäran matchade. |
| RulesEngineMatchNames | Namnen på de regler som begäran matchade. |
| SecurityProtocol | TLS/SSL-protokollversionen som används av begäran eller null om det inte finns någon kryptering. |
| SentToOriginShield (inaktuell) * Se anteckningar om utfasning i följande avsnitt. |
Om det är sant innebär det att begäran besvarades från ursprungssköldcachen i stället för kantpopen. Ursprungssköld är en överordnad cache som används för att förbättra cacheträffförhållandet. |
| isReceivedFromClient | Om det är sant innebär det att begäran kom från klienten. Om det är falskt är begäran en miss i gränsen (underordnad POP) och besvaras från ursprungsskölden (överordnad POP). |
| TimeTaken | Hur lång tid från första byte av begäran till Front Door till sista byte svar ut, i sekunder. |
| TrackingReference | Den unika referenssträngen som identifierar en begäran som hanteras av Front Door, som också skickas som X-Azure-Ref-huvud till klienten. Krävs för att söka efter information i åtkomstloggarna för en specifik begäran. |
| UserAgent | Webbläsartypen som klienten använde. |
| ErrorInfo | Det här fältet innehåller den specifika typen av fel för ytterligare felsökning. Möjliga värden är: NoError: Anger att inget fel hittades. CertificateError: Allmänt SSL-certifikatfel. CertificateNameCheckFailed: Värdnamnet i SSL-certifikatet är ogiltigt eller matchar inte. ClientDisconnected: Begärandefel på grund av klientnätverksanslutning. UnspecifiedClientError: Allmänt klientfel. InvalidRequest: Ogiltig begäran. Det kan inträffa på grund av felaktigt sidhuvud, brödtext och URL. DNSFailure: DNS-fel. DNSNameNotResolved: Servernamnet eller adressen kunde inte matchas. OriginConnectionAborted: Anslutningen till ursprunget stoppades plötsligt. OriginConnectionError: Allmänt anslutningsfel för ursprung. OriginConnectionRefused: Anslutningen till ursprunget kunde inte upprättas. OriginError: Allmänt ursprungsfel. OriginInvalidResponse: Origin returnerade ett ogiltigt eller okänt svar. OriginTimeout: Tidsgränsen för ursprungsbegäran har upphört att gälla. ResponseHeaderTooBig: Ursprunget returnerade för stort svarshuvud. RestrictedIP: Begäran blockerades på grund av begränsad IP-adress. SSLHandshakeError: Det går inte att upprätta en anslutning med ursprunget på grund av SSL-handskakningsfel. UnspecifiedError: Ett fel uppstod som inte passade in i något av felen i tabellen. SSLMismatchedSNI: Begäran var ogiltig eftersom HTTP-meddelandehuvudet inte matchade värdet som visas i TLS SNI-tillägget under SSL/TLS-anslutningskonfigurationen. |
| Result | SSLMismatchedSNI är en statuskod som innebär en lyckad begäran med en felmatchningsvarning mellan SNI och värdhuvudet. Den här statuskoden innebär domänfronting, en teknik som strider mot Azure Front Door-användarvillkoren. Begäranden med SSLMismatchedSNI avvisas efter den 22 januari 2024. |
| Sni | Det här fältet anger den servernamnsindikator (SNI) som skickas under handskakningen för TLS/SSL. Den kan användas för att identifiera det exakta SNI-värdet om det fanns en SSLMismatchedSNI statuskod. Dessutom kan det jämföras med värdvärdet i requestUri fältet för att identifiera och lösa felmatchningsproblemet. |
Skickas till utfasning av ursprungssköld
Egenskapen raw log isSentToOriginShield är inaktuell och ersätts av ett nytt fält isReceivedFromClient. Använd det nya fältet om du redan använder det inaktuella fältet.
Rådataloggar innehåller loggar som genererats från både CDN-gränsen (underordnad POP) och ursprungsskölden. Ursprungssköld refererar till överordnade noder som är strategiskt placerade över hela världen. Dessa noder kommunicerar med ursprungsservrar och minskar trafikbelastningen på ursprunget.
För varje begäran som går till en ursprungssköld finns det två loggposter:
- En för kantnoder
- En för ursprungssköld.
Om du vill skilja utgående eller svar från gränsnoderna jämfört med ursprungsskölden kan du använda fältet isReceivedFromClient för att hämta rätt data.
Om värdet är falskt innebär det att begäran besvaras från ursprungsskölden till kantnoder. Den här metoden är effektiv för att jämföra rådata med faktureringsdata. Avgifter debiteras inte för utgående från ursprungsskölden till kantnoderna. Avgifter tillkommer för utgående trafik från gränsnoderna till klienter.
Kusto-frågeexempel för att exkludera loggar som genererats på ursprungsskölden i Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Kommentar
För olika routningskonfigurationer och trafikbeteenden kan vissa av fälten som backendHostname, cacheStatus, isReceivedFromClient och POP-fältet svara med olika värden. I följande tabell förklaras de olika värden som dessa fält har för olika scenarier:
| Scenarier | Antal loggposter | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Routningsregel utan cachelagring aktiverat | 1 | Edge POP-kod | Serverdel där begäran vidarebefordrades | Sant | CONFIG_NOCACHE |
| Routningsregel med cachelagring aktiverat. Cacheträff vid gränsens POP | 1 | Edge POP-kod | Tomt | Sant | HIT |
| Routningsregel med cachelagring aktiverat. Cache missar vid edge POP men cachen träffar på överordnad cache POP | 2 | 1. Edge POP-kod 2. Pop-kod för överordnad cache |
1. Pop-värdnamn för överordnad cache 2. Tomt |
1. Sant 2. Falsk |
1. MISS 2. HIT |
| Routningsregel med cachelagring aktiverat. Cacheminnen missar vid edge POP men PARTIELL cacheträff vid överordnad cache-POP | 2 | 1. Edge POP-kod 2. Pop-kod för överordnad cache |
1. Pop-värdnamn för överordnad cache 2. Serverdel som hjälper till att fylla i cacheminnet |
1. Sant 2. Falsk |
1. MISS 2. PARTIAL_HIT |
| Routningsregel med cachelagring aktiverat. Cachelagring PARTIAL_HIT vid gränsens POP men cachen träffar på överordnad cache-POP | 2 | 1. Edge POP-kod 2. Pop-kod för överordnad cache |
1. Edge POP-kod 2. Pop-kod för överordnad cache |
1. Sant 2. Falsk |
1. PARTIAL_HIT 2. HIT |
| Routningsregel med cachelagring aktiverat. Cachemissar vid både gränsen och överordnad cache-POP | 2 | 1. Edge POP-kod 2. Pop-kod för överordnad cache |
1. Edge POP-kod 2. Pop-kod för överordnad cache |
1. Sant 2. Falsk |
1. MISS 2. FRÖKEN |
| Det gick inte att bearbeta begäran | Inte tillgänglig |
Kommentar
För cachelagringsscenarier blir värdet för cachestatus partial_hit när vissa byte för en begäran hanteras från Azure Front Door-gränsen eller ursprungssköldcachen medan vissa byte hanteras från ursprunget för stora objekt.
Azure Front Door använder en teknik som kallas objektsegmentering. När en stor fil begärs hämtar Azure Front Door mindre delar av filen från ursprunget. När Azure Front Door POP-servern har fått ett fullständigt intervall eller byteintervall för den begärda filen begär Azure Front Door Edge-servern filen från ursprunget i segment på 8 MB.
När segmentet har anlänt till Azure Front Door-gränsen cachelagras det och hanteras omedelbart av användaren. Azure Front Door förinstallerar sedan nästa segment parallellt. Den här prefetchen säkerställer att innehållet ligger ett segment före användaren, vilket minskar svarstiden. Den här processen fortsätter tills hela filen laddas ned (om det begärs), alla byteintervall är tillgängliga (om det begärs) eller så stänger klienten anslutningen. Mer information om byteintervallbegäran finns i RFC 7233. Azure Front Door cachelagrar eventuella segment när de tas emot. Hela filen behöver inte cachelagras i Front Door-cachen. Efterföljande begäranden för filen eller byteintervallen hanteras från Azure Front Door-cachen. Om inte alla segment cachelagras på Azure Front Door används prefetch för att begära segment från ursprunget. Den här optimeringen bygger på ursprungsserverns förmåga att stödja byteintervallbegäranden. Om ursprungsservern inte stöder byteintervallbegäranden är den här optimeringen inte effektiv.