10 padrões de filtro que são úteis para gerenciar seus logs

Aryel Evelin

18 de agosto de 2020

10 padrões de filtro que são úteis para gerenciar seus logs

18 de agosto de 2020

Os arquivos de log, que são os registros de tudo o que aconteceu em seu servidor, aplicativo ou estrutura, geralmente não são filtrados e são enormes. Continuando por páginas, esses arquivos de texto simples são embalados com toneladas de informações e são o local inicial para qualquer solução de problemas. No entanto, o desafio está em ler, compreender e interpretar arquivos de log e, em última análise, extrair a informação certa necessária para análise.

Ferramentas de gerenciamento e análise de log tornam esse trabalho mais fácil, pois filtram os detalhes necessários e fornecem o que estamos procurando, mas cabe ao usuário fornecer a consulta certa e buscar os resultados certos. Existem vários tipos de operadores que podem ser usados em uma consulta; no entanto, usar apenas um operador simples pode não ajudar em cenários complexos. É aqui que os padrões de filtro, que combinam operadores, são úteis. Abaixo está uma lista de padrões de filtro comuns e úteis que podem ser usados em consultas, junto com casos de uso.

e contémConsidere um cenário em que você precisa filtrar as linhas de log onde seus logs de auditoria são limpos nos logs de eventos do Windows. Você pode usar esta consulta: Aqui, e é usado para filtrar as condições, como informações e mensagem, enquanto contém pode buscar a mensagem exata.

logtype="Windows Event Logs" and level contains "Information" and the message contains "The audit log was cleared"
e,! =Para ignorar verificações de integridade em um ambiente de Internet Information Services (IIS), você pode usar: Aqui,! = Não é igual a, o que significa filtrar as linhas em que a condição não satisfaz ELB-HealthChecker / 1.0 e ELB-HealthChecker / 2.0.

logtype="IIS Access Logs" and useragent!="ELB-HealthChecker/1.0" and useragent!="ELB-HealthChecker/2.0"
ou ouEste é um caso simples, mas você o vê usado com frequência para citar logs de eventos do Windows em que qualquer uma das duas IDs de evento que denotam um travamento do aplicativo que precisa ser filtrado.

logtype="Windows Event Logs" and (eventid="1000" or eventid="1002" or eventid="1001")

ID de evento 1000, 1001 ou 1002 – todos eles denotam um aplicativo travado ou com falha, portanto, ou podem ser usados.
e, ou,! =, contémAs consultas costumam ser complexas quando existem várias condições. Você pode querer que a linha de log contenha algumas mensagens enquanto ignora outras. Também pode haver momentos em que você deseja capturar um de dois eventos e ter uma terceira parte obrigatória. Aqui está um exemplo de criação de um evento Amazon Web Services (AWS) com um cenário tão complexo: Neste cenário CloudTrail Logs,! = É usado quando um determinado evento não precisa ser incluído. Ao mesmo tempo, Criar ou Gravar é um caso obrigatório.

logtype="CloudTrail Logs" and eventname!="CreateLogStream" and eventname!="CreateNetworkInterface" and (eventname contains "Create" or eventname contains "Write")
e,! =, contém, médiaSemelhante ao caso acima, esse padrão é útil quando seu filtro tem que incluir uma duração média junto com o cenário acima. Para encontrar o tempo médio gasto em um log de acesso IIS, excluindo as solicitações de verificação de saúde e o stemuri contém a mensagem especificada, a consulta acima pode ser útil.

logtype="IIS Access Logs" and useragent!="ELB-HealthChecker/1.0" and useragent!="ELB-HealthChecker/2.0" and stemuri contains "/get_usage_info/" avg(timetaken)
timeslice, min, max, avgO uso de timeslice gera uma tabela do período de tempo total selecionado para a consulta, dividido por fatias de tempo especificadas na consulta em relação à contagem de entradas de log. Quando é usado com min, max e avg, ele gera uma tabela para todos esses valores para o tempo especificado. Nesse log de acesso do IIS, os valores de tempo médio, mínimo e máximo obtidos a cada intervalo de 15 minutos serão representados como uma tabela.

logtype="IIS Access Logs" and monitor_name=" Server" AVG(timetaken) MIN(timetaken) MAX(timetaken) timeslice 15m
! =, count_distinct, timesliceQuando você deseja valores únicos e distintos divididos por tempo, a contagem distinta e a fatia de tempo são úteis. Quando usado em uma consulta, a contagem distinta busca apenas o número dos valores distintos.

logtype="Apache Access Logs" and useragent !="bot" COUNT_DISTINCT(remotehost) timeslice 1h

Considerando um caso de uso simples de logs de acesso do Apache em que você precisa filtrar o acesso IP não bot por hora, a consulta acima pode ser usada.
e,! =, groupbyGroupby mostra o número de entradas com o mesmo valor para o campo fornecido. Para combinar algumas condições e agrupá-las, considere o caso de uso abaixo de registros da AWS. A partir dos logs do AWS CloudTrail, você pode remover um site que não precisa ser incluído usando! =, Combinar condições semelhantes usando e e agrupá-los por useridentity_principalid, eventsource.

logtype="CloudTrail Logs" and eventsource != "ssm.amazonaws.com" and eventsource != "logs.amazonaws.com" and eventsource!="config.amazonaws.com" groupby useridentity_principalid,eventsource
! =, e, conter, grupo, fatia de tempoPara agrupar um conjunto de campos e dividir os resultados com base no tempo, esse padrão pode ser usado. Para obter as estatísticas de logon do usuário nos logs do AWS CloudWatch, você pode precisar apenas dos detalhes de certas fontes e eles devem conter signin.amazonaws.com. Para agrupá-los com base no useridentity_principalid e visualizar os resultados diariamente, a consulta acima pode ser usada.

logtype="CloudWatch Logs" = and eventsource != "ssm.amazonaws.com" and eventsource != "logs.amazonaws.com" and eventsource CONTAINS "signin.amazonaws.com" groupby useridentity_principalid timeslice 1d
> =, <=, groupbyCódigos de erro maiores ou iguais a determinados valores podem não ser um sinal positivo em ambientes de produção. Agrupá-los fornecerá insights sobre o que deu errado, para o qual a consulta abaixo pode ser usada: Agrupar resultados com base em encaminhados para em um determinado vhost cujos status estão entre 500 e 599 ajudará a identificar IPs de solicitação com falha exclusiva no intervalo 500.

logtype="Nginx Logs" and status>=500 and status<=599 and vhost="zylker_1200" groupby xforwardedfor

Além dos exemplos acima, você também pode criar seus próprios padrões usando diferentes operadores com base em seus casos de uso. Isso pode tornar sua pesquisa de linguagem de consulta e análise de registro mais fácil e completa.

AppLogs é a solução de gerenciamento de log do Site24x7 que coleta, consolida, indexa e analisa logs de diferentes aplicativos, servidores, estruturas e nuvem. O AppLogs também permite que você salve consultas, crie alertas com base nelas e visualize seus resultados em painéis intuitivos.

Experimente o Site24x7 para gerenciamento de log agora mesmo, contando sempre com o apoio da equipe ACSoftware.