2015-07-11 41 views
0

我目前正在處理兩個logstash項目,一個監視IIS日誌,另一個監視IIS防火牆。在Logstash中使用外部查找

現在IIS日誌來自高使用率的服務器,每月產生大約25GB的日誌,並且有幾個這樣的日誌。這裏的問題是,我們不希望啓用反向查找,而不是在服務器上或Logstash中,而是從外部服務啓用反向查找,因爲我們可以在logstash中的DNS查找功能之外進行緩存。

我們想要解決的另一個問題是防火牆項目與查找標準和非標準端口有關。我們的防火牆只是生成我們想要翻譯的dest端口號,使我們的Kibana儀表板更具可讀性。防火牆有大約10Gb/s的流量,併產生大量的系統日誌流量。

我們目前在logstash服務器上運行8-16名工人。有沒有一種簡單(?)的方式來從logstash進行API調用,甚至是值得考慮基於性能?

我正在討論的另一個選擇是「脫機」批處理,即直接向elasticsearch運行批處理作業,但這最有可能意味着我應該在FrontEnd之前有一個單獨的elasticsearch或redis實例。

然而,最好的選擇最可能的是在Kibana界面中作爲腳本字段進行翻譯,但至於我的理解,這對我的用戶工作不起作用?

回答

0

dns {}過濾器使用本地計算機的分辨率,因此您無法將其與非DNS緩存集成,而無需創建新過濾器或放置到ruby {}。

根據您擁有的值的數量,您可以將它們發佈到一個文件並使用translate {},但我只會建議對於類似於專用網絡查找的內容。

如果您的DNS數據在elasticsearch中,您可以在您的過濾期間查詢它,並以這種方式向您的活動添加字段。

對於您的防火牆端口問題,您沒有給出原始值和期望值的示例,但再次查看翻譯{}或放到ruby {}。