Diagnostikloggar för Application Gateway
Application Gateway-loggar innehåller detaljerad information om händelser som rör en resurs och dess åtgärder. Dessa loggar är tillgängliga för händelser som Åtkomst, Aktivitet, Brandvägg och Prestanda (endast för V1). Detaljerad information i loggar är användbar när du felsöker ett problem eller skapar en analysinstrumentpanel genom att använda dessa rådata.
Loggar är tillgängliga för alla resurser i Application Gateway. Men om du vill använda dem måste du aktivera deras samling på valfri lagringsplats. Loggning i Azure Application Gateway aktiveras av Azure Monitor-tjänsten. Vi rekommenderar att du använder Log Analytics-arbetsytan eftersom du enkelt kan använda dess fördefinierade frågor och ange aviseringar baserat på specifika loggvillkor.
Typer av diagnostikloggar
Du kan använda olika typer av loggar i Azure för att hantera och felsöka programgatewayer. Du kan läsa mer om de här typerna nedan:
- Aktivitetslogg: Du kan använda Azure-aktivitetsloggar (tidigare kallade driftloggar och granskningsloggar) för att visa alla åtgärder som skickas till din Azure-prenumeration och deras status. Aktivitetsloggposter samlas in som standard, och du kan visa dem i Azure Portal.
- Åtkomstlogg: Du kan använda den här loggen för att visa Åtkomstmönster för Application Gateway och analysera viktig information. Detta inkluderar anroparens IP-adress, begärd URL, svarsfördröjning, returkod och byte in och ut. En åtkomstlogg samlas in var 60:e sekund. Den här loggen innehåller en post per instans av Application Gateway. Application Gateway-instansen identifieras av egenskapen instanceId.
- Prestandalogg: Du kan använda den här loggen för att visa hur Application Gateway-instanser fungerar. Den här loggen samlar in prestandainformation för varje instans, inklusive totalt antal begäranden som hanteras, dataflöde i byte, totalt antal begäranden som hanteras, antal misslyckade begäranden och felfritt antal serverdelsinstanser. En prestandalogg samlas in var 60:e sekund. Prestandaloggen är endast tillgänglig för V1-SKU:n. För V2 SKU använder du Mått för prestandadata.
- Brandväggslogg: Du kan använda den här loggen för att visa begäranden som loggas via antingen identifierings- eller förebyggande läge för en programgateway som har konfigurerats med brandväggen för webbprogram. Brandväggsloggar samlas in var 60:e sekund.
Kommentar
Loggar är endast tillgängliga för resurser som distribueras i Azure Resource Manager-distributionsmodellen. Du kan inte använda loggar för resurser i den klassiska distributionsmodellen. En bättre förståelse för de två modellerna finns i artikeln Förstå Resource Manager-distribution och klassisk distribution .
Lagringsplatser
Du har följande alternativ för att lagra loggarna på önskad plats.
Log Analytic-arbetsyta: Med det här alternativet kan du enkelt använda fördefinierade frågor, visualiseringar och ställa in aviseringar baserat på specifika loggvillkor. Vilka tabeller som används av resursloggar på log analytics-arbetsytan beror på vilken typ av samling resursen använder:
Azure-diagnostik: Data skrivs till tabellen Azure Diagnostics. Azure Diagnostics-tabellen delas mellan flera resurstyper, där var och en av dem lägger till sina egna anpassade fält. När antalet anpassade fält som matas in i Azure Diagnostics-tabellen överskrider 500 läggs inte nya fält till som toppnivå, utan läggs till i fältet "AdditionalFields" som dynamiska nyckelvärdepar.
Resursspecifik(rekommenderas): Data skrivs till dedikerade tabeller för varje kategori av resursen. I resursspecifikt läge tilldelas varje loggkategori som valts i diagnostikinställningen en egen tabell i den valda arbetsytan. Detta har flera fördelar, bland annat:
- Enklare datamanipulering i loggfrågor
- Förbättrad identifiering av scheman och deras strukturer
- Förbättrad prestanda när det gäller svarstid för inmatning och frågetider
- Möjligheten att tilldela rollbaserade åtkomstkontrollrättigheter i Azure till specifika tabeller
För Application Gateway skapar resursspecifikt läge tre tabeller:
Kommentar
Det resursspecifika alternativet är för närvarande tillgängligt i alla offentliga regioner.
Befintliga användare kan fortsätta använda Azure Diagnostics eller välja dedikerade tabeller genom att växla växlingsknappen i Diagnostikinställningar till Resursspecifik eller till Dedikerad i API-mål. Dubbelläge är inte möjligt. Data i alla loggar kan antingen flöda till Azure Diagnostics eller till dedikerade tabeller. Du kan dock ha flera diagnostikinställningar där ett dataflöde är till Azure Diagnostic och ett annat använder resursspecifikt samtidigt.
Välja måltabellen i Log Analytics: Alla Azure-tjänster använder slutligen de resursspecifika tabellerna. Som en del av den här övergången kan du välja Azure-diagnostik- eller resursspecifik tabell i diagnostikinställningen med hjälp av en växlingsknapp. Växlingsknappen är inställd på Resursspecifik som standard och i det här läget skickas loggar för nya valda kategorier till dedikerade tabeller i Log Analytics, medan befintliga strömmar förblir oförändrade. Se följande exempel.
Omvandlingar av arbetsytor: Om du väljer alternativet Resursspecifik kan du filtrera och ändra dina data innan de matas in med arbetsytetransformeringar. Detta ger detaljerad kontroll så att du kan fokusera på den mest relevanta informationen från loggarna där genom att minska datakostnaderna och förbättra säkerheten. Detaljerade anvisningar om hur du konfigurerar arbetsytetransformeringar finns i:Självstudie: Lägga till en arbetsytetransformering i Azure Monitor-loggar med hjälp av Azure-portalen.
Exempel på hur du optimerar åtkomstloggar med hjälp av arbetsytetransformeringar
Exempel 1: Selektiv projektion av kolumner: Anta att du har åtkomstloggar för application gateway med 20 kolumner, men du är intresserad av att analysera data från endast 6 specifika kolumner. Genom att använda arbetsytetransformering kan du projicera dessa 6 kolumner till din arbetsyta, vilket effektivt utesluter de övriga 14 kolumnerna. Även om de ursprungliga data från de undantagna kolumnerna inte lagras, visas tomma platshållare för dem fortfarande på bladet Loggar. Den här metoden optimerar lagringen och ser till att endast relevanta data bevaras för analys.
Kommentar
Om du väljer alternativet Prova ny Log Analytics på bladet Loggar får du större kontroll över de kolumner som visas i användargränssnittet.
Exempel 2: Om du fokuserar på specifika statuskoder: När du analyserar åtkomstloggar kan du i stället för att bearbeta alla loggposter skriva en fråga för att endast hämta rader med specifika HTTP-statuskoder (till exempel 4xx och 5xx). Eftersom de flesta begäranden helst faller under kategorierna 2xx och 3xx (som representerar lyckade svar) begränsas datauppsättningen med fokus på de problematiska statuskoderna. Med den här riktade metoden kan du extrahera den mest relevanta och användbara informationen, vilket gör den både fördelaktig och kostnadseffektiv.
Rekommenderad övergångsstrategi för att gå från Azure-diagnostik till resursspecifik tabell:
- Utvärdera aktuell datakvarhållning: Fastställa hur länge data för närvarande bevaras i Azure-diagnostiktabellen (anta till exempel att diagnostiktabellen behåller data i 15 dagar).
- Upprätta resursspecifik kvarhållning: Implementera en ny diagnostikinställning med resursspecifik tabell.
- Parallell datainsamling: Under en tillfällig period samlar du in data samtidigt i både Azure Diagnostics och de resursspecifika inställningarna.
- Bekräfta datanoggrannhet: Kontrollera att datainsamlingen är korrekt och konsekvent i båda inställningarna.
- Ta bort azure-diagnostikinställning: Ta bort azure-diagnostikinställningen för att förhindra dubbletter av datainsamling.
Andra lagringsplatser:
- Azure Storage-konto: Lagringskonton används bäst för loggar när loggar lagras under en längre tid och granskas när det behövs.
- Azure Event Hubs: Händelsehubbar är ett bra alternativ för att integrera med andra SIEM-verktyg (säkerhetsinformation och händelsehantering) för att få aviseringar om dina resurser.
- Azure Monitor-partnerintegreringar.
Läs mer om mål för Diagnostikinställningar för Azure Monitor .
Aktivera loggning via PowerShell
Aktivitetsloggning är automatiskt aktiverad för alla Resource Manager-resurser. Du måste aktivera åtkomst och prestandaloggning för att börja samla in de data som är tillgängliga via dessa loggar. Använd följande steg för att aktivera loggning:
Anteckna resurs-ID:t för det lagringskonto där loggdata lagras. Det här värdet är av formuläret : /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name>. Du kan använda valfritt lagringskonto i din prenumeration. Du hittar den här informationen i Azure Portal.
Observera programgatewayens resurs-ID som loggning är aktiverad för. Det här värdet är av formuläret : /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>. Du hittar den här informationen i Azure Portal.
Aktivera diagnostisk loggning med följande PowerShell-cmdlet:
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
Dricks
Aktivitetsloggar kräver inte ett separat lagringskonto. När du använder lagring för åtkomst- och prestandaloggning debiteras avgifter för tjänsten.
aktivera loggning via Azure Portal
Leta reda på din resurs i Azure-portalen och välj Diagnostikinställningar.
För Application Gateway är tre loggar tillgängliga:
- Åtkomstlogg
- Prestandalogg
- Brandväggslogg
Om du vill börja samla in data väljer du Aktivera diagnostik.
På sidan Diagnostikinställningar kan du göra inställningar för diagnostikloggarna. I det här exemplet lagrar Log Analytics loggarna. Du kan också använda händelsehubbar och ett lagringskonto till att spara dina diagnostiska loggar.
Ange ett namn för inställningarna, bekräfta inställningarna och välj Spara.
Aktivitetslogg
Azure genererar aktivitetsloggen som standard. Loggarna bevaras i 90 dagar i Azure-händelseloggarkivet. Läs mer om dessa loggar genom att läsa artikeln Visa händelser och aktivitetsloggar .
Åtkomstlogg
Åtkomstloggen genereras endast om du har aktiverat den på varje Application Gateway-instans, enligt beskrivningen i föregående steg. Data lagras i det lagringskonto som du angav när du aktiverade loggningen. Varje åtkomst till Application Gateway loggas i JSON-format enligt nedan.
För Application Gateway och WAF v2 SKU
Kommentar
Information om TLS/TCP-proxy finns i datareferensen.
| Värde | beskrivning |
|---|---|
| instanceId | Application Gateway-instans som hanterade begäran. |
| clientIP | IP för den omedelbara klienten för Application Gateway. Om en annan proxy frontar programgatewayen visas IP-adressen för klientproxyn. |
| httpMethod | HTTP-metod som används av begäran. |
| requestUri | URI för den mottagna begäran. |
| UserAgent | Användaragent från HTTP-begärandehuvudet. |
| httpStatus | HTTP-statuskod som returneras till klienten från Application Gateway. |
| httpVersion | HTTP-versionen av begäran. |
| receivedBytes | Storleken på det mottagna paketet i byte. |
| sentBytes | Storleken på det paket som skickas i byte. |
| clientResponseTime | Tidsskillnad (i sekunder) mellan den första byte och den sista byte-programgatewayen som skickades till klienten. Användbart för att mäta Application Gateways bearbetningstid för svar eller långsamma klienter. |
| timeTaken | Hur lång tid (i sekunder) det tar för den första byte av en klientbegäran att bearbetas och dess sista byte skickas i svaret till klienten. Det är viktigt att observera att fältet Tidsåtgång vanligtvis innehåller den tid då paketen för begäran och svar färdas över nätverket. |
| WAFEvaluationTime | Hur lång tid (i sekunder) det tar för begäran att bearbetas av WAF. |
| WAFMode | Värdet kan vara identifiering eller förebyggande |
| transactionId | Unik identifierare för att korrelera begäran som tagits emot från klienten |
| sslEnabled | Om kommunikationen till serverdelspoolerna använde TLS. Giltiga värden är på och av. |
| sslCipher | Chiffersvit som används för TLS-kommunikation (om TLS är aktiverat). |
| sslProtocol | SSL/TLS-protokoll som används (om TLS är aktiverat). |
| serverRouted | Serverdelsservern som programgatewayen dirigerar begäran till. |
| serverStatus | HTTP-statuskod för serverdelsservern. |
| serverResponseLatency | Svarstiden för svaret (i sekunder) från serverdelsservern. |
| värd | Adress som anges i värdhuvudet för begäran. Om det skrivs om med sidhuvudomskrivning innehåller det här fältet det uppdaterade värdnamnet |
| originalRequestUriWithArgs | Det här fältet innehåller den ursprungliga url:en för begäran |
| requestUri | Det här fältet innehåller URL:en efter omskrivningsåtgärden på Application Gateway |
| upstreamSourcePort | Källporten som används av Application Gateway när du initierar en anslutning till serverdelsmålet |
| originalHost | Det här fältet innehåller det ursprungliga värdnamnet för begäran |
| error_info | Orsaken till felet 4xx och 5xx. Visar en felkod för en misslyckad begäran. Mer information finns i Felkodsinformation. |
| Contenttype | Den typ av innehåll eller data som bearbetas eller levereras av programgatewayen |
{
"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"
}
}
Kommentar
Åtkomstloggar med clientIP-värdet 127.0.0.1 kommer från en intern säkerhetsprocess som körs på programgatewayinstanserna. Du kan ignorera dessa loggposter på ett säkert sätt.
För Application Gateway Standard och WAF SKU (v1)
| Värde | beskrivning |
|---|---|
| instanceId | Application Gateway-instans som hanterade begäran. |
| clientIP | Ursprunglig IP-adress för begäran. |
| clientPort | Ursprungsport för begäran. |
| httpMethod | HTTP-metod som används av begäran. |
| requestUri | URI för den mottagna begäran. |
| RequestQuery | Server-Routed: Serverdelspoolinstans som skickades begäran. X-AzureApplicationGateway-LOG-ID: Korrelations-ID som används för begäran. Den kan användas för att felsöka trafikproblem på serverdelsservrarna. SERVER-STATUS: HTTP-svarskod som Application Gateway tog emot från serverdelen. |
| UserAgent | Användaragent från HTTP-begärandehuvudet. |
| httpStatus | HTTP-statuskod som returneras till klienten från Application Gateway. |
| httpVersion | HTTP-versionen av begäran. |
| receivedBytes | Storleken på det mottagna paketet i byte. |
| sentBytes | Storleken på det paket som skickas i byte. |
| timeTaken | Hur lång tid (i millisekunder) som det tar för en begäran att bearbetas och dess svar skickas. Detta beräknas som intervallet från den tidpunkt då Application Gateway tar emot den första byte av en HTTP-begäran till den tidpunkt då svarssändningen slutförs. Det är viktigt att observera att fältet Tidsåtgång vanligtvis innehåller den tid då paketen för begäran och svar färdas över nätverket. |
| sslEnabled | Om kommunikationen till serverdelspoolerna använde TLS/SSL. Giltiga värden är på och av. |
| värd | Värdnamnet för vilket begäran har skickats till serverdelen. Om värdnamnet för serverdelen åsidosätts återspeglar det här namnet detta. |
| originalHost | Värdnamnet för vilket begäran togs emot av Application Gateway från klienten. |
{
"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"
}
}
Felkodsinformation
Om programgatewayen inte kan slutföra begäran lagras någon av följande orsakskoder i fältet error_info i åtkomstloggen.
| 5XX-fel | beskrivning |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | Programgatewayen kan inte hitta några aktiva eller nåbara serverdelsservrar för att hantera inkommande begäranden |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | Serverdelsservern stängde anslutningen oväntat eller innan begäran bearbetades fullständigt. Detta kan inträffa på grund av att serverdelsservern når sina gränser, kraschar osv. |
| ERRORINFO_UPSTREAM_TIMED_OUT | Den etablerade TCP-anslutningen till servern stängdes eftersom anslutningen tog längre tid än det konfigurerade timeout-värdet. |
Prestandalogg
Prestandaloggen genereras endast om du har aktiverat den på varje Application Gateway-instans, enligt beskrivningen i föregående steg. Data lagras i det lagringskonto som du angav när du aktiverade loggningen. Prestandaloggdata genereras inom 1 minuts intervall. Den är endast tillgänglig för V1 SKU:n. För V2 SKU använder du Mått för prestandadata. Följande data loggas:
| Värde | beskrivning |
|---|---|
| instanceId | Application Gateway-instans för vilken prestandadata genereras. För en programgateway med flera instanser finns det en rad per instans. |
| healthyHostCount | Antal felfria värdar i serverdelspoolen. |
| unHealthyHostCount | Antal värdar som inte är felfria i serverdelspoolen. |
| requestCount | Antal begäranden som hanteras. |
| svarstid | Genomsnittlig svarstid (i millisekunder) för begäranden från instansen till serverdelen som hanterar begäranden. |
| failedRequestCount | Antal misslyckade begäranden. |
| dataflöde | Genomsnittligt dataflöde sedan den senaste loggen, mätt i byte per sekund. |
{
"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"
}
}
Kommentar
Svarstiden beräknas från den tidpunkt då den första byte av HTTP-begäran tas emot till den tidpunkt då http-svarets sista byte skickas. Det är summan av Application Gateway-bearbetningstiden plus nätverkskostnaden för serverdelen, plus den tid som serverdelen tar att bearbeta begäran.
Brandväggslogg
Brandväggsloggen genereras endast om du har aktiverat den för varje programgateway, enligt beskrivningen i föregående steg. Den här loggen kräver också att brandväggen för webbprogram har konfigurerats på en programgateway. Data lagras i det lagringskonto som du angav när du aktiverade loggningen. Följande data loggas:
| Värde | beskrivning |
|---|---|
| instanceId | Application Gateway-instans för vilken brandväggsdata genereras. För en programgateway med flera instanser finns det en rad per instans. |
| clientIp | Ursprunglig IP-adress för begäran. |
| clientPort | Ursprungsport för begäran. |
| requestUri | URL för den mottagna begäran. |
| ruleSetType | Regeluppsättningstyp. Det tillgängliga värdet är OWASP. |
| ruleSetVersion | Regeluppsättningsversion som används. Tillgängliga värden är 2.2.9 och 3.0. |
| ruleId | Regel-ID för utlösande händelse. |
| meddelande | Användarvänligt meddelande för utlösande händelse. Mer information finns i informationsavsnittet. |
| åtgärd | Åtgärd som vidtagits på begäran. Tillgängliga värden är Blockerade och Tillåtna (för anpassade regler), Matchade (när en regel matchar en del av begäran) och Identifierad och Blockerad (båda är för obligatoriska regler, beroende på om WAF är i identifierings- eller förebyggande läge). |
| webbplats | Webbplats som loggen genererades för. För närvarande visas endast Global eftersom reglerna är globala. |
| information | Information om utlösande händelse. |
| details.message | Beskrivning av regeln. |
| details.data | Specifika data som hittades i begäran som matchade regeln. |
| details.file | Konfigurationsfil som innehöll regeln. |
| details.line | Radnummer i konfigurationsfilen som utlöste händelsen. |
| värddatornamn | Programgatewayens värdnamn eller IP-adress. |
| transactionId | Unikt ID för en viss transaktion som hjälper till att gruppera flera regelöverträdelser som inträffat inom samma begäran. |
{
"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"
}
}
Visa och analysera aktivitetsloggar
Du kan visa och analysera aktivitetsloggdata med någon av följande metoder:
- Azure-verktyg: Hämta information från aktivitetsloggen via Azure PowerShell, Azure-CLI:t, Azure REST-API:t eller Azure Portal. Det finns stegvisa instruktioner för respektive metod i artikeln Aktivitetsåtgärder med Resource Manager.
- Power BI: Om du inte redan har ett Power BI-konto kan du prova ett utan kostnad. Genom att använda Power BI-mallapparna kan du analysera dina data.
Visa och analysera åtkomst-, prestanda- och brandväggsloggar
Azure Monitor-loggar kan samla in räknar- och händelseloggfilerna från ditt Blob Storage-konto. Där finns visualiseringar och kraftfulla sökfunktioner när du ska analysera dina loggar.
Du kan också ansluta till ditt lagringskonto och hämta JSON-loggposter för åtkomst- och prestandaloggar. När du har laddat ned JSON-filerna kan du konvertera dem till CSV-format och visa dem i Excel, Power BI eller något annat verktyg för visualisering av data.
Dricks
Om du är bekant med Visual Studio och grundläggande begrepp om att ändra värden för konstanter och variabler i C#, kan du använda loggkonverterarens verktyg som är tillgängliga från GitHub.
Analysera åtkomstloggar via GoAccess
Vi har publicerat en Resource Manager-mall som installerar och kör den populära GoAccess-logganalysen för Application Gateway-åtkomstloggar. GoAccess tillhandahåller värdefull HTTP-trafikstatistik som unika besökare, begärda filer, värdar, operativsystem, webbläsare, HTTP-statuskoder med mera. Mer information finns i Readme-filen i resource manager-mallmappen i GitHub.
Nästa steg
- Visualisera räknar- och händelseloggar med hjälp av Azure Monitor-loggar.
- Visualisera din Azure-aktivitetslogg med Power BI-blogginlägget .
- Visa och analysera Azure-aktivitetsloggar i Power BI och fler blogginlägg.