Diagnoseprotokolle für Application Gateway
Application Gateway-Protokolle enthalten detaillierte Informationen über die Ereignisse im Zusammenhang mit einer Ressource und deren Vorgängen. Diese Protokolle sind für Ereignisse wie Access, Aktivität, Firewall und Leistung (nur für V1) verfügbar. Die genauen Informationen in den Protokollen helfen bei Problembehebung oder Erstellung eines Analytics-Dashboards durch Verwenden dieser Rohdaten.
Protokolle sind für alle Ressourcen des Application Gateway verfügbar. Zu deren Nutzung müssen Sie jedoch deren Sammlung an einem Speicherort Ihrer Wahl aktivieren. Die Protokollierung im Azure-Application Gateway wird vom Azure Monitor-Dienst aktiviert. Wir empfehlen die Verwendung des Log Analytics-Arbeitsbereichs, da Sie dessen vordefinierten Abfragen problemlos verwenden und basierend auf bestimmten Protokollbedingungen Warnungen festlegen können.
Typen von Diagnoseprotokollen
Sie können in Azure verschiedene Protokolltypen verwenden, um Anwendungsgateways zu verwalten und eventuelle Fehler zu beheben. Nachfolgend sind Informationen zu diesen Typen:
- Aktivitätsprotokoll: Sie können das Feature Azure-Aktivitätsprotokolle (ehemals Betriebs- und Überwachungsprotokolle) verwenden, um alle an Ihr Azure-Abonnement übermittelten Vorgänge und deren Status anzuzeigen. Aktivitätsprotokolleinträge werden standardmäßig gesammelt und können im Azure-Portal angezeigt werden.
- Access Log: Mithilfe dieses Protokolls können Sie Application Gateway-Zugriffsmuster anzeigen und wichtige Informationen analysieren. Dazu gehören die IP des Aufrufers, die angeforderte URL, die Antwortlatenz, der Rückgabecode sowie die ein- und ausgehenden Bytes. Ein Zugriffsprotokoll wird alle 60 Sekunden erstellt. Dieses Protokoll enthält einen Datensatz pro Instanz von Application Gateway. Die Application Gateway-Instanz wird anhand der InstanceId-Eigenschaft identifiziert.
- Leistungsprotokoll: Mithilfe dieses Protokolls können Sie die Leistung von Application Gateway-Instanzen anzeigen. In diesem Protokoll werden Leistungsinformationen für jede Instanz erfasst, z. B. insgesamt bereitgestellte Anforderungen, Durchsatz in Byte, Anzahl von Anforderungen mit Fehlern und Anzahl von fehlerfreien und fehlerhaften Back-End-Instanzen. Ein Leistungsprotokoll wird alle 60 Sekunden erstellt. Das Leistungsprotokoll ist nur für die v1-SKU verfügbar. Verwenden Sie für die v2-SKU Metriken für die Leistungsdaten.
- Firewallprotokoll: Mithilfe dieses Protokolls können Sie die Anforderungen anzeigen, die entweder über den Erkennungs- oder über den Schutzmodus eines Anwendungsgateways protokolliert werden, das mit der Web Application Firewall konfiguriert wurde. Firewallprotokolle werden alle 60 Sekunden erfasst.
Hinweis
Protokolle sind nur für Ressourcen verfügbar, die über das Azure Resource Manager-Bereitstellungsmodell bereitgestellt werden. Sie können Protokolle nicht für Ressourcen im klassischen Bereitstellungsmodell verwenden. Ein besseres Verständnis der beiden Modelle können Sie entwickeln, indem Sie den Artikel Grundlegendes zur Bereitstellung über den Resource Manager im Vergleich zur klassischen Bereitstellung lesen.
Speicherorte
Zur Speicherung der Protokolle an Ihrem bevorzugten Speicherort gibt es folgende Optionen.
- Log Analytic Workspace: Empfohlen, da es Ihnen ermöglicht, die vordefinierten Abfragen, Visualisierungen und Benachrichtigungen basierend auf bestimmten Protokollbedingungen problemlos zu verwenden.
- Azure Speicherkonto: Speicherkonten eignen sich am besten für Protokolle, die eine längere Zeit gespeichert und bei Bedarf überprüft werden.
- Azure Event Hubs: Event Hubs-Instanzen sind eine hervorragende Möglichkeit für die Integration in andere SIEM-Tools (Security Information and Event Management), um Warnungen für Ihre Ressourcen zu erhalten.
- Azure Monitor – integrierte Partnerlösungen
Erfahren Sie mehr über die Diagnoseeinstellungen von Azure Monitor.
Ermöglichen der Protokollierung mit PowerShell
Die Aktivitätsprotokollierung ist automatisch für alle Resource Manager-Ressourcen aktiviert. Sie müssen die Zugriffs- und Leistungsprotokollierung aktivieren, um mit der Erfassung von Daten aus diesen Protokollen zu beginnen. Führen Sie zum Aktivieren der Protokollierung die folgenden Schritte aus:
Notieren Sie sich die Ressourcen-ID Ihres Speicherkontos, unter dem die Protokolldaten gespeichert werden. Dieser Wert weist folgendes Format auf: /subscriptions/<Abonnement-ID>/resourceGroups/<Ressourcengruppenname>/providers/Microsoft.Storage/storageAccounts/<Speicherkontoname>. Sie können jedes Speicherkonto Ihres Abonnements verwenden. Sie können das Azure-Portal verwenden, um nach diesen Informationen zu suchen.
Notieren Sie sich die Ressourcen-ID Ihres Anwendungsgateways, für das die Protokollierung aktiviert ist. Dieser Wert weist folgendes Format auf: /subscriptions/<Abonnement-ID>/resourceGroups/<Ressourcengruppenname>/providers/Microsoft.Network/applicationGateways/<Anwendungsgatewayname>. Sie können das Portal verwenden, um nach diesen Informationen zu suchen.
Aktivieren Sie die Diagnoseprotokollierung mit dem folgenden 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
Tipp
Für Aktivitätsprotokolle ist kein separates Speicherkonto erforderlich. Für die Nutzung des Speichers für die Zugriffs- und Leistungsprotokollierung fallen Dienstgebühren an.
Ermöglichen der Protokollierung über das Azure-Portal
Suchen Sie im Azure-Portal nach Ihrer Ressource, und wählen Sie Diagnoseeinstellungen aus.
Für Application Gateway sind drei Protokolle verfügbar:
- Zugriffsprotokoll
- Leistungsprotokoll
- Firewallprotokoll
Wählen Sie Diagnose aktivieren aus, um die Erfassung von Daten zu starten.
Auf der Seite Diagnoseeinstellungen befinden sich die Einstellungen für die Diagnoseprotokolle. In diesem Beispiel werden die Protokolle in Log Analytics gespeichert. Sie können auch Event Hubs und ein Speicherkonto verwenden, um die Diagnoseprotokolle zu speichern.
Geben Sie einen Namen für die Einstellungen ein, bestätigen Sie die Einstellungen, und wählen Sie Speichern aus.
Aktivitätsprotokoll
Das Aktivitätsprotokoll wird von Azure standardmäßig generiert. Die Protokolle werden 90 Tage lang im Azure-Ereignisprotokollspeicher aufbewahrt. Weitere Informationen zu diesen Protokollen finden Sie im Artikel Anzeigen von Ereignis- und Aktivitätsprotokollen.
Zugriffsprotokoll
Das Zugriffsprotokoll wird nur generiert, wenn Sie es auf jeder Application Gateway-Instanz gemäß den obigen Schritten aktiviert haben. Die Daten werden in dem Speicherkonto gespeichert, das Sie beim Aktivieren der Protokollierung angegeben haben. Jeder Application Gateway-Zugriff wird wie unten gezeigt im JSON-Format protokolliert.
Für die SKU Application Gateway und WAF v2
Hinweis
Informationen zu TLS/TCP-Proxys finden Sie in der Datenreferenz.
| Wert | BESCHREIBUNG |
|---|---|
| instanceId | Application Gateway-Instanz, von der die Anforderung bereitgestellt wurde |
| clientIP | IP-Adresse des unmittelbaren Clients von Application Gateway. Wenn Ihrem Anwendungsgateway ein anderer Proxy vorgeschaltet ist, wird hiervon die IP-Adresse dieses vorgeschalteten Proxys angezeigt. |
| httpMethod | Von der Anforderung verwendete HTTP-Methode |
| requestUri | URI der empfangenen Anforderung |
| UserAgent | Benutzer-Agent aus dem HTTP-Anforderungsheader |
| httpStatus | HTTP-Statuscode, der vom Application Gateway an den Client zurückgegeben wurde |
| httpVersion | HTTP-Version der Anforderung |
| receivedBytes | Größe des empfangenen Pakets in Byte |
| sentBytes | Größe des gesendeten Pakets in Byte |
| clientResponseTime | Zeitunterschied (in Sekunden) zwischen dem Application Gateway des ersten Byte und des letzten Byte, das an den Client gesendet wird. Hilfreich beim Messen der Verarbeitungszeit des Application Gateway für Antworten oder langsame Clients. |
| timeTaken | Die Dauer (in Sekunden), bis das erste Byte einer Clientanforderung verarbeitet und ihr letztes Byte in der Antwort an den Client gesendet wird. Hierbei ist der Hinweis wichtig, dass das Feld „Time-Taken“ normalerweise die Zeitdauer enthält, die von den Anforderungs- und Antwortpaketen für die Übermittlung über das Netzwerk benötigt wird. |
| WAFEvaluationTime | Dauer (in Sekunden), die die Verarbeitung der Anforderung durch die WAF benötigt. |
| WAFMode | Der Wert kann entweder „Detection“ (Erkennung) oder „Prevention“ (Prävention) sein. |
| transactionId | Eindeutiger Bezeichner zum Korrelieren der vom Client empfangenen Anforderung. |
| sslEnabled | Gibt an, ob für die Kommunikation mit den Back-End-Pools TLS verwendet wurde. Gültige Werte sind „on“ und „off“. |
| sslCipher | Verschlüsselungssammlung, die für die TLS-Kommunikation verwendet wird (sofern TLS aktiviert ist). |
| sslProtocol | Das verwendete SSL-/TLS-Protokoll (sofern TLS aktiviert ist) |
| serverRouted | Back-End-Server, an den das Anwendungsgateway die Anforderung weiterleitet |
| serverStatus | HTTP-Statuscode des Back-End-Servers |
| serverResponseLatency | Wartezeit für die Antwort (in Sekunden) vom Back-End-Server. |
| host | Adresse im host-Header der Anforderung Wenn dieses Feld beim erneuten Generieren von Headern neu geschrieben wird, enthält es den aktualisierten Hostnamen. |
| originalRequestUriWithArgs | Dieses Feld enthält die ursprüngliche Anforderungs-URL. |
| requestUri | Dieses Feld enthält die URL nach dem Vorgang zur erneuten Generierung in Application Gateway. |
| upstreamSourcePort | Der Quelle-Port, der beim Initiieren einer Verbindung mit dem Back-End-Ziel vom Application Gateway verwendet wird |
| originalHost | Dieses Feld enthält den Hostnamen der ursprüngliche Anforderung. |
| error_info | Die Ursache für die Fehler 4xx und 5xx. Zeigt einen Fehlercode für eine fehlgeschlagene Anforderung an. Weitere Details finden Sie im Abschnitt Informationen zu Fehlercodes. |
| contentType | Der Typ von Inhalten und Daten, die von Application Gateway verarbeitet oder bereitgestellt werden |
{
"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"
}
}
Hinweis
Zugriffsprotokolle mit clientIP-Wert 127.0.0.1 stammen aus einem internen Sicherheitsprozess, der auf den Anwendungsgatewayinstanzen ausgeführt wird. Sie können diese Protokolleinträge ohne Gefahr ignorieren.
Für die SKU Application Gateway Standard und WAF (v1)
| Wert | BESCHREIBUNG |
|---|---|
| instanceId | Application Gateway-Instanz, von der die Anforderung bereitgestellt wurde |
| clientIP | Ursprungs-IP für die Anforderung |
| clientPort | Ursprungsport für die Anforderung |
| httpMethod | Von der Anforderung verwendete HTTP-Methode |
| requestUri | URI der empfangenen Anforderung |
| RequestQuery | Server-Routed: Back-End-Poolinstanz, an die die Anforderung gesendet wurde.X-AzureApplicationGateway-LOG-ID: Für die Anforderung verwendete Korrelations-ID. Kann für die Behandlung von Datenverkehrsproblemen auf den Back-End-Servern verwendet werden. SERVER-STATUS: HTTP-Antwortcode, den Application Gateway vom Back-End empfangen hat. |
| UserAgent | Benutzer-Agent aus dem HTTP-Anforderungsheader |
| httpStatus | HTTP-Statuscode, der vom Application Gateway an den Client zurückgegeben wurde |
| httpVersion | HTTP-Version der Anforderung |
| receivedBytes | Größe des empfangenen Pakets in Byte |
| sentBytes | Größe des gesendeten Pakets in Byte |
| timeTaken | Dauer (in Millisekunden), bis eine Anforderung verarbeitet und die dazugehörige Antwort gesendet wurde. Dies wird als Intervall zwischen dem Zeitpunkt, zu dem Application Gateway das erste Byte einer HTTP-Anforderung empfängt, bis zu dem Zeitpunkt berechnet, zu dem der Vorgang zum Senden der Antwort abgeschlossen ist. Hierbei ist der Hinweis wichtig, dass das Feld „Time-Taken“ normalerweise die Zeitdauer enthält, die von den Anforderungs- und Antwortpaketen für die Übermittlung über das Netzwerk benötigt wird. |
| sslEnabled | Gibt an, ob für die Kommunikation mit den Back-End-Pools TLS/SSL verwendet wurde. Gültige Werte sind „on“ und „off“. |
| host | Der Hostname, für den die Anforderung an den Back-End-Server gesendet wurde. Wenn der Back-End-Hostname überschrieben wird, wird es diesem Namen sichtbar. |
| originalHost | Der Hostname, für den die Anforderung des Clients durch Application Gateway empfangen wurde |
{
"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"
}
}
Informationen zu Fehlercodes
Wenn Application Gateway die Anforderung nicht abschließen kann, wird einer der folgenden Ursachencodes im Feld für error_info des Zugriffsprotokolls gespeichert.
| 4XX-Fehler | (Die 4xx-Fehlercodes geben an, dass ein Problem mit der Anforderung des Clients aufgetreten ist und Application Gateway diese nicht erfüllen kann.) |
|---|---|
| ERRORINFO_INVALID_METHOD | Der Client hat eine nicht RFC-konforme Anforderung gesendet. Mögliche Ursachen: Der Client verwendet vom Server nicht unterstützte HTTP-Methoden, die Methoden wurden falsch geschrieben oder die Version des HTTP-Protokolls ist nicht kompatibel. |
| ERRORINFO_INVALID_REQUEST | Der Server kann die Anforderung aufgrund einer falschen Syntax nicht erfüllen. |
| ERRORINFO_INVALID_VERSION | Application Gateway hat eine Anforderung mit einer ungültigen oder nicht unterstützten HTTP-Version erhalten. |
| ERRORINFO_INVALID_09_METHOD | Der Client hat eine Anforderung mit Version 0.9 des HTTP-Protokolls gesendet. |
| ERRORINFO_INVALID_HOST | Der im Header „Host“ angegebene Wert fehlt, ist falsch formatiert oder stimmt nicht mit dem erwarteten Hostwert überein (wenn kein Basislistener vorhanden ist und keine Hostnamen der Listeners für mehrere Standorte mit dem Host übereinstimmen). |
| ERRORINFO_INVALID_CONTENT_LENGTH | Die Länge des vom Client im Header „content-Length“ angegebenen Inhalts stimmt nicht mit der tatsächlichen Länge des Inhalts in der Anforderung überein. |
| ERRORINFO_INVALID_METHOD_TRACE | Der Client hat eine TRACE-Methode für HTTP gesendet, die von Application Gateway nicht unterstützt wird. |
| ERRORINFO_CLIENT_CLOSED_REQUEST | Der Client hat die Verbindung mit Application Gateway beendet, bevor das Leerlauftimeout abgelaufen ist. Überprüfen Sie, ob der Zeitraum des Clienttimeouts größer als der des Leerlauftimeouts für Application Gateway ist. |
| ERRORINFO_REQUEST_URI_INVALID | Gibt ein Problem mit dem URI (Uniform Resource Identifier) an, der in der Anforderung des Clients bereitgestellt wird |
| ERRORINFO_HTTP_NO_HOST_HEADER | Der Client hat eine Anforderung ohne Hostheader gesendet. |
| ERRORINFO_HTTP_TO_HTTPS_PORT | Der Client hat eine einfache HTTP-Anforderung an einen HTTPS-Port gesendet. |
| ERRORINFO_HTTPS_NO_CERT | Gibt an, dass der Client während der gegenseitigen TLS-Authentifizierung kein gültiges und ordnungsgemäß konfiguriertes TLS-Zertifikat sendet |
| 5XX-Fehler | Beschreibung |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | Application Gateway kann keine aktiven oder erreichbaren Back-End-Server finden, um eingehende Anforderungen zu verarbeiten. |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | Der Back-End-Server hat die Verbindung unerwartet oder vor Abschluss der Verarbeitung der Anforderung beendet. Das geschieht möglicherweise, weil der Back-End-Server unter anderem seine Grenzwerte erreicht oder abstürzt. |
| ERRORINFO_UPSTREAM_TIMED_OUT | Die mit dem Server hergestellte TCP-Verbindung wurde beendet, da die Verbindung den konfigurierten Timeoutwert überschritten hatte. |
Leistungsprotokoll
Das Leistungsprotokoll wird nur generiert, wenn Sie es auf jeder Application Gateway-Instanz gemäß den obigen Schritten aktiviert haben. Die Daten werden in dem Speicherkonto gespeichert, das Sie beim Aktivieren der Protokollierung angegeben haben. Die Daten für das Leistungsprotokoll werden in Intervallen von einer Minute generiert. Diese Funktion ist nur für die v1-SKU verfügbar. Verwenden Sie für die v2-SKU Metriken für die Leistungsdaten. Die folgenden Daten werden protokolliert:
| Wert | BESCHREIBUNG |
|---|---|
| instanceId | Application Gateway-Instanz, für die Leistungsdaten generiert werden. Für ein Anwendungsgateway mit mehreren Instanzen ist eine Zeile pro Instanz vorhanden. |
| healthyHostCount | Anzahl fehlerfreier Hosts im Back-End-Pool |
| unHealthyHostCount | Anzahl fehlerhafter Hosts im Back-End-Pool |
| requestCount | Anzahl von bereitgestellten Anforderungen |
| latency | Durchschnittliche Wartezeit (in Millisekunden) für Anforderungen von der Instanz an das Back-End, das die Anforderungen verarbeitet. |
| failedRequestCount | Anzahl von fehlerhaften Anforderungen |
| throughput | Durchschnittlicher Durchsatz seit dem letzten Protokoll, gemessen in Bytes pro Sekunde. |
{
"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"
}
}
Hinweis
Latenz wird von dem Zeitpunkt, zu dem das erste Byte der HTTP-Anforderung empfangen wird, bis zu dem Zeitpunkt berechnet, zu dem das letzte Byte der HTTP-Antwort gesendet wird. Dies ist die Summe der Application Gateway-Verarbeitungszeit plus Netzwerkkosten zum Back-End plus die Zeit, die das Back-End zum Verarbeiten der Anforderung benötigt.
Firewallprotokoll
Das Firewallprotokoll wird nur generiert, wenn Sie es für jedes Anwendungsgateway gemäß den obigen Schritten aktiviert haben. Für dieses Protokoll muss zudem die Web Application Firewall auf einem Anwendungsgateway konfiguriert sein. Die Daten werden in dem Speicherkonto gespeichert, das Sie beim Aktivieren der Protokollierung angegeben haben. Die folgenden Daten werden protokolliert:
| Wert | BESCHREIBUNG |
|---|---|
| instanceId | Application Gateway-Instanz, für die Firewalldaten generiert werden. Für ein Anwendungsgateway mit mehreren Instanzen ist eine Zeile pro Instanz vorhanden. |
| clientIp | Ursprungs-IP für die Anforderung |
| clientPort | Ursprungsport für die Anforderung |
| requestUri | URI der empfangenen Anforderung |
| ruleSetType | Regelsatztyp: Der verfügbare Wert ist OWASP. |
| ruleSetVersion | Verwendete Regelsatzversion. Verfügbare Werte sind 2.2.9 und 3.0. |
| ruleId | Regel-ID des auslösenden Ereignisses |
| message | Benutzerfreundliche Meldung für das auslösende Ereignis. Weitere Details im Abschnitt „Details“. |
| action | Aktion, die für die Anforderung durchgeführt wird. Verfügbare Werte sind „Blocked“ (Blockiert) und „Allowed“ (Zulässig) für benutzerdefinierte Regeln, „Matched“ (Übereinstimmend), wenn eine Regel mit einem Teil der Anforderung übereinstimmt, und „Detected“ (Erkannt) und „Blocked“ (Blockiert), beide für obligatorische Regeln, je nachdem, ob sich die WAF im Erkennungs- oder Präventionsmodus befindet. |
| site | Standort, für den das Protokoll generiert wurde. Derzeit ist nur „Global“ aufgeführt, da Regeln global sind. |
| Details | Details zum auslösenden Ereignis |
| details.message | Beschreibung der Regel |
| details.data | Spezifische Daten in der Anforderung, die eine Übereinstimmung mit der Regel ergeben |
| details.file | Konfigurationsdatei, die die Regel enthalten hat |
| details.line | Nummer der Zeile in der Konfigurationsdatei, die das Ereignis ausgelöst hat |
| hostname | Hostname oder IP-Adresse für Application Gateway. |
| transactionId | Eindeutige ID für eine bestimmte Transaktion, die Sie beim Gruppieren mehrerer Regelverstöße innerhalb derselben Anforderung unterstützt. |
{
"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"
}
}
Anzeigen und Analysieren des Aktivitätsprotokolls
Mit einer der folgenden Methoden können Sie die Aktivitätsprotokolldaten anzeigen und analysieren:
- Azure-Tools: Rufen Sie Informationen aus dem Aktivitätsprotokoll über Azure PowerShell, über die Azure-Befehlszeilenschnittstelle, mithilfe der Azure-REST-API oder über das Azure-Portal ab. Detaillierte Anleitungen für die einzelnen Methoden finden Sie im Artikel Überwachen von Vorgängen mit dem Ressourcen-Manager .
- Power BI: Falls Sie noch kein Power BI-Konto besitzen, können Sie es kostenlos testen. Mithilfe der Power BI-Vorlagen-Apps können Sie Ihre Daten analysieren.
Anzeigen und Analysieren der Zugriffs-, Leistungs- und Firewallprotokolle
Azure Monitor-Protokolle können die Indikator- und Ereignisprotokolldateien aus Ihrem Blobspeicherkonto erfassen. Die Anwendung umfasst Visualisierungen und leistungsfähige Suchfunktionen zum Analysieren Ihrer Protokolle.
Sie können auch eine Verbindung mit Ihrem Speicherkonto herstellen und die JSON-Protokolleinträge für Zugriffs- und Leistungsprotokolle abrufen. Nachdem Sie die JSON-Dateien heruntergeladen haben, können Sie diese in das CSV-Format konvertieren oder in Excel, Power BI oder einem anderen Datenvisualisierungstool anzeigen.
Tipp
Wenn Sie mit Visual Studio und den grundlegenden Konzepten zum Ändern der Werte für Konstanten und Variablen in C# vertraut sind, können Sie die Protokollkonvertierungstools von GitHub verwenden.
Analysieren der Zugriffsprotokolle mit GoAccess
Wir haben eine Resource Manager-Vorlage veröffentlicht, die die beliebte GoAccess-Protokollanalyse für Application Gateway-Zugriffsprotokolle installiert und ausführt. GoAccess stellt wertvolle HTTP-Datenverkehrsstatistiken bereit, z.B. eindeutige Besucher, angeforderte Dateien, Hosts, Betriebssysteme, Browser, HTTP-Statuscodes und vieles mehr. Weitere Informationen finden Sie in der Infodatei im Resource Manager-Vorlagenordner auf GitHub.
Nächste Schritte
- Visualisieren von Indikator- und Ereignisprotokollen mit Azure Monitor-Protokollen
- Blogbeitrag Visualize your Azure activity log with Power BI (Visualisieren von Azure-Aktivitätsprotokollen mit Power BI)
- Blogbeitrag View and analyze Azure activity logs in Power BI and more (Anzeigen und Analysieren von Azure-Aktivitätsprotokollen in Power BI und mehr)