logstash注意事項

注意

1. 一般你要導入原有數據進 Elasticsearch 的話，你還須要 filter/date 插件來修改默認的"@timestamp" 字段值。稍後會學習這方面的知識。

2. FileWatch 只支持文件的絕對路徑，並且會不自動遞歸目錄。因此有須要的話，請用數組方式都寫明具體哪些文件。

3. LogStash::Inputs::File 只是在進程運行的註冊階段初始化一個 FileWatch 對象。因此它不能支持相似 fluentd 那樣的 path => "/path/to/%{+yyyy/MM/dd/hh}.log" 寫法。達到相同目的，你只能寫成 path => "/path/to/*/*/*/*.log"。FileWatch 模塊提供了一個稍微簡單一點的寫法：/path/to/**/*.log，用 ** 來縮寫表示遞歸所有子目錄。

4. start_position 僅在該文件從未被監聽過的時候起做用。若是 sincedb 文件中已經有這個文件的 inode 記錄了，那麼 logstash 依然會從記錄過的 pos 開始讀取數據。因此重複測試的時候每回須要刪除 sincedb 文件(官方博客上提供了另外一個巧妙的思路：將 sincedb_path 定義爲 /dev/null，則每次重啓自動從頭開始讀)。

5. 由於 windows 平臺上沒有 inode 的概念，Logstash 某些版本在 windows 平臺上監聽文件不是很靠譜。windows 平臺上，推薦考慮使用 nxlog 做爲收集端

讀取網絡數據(TCP)

將來你可能會用 Redis 服務器或者其餘的消息隊列系統來做爲 logstash broker 的角色。不過 Logstash 其實也有本身的 TCP/UDP 插件，在臨時任務的時候，也算能用，尤爲是測試環境。

+

小貼士：雖然 LogStash::Inputs::TCP 用 Ruby 的 Socket 和 OpenSSL 庫實現了高級的 SSL 功能，但 Logstash 自己只能在 SizedQueue 中緩存 20 個事件。這就是咱們建議在生產環境中換用其餘消息隊列的緣由。

nginx access.log --->----logstash讀取文件 -->---redis---->----

nginx access.log --->----logstash讀取文件 -->---kafka ---->----

nginx access.log --->----logstash 讀取文件--->---elasticsearch--->---其餘(kibana)