ELK：LogStash 從遠端 Samba 映射的網路驅動器讀取日誌文件

我是 ELK 的新手，我想建立一個解決方案來索引 Microsoft IIS 和使用 ES 的應用程序 .NET 日誌。

我知道不同的方法：

1)$$ app servers: log files ➔ Logstash $$➔$$ collecting server: Redis ➔ Logstash $$➔$$ ES cluster: ES ➔ Kibana $$

這種方法的缺點是必須在每個產生日誌的 Windows 伺服器上安裝、配置和維護一個 logstash 實例

2)$$ app servers: log files ➔ Filebeat $$➔$$ collecting server: Logstash ➔ Redis ➔ Logstash $$➔$$ ES cluster: ES ➔ Kibana $$

此方法的缺點是目前 filebeat 不支持多行日誌條目，並且我的 .NET 應用程序會產生多行異常。我不確定如何配置中間 logstash+redis+logstash 來處理這個問題。

所以我想，也許考慮到 Logstash 能夠在沒有 filebeat 或任何其他轉發器的情況下自行收集日誌數據（如果我錯了，請糾正我），我可能會嘗試以下操作：

$$ app servers: log files $$➔$$ collecting server: Samba-mapped network drives ➔ Logstash ➔ Redis ➔ Logstash $$➔$$ ES cluster: ES ➔ Kibana $$

在那個假設中，我不需要在每個應用伺服器上安裝 Logstash 實例。中央 logstash 實例（或多個實例）將獲取文件（使用 Samba 映射的網路驅動器）並在將日誌條目推送到 Redis 之前應用多行編解碼器。

這在技術上可行嗎？這是一個合理的架構選擇嗎？

雖然使用 CIFS 共享上的日誌輸入執行 Logstashfile會起作用，但我認為它不會很好地工作。我沒有像那樣直接使用 Logstash，但是，根據我使用 Logstash-Forwarder 通過 SSHFS 掛載查看日誌文件的經驗，它不能很好地處理文件輪換或任一端的重啟。

至於不確定如何使用 Filebeat 處理您的多行異常，我認為您無需擔心。FileBeat 只是從您要發送的文件中提取行，並通過網路觸發它們。它添加了一些欄位，但它們不會影響 FileBeat 作為一個非常基本的日誌傳送器的整體概念。

這意味著您可以在收集伺服器上的 Logstash 中執行多行過濾器，就像直接在應用伺服器上執行 Logstash 一樣。

現在，根據您的日誌量，您可能會發現您需要增加 LS 的工作人員數量才能有效地處理您的數據。

我處理此類事情的方式與您的選項 2 非常相似，但我有 3 個而不是只有兩個 LS 實例（“代理”和一個“解析器”）。

                           +-------------------+
                          +-------------------+|
                         +-------------------+||
                         |    App Servers    |||
                         |    +----------+   ||+
                         |    | FileBeat |   |+
                         +----+----------+---+
                              /
                            /       
                          /        
       +----------------/----------------------------------------+
       |              /      Collecting Server                   |
       | +----------/-+  +---------------------+  +------------+ |
       | |  Logstash  |  |      Logstash       |  |  Logstash  | |
       | |   Broker   |  |Multi-line Pre-Parser|  |   Parser   | |
       | +------------+  +---^-----------------+  +-----^---V--+ |
       |     |               |             |            |   |    |
       |     |               |    Redis    |            |   |    |
       |     V       +---------------------V------+     |   |    |
       |     +------->     DB0      |      DB1    + --->+   |    |
       |             +----------------------------+        /     |
       +-------------------------------------------------/-------+
                                                       /
                                                     /
                                                   /
                          +-------------------+  /
                         +-------------------+|/
                        +-------------------+||
                        |   ElasticSearch   ||+
                        |      Cluster      |+
                        +-------------------+

該Pre-Parser實例所做的只是將多行日誌條目轉換為單行，以便Parser可以正常工作。即便如此，我也在檢查類型和標籤，看看是否有可能行是多行的，所以成本是最小的。

我可以輕鬆地通過它每秒推送 1000 個事件（幾乎沒有達到 20% 的 CPU）。此外，該系統是一個 ELK stack-in-a-box，因此對於 LS 和 ES 都有專用節點，應該很容易。

為什麼不直接啟動workersParser 實例呢？嗯，這源於 LS 中的multiline 過濾器不支持多個工人的事實。

multiline

此過濾器會將來自單個源的多行消息折疊到一個 Logstash 事件中。

此過濾器的最初目標是允許將來自文件的多行消息加入到單個事件中。例如 - 將 java 異常和堆棧跟踪消息加入單個事件。

注意：-w 2此過濾器不適用於 Logstash 命令行上的多個工作執行緒。

引用自：https://serverfault.com/questions/744352