Övervaka Azure Front Door
Azure Monitor samlar in och aggregerar mått och loggar från systemet för att övervaka tillgänglighet, prestanda och motståndskraft och meddela dig om problem som påverkar systemet. Du kan använda Azure Portal, PowerShell, Azure CLI, REST API eller klientbibliotek för att konfigurera och visa övervakningsdata.
Olika mått och loggar är tillgängliga för olika resurstyper. Den här artikeln beskriver de typer av övervakningsdata som du kan samla in för den här tjänsten och hur du analyserar dessa data.
Rapporter ger insikter om hur trafiken flödar genom Azure Front Door, brandväggen för webbprogram (WAF) och till ditt program.
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.
Samla in data med Azure Monitor
Den här tabellen beskriver hur du kan samla in data för att övervaka din tjänst och vad du kan göra med data när de har samlats in:
| Data som ska samlas in | beskrivning | Så här samlar du in och dirigerar data | Var du kan visa data | Data som stöds |
|---|---|---|---|---|
| Måttdata | Mått är numeriska värden som beskriver en aspekt av ett system vid en viss tidpunkt. Mått kan aggregeras med hjälp av algoritmer, jämfört med andra mått, och analyseras för trender över tid. | - Samlas in automatiskt med jämna mellanrum. – Du kan dirigera vissa plattformsmått till en Log Analytics-arbetsyta för att fråga med andra data. Kontrollera DS-exportinställningen för varje mått för att se om du kan använda en diagnostikinställning för att dirigera måttdata. |
Metrics Explorer | Azure Front Door-mått som stöds av Azure Monitor |
| Resursloggdata | Loggar är registrerade systemhändelser med en tidsstämpel. Loggar kan innehålla olika typer av data och vara strukturerade eller friformstext. Du kan dirigera resursloggdata till Log Analytics-arbetsytor för frågor och analys. | Skapa en diagnostikinställning för att samla in och dirigera resursloggdata. | Log Analytics | Azure Front Door-resursloggdata som stöds av Azure Monitor |
| Aktivitetsloggdata | Azure Monitor-aktivitetsloggen ger insikter om händelser på prenumerationsnivå. Aktivitetsloggen innehåller till exempel information om när en resurs ändras eller när en virtuell dator startas. | - Samlas in automatiskt. - Skapa en diagnostikinställning till en Log Analytics-arbetsyta utan kostnad. |
Aktivitetslogg |
Listan över alla data som stöds av Azure Monitor finns i:
Inbyggd övervakning för Azure Front Door
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 det här värdet 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 det här värdet 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 | Så hanterar Azure Front Door-cachen begäran. 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 regelmotorn skriver om begärande-URL:en 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 märker 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 ursprung har konfigurerats för att använda ett FQDN. |
| 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 är konfigurerat till ett FQDN 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.
För klassisk Azure Front Door innehåller inbyggd övervakning diagnostikloggar.
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 utför. 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 är värdet för cachestatus en 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.
Använda Azure Monitor-verktyg för att analysera data
Dessa Azure Monitor-verktyg är tillgängliga i Azure Portal som hjälper dig att analysera övervakningsdata:
Vissa Azure-tjänster har en inbyggd instrumentpanel för övervakning i Azure Portal. Dessa instrumentpaneler kallas insikter och du hittar dem i avsnittet Insikter i Azure Monitor i Azure Portal.
Med Metrics Explorer kan du visa och analysera mått för Azure-resurser. Mer information finns i Analysera mått med Azure Monitor Metrics Explorer.
Med Log Analytics kan du fråga och analysera loggdata med hjälp av KQL (Kusto Query Language). Mer information finns i Kom igång med loggfrågor i Azure Monitor.
Azure Portal har ett användargränssnitt för visning och grundläggande sökningar i aktivitetsloggen. Om du vill göra mer djupgående analys dirigerar du data till Azure Monitor-loggar och kör mer komplexa frågor i Log Analytics.
Application Insights övervakar tillgänglighet, prestanda och användning av dina webbprogram, så att du kan identifiera och diagnostisera fel utan att vänta på att en användare ska rapportera dem.
Application Insights innehåller anslutningspunkter till olika utvecklingsverktyg och integreras med Visual Studio för att stödja dina DevOps-processer. Mer information finns i Programövervakning för App Service.
Verktyg som möjliggör mer komplex visualisering är:
- Instrumentpaneler som gör att du kan kombinera olika typer av data i ett enda fönster i Azure Portal.
- Arbetsböcker, anpassningsbara rapporter som du kan skapa i Azure Portal. Arbetsböcker kan innehålla text-, mått- och loggfrågor.
- Grafana, ett öppet plattformsverktyg som utmärker sig i operativa instrumentpaneler. Du kan använda Grafana för att skapa instrumentpaneler som innehåller data från flera andra källor än Azure Monitor.
- Power BI, en tjänst för affärsanalys som tillhandahåller interaktiva visualiseringar mellan olika datakällor. Du kan konfigurera Power BI för att automatiskt importera loggdata från Azure Monitor för att dra nytta av dessa visualiseringar.
Exportera Azure Monitor-data
Du kan exportera data från Azure Monitor till andra verktyg med hjälp av:
Mått: Använd REST-API:et för mått för att extrahera måttdata från Azure Monitor-måttdatabasen. Mer information finns i Azure Monitor REST API-referens.
Loggar: Använd REST-API:et eller de associerade klientbiblioteken.
Dataexporten för Log Analytics-arbetsytan.
Information om hur du kommer igång med REST API :et för Azure Monitor finns i Genomgång av REST API för Azure-övervakning.
Använda Kusto-frågor för att analysera loggdata
Du kan analysera Azure Monitor-loggdata med hjälp av Kusto-frågespråket (KQL). Mer information finns i Logga frågor i Azure Monitor.
Använda Azure Monitor-aviseringar för att meddela dig om problem
Med Azure Monitor-aviseringar kan du identifiera och åtgärda problem i systemet och proaktivt meddela dig när specifika villkor finns i dina övervakningsdata innan kunderna märker dem. Du kan avisera om valfritt mått eller loggdatakälla på Azure Monitor-dataplattformen. Det finns olika typer av Azure Monitor-aviseringar beroende på vilka tjänster du övervakar och vilka övervakningsdata du samlar in. Se Välja rätt typ av aviseringsregel.
Exempel på vanliga aviseringar för Azure-resurser finns i Exempelloggaviseringsfrågor.
Implementera aviseringar i stor skala
För vissa tjänster kan du övervaka i stor skala genom att tillämpa samma måttaviseringsregel på flera resurser av samma typ som finns i samma Azure-region. Azure Monitor Baseline Alerts (AMBA) tillhandahåller en halvautomatiserad metod för att implementera viktiga plattformsmåttaviseringar, instrumentpaneler och riktlinjer i stor skala.
Få anpassade rekommendationer med Hjälp av Azure Advisor
För vissa tjänster, om kritiska villkor eller överhängande ändringar inträffar under resursåtgärder, visas en avisering på sidan Tjänstöversikt i portalen. Du hittar mer information och rekommenderade korrigeringar för aviseringen i Advisor-rekommendationer under Övervakning i den vänstra menyn. Under normal drift visas inga advisor-rekommendationer.
Mer information om Azure Advisor finns i Översikt över Azure Advisor.