Tutorial do Logstash: usando o Logstash para simplificar as notificações por e-mail

Aplicativos que usam e-mails como o principal mecanismo para relatar erros e exceções sempre parecem uma boa ideia a princípio. Como desenvolvedores Java, pensamos: “ei, saberei imediatamente quando algo der errado!”

No entanto, em algum momento, você perceberá que os e-mails de erro estão fugindo de você e você precisa limpar sua caixa de entrada de e-mail. Você pode ignorar 404s (na maioria das vezes) e pode ser bom receber notificações de novas inscrições, mas no final do dia pode se tornar um pouco agitado ou demorado.

Mais cedo ou mais tarde, torna-se difícil distinguir emails “acionáveis” de notificações inúteis. Você pode configurar regras e filtros em seu e-mail, mas mesmo eles podem começar a se tornar incontroláveis.

Este tutorial Java analisará a possibilidade de usar o Logstash para recuperar o controle e limpar sua caixa de entrada de e-mail e tornar seus e-mails de erro gerenciáveis ​​novamente, tudo sem alterar nada em seu aplicativo.

Configuração e entrada do Logstash

A primeira etapa em nosso tutorial do Logstash é garantir que todos os e-mails que você recebe do seu sistema vão para uma pasta. Como estamos removendo toda a classificação e gerenciamento de sua caixa de entrada, não importará mais que seja uma pasta grande. Vá em frente e remova todas as pastas e filtros que você já configurou e reduza-os a uma pasta e um filtro.

Mova todos os e-mails de “[email protected]” para a pasta “MyAwesomeAppEmails”. Se você tiver uma caixa de correio separada para esses e-mails, será ainda mais fácil.

Agora podemos configurar o Logstash para pesquisar essa pasta e analisar os e-mails usando o plug-in IMAP. A versão 1.4.2 suporta apenas a extração de e-mails da caixa de entrada, mas há uma correção relativamente simples que foi aplicada na versão 1.5 para permitir a pesquisa de uma pasta específica. Se você não tiver uma caixa de correio separada, aplique o patch ao plug-in IMAP em sua instância do Logstash antes de continuar.

 # /etc/logstash/conf.d/01-imap-input.conf input { imap { host => "imap.yourmailserver.com" user => "username" password => "password" secure => true fetch_count => 15 folder => "MyAwesomeAppEmails" # This line will only work if you apply the above mentioned patch } }

Isso começará a verificar novos e-mails e a analisá-los em eventos do Logstash.

Filtro do Logstash

Muitos dados úteis são analisados ​​de e-mails em diferentes propriedades de eventos - observe que o carimbo de data/hora do e-mail é usado como “@timestamp” para o evento. Ainda mais, a partir dos cabeçalhos, podemos fazer coisas como identificar o host do qual o erro se originou:

 filter { mutate { replace => [ "received", "%{[received][-1]}" ] } grok { match => [ "received", "from %{HOSTNAME:hostname} \(%{HOSTNAME:full_hostname} \[%{IP:ip}\]\)" ] } mutate { remove_field => [ "received" ] } }

Isso, no entanto, não é suficiente para domar seus e-mails de erro. Precisamos de um pouco mais, especificamente das três etapas a seguir que descrevem:

• O tipo do erro
• A gravidade do erro
• Quaisquer detalhes do erro incluídos no e-mail

Vamos supor que você colocou o nome do erro, por exemplo, “Widget Failed”, bem como a gravidade do erro “ERROR” no assunto do e-mail assim: “ERROR: Widget Failed in /var/www/myapp/foobar .php 20”.

Usaremos isso para definir várias propriedades do evento:

 filter { grok { match => [ "subject", "%{WORD:severity}: %{DATA:type} in %{PATH:path} %{POSINT:line}" ] } }

O Logstash vem com vários padrões predefinidos que você pode esperar ver nos logs e em outros lugares. Use-os para construir seus padrões Grok e torná-los mais fáceis de ler. Usamos “WORD” (uma única palavra), “DATA” (pega-tudo não-ganancioso), “PATH” (um caminho de arquivo Unix ou Windows) e “POSINT” (um inteiro positivo). Você também pode usar o Grok Debugger para depurar seus padrões Grok. As mensagens que não corresponderem ao padrão serão marcadas com a tag “_grokparsefailure”.

Isso cuida do tipo, gravidade, arquivo de origem e linha do erro - basicamente todos os metadados relevantes do evento. Agora vamos aos detalhes.

Ajuste fino do Logstash

Você pode ter adicionado anteriormente uma boa assinatura de cabeçalho ou rodapé ao seu e-mail, sendo a pessoa cortês que você é, mas agora está no caminho. Vamos removê-lo da mensagem, bem como qualquer espaço em branco à direita para que possamos analisar o restante do email para o rastreamento de pilha de erro:

 filter { mutate { # gsub takes 3 elements per substitution: field, regular expression and substitution gsub => [ "message", "Your Dev Team", "", "message", "More error details:", "" ] } mutate { strip => "message" } # Split the message into an array of lines, each containing a line of the stacktrace mutate { split => [ "message", "\n" ] } }

A mutação “gsub” usa o objeto Ruby Regexp padrão, então todas as opções e recursos também estão disponíveis no logstash.

Saída via Elasticsearch e Amazon SNS

Vamos aplicar isso à nossa instância do Elasticsearch usando a saída do Logstash Elasticsearch para que possamos pesquisar e quantificar facilmente os dados que estamos coletando:

 output { if "_grokparsefailure" not in [tags] { elasticsearch { } } }

Estamos excluindo todas as mensagens que não fizeram Grok corretamente verificando a tag “_grokparsefailure”. A suposição é que apenas emails cujo assunto corresponda ao assunto especificado devem ser interpretados como emails de erro. Caso contrário, é simples e direto.

O Logstash vem com uma infinidade de saídas, então vamos aprimorar isso ainda mais usando a saída do SNS para nos notificar sobre erros significativos usando o Simple Notification Service (SNS) da Amazon. Vamos supor que todos os erros do tipo “notificável” precisam gerar uma notificação. Se você não estiver em uma instância do EC2, precisará especificar uma chave e um segredo da AWS.

 output { if "notifiable" in [tags] { sns { region => "us-east-1" arn => "arn:aws:sns:us-east-1:1234567890123456:mytopic" access_key_id => "AWS ACCESS_KEY" # Only specify these if you're not on an EC2 instance secret_access_key => "AWS ACCESS SECRET" # Only specify these if you're not on an EC2 instance } } }

A marcação de erros como “notificáveis” é com você. Você pode fazer isso observando a gravidade do erro ou o tipo de erro.

Agora você pode realmente ler e-mails importantes novamente e pode ter certeza de que não perderá e-mails de erros importantes. Você também pode tomar decisões informadas sobre quais erros corrigir, pois pode ver com que frequência um erro ocorre e quando ocorreu pela última vez. Pesquisar um erro específico também é mais fácil e rápido, graças aos incríveis poderes de pesquisa do Elasticsearch descritos neste tutorial do Logstash.