Logs

O Bot Manager escreve um log de report. Cada linha é um objeto JSON que nomeia a requisição, a pontuação que a função calculou para ela, as regras que a requisição correspondeu e a ação que a função aplicou. O argumento internal_logs define para quais requisições a função escreve uma linha, e log_tag define a tag que identifica a instância de onde a linha veio. Para mais informações, consulte Argumentos.

As duas edições não escrevem o mesmo payload. O Bot Manager Lite escreve 14 campos, e o Bot Manager documenta 25. Uma linha lida de uma instância Lite não é uma linha da edição completa com campos faltando.

Esta página lista os campos que cada edição escreve, os valores que classified e bot_category assumem, o que o veredito de avaliação pendente significa, onde cada log aparece e por quanto tempo cada dataset é retido.

Campos

Toda linha de report abre com o mesmo prefixo e depois um único objeto JSON. O prefixo é [Bot-Protection][<log_tag>] Report:, onde o segundo colchete carrega o valor do argumento log_tag da instância. O host não está no prefixo. Ele é um campo dentro do objeto, então o prefixo identifica a instância que escreveu a linha e nada mais sobre a requisição.

Campos do Bot Manager Lite

Uma linha do Bot Manager Lite, de uma instância com a tag storefront-bots:

O Bot Manager Lite escreve estes 14 campos, e escreve os 14 em toda linha:

O Bot Manager Lite não carrega um campo log_tag, porque o prefixo já nomeia a instância. Ele também não carrega array de cabeçalhos, campo de CAPTCHA nem campo de cookie. A pontuação é a soma dos incrementos das regras em matched_rules, que a tabela de regras publica uma a uma. Para mais informações, consulte Bot Manager Lite.

Campos do Bot Manager

O Bot Manager documenta 25 campos. Dez deles, e o tipo de mais dois, são a diferença entre as duas edições:

Mais uma chave, concat_headers, aparece em um objeto de report do Bot Manager sem definição publicada. O seu valor é uma lista de nomes de cabeçalho separados por vírgula.

request_headers é limitado. Cada chave e cada valor descontam de um total de 10.000 caracteres, e depois que esse total é alcançado nenhum outro cabeçalho é escrito no array. O valor de um cabeçalho é codificado em base64, então bnVsbA== no array é a codificação de null, que é o que um cabeçalho que a requisição não enviou decodifica. Para mais informações, consulte Limites de Firewall.

Dois campos apontam para a configuração, não para a requisição. Uma instância que não define log_tag recebe a tag do host para o qual a requisição foi feita, então duas instâncias que mantêm o padrão entregue são indistinguíveis no log. O fingerprint é o identificador que a Azion deriva para um cliente, o que o torna o campo que agrupa as requisições repetidas de um dispositivo. O Bot Manager consolida os dados de fingerprint entre requisições e a GraphQL API os devolve, então você pode agir sobre um dispositivo ou usuário identificado como bad bot em um threshold, em vez de sobre uma única requisição.

Classificação

Dois campos carregam o veredito, e eles são calculados de formas diferentes. classified compara a pontuação com o threshold em vigor. bot_category nomeia as categorias das regras que a requisição correspondeu, qualquer que seja o veredito.

classified é, portanto, relativo, e não uma propriedade da requisição por si só. A mesma pontuação, das mesmas regras, é classificada de dois jeitos sob dois thresholds:

Elevar um threshold reetiqueta o tráfego, além de impedir que a ação seja executada. Uma contagem de classificações só é comparável entre dois períodos quando o threshold foi o mesmo nos dois, então registre o threshold ao lado de qualquer número que você tirar dos gráficos de classificação.

bot_category é derivado das regras que a requisição correspondeu, e é uma lista unida por vírgula, não um valor único. Uma requisição que correspondeu a regras de duas categorias carrega as duas, como Bad Bot Signatures, Malicious Intent detected. Como as categorias seguem as regras e o veredito segue o threshold, uma linha classificada como legitimate ainda pode nomear categorias de bad bot: as categorias dizem quais regras dispararam, e classified diz se o total delas cruzou o threshold.

Os pares que os dois campos assumem, e como uma requisição chega a cada um, estão abaixo. Real-Time Metrics agrupa os seus gráficos pelos mesmos pares.

O log escreve os quatro valores de classified em minúsculas, como bad bot, good bot, legitimate e under evaluation. Os gráficos construídos sobre eles escrevem os mesmos valores com iniciais maiúsculas, então um valor lido de um gráfico e um valor lido de uma linha diferem na caixa e em mais nada.

Cada valor tem uma condição. legitimate significa que a função não identificou um bot e tinha dados de fingerprint suficientes para descartar um ataque. good bot significa que a função não identificou ataque e correspondeu o user agent a um padrão de user agent bom. bad bot significa que a requisição alcançou o threshold de pontuação, ou que a função a identificou como um ataque. under evaluation significa que a função não identificou um bot e não tinha dados de fingerprint suficientes para descartar um ataque.

Para uma requisição classificada como good bot, a categoria é o tipo de bot bom que o seu user agent correspondeu: Aggregator Bot, Enterprise Bot, Monitoring Bot, Search Engine Bot ou Social Network Bot.

Under evaluation

under evaluation é o veredito que a função registra quando não identificou um bot e ainda não tem dados de fingerprint suficientes para descartar um ataque. Tanto classified quanto bot_category o carregam, e ele é um dos quatro valores entre os quais os gráficos de tráfego dividem as requisições.

Um fingerprint fica sob avaliação até o Bot Manager consolidar dados suficientes sobre ele, e é por isso que um fingerprint que a função está vendo pela primeira vez carrega o veredito. Para mais informações, consulte Score de bots.

O veredito é uma ausência de evidência, não um achado. Contar uma linha sob avaliação como tráfego legítimo superestima o seu tráfego limpo, e contá-la como tráfego de bot superestima o oposto. Leia os três vereditos decididos um contra o outro e leia este como a parcela de tráfego que a função ainda não situou.

Onde os logs aparecem

Quatro superfícies carregam dados do Bot Manager, e elas não carregam a mesma coisa. Real-Time Events e Data Stream carregam a linha de report em si, campo por campo. Real-Time Metrics e a GraphQL API de Real-Time Metrics carregam contagens agregadas a partir desses campos, então uma requisição isolada não é recuperável em nenhuma das duas.

No Real-Time Events, uma linha de report é um registro do dataset functionConsoleEvents, consultado em https://api.azion.com/v4/events/graphql:

A consulta responde 200 e devolve um registro por linha que a função escreveu. line guarda o prefixo e o objeto JSON juntos, level é LOG e lineSource é CONSOLE. functionId é o id da função instalada, e configurationId é o id do workload em que a requisição chegou, não o id do firewall em que a instância é executada. Como toda linha nomeia a sua instância no prefixo, o valor de log_tag é o que separa as linhas de uma instância das de outra. No Azion Console os mesmos registros são renderizados com uma coluna Time e uma coluna Log Body, e a interface não carrega nenhum campo próprio do Bot Manager: o objeto JSON chega inteiro, em vez de dividido em colunas que você possa ordenar. Para mais informações, consulte Real-Time Events.

Azion CLI não devolve essas linhas. Enquanto uma instância pontua tráfego real, azion logs cells --function-id <function-id> e azion logs http não imprimem nada, com ou sem filtro, ao passo que o dataset devolve toda linha que a função escreve. Um resultado vazio da CLI, portanto, não mostra uma função silenciosa.

O Data Stream encaminha a linha de report para um endpoint que você configura, lendo-a da data source Functions, o que exige assinatura de Functions. O encaminhamento é em tempo real, então um dashboard ou um alerta construído sobre esse endpoint vê uma linha no momento em que a função a escreve. Os campos que um endpoint recebe dependem do tipo dele. Para mais informações, consulte Endpoints.

O Real-Time Metrics carrega uma página Bot Manager com um dashboard Overview e um dashboard Breakdown. Os seus gráficos agregam a classificação que o log carrega: Top Bot Action, por exemplo, agrupa as requisições pela ação que a função aplicou. As métricas são geradas quase em tempo real, com um intervalo de agregação de até 60 segundos. Para mais informações, consulte Real-Time Metrics.

Dois datasets GraphQL carregam os mesmos dados agregados para consulta. botManagerMetrics agrupa pela classificação, pela ação, pelo modo, pelo resultado do CAPTCHA, pelo host e pela geografia de uma requisição. botManagerBreakdownMetrics agrupa pelas URLs que o tráfego de bots alcançou e pelos endereços IP de onde ele veio. Os campos de cada um estão listados na página Campos da GraphQL API de Real-Time Metrics, em botManagerMetrics e botManagerBreakdownMetrics.

Retenção

Os dois datasets GraphQL de Real-Time Metrics são retidos por períodos diferentes, porque guardam dados diferentes. botManagerMetrics é retido por 2 anos, que é também por quanto tempo os gráficos construídos sobre ele mantêm os seus dados. botManagerBreakdownMetrics é retido por 60 dias. Uma consulta que alcança mais de 60 dias para trás devolve, portanto, as contagens de classificação, e não as URLs e os endereços IP por trás delas.

O Data Stream muda a pergunta em vez de respondê-la. Ele encaminha uma cópia da linha de report para um endpoint que você controla, então por quanto tempo essa cópia sobrevive é uma propriedade do endpoint e do que você configurou nele para guardar, não do Bot Manager.

Recursos relacionados