Diagnostische logboeken voor Application Gateway
Application Gateway-logboeken bieden gedetailleerde informatie over gebeurtenissen met betrekking tot een resource en de bijbehorende bewerkingen. Deze logboeken zijn beschikbaar voor gebeurtenissen zoals Toegang, Activiteit, Firewall en Prestaties (alleen voor V1). De gedetailleerde informatie in logboeken is handig bij het oplossen van een probleem of het bouwen van een analysedashboard door deze onbewerkte gegevens te gebruiken.
Logboeken zijn beschikbaar voor alle resources van Application Gateway; Als u ze echter wilt gebruiken, moet u hun verzameling inschakelen op een opslaglocatie van uw keuze. Aanmelden bij Azure-toepassing Gateway is ingeschakeld door de Azure Monitor-service. U wordt aangeraden de Log Analytics-werkruimte te gebruiken, omdat u de vooraf gedefinieerde query's gemakkelijk kunt gebruiken en waarschuwingen kunt instellen op basis van specifieke logboekvoorwaarden.
Typen diagnostische logboeken
U kunt verschillende typen logboeken in Azure gebruiken om toepassingsgateways te beheren en problemen met toepassingsgateways op te lossen. Hieronder vindt u meer informatie over deze typen:
- Activiteitenlogboek: U kunt Azure-activiteitenlogboeken (voorheen operationele logboeken en auditlogboeken genoemd) gebruiken om alle bewerkingen weer te geven die zijn verzonden naar uw Azure-abonnement en hun status. Activiteitenlogboekitems worden standaard verzameld en kunnen in de Azure-portal worden bekeken.
- Toegangslogboek: U kunt dit logboek gebruiken om toegangspatronen voor Application Gateway weer te geven en belangrijke informatie te analyseren. Dit omvat het IP-adres van de aanroeper, aangevraagde URL, reactielatentie, retourcode en bytes in en uit. Er wordt elke 60 seconden een toegangslogboek verzameld. Dit logboek bevat één record per exemplaar van Application Gateway. Het Application Gateway-exemplaar wordt geïdentificeerd door de eigenschap instanceId.
- Prestatielogboek: U kunt dit logboek gebruiken om te bekijken hoe Application Gateway-exemplaren presteren. In dit logboek worden prestatiegegevens vastgelegd voor elk exemplaar, inclusief het totale aantal aanvragen, de doorvoer in bytes, het totale aantal aanvragen, het aantal mislukte aanvragen en het aantal gezonde en beschadigde back-endinstanties. Er wordt elke 60 seconden een prestatielogboek verzameld. Het prestatielogboek is alleen beschikbaar voor de v1-SKU. Voor de v2-SKU gebruikt u Metrische gegevens voor prestatiegegevens.
- Firewalllogboek: U kunt dit logboek gebruiken om de aanvragen weer te geven die zijn geregistreerd via de detectie- of preventiemodus van een toepassingsgateway die is geconfigureerd met de firewall van de webtoepassing. Firewalllogboeken worden elke 60 seconden verzameld.
Notitie
Logboeken zijn alleen beschikbaar voor resources die zijn geïmplementeerd in het Azure Resource Manager-implementatiemodel. U kunt geen logboeken gebruiken voor resources in het klassieke implementatiemodel. Zie het artikel Over resource manager-implementatie en klassieke implementatie voor een beter begrip van de twee modellen.
Opslaglocaties
U hebt de volgende opties om de logboeken op uw voorkeurslocatie op te slaan.
Log Analytics-werkruimte: met deze optie kunt u de vooraf gedefinieerde query's, visualisaties en waarschuwingen instellen op basis van specifieke logboekvoorwaarden. De tabellen die worden gebruikt door resourcelogboeken in de Log Analytics-werkruimte, zijn afhankelijk van het type verzameling dat de resource gebruikt:
Diagnostische gegevens van Azure: gegevens worden naar de Azure Diagnostics-tabel geschreven. Azure Diagnostics-tabel wordt gedeeld tussen meerdere resourcetypen, waarbij ze elk hun eigen aangepaste velden toevoegen. Wanneer het aantal aangepaste velden dat is opgenomen in de Azure Diagnostics-tabel groter is dan 500, worden nieuwe velden niet als het hoogste niveau toegevoegd, maar toegevoegd aan het veld AdditionalFields als waardeparen voor dynamische sleutels.
Resourcespecifiek (aanbevolen): gegevens worden naar toegewezen tabellen geschreven voor elke categorie van de resource. In de resourcespecifieke modus wordt aan elke logboekcategorie die in de diagnostische instelling is geselecteerd, een eigen tabel toegewezen in de gekozen werkruimte. Dit heeft verschillende voordelen, waaronder:
- Eenvoudiger gegevensmanipulatie in logboekquery's
- Verbeterde detectie van schema's en hun structuren
- Verbeterde prestaties in termen van opnamelatentie en querytijden
- De mogelijkheid om op rollen gebaseerd toegangsbeheer van Azure toe te wijzen aan specifieke tabellen
Voor Application Gateway maakt de resourcespecifieke modus drie tabellen:
Notitie
De resourcespecifieke optie is momenteel beschikbaar in alle openbare regio's.
Bestaande gebruikers kunnen Azure Diagnostics blijven gebruiken of ervoor kiezen om toegewezen tabellen te gebruiken door de wisselknop in diagnostische instellingen over te zetten op Resourcespecifiek of op Toegewezen in API-bestemming. Dual-modus is niet mogelijk. De gegevens in alle logboeken kunnen stromen naar Azure Diagnostics of naar toegewezen tabellen. U kunt echter meerdere diagnostische instellingen hebben waarbij de ene gegevensstroom naar Azure Diagnostic gaat en een andere resource op hetzelfde moment gebruikt.
Als u de doeltabel selecteert in Log Analytics: alle Azure-services gebruiken uiteindelijk de resourcespecifieke tabellen. Als onderdeel van deze overgang kunt u de diagnostische tabel of resourcespecifieke tabel van Azure selecteren in de diagnostische instelling met behulp van een wisselknop. De wisselknop is standaard ingesteld op Resourcespecifiek en in deze modus worden logboeken voor nieuwe geselecteerde categorieën verzonden naar toegewezen tabellen in Log Analytics, terwijl bestaande streams ongewijzigd blijven. Zie het volgende voorbeeld.
Werkruimtetransformaties: als u kiest voor de optie Resourcespecifiek, kunt u uw gegevens filteren en wijzigen voordat deze worden opgenomen met werkruimtetransformaties. Dit biedt gedetailleerde controle, zodat u zich kunt richten op de meest relevante informatie uit de logboeken daar door de gegevenskosten te verlagen en de beveiliging te verbeteren. Raadpleeg voor gedetailleerde instructies over het instellen van werkruimtetransformaties: Zelfstudie: Een werkruimtetransformatie toevoegen aan Azure Monitor-logboeken met behulp van Azure Portal.
Voorbeelden van het optimaliseren van toegangslogboeken met behulp van werkruimtetransformaties
Voorbeeld 1: Selectieve projectie van kolommen: Stel dat u toegangslogboeken voor Application Gateway hebt met 20 kolommen, maar u bent geïnteresseerd in het analyseren van gegevens uit slechts 6 specifieke kolommen. Met behulp van werkruimtetransformatie kunt u deze 6 kolommen projecteren in uw werkruimte, met uitzondering van de andere 14 kolommen. Hoewel de oorspronkelijke gegevens van de uitgesloten kolommen niet worden opgeslagen, worden lege tijdelijke aanduidingen voor deze kolommen nog steeds weergegeven op de blade Logboeken. Deze aanpak optimaliseert de opslag en zorgt ervoor dat alleen relevante gegevens worden bewaard voor analyse.
Notitie
Als u op de blade Logboeken de optie Nieuwe Log Analytics uitproberen selecteert, hebt u meer controle over de kolommen die in uw gebruikersinterface worden weergegeven.
Voorbeeld 2: Gericht op specifieke statuscodes: bij het analyseren van toegangslogboeken, in plaats van alle logboekvermeldingen te verwerken, kunt u een query schrijven om alleen rijen met specifieke HTTP-statuscodes op te halen (zoals 4xx en 5xx). Omdat de meeste aanvragen idealiter onder de categorieën 2xx en 3xx vallen (die geslaagde antwoorden vertegenwoordigen), wordt de gegevensset beperkt door de aandacht te richten op de problematische statuscodes. Met deze gerichte aanpak kunt u de meest relevante en bruikbare informatie extraheren, waardoor deze zowel nuttig als rendabel is.
Aanbevolen overgangsstrategie om over te stappen van diagnostische Azure-gegevens naar resourcespecifieke tabel:
- Huidige gegevensretentie evalueren: bepaal de duur van de gegevens die momenteel worden bewaard in de diagnostische azure-tabel (bijvoorbeeld: stel dat de diagnostische tabel 15 dagen gegevens bewaart).
- Resourcespecifieke retentie tot stand brengen: implementeer een nieuwe diagnostische instelling met resourcespecifieke tabel.
- Parallelle gegevensverzameling: Verzamel gedurende een tijdelijke periode gelijktijdig gegevens in zowel de Diagnostische gegevens van Azure als de resourcespecifieke instellingen.
- Bevestig de nauwkeurigheid van de gegevens: controleer of het verzamelen van gegevens nauwkeurig en consistent is in beide instellingen.
- Azure Diagnostics-instelling verwijderen: Verwijder de diagnostische instelling van Azure om dubbele gegevensverzameling te voorkomen.
Andere opslaglocaties:
- Azure Storage-account: Opslagaccounts kunnen het beste worden gebruikt voor logboeken wanneer logboeken worden opgeslagen voor een langere duur en indien nodig worden gecontroleerd.
- Azure Event Hubs: Event Hubs zijn een uitstekende optie voor integratie met andere SIEM-hulpprogramma's (Security Information and Event Management) om waarschuwingen over uw resources op te halen.
- Integraties van Azure Monitor-partners.
Meer informatie over de bestemmingen voor diagnostische instellingen van Azure Monitor.
Logboekregistratie inschakelen via PowerShell
Activiteitenlogboekregistratie is automatisch ingeschakeld voor elke Resource Manager-resource. U moet toegangs- en prestatielogboekregistratie inschakelen om te beginnen met het verzamelen van de gegevens die beschikbaar zijn via deze logboeken. Gebruik de volgende stappen om logboekregistratie in te schakelen:
Noteer de resource-ID van uw opslagaccount waar de logboekgegevens worden opgeslagen. Deze waarde is van het formulier: /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name>. U kunt elk opslagaccount in uw abonnement gebruiken. U kunt de Azure-portal gebruiken om deze informatie te vinden.
Noteer de resource-id van uw toepassingsgateway waarvoor logboekregistratie is ingeschakeld. Deze waarde is van het formulier: /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application Gateway name>. U kunt de portal gebruiken om deze informatie te vinden.
Schakel diagnostische logboekregistratie in door de volgende PowerShell-cmdlet te gebruiken:
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
Tip
Voor activiteitenlogboeken is geen afzonderlijk opslagaccount vereist. Voor het gebruik van opslag voor toegangs- en prestatielogboeken worden servicekosten in rekening gebracht.
Logboekregistratie inschakelen via de Azure-portal
Zoek uw resource in Azure Portal en selecteer diagnostische instellingen.
Voor Application Gateway zijn drie logboeken beschikbaar:
- Toegangslogboek
- Prestatielogboek
- Firewalllogboek
Als u gegevens wilt verzamelen, selecteert u Diagnostische gegevens inschakelen.
Op de pagina Diagnostische instellingen staan de instellingen voor de diagnostische logboeken. In dit voorbeeld worden de logboeken opgeslagen in Log Analytics. U kunt ook Event Hubs en een opslagaccount gebruiken om de diagnostische logboeken op te slaan.
Typ een naam voor de instellingen, bevestig de instellingen en selecteer Opslaan.
Activiteitenlogboek
Azure genereert standaard het activiteitenlogboek. De logboeken worden gedurende 90 dagen bewaard in het Logboekenarchief van Azure. Lees het artikel Gebeurtenissen en activiteitenlogboeken weergeven voor meer informatie over deze logboeken.
Toegangslogboek
Het toegangslogboek wordt alleen gegenereerd als u dit hebt ingeschakeld voor elk Application Gateway-exemplaar, zoals beschreven in de voorgaande stappen. De gegevens worden opgeslagen in het opslagaccount dat u hebt opgegeven toen u de logboekregistratie hebt ingeschakeld. Elke toegang tot Application Gateway wordt vastgelegd in JSON-indeling, zoals hieronder wordt weergegeven.
Voor Application Gateway en WAF v2 SKU
Notitie
Ga naar de gegevensverwijzing voor informatie met betrekking tot TLS/TCP-proxy.
| Weergegeven als | Beschrijving |
|---|---|
| instanceId | Application Gateway-exemplaar dat de aanvraag heeft geleverd. |
| clientIP | IP van de directe client van Application Gateway. Als een andere proxy uw toepassingsgateway fronteert, wordt hiermee het IP-adres van die frontingproxy weergegeven. |
| httpMethod | De HTTP-methode die wordt gebruikt door de aanvraag. |
| requestUri | URI van de ontvangen aanvraag. |
| UserAgent | Gebruikersagent van de HTTP-aanvraagheader. |
| httpStatus | HTTP-statuscode geretourneerd naar de client vanuit Application Gateway. |
| httpVersion | HTTP-versie van de aanvraag. |
| ontvangenbytes | Grootte van het ontvangen pakket, in bytes. |
| verzonden bytes | De grootte van het pakket dat wordt verzonden, in bytes. |
| clientResponseTime | Tijdsverschil (in seconden) tussen de eerste byte en de laatste bytetoepassingsgateway die naar de client is verzonden. Handig bij het controleren van de verwerkingstijd van Application Gateway voor reacties of trage clients. |
| timeTaken | De tijdsduur (in seconden) die nodig is voor de eerste byte van een clientaanvraag moet worden verwerkt en de laatste byte die in het antwoord op de client is verzonden. Het is belangrijk om te weten dat het veld Time-Taken meestal de tijd bevat waarop de aanvraag- en antwoordpakketten via het netwerk worden verzonden. |
| WAFEvaluationTime | De tijdsduur (in seconden) die nodig is voordat de aanvraag door de WAF wordt verwerkt. |
| WAFMode | Waarde kan detectie of preventie zijn |
| transactionId | Unieke id om de aanvraag te correleren die van de client is ontvangen |
| sslEnabled | Of de communicatie met de back-endpools TLS heeft gebruikt. Geldige waarden zijn in- en uitgeschakeld. |
| sslCipher | Coderingssuite die wordt gebruikt voor TLS-communicatie (als TLS is ingeschakeld). |
| sslProtocol | SSL/TLS-protocol dat wordt gebruikt (als TLS is ingeschakeld). |
| serverRouted | De back-endserver waarnaar de toepassingsgateway de aanvraag stuurt. |
| serverStatus | HTTP-statuscode van de back-endserver. |
| serverResponseLatency | Latentie van het antwoord (in seconden) van de back-endserver. |
| host | Adres vermeld in de hostheader van de aanvraag. Als het opnieuw wordt geschreven met behulp van het herschrijven van headers, bevat dit veld de bijgewerkte hostnaam |
| originalRequestUriWithArgs | Dit veld bevat de oorspronkelijke aanvraag-URL |
| requestUri | Dit veld bevat de URL na de herschrijfbewerking in Application Gateway |
| upstreamSourcePort | De bronpoort die door Application Gateway wordt gebruikt bij het initiëren van een verbinding met het back-enddoel |
| originalHost | Dit veld bevat de oorspronkelijke hostnaam van de aanvraag |
| error_info | De reden voor de fout 4xx en 5xx. Geeft een foutcode weer voor een mislukte aanvraag. Meer informatie in foutcodegegevens. |
| Contenttype | Het type inhoud of gegevens dat wordt verwerkt of geleverd door de toepassingsgateway |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"listenerName": "HTTP-Listener",
"ruleName": "Storage-Static-Rule",
"backendPoolName": "StaticStorageAccount",
"backendSettingName": "StorageStatic-HTTPS-Setting",
"operationName": "ApplicationGatewayAccess",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "appgw_2",
"clientIP": "185.42.129.24",
"clientPort": 45057,
"httpMethod": "GET",
"originalRequestUriWithArgs": "\/",
"requestUri": "\/",
"requestQuery": "",
"userAgent": "Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/52.0.2743.116 Safari\/537.36",
"httpStatus": 200,
"httpVersion": "HTTP\/1.1",
"receivedBytes": 184,
"sentBytes": 466,
"clientResponseTime": 0,
"timeTaken": 0.034,
"WAFEvaluationTime": "0.000",
"WAFMode": "Detection",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"sslEnabled": "on",
"sslCipher": "ECDHE-RSA-AES256-GCM-SHA384",
"sslProtocol": "TLSv1.2",
"sslClientVerify": "NONE",
"sslClientCertificateFingerprint": "",
"sslClientCertificateIssuerName": "",
"serverRouted": "52.239.221.65:443",
"serverStatus": "200",
"serverResponseLatency": "0.028",
"upstreamSourcePort": "21564",
"originalHost": "20.110.30.194",
"host": "20.110.30.194",
"error_info":"ERRORINFO_NO_ERROR",
"contentType":"application/json"
}
}
Notitie
Toegangslogboeken met clientIP-waarde 127.0.0.1 zijn afkomstig van een intern beveiligingsproces dat wordt uitgevoerd op de exemplaren van de toepassingsgateway. U kunt deze logboekvermeldingen veilig negeren.
Voor Application Gateway Standard en WAF SKU (v1)
| Weergegeven als | Beschrijving |
|---|---|
| instanceId | Application Gateway-exemplaar dat de aanvraag heeft geleverd. |
| clientIP | Oorspronkelijk IP-adres voor de aanvraag. |
| clientPort | Oorspronkelijke poort voor de aanvraag. |
| httpMethod | De HTTP-methode die wordt gebruikt door de aanvraag. |
| requestUri | URI van de ontvangen aanvraag. |
| RequestQuery | Serverrouted: instantie van back-endpool die de aanvraag heeft verzonden. X-AzureApplicationGateway-LOG-ID: Correlatie-id die wordt gebruikt voor de aanvraag. Het kan worden gebruikt om verkeersproblemen op de back-endservers op te lossen. SERVER-STATUS: HTTP-antwoordcode die Application Gateway heeft ontvangen van de back-end. |
| UserAgent | Gebruikersagent van de HTTP-aanvraagheader. |
| httpStatus | HTTP-statuscode geretourneerd naar de client vanuit Application Gateway. |
| httpVersion | HTTP-versie van de aanvraag. |
| ontvangenbytes | Grootte van het ontvangen pakket, in bytes. |
| verzonden bytes | De grootte van het pakket dat wordt verzonden, in bytes. |
| timeTaken | De tijdsduur (in milliseconden) die nodig is om een aanvraag te verwerken en de reactie die moet worden verzonden. Dit wordt berekend als het interval van het tijdstip waarop Application Gateway de eerste byte van een HTTP-aanvraag ontvangt tot het tijdstip waarop de verzendbewerking van het antwoord is voltooid. Het is belangrijk om te weten dat het veld Time-Taken meestal de tijd bevat waarop de aanvraag- en antwoordpakketten via het netwerk worden verzonden. |
| sslEnabled | Of communicatie met de back-endpools TLS/SSL heeft gebruikt. Geldige waarden zijn in- en uitgeschakeld. |
| host | De hostnaam waarvoor de aanvraag is verzonden naar de back-endserver. Als de hostnaam van de back-end wordt overschreven, weerspiegelt deze naam dat. |
| originalHost | De hostnaam waarvoor de aanvraag is ontvangen door de Application Gateway van de client. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIP": "191.96.249.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-AzureApplicationGateway-LOG-ID=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"host": "www.contoso.com",
"originalHost": "www.contoso.com"
}
}
Informatie over foutcodes
Als de toepassingsgateway de aanvraag niet kan voltooien, worden een van de volgende redencodes opgeslagen in het veld error_info van het toegangslogboek.
| 4XX-fouten | (De 4xx-foutcodes geven aan dat er een probleem is met de aanvraag van de client en dat de Application Gateway deze niet kan vervullen.) |
|---|---|
| ERRORINFO_INVALID_METHOD | De client heeft een aanvraag verzonden die niet-RFC-compatibel is. Mogelijke redenen: client met behulp van http-methode die niet wordt ondersteund door server, verkeerd gespelde methode, incompatibele VERSIE van het HTTP-protocol, enzovoort. |
| ERRORINFO_INVALID_REQUEST | De server kan niet voldoen aan de aanvraag vanwege een onjuiste syntaxis. |
| ERRORINFO_INVALID_VERSION | De toepassingsgateway heeft een aanvraag ontvangen met een ongeldige of niet-ondersteunde HTTP-versie. |
| ERRORINFO_INVALID_09_METHOD | De client heeft een aanvraag verzonden met HTTP Protocol versie 0.9. |
| ERRORINFO_INVALID_HOST | De waarde in de header Host ontbreekt, is onjuist opgemaakt of komt niet overeen met de verwachte hostwaarde. Als er bijvoorbeeld geen Basic-listener is en geen van de hostnamen van listeners voor meerdere locaties overeenkomt met de host. |
| ERRORINFO_INVALID_CONTENT_LENGTH | De lengte van de inhoud die is opgegeven door de client in de header content-Length komt niet overeen met de werkelijke lengte van de inhoud in de aanvraag. |
| ERRORINFO_INVALID_METHOD_TRACE | De client heeft een HTTP TRACE-methode verzonden, die niet wordt ondersteund door de toepassingsgateway. |
| ERRORINFO_CLIENT_CLOSED_REQUEST | De client heeft de verbinding met de toepassingsgateway gesloten voordat de time-outperiode voor inactiviteit is verstreken. Controleer of de time-outperiode van de client groter is dan de niet-actieve time-outperiode voor de toepassingsgateway. |
| ERRORINFO_REQUEST_URI_INVALID | Geeft het probleem aan met de URI (Uniform Resource Identifier) die is opgegeven in de aanvraag van de client. |
| ERRORINFO_HTTP_NO_HOST_HEADER | Client heeft een aanvraag verzonden zonder hostheader. |
| ERRORINFO_HTTP_TO_HTTPS_PORT | De client heeft een gewone HTTP-aanvraag verzonden naar een HTTPS-poort. |
| ERRORINFO_HTTPS_NO_CERT | Geeft aan dat de client geen geldig en correct geconfigureerd TLS-certificaat verzendt tijdens wederzijdse TLS-verificatie. |
| 5XX-fouten | Beschrijving |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | De toepassingsgateway kan geen actieve of bereikbaar back-endservers vinden om binnenkomende aanvragen te verwerken |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | De back-endserver heeft de verbinding onverwacht gesloten of voordat de aanvraag volledig is verwerkt. Dit kan gebeuren omdat de back-endserver de limieten bereikt, vastloopt, enzovoort. |
| ERRORINFO_UPSTREAM_TIMED_OUT | De tot stand gebrachte TCP-verbinding met de server is gesloten omdat de verbinding langer duurde dan de geconfigureerde time-outwaarde. |
Prestatielogboek
Het prestatielogboek wordt alleen gegenereerd als u dit hebt ingeschakeld voor elk Application Gateway-exemplaar, zoals beschreven in de voorgaande stappen. De gegevens worden opgeslagen in het opslagaccount dat u hebt opgegeven toen u de logboekregistratie hebt ingeschakeld. De prestatielogboekgegevens worden met intervallen van 1 minuut gegenereerd. Deze is alleen beschikbaar voor de v1-SKU. Voor de v2-SKU gebruikt u Metrische gegevens voor prestatiegegevens. De volgende gegevens worden vastgelegd:
| Weergegeven als | Beschrijving |
|---|---|
| instanceId | Application Gateway-exemplaar waarvoor prestatiegegevens worden gegenereerd. Voor een toepassingsgateway met meerdere exemplaren is er één rij per exemplaar. |
| healthyHostCount | Aantal hosts in orde in de back-endpool. |
| unHealthyHostCount | Aantal beschadigde hosts in de back-endpool. |
| requestCount | Het aantal aanvragen dat is verwerkt. |
| latentie | Gemiddelde latentie (in milliseconden) van aanvragen van het exemplaar naar de back-end die de aanvragen verwerkt. |
| failedRequestCount | Aantal mislukte aanvragen. |
| doorvoer | Gemiddelde doorvoer sinds het laatste logboek, gemeten in bytes per seconde. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
Notitie
Latentie wordt berekend vanaf het moment waarop de eerste byte van de HTTP-aanvraag wordt ontvangen tot het moment waarop de laatste byte van het HTTP-antwoord wordt verzonden. Dit is de som van de verwerkingstijd van Application Gateway plus de netwerkkosten voor de back-end, plus de tijd die de back-end nodig heeft om de aanvraag te verwerken.
Firewalllogboek
Het firewalllogboek wordt alleen gegenereerd als u dit hebt ingeschakeld voor elke toepassingsgateway, zoals beschreven in de voorgaande stappen. Dit logboek vereist ook dat de webtoepassingsfirewall is geconfigureerd op een toepassingsgateway. De gegevens worden opgeslagen in het opslagaccount dat u hebt opgegeven toen u de logboekregistratie hebt ingeschakeld. De volgende gegevens worden vastgelegd:
| Weergegeven als | Beschrijving |
|---|---|
| instanceId | Application Gateway-exemplaar waarvoor firewallgegevens worden gegenereerd. Voor een toepassingsgateway met meerdere exemplaren is er één rij per exemplaar. |
| clientIp | Oorspronkelijk IP-adres voor de aanvraag. |
| clientPort | Oorspronkelijke poort voor de aanvraag. |
| requestUri | URL van de ontvangen aanvraag. |
| ruleSetType | Type regelset. De beschikbare waarde is OWASP. |
| ruleSetVersion | Gebruikte regelsetversie. Beschikbare waarden zijn 2.2.9 en 3.0. |
| ruleId | Regel-id van de activerende gebeurtenis. |
| bericht | Gebruiksvriendelijk bericht voor de triggergebeurtenis. Meer informatie vindt u in de sectie details. |
| action | Actie ondernomen op het verzoek. Beschikbare waarden zijn geblokkeerd en toegestaan (voor aangepaste regels), Overeenkomend (wanneer een regel overeenkomt met een deel van de aanvraag) en Gedetecteerd en Geblokkeerd (dit zijn beide voor verplichte regels, afhankelijk van of de WAF zich in de detectie- of preventiemodus bevindt). |
| site | Site waarvoor het logboek is gegenereerd. Momenteel wordt alleen Algemeen vermeld omdat regels globaal zijn. |
| details | Details van de triggering-gebeurtenis. |
| details.message | Beschrijving van de regel. |
| details.data | Specifieke gegevens gevonden in aanvraag die overeenkomen met de regel. |
| details.file | Configuratiebestand met de regel. |
| details.line | Regelnummer in het configuratiebestand dat de gebeurtenis heeft geactiveerd. |
| hostname | Hostnaam of IP-adres van de Application Gateway. |
| transactionId | Unieke id voor een bepaalde transactie die helpt bij het groeperen van meerdere regelschendingen die zich in dezelfde aanvraag hebben voorgedaan. |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_2",
"clientIp": "185.42.129.24",
"clientPort": "",
"requestUri": "\/",
"ruleSetType": "OWASP_CRS",
"ruleSetVersion": "3.0.0",
"ruleId": "920350",
"message": "Host header is a numeric IP address",
"action": "Matched",
"site": "Global",
"details": {
"message": "Warning. Pattern match \\\"^[\\\\d.:]+$\\\" at REQUEST_HEADERS:Host .... ",
"data": "20.110.30.194:80",
"file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
"line": "791"
},
"hostname": "20.110.30.194:80",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"policyId": "default",
"policyScope": "Global",
"policyScopeName": "Global"
}
}
Het activiteitenlogboek bekijken en analyseren
U kunt activiteitenlogboekgegevens bekijken en analyseren via een van de volgende methoden:
- Azure-hulpprogramma’s: Haal informatie uit het activiteitenlogboek op via Azure PowerShell, de Azure CLI, de Azure REST-API of de Azure-portal. In het artikel Activiteitsbewerkingen met Resource Manager staan stapsgewijze instructies voor elke methode.
- Power BI: Als u nog geen Power BI-account hebt, kunt u het gratis uitproberen. Met behulp van de Power BI-sjabloon-apps kunt u uw gegevens analyseren.
De toegangs-, prestatie- en firewalllogboeken weergeven en analyseren
Azure Monitor-logboeken kunnen de teller- en gebeurtenislogboekbestanden verzamelen uit uw Blob Storage-account. Het omvat visualisaties en krachtige zoekmogelijkheden om uw logboeken te analyseren.
U kunt ook verbinding maken met uw opslagaccount en de JSON-logboekitems voor toegangs- en prestatielogboeken ophalen. Nadat u de JSON-bestanden hebt gedownload, kunt u ze naar de CSV-indeling converteren en in Excel, Power BI of een ander hulpprogramma voor gegevensvisualisatie bekijken.
Tip
Als u bekend bent met Visual Studio en basisconcepten voor het wijzigen van waarden voor constanten en variabelen in C#, kunt u de hulpprogramma's voor logboekconversie gebruiken die beschikbaar zijn via GitHub.
Toegangslogboeken analyseren via GoAccess
We hebben een Resource Manager-sjabloon gepubliceerd waarmee de populaire GoAccess-logboekanalyse voor Application Gateway-toegangslogboeken wordt geïnstalleerd en uitgevoerd. GoAccess biedt waardevolle HTTP-verkeersstatistieken zoals unieke bezoekers, aangevraagde bestanden, hosts, besturingssystemen, browsers, HTTP-statuscodes en meer. Zie het Leesmij-bestand in de map Resource Manager-sjabloon in GitHub voor meer informatie.
Volgende stappen
- Visualiseer teller- en gebeurtenislogboeken met behulp van Azure Monitor-logboeken.
- Visualiseer uw Azure-activiteitenlogboek met een Power BI-blogbericht .
- Azure-activiteitenlogboeken weergeven en analyseren in Power BI en meer blogpost.