Azure Front Door bewaken
Azure Monitor verzamelt en aggregeert metrische gegevens en logboeken van uw systeem om de beschikbaarheid, prestaties en tolerantie te bewaken en u op de hoogte te stellen van problemen die van invloed zijn op uw systeem. U kunt de Azure-portal, PowerShell, Azure CLI, REST API of clientbibliotheken gebruiken om bewakingsgegevens in te stellen en weer te geven.
Er zijn verschillende metrische gegevens en logboeken beschikbaar voor verschillende resourcetypen. In dit artikel worden de typen bewakingsgegevens beschreven die u voor deze service kunt verzamelen en manieren om die gegevens te analyseren.
Rapporten bieden inzicht in hoe uw verkeer stroomt via Azure Front Door, de Web Application Firewall (WAF) en uw toepassing.
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.
Gegevens verzamelen met Azure Monitor
In deze tabel wordt beschreven hoe u gegevens kunt verzamelen om uw service te bewaken en wat u kunt doen met de gegevens die eenmaal zijn verzameld:
| Te verzamelen gegevens | Beschrijving | De gegevens verzamelen en routeren | Waar de gegevens worden weergegeven | Ondersteunde gegevens |
|---|---|---|---|---|
| Metrische gegevens | Metrische gegevens zijn numerieke waarden die een aspect van een systeem op een bepaald moment beschrijven. Metrische gegevens kunnen worden geaggregeerd met behulp van algoritmen, vergeleken met andere metrische gegevens en geanalyseerd op trends in de loop van de tijd. | - Automatisch verzameld met regelmatige tussenpozen. - U kunt bepaalde metrische platformgegevens omleiden naar een Log Analytics-werkruimte om query's uit te voeren op andere gegevens. Controleer de DS-exportinstelling voor elke metriek om te zien of u een diagnostische instelling kunt gebruiken om de metrische gegevens te routeren. |
Metrics Explorer | Metrische gegevens van Azure Front Door die worden ondersteund door Azure Monitor |
| Resourcelogboekgegevens | Logboeken worden systeemevenementen vastgelegd met een tijdstempel. Logboeken kunnen verschillende typen gegevens bevatten en gestructureerde of vrije tekst zijn. U kunt resourcelogboekgegevens routeren naar Log Analytics-werkruimten voor het uitvoeren van query's en analyses. | Maak een diagnostische instelling voor het verzamelen en routeren van resourcelogboekgegevens. | Log Analytics | Azure Front Door-resourcelogboekgegevens die worden ondersteund door Azure Monitor |
| Activiteitenlogboekgegevens | Het Activiteitenlogboek van Azure Monitor biedt inzicht in gebeurtenissen op abonnementsniveau. Het activiteitenlogboek bevat informatie zoals wanneer een resource wordt gewijzigd of wanneer een virtuele machine wordt gestart. | - Automatisch verzameld. - Maak gratis een diagnostische instelling voor een Log Analytics-werkruimte. |
Activiteitenlogboek |
Zie voor de lijst met alle gegevens die worden ondersteund door Azure Monitor:
Ingebouwde bewaking voor Azure Front Door
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 deze waarde 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 deze waarde 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 zijn bijgewerkt naar WebSocket, 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 Azure Front Door-cache de aanvraag verwerkt. Mogelijke waarden zijn:
|
| MatchedRulesSetName | De namen van de regelengineregels die zijn verwerkt. |
| RouteName | De naam van de route die overeenkomt met de aanvraag. |
| ClientPort | De IP-poort van de client die de aanvraag heeft ingediend. |
| Referrer | De URL van de site die afkomstig is van de aanvraag. |
| TimetoFirstByte | De tijdsduur, in seconden, vanaf het moment waarop de Edge van Azure Front Door de aanvraag heeft ontvangen tot de tijd dat de eerste byte naar de client werd verzonden, zoals gemeten door Azure Front Door. Met deze eigenschap worden de clientgegevens niet gemeten. |
| ErrorInfo | Als er een fout is opgetreden tijdens de verwerking van de aanvraag, bevat dit veld gedetailleerde informatie over de fout. Mogelijke waarden zijn:
|
| OriginURL | De volledige URL van de oorsprong waar de aanvraag is verzonden. De URL bestaat uit het schema, de hostheader, de poort, het pad en de querytekenreeks. URL herschrijven: als de regelengine de aanvraag-URL herschrijft, 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 ziet bijvoorbeeld 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 FQDN. |
| 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 FQDN 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).
Voor klassieke Azure Front Door bevat ingebouwde bewaking diagnostische logboeken.
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 doet. Zie diagnostische logboeken van Azure Monitor voor meer informatie.
Diagnostische logboeken configureren voor uw Azure Front Door (klassiek):
Selecteer uw Azure Front Door-profiel (klassiek).
Kies Diagnostische instellingen.
Selecteer Diagnostische gegevens inschakelen. Archiveer diagnostische logboeken samen met metrische gegevens naar een opslagaccount, stream ze naar een Event Hub of verzend ze naar Azure Monitor-logboeken.
Front Door biedt momenteel diagnostische logboeken. Diagnostische logboeken bieden afzonderlijke API-aanvragen met elk item met het volgende schema:
| Eigenschappen | Beschrijving |
|---|---|
| BackendHostname | Als de aanvraag wordt doorgestuurd naar een back-end, vertegenwoordigt dit veld de hostnaam van de back-end. Dit veld is leeg als de aanvraag wordt omgeleid of doorgestuurd naar een regionale cache (wanneer caching wordt ingeschakeld voor de routeringsregel). |
| CacheStatus | Voor cachescenario's definieert dit veld de cachetreffer/miss in de POP |
| ClientIp | Het IP-adres van de client die de aanvraag heeft ingediend. Als er een X-Forwarded-For-header in de aanvraag was, wordt het CLIENT-IP-adres uit hetzelfde gekozen. |
| ClientPort | De IP-poort van de client die de aanvraag heeft ingediend. |
| HttpMethod | De HTTP-methode die wordt gebruikt door de aanvraag. |
| HttpStatusCode | De HTTP-statuscode die is geretourneerd door de proxy. Als er een time-out optreedt voor een aanvraag voor de oorsprong, wordt de waarde voor HttpStatusCode ingesteld op 0. |
| HttpStatusDetails | Resulterende status van de aanvraag. De betekenis van deze tekenreekswaarde vindt u in een statusreferentietabel. |
| HttpVersion | Type aanvraag of verbinding. |
| POP | Korte naam van de rand waar de aanvraag is geland. |
| RequestBytes | De grootte van het HTTP-aanvraagbericht in bytes, inclusief de aanvraagheaders en de aanvraagbody. |
| RequestUri | URI van de ontvangen aanvraag. |
| ResponseBytes | Bytes die door de back-endserver worden verzonden als antwoord. |
| RoutingRuleName | De naam van de routeringsregel die overeenkomt met de aanvraag. |
| RulesEngineMatchNames | De namen van de regels die overeenkomen met de aanvraag. |
| SecurityProtocol | De TLS/SSL-protocolversie die wordt gebruikt door de aanvraag of null als er geen versleuteling is. |
| SentToOriginShield (afgeschaft) * Zie de opmerkingen over afschaffing in de volgende sectie. |
Als waar, betekent dit dat de aanvraag is beantwoord vanuit de origin shield-cache in plaats van de edge pop. Origin Shield is een bovenliggende cache die wordt gebruikt om de verhouding tussen cachetreffers te verbeteren. |
| isReceivedFromClient | Indien waar, betekent dit dat de aanvraag afkomstig is van de client. Als dit onwaar is, is de aanvraag een misser in de rand (onderliggende POP) en wordt er gereageerd vanaf het oorspronkelijke schild (bovenliggende POP). |
| TimeTaken | De tijdsduur van de eerste byte van aanvraag in Front Door tot laatste byte van reactie, in seconden. |
| TrackingReference | De unieke referentietekenreeks die een aanvraag identificeert die wordt geleverd door Front Door, ook verzonden als X-Azure-Ref-header naar de client. Vereist voor het zoeken naar details in de toegangslogboeken voor een specifieke aanvraag. |
| UserAgent | Het browsertype dat de client heeft gebruikt. |
| ErrorInfo | Dit veld bevat het specifieke type fout voor verdere probleemoplossing.
Mogelijke waarden zijn: NoError: Geeft aan dat er geen fout is gevonden. CertificateError: Algemene SSL-certificaatfout. CertificateNameCheckFailed: de hostnaam in het SSL-certificaat is ongeldig of komt niet overeen. ClientDisconnected: aanvraagfout vanwege clientnetwerkverbinding. UnspecifiedClientError: Algemene clientfout. InvalidRequest: Ongeldige aanvraag. Dit kan optreden vanwege ongeldige headers, hoofdteksten en URL's. DNSFailure: DNS-fout. DNSNameNotResolved: de servernaam of het adres kan niet worden omgezet. OriginConnectionAborted: De verbinding met de oorsprong is plotseling gestopt. OriginConnectionError: Algemene verbindingsfout voor oorsprong. OriginConnectionRefused: De verbinding met de oorsprong kon niet tot stand worden gebracht. OriginError: Algemene oorsprongsfout. OriginInvalidResponse: Origin heeft een ongeldig of niet-herkend antwoord geretourneerd. OriginTimeout: de time-outperiode voor de oorspronkelijke aanvraag is verlopen. ResponseHeaderTooBig: De oorsprong heeft te groot geretourneerd van een antwoordheader. RestrictedIP: de aanvraag is geblokkeerd vanwege een beperkt IP-adres. SSLHandshakeError: kan geen verbinding maken met de oorsprong vanwege een SSL-handshakefout. UnspecifiedError: er is een fout opgetreden die niet in een van de fouten in de tabel past. SSLMismatchedSNI: de aanvraag is ongeldig omdat de HTTP-berichtkop niet overeenkomt met de waarde die wordt weergegeven in de TLS SNI-extensie tijdens het instellen van de SSL/TLS-verbinding. |
| Resultaat |
SSLMismatchedSNI is een statuscode waarmee een geslaagde aanvraag wordt aangegeven met een waarschuwing over niet-overeenkomende waarden tussen de SNI en de hostheader. Deze statuscode impliceert domeinfronting, een techniek die de servicevoorwaarden van Azure Front Door schendt. Aanvragen met SSLMismatchedSNI worden geweigerd na 22 januari 2024. |
| Sni | Dit veld geeft de servernaamindicatie (SNI) op die wordt verzonden tijdens de TLS/SSL-handshake. Deze kan worden gebruikt om de exacte SNI-waarde te identificeren als er een SSLMismatchedSNI statuscode is. Daarnaast kan het worden vergeleken met de hostwaarde in het requestUri veld om het probleem met niet-overeenkomende items te detecteren en op te lossen. |
Verzonden naar afschaffing van oorsprongsschild
De onbewerkte logboekeigenschap isSentToOriginShield is afgeschaft en vervangen door een nieuw veld isReceivedFromClient. Gebruik het nieuwe veld als u het afgeschafte veld al gebruikt.
Onbewerkte logboeken bevatten logboeken die zijn gegenereerd op basis van zowel CDN Edge (onderliggende POP) als origin shield. Oorsprongsschild verwijst naar bovenliggende knooppunten die strategisch over de hele wereld zijn gelegen. Deze knooppunten communiceren met oorspronkelijke servers en verminderen de belasting van het verkeer op de oorsprong.
Voor elke aanvraag die naar een oorsprongsschild gaat, zijn er twee logboekvermeldingen:
- Eén voor edge-knooppunten
- Een voor oorsprongsschild
U kunt het veld isReceivedFromClient gebruiken om de juiste gegevens op te halen om het uitgangspunt of de antwoorden van de edge-knooppunten te onderscheiden van de edge-knooppunten versus het oorsprongsschild.
Als de waarde onwaar is, betekent dit dat de aanvraag wordt gereageerd van oorsprongsschild naar edge-knooppunten. Deze methode is effectief om onbewerkte logboeken te vergelijken met factureringsgegevens. Er worden geen kosten in rekening gebracht voor uitgaand verkeer van oorsprongsschild naar de edge-knooppunten. Er worden kosten in rekening gebracht voor uitgaand verkeer van de edge-knooppunten naar clients.
Kusto-queryvoorbeeld voor het uitsluiten van logboeken die zijn gegenereerd op het oorspronkelijke schild in Log Analytics.
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
Notitie
Voor verschillende routeringsconfiguraties en verkeersgedrag kunnen sommige velden, zoals backendHostname, cacheStatus, isReceivedFromClient en POP-veld reageren met verschillende waarden. In de volgende tabel worden de verschillende waarden voor deze velden voor verschillende scenario's uitgelegd:
| Scenario's | Aantal logboekvermeldingen | POP | BackendHostname | isReceivedFromClient | CacheStatus |
|---|---|---|---|---|---|
| Routeringsregel zonder caching ingeschakeld | 1 | Edge POP-code | Back-end waar de aanvraag is doorgestuurd | Waar | CONFIG_NOCACHE |
| Routeringsregel waarvoor caching is ingeschakeld. Cache bereikt op de edge POP | 1 | Edge POP-code | Leeg | Waar | HIT |
| Routeringsregel waarvoor caching is ingeschakeld. Cache mist bij edge POP, maar cache raakt op bovenliggende cache POP | 2 | 1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Bovenliggende cache POP-hostnaam 2. Leeg |
1. Waar 2. Onwaar |
1. MISS 2. HIT |
| Routeringsregel waarvoor caching is ingeschakeld. Caches missen bij edge POP, maar GEDEELTELIJKE cache hit bij bovenliggende cache POP | 2 | 1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Bovenliggende cache POP-hostnaam 2. Back-end waarmee de cache wordt gevuld |
1. Waar 2. Onwaar |
1. MISS 2. PARTIAL_HIT |
| Routeringsregel waarvoor caching is ingeschakeld. Cache PARTIAL_HIT bij edge POP, maar cache hit bij bovenliggende cache POP | 2 | 1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Waar 2. Onwaar |
1. PARTIAL_HIT 2. HIT |
| Routeringsregel waarvoor caching is ingeschakeld. Cache mist zowel edge- als bovenliggende cache POP | 2 | 1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Edge POP-code 2. POP-code voor bovenliggende cache |
1. Waar 2. Onwaar |
1. MISS 2. MISSEN |
| Fout bij het verwerken van de aanvraag | N.v.t. |
Notitie
Voor cachescenario's is de waarde voor cachestatus een PARTIAL_HIT wanneer sommige van de bytes voor een aanvraag worden geleverd vanuit de Azure Front Door-edge 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.
Azure Monitor-hulpprogramma's gebruiken om de gegevens te analyseren
Deze Azure Monitor-hulpprogramma's zijn beschikbaar in Azure Portal om u te helpen bij het analyseren van bewakingsgegevens:
Sommige Azure-services hebben een ingebouwd bewakingsdashboard in Azure Portal. Deze dashboards worden inzichten genoemd en u kunt ze vinden in de sectie Inzichten van Azure Monitor in Azure Portal.
Met Metrics Explorer kunt u metrische gegevens voor Azure-resources weergeven en analyseren. Zie Metrische gegevens analyseren met Azure Monitor Metrics Explorer voor meer informatie.
Met Log Analytics kunt u logboekgegevens opvragen en analyseren met behulp van de Kusto-querytaal (KQL). Zie Aan de slag met logboekquery's in Azure Monitor voor meer informatie.
Azure Portal heeft een gebruikersinterface voor het weergeven en eenvoudig doorzoeken van het activiteitenlogboek. Als u uitgebreidere analyses wilt uitvoeren, stuurt u de gegevens door naar Azure Monitor-logboeken en voert u complexere query's uit in Log Analytics.
Application Insights bewaakt de beschikbaarheid, prestaties en het gebruik van uw webtoepassingen, zodat u fouten kunt identificeren en diagnosticeren zonder te wachten tot een gebruiker deze rapporteert.
Application Insights bevat verbindingspunten voor verschillende ontwikkelhulpprogramma's en kan worden geïntegreerd met Visual Studio ter ondersteuning van uw DevOps-processen. Zie Toepassingsbewaking voor App Service voor meer informatie.
Hulpprogramma's waarmee complexere visualisaties mogelijk zijn, zijn onder andere:
- Dashboards waarmee u verschillende soorten gegevens kunt combineren in één deelvenster in Azure Portal.
- Werkmappen, aanpasbare rapporten die u kunt maken in Azure Portal. Werkmappen kunnen tekst, metrische gegevens en logboekquery's bevatten.
- Grafana, een open platformhulpprogramma dat excelleert in operationele dashboards. U kunt Grafana gebruiken om dashboards te maken die gegevens uit meerdere andere bronnen dan Azure Monitor bevatten.
- Power BI, een business analytics-service die interactieve visualisaties biedt in verschillende gegevensbronnen. U kunt Power BI zo configureren dat logboekgegevens automatisch vanuit Azure Monitor worden geïmporteerd om te profiteren van deze visualisaties.
Azure Monitor-gegevens exporteren
U kunt gegevens uit Azure Monitor exporteren naar andere hulpprogramma's met behulp van:
Metrische gegevens: gebruik de REST API voor metrische gegevens om metrische gegevens te extraheren uit de metrische Azure Monitor-database. Zie azure Monitor REST API-naslaginformatie voor meer informatie.
Logboeken: Gebruik de REST API of de bijbehorende clientbibliotheken.
De gegevensexport van de Log Analytics-werkruimte.
Als u aan de slag wilt gaan met de Rest API van Azure Monitor, raadpleegt u de stapsgewijze instructies voor Azure Monitoring REST API.
Kusto-query's gebruiken om logboekgegevens te analyseren
U kunt Azure Monitor-logboekgegevens analyseren met behulp van de Kusto-querytaal (KQL). Zie Logboekquery's in Azure Monitor voor meer informatie.
Azure Monitor-waarschuwingen gebruiken om u op de hoogte te stellen van problemen
Met Azure Monitor-waarschuwingen kunt u problemen in uw systeem identificeren en oplossen, en u proactief op de hoogte stellen wanneer er specifieke voorwaarden worden gevonden in uw bewakingsgegevens voordat uw klanten ze opmerken. U kunt een waarschuwing ontvangen voor elke metrische gegevensbron of logboekgegevensbron in het Azure Monitor-gegevensplatform. Er zijn verschillende soorten Azure Monitor-waarschuwingen , afhankelijk van de services die u bewaakt en de bewakingsgegevens die u verzamelt. Zie Het kiezen van het juiste type waarschuwingsregel.
Zie Voorbeeldquery's voor logboekwaarschuwingen voor voorbeelden van veelvoorkomende waarschuwingen voor Azure-resources.
Waarschuwingen op schaal implementeren
Voor sommige services kunt u op schaal bewaken door dezelfde waarschuwingsregel voor metrische gegevens toe te passen op meerdere resources van hetzelfde type dat in dezelfde Azure-regio aanwezig is. Azure Monitor Baseline Alerts (AMBA) biedt een semi-geautomatiseerde methode voor het implementeren van belangrijke metrische platformwaarschuwingen, dashboards en richtlijnen op schaal.
Persoonlijke aanbevelingen krijgen met Behulp van Azure Advisor
Voor sommige services, als er kritieke omstandigheden of aanstaande wijzigingen optreden tijdens resourcebewerkingen, wordt een waarschuwing weergegeven op de pagina Serviceoverzicht in de portal. Meer informatie en aanbevolen oplossingen voor de waarschuwing vindt u in Advisor-aanbevelingen onder Bewaking in het linkermenu. Tijdens normale bewerkingen worden er geen aanbevelingen van advisor weergegeven.
Zie het overzicht van Azure Advisor voor meer informatie over Azure Advisor.