Skip to content

Application Gateway Logs

When your application is published through the hub Application Gateway (Shared services), its access and firewall (WAF) logs help you answer "was my request blocked, and why?". On platforms that send the gateway diagnostics to a central Log Analytics workspace, you can query them with Kusto Query Language (KQL).

Platform-specific

Where the logs go, the table they land in and the group that gives access depend on your platform. The workspace and group names below are placeholders. Ask your platform team.

Get access

Access is given through an Entra ID group. In the example platform the reader group gives two things:

Permission Scope
Read on the diagnostics table The central Log Analytics workspace (<central workspace>)
Monitoring Reader The Application Gateway resource

Ask your platform team to add you to the reader group (<application gateway readers group>). Group membership is managed like any other access, see Access, groups and PIM.

Query the logs

  1. Open the Application Gateway resource (<application gateway name>) in the Azure portal.
  2. Select Logs. The query runs against the central workspace.
  3. Query the table that holds the gateway diagnostics.

In the example platform, the logs are in the legacy table AzureDiagnostics. It is shared by many resource types, so always filter on the resource type and the log category:

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where TimeGenerated > ago(1h)
| take 50

Use ApplicationGatewayAccessLog as category for access logs. The columns differ per category. Inspect a few rows first with take. The platform may later move to resource-specific tables, which then change the table names. Your platform team announces that.

Where the logs come from

Logs only exist when a diagnostic setting sends them to a workspace. The shared services Application Gateway code does not create a diagnostic setting for the gateway (only for some other shared services). On a platform that runs it, the setting comes from elsewhere, for example from policy. If you see no rows, ask your platform team whether and where the gateway logs are sent, before you assume that nothing was blocked.

From a blocked request to an exception

The firewall log of a blocked request tells you which managed rule matched. Use it to build the request for an exception (WAF false positives and exclusions):

  1. Find the entry for your request: filter on the time, the host name and the client address.
  2. Note the rule ID, the rule group and the matched argument, header or URI.
  3. Check that the request is legitimate and that the block is a false positive, not an attack.
  4. Send these details to the platform team, with the reason and the narrowest match that works (one header value, one client address or one URI). The platform team and your security officer decide. The module has limits on exceptions (WAF exceptions), so a broad request is likely to be refused.

Keep the policy mode in mind: in Detection mode the WAF only logs, in Prevention mode it blocks. Ask which mode applies to your listener.

Firewall logs

Logs of the hub Azure Firewall work in the same way: a reader group, a central workspace and tables such as AZFWNetworkRule and AZFWApplicationRule. See Firewall rules and the firewall runbook for how to use them when a connection is blocked.