Logs de diagnóstico para o Application Gateway
Os logs do Application Gateway fornecem informações detalhadas para eventos relacionados a um recurso e suas operações. Esses logs estão disponíveis para eventos como Acesso, Atividade, Firewall e Desempenho (somente para V1). As informações granulares nos logs são úteis na solução de um problema ou na criação de um painel de análise consumindo esses dados brutos.
Os logs estão disponíveis para todos os recursos do Application Gateway; No entanto, para consumi-los, você deve habilitar sua coleta em um local de armazenamento de sua escolha. O registro em log no Gateway de Aplicativo do Azure é habilitado pelo serviço Azure Monitor. Recomendamos o uso do espaço de trabalho do Log Analytics, pois você pode usar prontamente suas consultas predefinidas e definir alertas com base em condições de log específicas.
Tipos de logs de diagnóstico
Você pode usar diferentes tipos de logs no Azure para gerenciar e solucionar problemas de gateways de aplicativos. Você pode saber mais sobre esses tipos abaixo:
- Log de atividades: você pode usar os logs de atividade do Azure (anteriormente conhecidos como logs operacionais e logs de auditoria) para exibir todas as operações enviadas à sua assinatura do Azure e seu status. As entradas de registos de atividades são recolhidas por predefinição e pode visualizá-las no portal do Azure.
- Log de acesso: você pode usar esse log para exibir padrões de acesso do Application Gateway e analisar informações importantes. Isso inclui o IP do chamador, URL solicitado, latência de resposta, código de retorno e bytes de entrada e saída. Um log de acesso é coletado a cada 60 segundos. Esse log contém um registro por instância do Application Gateway. A instância do Application Gateway é identificada pela propriedade instanceId.
- Log de desempenho: você pode usar esse log para exibir o desempenho das instâncias do Application Gateway. Esse log captura informações de desempenho para cada instância, incluindo o total de solicitações atendidas, a taxa de transferência em bytes, o total de solicitações atendidas, a contagem de solicitações com falha e a contagem de instâncias de back-end íntegras e não íntegras. Um log de desempenho é coletado a cada 60 segundos. O log de desempenho está disponível apenas para a SKU v1. Para o SKU v2, use Métricas para dados de desempenho.
- Log de firewall: você pode usar esse log para exibir as solicitações registradas por meio do modo de deteção ou prevenção de um gateway de aplicativo configurado com o firewall de aplicativo Web. Os logs do firewall são coletados a cada 60 segundos.
Nota
Os logs estão disponíveis apenas para recursos implantados no modelo de implantação do Azure Resource Manager. Não é possível usar logs para recursos no modelo de implantação clássico. Para uma melhor compreensão dos dois modelos, consulte o artigo Understanding Resource Manager deployment and classic deployment .
Locais de armazenamento
Você tem as seguintes opções para armazenar os logs em seu local preferido.
Espaço de trabalho analítico de log: essa opção permite que você use prontamente as consultas, visualizações e alertas predefinidos com base em condições de log específicas. As tabelas usadas pelos logs de recursos no espaço de trabalho de análise de log dependem do tipo de coleção que o recurso está usando:
Diagnóstico do Azure: os dados são gravados na tabela do Diagnóstico do Azure. A tabela de Diagnóstico do Azure é compartilhada entre vários tipos de recursos, com cada um deles adicionando seus próprios campos personalizados. Quando o número de campos personalizados ingeridos à tabela de Diagnóstico do Azure excede 500, novos campos não são adicionados como nível superior, mas adicionados ao campo "AdditionalFields" como pares de valor de chave dinâmica.
Específico do recurso(recomendado): os dados são gravados em tabelas dedicadas para cada categoria do recurso. No modo específico do recurso, cada categoria de log selecionada na configuração de diagnóstico recebe sua própria tabela dentro do espaço de trabalho escolhido. Isso tem vários benefícios, incluindo:
- Manipulação de dados mais fácil em consultas de log
- Melhor capacidade de descoberta de esquemas e suas estruturas
- Desempenho melhorado em termos de latência de ingestão e tempos de consulta
- A capacidade de atribuir direitos de controle de acesso baseados em função do Azure a tabelas específicas
Para o Application Gateway, o modo específico do recurso cria três tabelas:
Nota
A opção específica do recurso está atualmente disponível em todas as regiões públicas.
Os usuários existentes podem continuar usando o Diagnóstico do Azure ou podem optar por tabelas dedicadas alternando a alternância nas configurações de Diagnóstico para Específico do recurso ou para Dedicado no destino da API. O modo duplo não é possível. Os dados em todos os logs podem fluir para o Diagnóstico do Azure ou para tabelas dedicadas. No entanto, você pode ter várias configurações de diagnóstico em que um fluxo de dados é para o diagnóstico azure e outro está usando recursos específicos ao mesmo tempo.
Selecionando a tabela de destino em Análise de log: todos os serviços do Azure eventualmente usam as tabelas específicas de recursos. Como parte dessa transição, você pode selecionar a tabela específica de diagnóstico ou recurso do Azure na configuração de diagnóstico usando um botão de alternância. A alternância é definida como Específico do recurso por padrão e, nesse modo, os logs para novas categorias selecionadas são enviados para tabelas dedicadas no Log Analytics, enquanto os fluxos existentes permanecem inalterados. Veja o seguinte exemplo.
Transformações do espaço de trabalho: optar pela opção específica do recurso permite filtrar e modificar seus dados antes que eles sejam ingeridos com transformações do espaço de trabalho. Isso fornece controle granular, permitindo que você se concentre nas informações mais relevantes dos logs de lá, reduzindo os custos de dados e aumentando a segurança. Para obter instruções detalhadas sobre como configurar transformações de espaço de trabalho, consulte:Tutorial: Adicionar uma transformação de espaço de trabalho aos Logs do Azure Monitor usando o portal do Azure.
Exemplos de otimização de logs de acesso usando transformações de espaço de trabalho
Exemplo 1: Projeção seletiva de colunas: Imagine que você tem logs de acesso ao gateway de aplicativo com 20 colunas, mas está interessado em analisar dados de apenas 6 colunas específicas. Usando a transformação do espaço de trabalho, você pode projetar essas 6 colunas em seu espaço de trabalho, excluindo efetivamente as outras 14 colunas. Embora os dados originais dessas colunas excluídas não sejam armazenados, os espaços reservados vazios para elas ainda aparecem na folha Logs. Essa abordagem otimiza o armazenamento e garante que apenas os dados relevantes sejam retidos para análise.
Nota
Na folha Logs, selecionar a opção Try New Log Analytics oferece maior controle sobre as colunas exibidas na interface do usuário.
Exemplo 2: Concentrando-se em códigos de status específicos: Ao analisar logs de acesso, em vez de processar todas as entradas de log, você pode escrever uma consulta para recuperar apenas linhas com códigos de status HTTP específicos (como 4xx e 5xx). Uma vez que, idealmente, a maioria dos pedidos se enquadra nas categorias 2xx e 3xx (que representam respostas bem-sucedidas), concentrar-se nos códigos de estado problemáticos reduz o conjunto de dados. Essa abordagem direcionada permite extrair as informações mais relevantes e acionáveis, tornando-as benéficas e econômicas.
Estratégia de transição recomendada para passar do diagnóstico do Azure para uma tabela específica de recursos:
- Avaliar a retenção de dados atual: determine a duração pela qual os dados são atualmente retidos na tabela de diagnóstico do Azure (por exemplo: suponha que a tabela de diagnóstico retém dados por 15 dias).
- Estabelecer retenção específica de recursos: implemente uma nova configuração de Diagnóstico com tabela específica de recurso.
- Coleta de dados paralela: por um período temporário, colete dados simultaneamente no Diagnóstico do Azure e nas configurações específicas do recurso.
- Confirmar a precisão dos dados: verifique se a coleta de dados é precisa e consistente em ambas as configurações.
- Remover configuração de diagnóstico do Azure: remova a configuração de Diagnóstico do Azure para evitar a coleta de dados duplicados.
Outros locais de armazenamento:
- Conta de Armazenamento do Azure: as contas de armazenamento são melhor usadas para logs quando os logs são armazenados por um período mais longo e revisados quando necessário.
- Hubs de Eventos do Azure: os Hubs de Eventos são uma ótima opção para integração com outras ferramentas de gerenciamento de eventos e informações de segurança (SIEM) para receber alertas sobre seus recursos.
- Integrações de parceiros do Azure Monitor.
Saiba mais sobre os destinos das configurações de diagnóstico do Azure Monitor .
Habilitar o registro em log por meio do PowerShell
O registo de atividades é ativado automaticamente para todos os recursos do Resource Manager. Você deve habilitar o log de acesso e desempenho para começar a coletar os dados disponíveis por meio desses logs. Para habilitar o registro em log, use as seguintes etapas:
Anote o ID de recurso da conta de armazenamento, onde os dados de registo são armazenados. Esse valor tem o formato: /subscriptions/subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name>.< Pode utilizar qualquer conta de armazenamento na sua subscrição. Pode utilizar o portal do Azure para encontrar estas informações.
Anote o ID de recurso do gateway de aplicativo para o qual o log está habilitado. Esse valor tem o formato: /subscriptions/subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>.< Pode utilizar o portal para encontrar estas informações.
Ative o registo de diagnósticos com o seguinte cmdlet do PowerShell:
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
Gorjeta
Os logs de atividades não exigem uma conta de armazenamento separada. A utilização do armazenamento para registo do acesso e do desempenho incorre em encargos de serviços.
Ativar o registo através do portal do Azure
No portal do Azure, localize seu recurso e selecione Configurações de diagnóstico.
Para o Application Gateway, três logs estão disponíveis:
- Registo de acesso
- Registo de desempenho
- Registo da firewall
Para começar a coletar dados, selecione Ativar diagnóstico.
A página Definições de diagnóstico fornece as definições para os registos de diagnóstico. Neste exemplo, o Log Analytics armazena os logs. Também pode utilizar os hubs de eventos e uma conta de armazenamento para guardar os registos de diagnóstico.
Digite um nome para as configurações, confirme as configurações e selecione Salvar.
Registo de atividades
O Azure gera o log de atividades por padrão. Os logs são preservados por 90 dias no repositório de logs de eventos do Azure. Saiba mais sobre esses logs lendo o artigo Exibir eventos e registro de atividades.
Registo de acesso
O log de acesso será gerado somente se você o tiver habilitado em cada instância do Application Gateway, conforme detalhado nas etapas anteriores. Os dados são armazenados na conta de armazenamento que você especificou quando ativou o registro. Cada acesso do Application Gateway é registrado no formato JSON, conforme mostrado abaixo.
Para gateway de aplicativo e WAF v2 SKU
Nota
Para obter informações relacionadas ao proxy TLS/TCP, visite a referência de dados.
| valor | Description |
|---|---|
| instanceId | Instância do Application Gateway que atendeu à solicitação. |
| clientIP [en] | IP do cliente imediato do Application Gateway. Se outro proxy estiver à frente do gateway de aplicativo, isso exibirá o IP desse proxy de frontamento. |
| httpMethod | Método HTTP usado pela solicitação. |
| requestUri | URI da solicitação recebida. |
| UserAgent | Agente de usuário do cabeçalho de solicitação HTTP. |
| httpStatus | Código de status HTTP retornado ao cliente do Application Gateway. |
| Versão http | Versão HTTP da solicitação. |
| receivedBytes | Tamanho do pacote recebido, em bytes. |
| enviBytes | Tamanho do pacote enviado, em bytes. |
| clientResponseTime | Diferença de tempo (em segundos) entre o primeiro byte e o último gateway de aplicativo de byte enviado ao cliente. Útil para avaliar o tempo de processamento do Application Gateway para respostas ou clientes lentos. |
| timeTaken | Período de tempo (em segundos) que leva para que o primeiro byte de uma solicitação de cliente seja processado e seu último byte enviado na resposta ao cliente. É importante observar que o campo Tempo gasto geralmente inclui o tempo que os pacotes de solicitação e resposta estão viajando pela rede. |
| WAFEvaluationTime | Período de tempo (em segundos) que leva para que a solicitação seja processada pelo WAF. |
| WAFMode | O valor pode ser Deteção ou Prevenção |
| transactionId | Identificador exclusivo para correlacionar a solicitação recebida do cliente |
| sslAtivado | Se a comunicação com os pools de back-end usou TLS. Os valores válidos estão ativados e desativados. |
| sslCipher | Conjunto de codificação sendo usado para comunicação TLS (se o TLS estiver habilitado). |
| sslProtocolo | Protocolo SSL/TLS sendo usado (se o TLS estiver habilitado). |
| servidorRoteado | O servidor back-end para o qual o gateway de aplicativo roteia a solicitação. |
| serverStatus | Código de status HTTP do servidor back-end. |
| serverResponseLatency | Latência da resposta (em segundos) do servidor back-end. |
| host | Endereço listado no cabeçalho do host da solicitação. Se reescrito usando a regravação de cabeçalho, este campo contém o nome do host atualizado |
| originalRequestUriWithArgs | Este campo contém o URL do pedido original |
| requestUri | Este campo contém a URL após a operação de regravação no Application Gateway |
| upstreamSourcePort [en] | A porta de origem usada pelo Application Gateway ao iniciar uma conexão com o destino de back-end |
| originalAnfitrião | Este campo contém o nome do host da solicitação original |
| error_info | A razão para o erro 4xx e 5xx. Exibe um código de erro para uma solicitação com falha. Mais detalhes em Informações de código de erro. |
| contentType | O tipo de conteúdo ou dados que estão sendo processados ou entregues pelo gateway de aplicativo |
{
"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"
}
}
Nota
Os logs de acesso com o valor clientIP 127.0.0.1 são originários de um processo de segurança interno em execução nas instâncias do gateway de aplicativo. Você pode ignorar com segurança essas entradas de log.
Para Application Gateway Standard e WAF SKU (v1)
| valor | Description |
|---|---|
| instanceId | Instância do Application Gateway que atendeu à solicitação. |
| clientIP [en] | IP de origem para a solicitação. |
| clientPort [en] | Porta de origem para a solicitação. |
| httpMethod | Método HTTP usado pela solicitação. |
| requestUri | URI da solicitação recebida. |
| RequestQuery | Server-Routed: instância do pool de back-end que recebeu a solicitação. X-AzureApplicationGateway-LOG-ID: ID de correlação usada para a solicitação. Ele pode ser usado para solucionar problemas de tráfego nos servidores back-end. SERVER-STATUS: Código de resposta HTTP que o Application Gateway recebeu do back-end. |
| UserAgent | Agente de usuário do cabeçalho de solicitação HTTP. |
| httpStatus | Código de status HTTP retornado ao cliente do Application Gateway. |
| Versão http | Versão HTTP da solicitação. |
| receivedBytes | Tamanho do pacote recebido, em bytes. |
| enviBytes | Tamanho do pacote enviado, em bytes. |
| timeTaken | Período de tempo (em milissegundos) que leva para uma solicitação ser processada e sua resposta ser enviada. Isso é calculado como o intervalo entre o momento em que o Application Gateway recebe o primeiro byte de uma solicitação HTTP até o momento em que a operação de envio de resposta é concluída. É importante observar que o campo Tempo gasto geralmente inclui o tempo que os pacotes de solicitação e resposta estão viajando pela rede. |
| sslAtivado | Se a comunicação com os pools de back-end usou TLS/SSL. Os valores válidos estão ativados e desativados. |
| host | O nome do host para o qual a solicitação foi enviada para o servidor back-end. Se o nome do host de back-end estiver sendo substituído, esse nome refletirá isso. |
| originalAnfitrião | O nome do host para o qual a solicitação foi recebida pelo Application Gateway do cliente. |
{
"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"
}
}
Informações sobre o código de erro
Se o gateway de aplicativo não puder concluir a solicitação, ele armazenará um dos seguintes códigos de motivo no campo error_info do log de acesso.
| 4XX Erros | (Os códigos de erro 4xx indicam que houve um problema com a solicitação do cliente e o Application Gateway não pode atendê-lo.) |
|---|---|
| ERRORINFO_INVALID_METHOD | O cliente enviou uma solicitação que não é compatível com RFC. Possíveis razões: cliente usando o método HTTP não suportado pelo servidor, método com erros ortográficos, versão do protocolo HTTP incompatível, etc. |
| ERRORINFO_INVALID_REQUEST | O servidor não pode atender à solicitação devido à sintaxe incorreta. |
| ERRORINFO_INVALID_VERSION | O gateway de aplicativo recebeu uma solicitação com uma versão HTTP inválida ou sem suporte. |
| ERRORINFO_INVALID_09_METHOD | O cliente enviou a solicitação com o protocolo HTTP versão 0.9. |
| ERRORINFO_INVALID_HOST | O valor fornecido no cabeçalho "Host" está ausente, formatado incorretamente ou não corresponde ao valor esperado do host. Por exemplo, quando não há nenhum ouvinte Básico e nenhum dos nomes de host dos ouvintes de Multisite corresponde ao host. |
| ERRORINFO_INVALID_CONTENT_LENGTH | O comprimento do conteúdo especificado pelo cliente no cabeçalho content-Length não corresponde ao comprimento real do conteúdo na solicitação. |
| ERRORINFO_INVALID_METHOD_TRACE | O cliente enviou o método HTTP TRACE, que não é suportado pelo gateway de aplicativo. |
| ERRORINFO_CLIENT_CLOSED_REQUEST | O cliente fechou a conexão com o gateway de aplicativo antes do período de tempo limite ocioso decorrer. Verifique se o período de tempo limite do cliente é maior do que o período de tempo limite ocioso para o gateway de aplicativo. |
| ERRORINFO_REQUEST_URI_INVALID | Indica problema com o URI (Uniform Resource Identifier) fornecido na solicitação do cliente. |
| ERRORINFO_HTTP_NO_HOST_HEADER | O cliente enviou uma solicitação sem cabeçalho Host. |
| ERRORINFO_HTTP_TO_HTTPS_PORT | O cliente enviou uma solicitação HTTP simples para uma porta HTTPS. |
| ERRORINFO_HTTPS_NO_CERT | Indica que o cliente não está enviando um certificado TLS válido e configurado corretamente durante a autenticação TLS mútua. |
| 5XX Erros | Description |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | O gateway de aplicativo não consegue encontrar nenhum servidor back-end ativo ou acessível para lidar com solicitações de entrada |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | O servidor back-end fechou a conexão inesperadamente ou antes que a solicitação fosse totalmente processada. Isso pode acontecer devido ao servidor back-end atingir seus limites, travar etc. |
| ERRORINFO_UPSTREAM_TIMED_OUT | A conexão TCP estabelecida com o servidor foi fechada porque a conexão levou mais tempo do que o valor de tempo limite configurado. |
Registo de desempenho
O log de desempenho será gerado somente se você o tiver habilitado em cada instância do Application Gateway, conforme detalhado nas etapas anteriores. Os dados são armazenados na conta de armazenamento que você especificou quando ativou o registro. Os dados do log de desempenho são gerados em intervalos de 1 minuto. Está disponível apenas para o SKU v1. Para o SKU v2, use Métricas para dados de desempenho. Os seguintes dados são registrados:
| valor | Description |
|---|---|
| instanceId | Instância do Application Gateway para a qual os dados de desempenho estão sendo gerados. Para um gateway de aplicativo de várias instâncias, há uma linha por instância. |
| healthyHostCount | Número de hosts íntegros no pool de back-end. |
| unHealthyHostCount | Número de hosts não íntegros no pool de back-end. |
| requestCount | Número de pedidos atendidos. |
| Latência | Latência média (em milissegundos) de solicitações da instância para o back-end que atende às solicitações. |
| failedRequestCount | Número de pedidos falhados. |
| de transferência de dados | Taxa de transferência média desde o último log, medida em bytes por segundo. |
{
"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"
}
}
Nota
A latência é calculada desde o momento em que o primeiro byte da solicitação HTTP é recebido até o momento em que o último byte da resposta HTTP é enviado. É a soma do tempo de processamento do Application Gateway mais o custo de rede para o back-end, mais o tempo que o back-end leva para processar a solicitação.
Registo da firewall
O log do firewall é gerado somente se você o tiver habilitado para cada gateway de aplicativo, conforme detalhado nas etapas anteriores. Esse log também requer que o firewall do aplicativo Web esteja configurado em um gateway de aplicativo. Os dados são armazenados na conta de armazenamento que você especificou quando ativou o registro. Os seguintes dados são registrados:
| valor | Description |
|---|---|
| instanceId | Instância do Application Gateway para a qual os dados de firewall estão sendo gerados. Para um gateway de aplicativo de várias instâncias, há uma linha por instância. |
| clienteIp | IP de origem para a solicitação. |
| clientPort [en] | Porta de origem para a solicitação. |
| requestUri | URL do pedido recebido. |
| ruleSetType | Tipo de conjunto de regras. O valor disponível é OWASP. |
| ruleSetVersion | Versão do conjunto de regras usada. Os valores disponíveis são 2.2.9 e 3.0. |
| ruleId | ID da regra do evento de acionamento. |
| mensagem | Mensagem amigável para o evento de acionamento. Mais detalhes são fornecidos na seção de detalhes. |
| action | Seguimento dado ao pedido. Os valores disponíveis são Bloqueado e Permitido (para regras personalizadas), Correspondido (quando uma regra corresponde a uma parte da solicitação) e Detetado e Bloqueado (ambos são para regras obrigatórias, dependendo se o WAF está no modo de deteção ou prevenção). |
| site | Site para o qual o log foi gerado. Atualmente, apenas Global está listado porque as regras são globais. |
| detalhes | Detalhes do evento desencadeador. |
| detalhes.mensagem | Descrição da regra. |
| detalhes.data | Dados específicos encontrados na solicitação que correspondiam à regra. |
| detalhes.arquivo | Arquivo de configuração que continha a regra. |
| detalhes.line | Número da linha no arquivo de configuração que disparou o evento. |
| Nome do anfitrião | Nome do host ou endereço IP do Application Gateway. |
| transactionId | ID exclusivo para uma determinada transação que ajuda a agrupar várias violações de regras que ocorreram dentro da mesma solicitação. |
{
"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"
}
}
Ver e analisar o registo de atividades
Pode ver e analisar os dados de registo de atividades através de um dos seguintes métodos:
- Ferramentas do Azure: recuperar informações de registo de atividades através do Azure PowerShell, a CLI do Azure, a API REST do Azure ou o portal do Azure. As instruções passo-a-passo para cada método estão detalhadas no artigo Operações de atividades com o Resource Manager.
- Power BI: se ainda não tiver uma conta do Power BI, pode experimentá-lo gratuitamente. Usando os aplicativos de modelo do Power BI, você pode analisar seus dados.
Visualize e analise os logs de acesso, desempenho e firewall
Os logs do Azure Monitor podem coletar os arquivos de log de contador e de eventos de sua conta de armazenamento de Blob. Inclui visualizações e capacidades de pesquisa poderosas para analisar os seus registos.
Também pode ligar à sua conta de armazenamento e obter as entradas de registo JSON para os registos de acesso e desempenho. Depois de transferir os ficheiros JSON, pode convertê-los em CSV e visualizá-los no Excel, Power BI ou qualquer outra ferramenta de visualização de dados.
Gorjeta
Se você estiver familiarizado com o Visual Studio e os conceitos básicos de alteração de valores para constantes e variáveis em C#, poderá usar as ferramentas de conversor de log disponíveis no GitHub.
Analisando logs de acesso através do GoAccess
Publicamos um modelo do Resource Manager que instala e executa o popular analisador de logs GoAccess para logs de acesso do Application Gateway. O GoAccess fornece estatísticas valiosas de tráfego HTTP, como visitantes únicos, arquivos solicitados, hosts, sistemas operacionais, navegadores, códigos de status HTTP e muito mais. Para obter mais detalhes, consulte o arquivo Leiame na pasta de modelo do Gerenciador de Recursos no GitHub.
Próximos passos
- Visualize logs de contadores e eventos usando logs do Azure Monitor.
- Visualize seu log de atividades do Azure com a postagem do blog do Power BI .
- Exiba e analise os logs de atividade do Azure no Power BI e mais postagens de blog.