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

本文概述

• Logstash设置和输入
• Logstash过滤器
• 微调Logstash
• 通过Elasticsearch和Amazon SNS输出

首先, 以电子邮件为主要机制来报告错误和异常的应用程序似乎总是一个好主意。作为Java开发人员, 我们认为：”嘿, 当出现问题时, 我会立即知道！”

但是, 在某个时候, 你一定会意识到错误电子邮件正在逐渐消失, 你需要清理电子邮件收件箱。你可以忽略404(大多数情况下), 并且很高兴收到新注册的通知, 但是到了一天结束时, 它可能会变得过于忙碌或耗时。

迟早要区分”可行的”电子邮件和毫无意义的通知变得很困难。你可以在邮件上设置规则和过滤器, 但是即使这些规则和过滤器也开始变得难以管理。

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

Logstash设置和输入

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

将所有电子邮件从” [受电子邮件保护]”移动到文件夹” 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" ]
  }
}

但是, 这还不足以驯服你的错误电子邮件。我们还需要更多一点, 特别是以下三个步骤描述：

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

假设你放置了错误的名称, 例如电子邮件主题中的”窗口小部件失败”, 以及错误” ERROR”的严重性如下：”错误：/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

你可能以前是彬彬有礼的人, 但是之前在电子邮件中添加了漂亮的页眉或页脚签名, 但现在却成了问题。我们将其从邮件以及所有尾随空格中删除, 以便我们可以分析电子邮件的其余部分以获取错误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" ]
  }
}

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

通过Elasticsearch和Amazon SNS输出

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

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

我们会通过检查” _grokparsefailure”标签来排除所有无法正常发出Grok的邮件。假设仅将主题与指定主题匹配的电子邮件解释为错误电子邮件。否则, 它很简单明了。

Logstash具有大量输出, 因此让我们使用SNS输出来进一步增强此功能, 以便使用Amazon的Simple Notification Service(SNS)通知我们重大错误。我们假设所有”可通知”类型的错误都需要生成通知。如果你不在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强大的搜索功能, 搜索特定错误也变得更加轻松快捷。