大規模的日誌傳輸和聚合
您如何分析來自 UNIX/Linux 機器的日誌文件？我們執行數百台伺服器，它們都直接或通過 syslog 生成自己的日誌文件。我正在尋找一個體面的解決方案來匯總這些並挑選出重要事件。這個問題分為 3 個部分：
- 消息傳輸
經典的方法是使用 syslog 將消息記錄到遠端主機。這適用於登錄到 syslog 的應用程序，但對寫入本地文件的應用程序不太有用。對此的解決方案可能包括將應用程序記錄到連接到程序的 FIFO 中，以使用 syslog 發送消息，或者通過編寫一些東西來 grep 本地文件並將輸出發送到中央 syslog 主機。但是，如果我們費心編寫工具來將消息輸入 syslog，我們是否會更好地用 Facebook 的Scribe之類的東西來代替整個工具，它比 syslog 提供更多的靈活性和可靠性？
- 消息聚合
日誌條目似乎屬於以下兩種類型之一：每個主機和每個服務。每主機消息是發生在一台機器上的消息；想想磁碟故障或可疑登錄。每個服務消息出現在大多數或所有執行服務的主機上。例如，我們想知道 Apache 何時發現 SSI 錯誤，但我們不希望 100 台機器出現相同的錯誤。在所有情況下，我們只希望看到每種類型的消息中的一種：我們不希望有 10 條消息說同一個磁碟發生故障，並且我們不希望每次遇到損壞的 SSI 時都收到一條消息。
解決此問題的一種方法是在每個主機上將多個相同類型的消息聚合為一個，將消息發送到中央伺服器，然後將相同類型的消息聚合為一個整體事件。SER可以做到這一點，但使用起來很尷尬。即使經過幾天的擺弄，我也只有基本的聚合工作，並且不得不不斷地查找 SER 用於關聯事件的邏輯。它很強大但很棘手：我需要我的同事可以在最短的時間內拿起和使用的東西。SER 規則不滿足該要求。
- 生成警報
當有趣的事情發生時，我們如何告訴我們的管理員？郵寄群組收件箱？注入Nagios？
那麼，你是如何解決這個問題的呢？我不指望一個盤子上的答案。我可以自己解決細節，但就什麼肯定是常見問題進行一些高級討論會很棒。目前，我們正在使用雜亂無章的 cron 作業、系統日誌以及誰知道還有什麼可以查找事件。這不是可擴展的、可維護的或靈活的，因此我們錯過了很多我們不應該做的事情。
**更新：**我們已經在使用 Nagios 進行監控，這對於檢測到的主機/測試服務/等非常有用，但對於抓取日誌文件的用處不大。我知道 Nagios 有日誌外掛，但我對比每個主機警報更具可擴展性和層次性的東西感興趣。
我使用了三種不同的系統來集中日誌：
- Syslog/syslog-ng 轉發到一台主機
- Zenoss 用於聚合和警報事件
- Splunk用於日誌聚合和搜尋
對於#3，我通常使用 syslog-ng 將來自每個主機的消息直接轉發到 splunk。它也可以直接解析日誌文件，但這可能有點麻煩。
Splunk 非常適合搜尋和分類您的日誌。我沒有使用 splunk 進行日誌警報，但我認為這是可能的。
你可以看看 OSSEC，一個完整的開源 HIDS，它會進行日誌分析並可以觸發操作或發送警報郵件。警報由一組簡單的基於 XML 的規則觸發，包括許多針對各種日誌格式的預定義規則，您可以添加自己的規則