Logstash 教程：使用 Logstash 簡化電子郵件通知

使用電子郵件作為報告錯誤和異常的主要機制的應用程序起初似乎總是一個好主意。 作為 Java 開發人員，我們認為，“嘿，我會立即知道什麼時候出了問題！”

但是，在某些時候，您一定會意識到錯誤電子郵件正在遠離您，您需要清理您的電子郵件收件箱。 您可以忽略 404（大部分時間），接收新註冊通知可能會很好，但最終可能會變得有點太忙或太耗時。

遲早，將“可操作”的電子郵件與毫無意義的通知區分開來會變得很困難。 您可以在郵件上設置規則和過濾器，但即使這些也可能開始變得難以管理。

本 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 的強大搜索功能，搜索特定錯誤也更加容易和快捷。