Tutoriel Logstash : Utiliser Logstash pour rationaliser les notifications par e-mail

Les applications qui utilisent les e-mails comme mécanisme principal pour signaler les erreurs et les exceptions semblent toujours être une bonne idée au début. En tant que développeurs Java, nous pensons : "Hé, je saurai immédiatement quand quelque chose ne va pas !"

Cependant, à un moment donné, vous vous rendrez compte que les e-mails d'erreur vous échappent et que vous devez nettoyer votre boîte de réception. Vous pouvez ignorer les 404 (la plupart du temps), et il peut être agréable de recevoir des notifications de nouvelles inscriptions, mais en fin de compte, cela peut devenir un peu trop mouvementé ou prendre du temps.

Tôt ou tard, il devient difficile de distinguer les e-mails « exploitables » des notifications inutiles. Vous pouvez configurer des règles et des filtres sur votre courrier, mais même ceux-ci peuvent commencer à devenir ingérables.

Ce tutoriel Java examinera la possibilité d'utiliser Logstash pour reprendre le contrôle et nettoyer votre boîte de réception et rendre vos e-mails d'erreur à nouveau gérables, le tout sans changer une seule chose dans votre application.

Configuration et saisie de Logstash

La première étape de notre didacticiel Logstash consiste à vous assurer que tous les e-mails que vous recevez de votre système sont dirigés vers un seul dossier. Puisque nous déplaçons tout le tri et la gestion de votre boîte de réception, le fait qu'il s'agisse d'un seul gros dossier n'aura plus d'importance. Allez-y et supprimez tous les dossiers et filtres que vous avez déjà configurés, et réduisez-les à un dossier et un filtre.

Déplacez tous les e-mails de "[email protected]" vers le dossier "MyAwesomeAppEmails". Si vous avez une boîte aux lettres séparée pour ces e-mails, ce sera encore plus facile.

Nous pouvons maintenant configurer Logstash pour interroger ce dossier et analyser les e-mails à l'aide du plugin IMAP. La version 1.4.2 ne prend en charge que l'extraction des e-mails de la boîte de réception, mais il existe un correctif relativement simple qui a été appliqué dans la version 1.5 pour permettre d'interroger un dossier spécifique. Si vous n'avez pas de boîte aux lettres distincte, veuillez appliquer le correctif au plug-in IMAP dans votre instance Logstash avant de continuer.

 # /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 } }

Cela commencera à vérifier les nouveaux e-mails et à les analyser dans les événements Logstash.

Filtre Logstash

De nombreuses données utiles sont analysées à partir des e-mails dans différentes propriétés d'événement - notez que l'horodatage de l'e-mail est utilisé comme "@timestamp" pour l'événement. Encore plus loin, à partir des seuls en-têtes, nous pouvons faire des choses comme identifier l'hôte d'où provient l'erreur :

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

Ceci, cependant, n'est pas suffisant pour apprivoiser vos e-mails d'erreur. Nous avons besoin d'un peu plus, en particulier les trois étapes suivantes décrivant :

• Le type d'erreur
• La gravité de l'erreur
• Tout détail d'erreur inclus dans l'e-mail

Supposons que vous ayez placé le nom de l'erreur, par exemple "Widget Failed", ainsi que la gravité de l'erreur "ERROR" dans l'objet de l'e-mail comme ceci : "ERROR : Widget Failed in /var/www/myapp/foobar .php 20".

Nous allons l'utiliser pour définir plusieurs propriétés de l'événement :

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

Logstash est livré avec un certain nombre de modèles prédéfinis que vous pouvez vous attendre à voir dans les journaux et à d'autres endroits. Utilisez-les pour créer vos modèles Grok et les rendre plus faciles à lire. Nous avons utilisé « WORD » (un seul mot), « DATA » (fourre-tout non gourmand), « PATH » (un chemin de fichier Unix ou Windows) et « POSINT » (un entier positif). Vous pouvez également utiliser le débogueur Grok pour déboguer vos modèles Grok. Les messages qui ne correspondent pas au modèle seront marqués avec la balise "_grokparsefailure".

Cela prend en charge le type, la gravité, le fichier source et la ligne de l'erreur - essentiellement toutes les métadonnées pertinentes de l'événement. Passons maintenant aux détails.

Logstash de réglage fin

Vous avez peut-être déjà ajouté une belle signature d'en-tête ou de pied de page à votre e-mail, étant la personne courtoise que vous êtes, mais maintenant c'est gênant. Supprimons-le du message, ainsi que tout espace blanc de fin afin que nous puissions analyser le reste de l'e-mail pour l'erreur stacktrace :

 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" ] } }

La mutation "gsub" utilise l'objet Ruby Regexp standard, de sorte que toutes les options et fonctionnalités sont également disponibles dans logstash.

Sortie via Elasticsearch et Amazon SNS

Appliquons cela à notre instance Elasticsearch à l'aide de la sortie Logstash Elasticsearch afin de pouvoir facilement rechercher et quantifier les données que nous collectons :

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

Nous excluons tous les messages qui n'ont pas été Grok correctement en vérifiant la balise « _grokparsefailure ». L'hypothèse est que seuls les e-mails dont le sujet correspond au sujet spécifié doivent être interprétés comme des e-mails d'erreur. Sinon, c'est simple et direct.

Logstash est livré avec une pléthore de sorties, alors améliorons cela encore plus en utilisant la sortie SNS pour nous informer des erreurs importantes à l'aide du service de notification simple (SNS) d'Amazon. Nous supposerons que toutes les erreurs de type "notifiable" doivent générer une notification. Si vous n'êtes pas sur une instance EC2, vous devrez spécifier une clé et un secret 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 } } }

Le marquage des erreurs comme "notifiables" dépend de vous. Vous pouvez le faire en examinant soit la gravité de l'erreur, soit le type d'erreur.

Vous pouvez désormais lire à nouveau les e-mails importants et vous pouvez être sûr de ne pas manquer les e-mails d'erreur importants. Vous pouvez également prendre des décisions éclairées sur les erreurs à corriger, car vous pouvez voir à quelle fréquence une erreur se produit et quand elle s'est produite pour la dernière fois. La recherche d'une erreur spécifique est également plus facile et plus rapide, grâce aux formidables capacités de recherche d'Elasticsearch décrites dans ce didacticiel Logstash.