Logstash 教程:使用 Logstash 简化电子邮件通知

已发表: 2022-03-11

使用电子邮件作为报告错误和异常的主要机制的应用程序起初似乎总是一个好主意。 作为 Java 开发人员,我们认为,“嘿,我会立即知道什么时候出了问题!”

但是,在某些时候,您一定会意识到错误电子邮件正在远离您,您需要清理您的电子邮件收件箱。 您可以忽略 404(大部分时间),接收新注册通知可能会很好,但最终可能会变得有点太忙或太耗时。

迟早,将“可操作”的电子邮件与毫无意义的通知区分开来会变得很困难。 您可以在邮件上设置规则和过滤器,但即使这些也可能开始变得难以管理。

logstash 教程

本 Java 教程将探讨使用 Logstash 重新获得控制权并清理您的电子邮件收件箱并使您的错误电子邮件再次可管理的可能性,而无需更改应用程序中的任何内容。

Logstash 设置和输入

我们的 Logstash 教程的第一步是确保您从系统收到的所有电子邮件都放在一个文件夹中。 由于我们将所有排序和管理移出您的收件箱,因此它不再是一个大文件夹。 继续删除您已经设置的所有文件夹和过滤器,并将其减少到一个文件夹和一个过滤器。

将所有电子邮件从“[email protected]”移动到文件夹“MyAwesomeAppEmails”。 如果您有一个单独的邮箱来存放这些电子邮件,那就更容易了。

现在我们可以设置 Logstash 来轮询该文件夹并使用 IMAP 插件解析邮件。 1.4.2 版仅支持从收件箱中提取电子邮件,但在 1.5 版中应用了一个相对简单的修复程序,以允许轮询特定文件夹。 如果您没有单独的邮箱,请在继续之前将补丁应用到 Logstash 实例中的 IMAP 插件。

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

这将开始检查新电子邮件并将其解析为 Logstash 事件。

日志存储事件

Logstash 过滤器

许多有用的数据从电子邮件解析为不同的事件属性 - 请注意,电子邮件时间戳用作事件的“@timestamp”。 更进一步,仅从标头中我们就可以做一些事情,例如识别错误源自的主机:

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

但是,这不足以驯服您的错误电子邮件。 我们需要多一点,具体是以下三个步骤描述:

  • 错误的类型
  • 错误的严重性
  • 电子邮件中包含的任何错误详细信息

假设您在电子邮件的主题中放置了错误的名称,例如“Widget Failed”,以及错误“ERROR”的严重性,如下所示:“ERROR: Widget Failed in /var/www/myapp/foobar .php 20”。

我们将使用它来设置事件的几个属性:

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

Logstash 带有许多预定义的模式,您可以期望在日志和其他不同的地方看到这些模式。 使用这些来构建您的 Grok 模式并使它们更易于阅读。 我们使用了“WORD”(单个单词)、“DATA”(非贪婪的包罗万象)、“PATH”(Unix 或 Windows 文件路径)和“POSINT”(正整数)。 您还可以使用 Grok 调试器来调试您的 Grok 模式。 与模式不匹配的消息将被标记为“_grokparsefailure”标签。

这会处理错误的类型、严重性、源文件和行——基本上是事件的所有相关元数据。 现在进入细节。

微调 Logstash

您之前可能已经为您的电子邮件添加了一个漂亮的页眉或页脚签名,作为一个有礼貌的人,但现在它妨碍了。 让我们从消息中删除它,以及任何尾随空格,以便我们可以解析电子邮件的其余部分以查找错误堆栈跟踪:

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

“gsub”突变使用标准的 Ruby Regexp 对象,因此所有选项和功能也可以在 logstash 中使用。

通过 Elasticsearch 和 Amazon SNS 输出

让我们使用 Logstash Elasticsearch 输出将其应用于我们的 Elasticsearch 实例,以便我们可以轻松搜索和量化我们正在收集的数据:

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

我们通过检查“_grokparsefailure”标签来排除所有没有正确 Grok 的消息。 假设只有主题与指定主题匹配的电子邮件才应被解释为错误电子邮件。 否则,它就简单明了。

Logstash 带有大量输出,因此让我们使用 SNS 输出进一步增强它,以便使用 Amazon 的简单通知服务 (SNS) 通知我们重大错误。 我们假设所有类型为“notifiable”的错误都需要生成通知。 如果您不在 EC2 实例上,则需要指定 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 } } }

将错误标记为“应通知”取决于您。 您可以通过查看错误的严重性或查看错误的类型来做到这一点。

现在您实际上可以再次阅读重要的电子邮件,并且可以确保您不会错过重要的错误电子邮件。 您还可以就要修复的错误做出明智的决定,因为您可以查看错误发生的频率以及上次发生的时间。 由于本 Logstash 教程中概述的 Elasticsearch 的强大搜索功能,搜索特定错误也更加容易和快捷。