Logstash學習3_通過Kafka傳輸數據給logstash-1.4和logstash-1.5

目錄(?)[-]

1. 通過kafka傳輸
   1. kafka 基本概念
      1. 小提示
   2. 插件安裝
      1. logstash-14 安裝
      2. logstash-15 安裝
      3. 小貼士
   3. 插件配置
      1. Input 配置示例
      2. Input 解釋
         1. 注意
      3. Output 配置
      4. Output 解釋
         1. 消息模式相關
      5. 小貼士
      6. 性能
         1. 隊列監控
         2. input-kafka 的 JSON 序列化性能
         3. 其他方案

通過kafka傳輸

Kafka 是一個高吞吐量的分佈式發佈訂閱日誌服務，具有高可用、高性能、分佈式、高擴展、持久性等特性。目前已經在各大公司中廣泛使用。和之前採用 Redis 做輕量級消息隊列不同，Kafka 利用磁盤作隊列，所以也就無所謂消息緩衝時的磁盤問題。此外，如果公司內部已有 Kafka 服務在運行，logstash 也可以快速接入，免去重複建設的麻煩。

如果打算新建 Kafka 系統的，請參考 Kafka 官方入門文檔：http://kafka.apache.org/documentation.html#quickstart

kafka 基本概念

以下僅對相關基本概念說明，更多概念見官方文檔：

• Topic 主題，聲明一個主題，producer指定該主題發佈消息，訂閱該主題的consumer對該主題進行消費
• Partition 每個主題可以分爲多個分區，每個分區對應磁盤上一個目錄，分區可以分佈在不同broker上，producer在發佈消息時，可以通過指定partition key映射到對應分區，然後向該分區發佈消息，在無partition key情況下，隨機選取分區，一段時間內觸發一次(比如10分鐘)，這樣就保證了同一個producer向同一partition發佈的消息是順序的。 消費者消費時，可以指定partition進行消費，也可以使用high-level-consumer api,自動進行負載均衡，並將partition分給consumer，一個partition只能被一個consumer進行消費。

• Consumer 消費者，可以多實例部署，可以批量拉取，有兩類API可供選擇：一個simpleConsumer，暴露所有的操作給用戶，可以提交offset、fetch offset、指定partition fetch message；另外一個high-level-consumer(ZookeeperConsumerConnector)，幫助用戶做基於partition自動分配的負載均衡，定期提交offset，建立消費隊列等。simpleConsumer相當於手動擋，high-level-consumer相當於自動擋。

  simpleConsumer：無需像high-level-consumer那樣向zk註冊brokerid、owner，甚至不需要提交offset到zk，可以將offset提交到任意地方比如(mysql,本地文件等)。

  high-level-consumer：一個進程中可以啓多個消費線程，一個消費線程即是一個consumer，假設A進程裏有2個線程(consumerid分別爲1，2)，B進程有2個線程(consumerid分別爲1，2)，topic1的partition有5個，那麼partition分配是這樣的：

    partition1 ---> A進程consumerid1
    partition2 ---> A進程consumerid1
    partition3 ---> A進程consumerid2
    partition4 ---> B進程consumer1
    partition5 ---> B進程consumer2

• Group High-level-consumer可以聲明group，每個group可以有多個consumer，每group各自管理各自的消費offset，各個不同group之間互不關聯影響。

  由於目前版本消費的offset、owner、group都是consumer自己通過zk管理，所以group對於broker和producer並不關心，一些監控工具需要通過group來監控，simpleComsumer無需聲明group。

小提示

以上概念是 logstash 的 kafka 插件的必要參數，請理解閱讀，對後續使用 kafka 插件有重要作用。logstash-kafka-input 插件使用的是 High-level-consumer API。

插件安裝

logstash-1.4 安裝

如果你使用的還是 1.4 版本，需要自己單獨安裝 logstash-kafka 插件。插件地址見：https://github.com/joekiller/logstash-kafka。

插件本身內容非常簡單，其主要依賴同一作者寫的 jruby-kafka 模塊。需要注意的是：該模塊僅支持 Kafka-0.8 版本。如果是使用 0.7 版本 kafka 的，將無法直接使 jruby-kafka 該模塊和 logstash-kafka 插件。

安裝按照官方文檔完全自動化的安裝。或是可以通過以下方式手動自己安裝插件，不過重點注意的是 kafka 的版本，上面已經指出了。

1. 下載 logstash 並解壓重命名爲 ./logstash-1.4.0 文件目錄。
2. 下載 kafka 相關組件，以下示例選的爲 kafka_2.8.0-0.8.1.1-src，並解壓重命名爲 ./kafka_2.8.0-0.8.1.1。
3. 從 releases 頁下載 logstash-kafka v0.4.2 版，並解壓重命名爲 ./logstash-kafka-0.4.2。
4. 從 ./kafka_2.8.0-0.8.1.1/libs 目錄下複製所有的 jar 文件拷貝到 ./logstash-1.4.0/vendor/jar/kafka_2.8.0-0.8.1.1/libs 下，其中你需要創建 kafka_2.8.0-0.8.1.1/libs 相關文件夾及目錄。
5. 分別複製 ./logstash-kafka-0.4.2/logstash 裏的 inputs 和 outputs 下的 kafka.rb，拷貝到對應的 ./logstash-1.4.0/lib/logstash 裏的 inputs 和 outputs 對應目錄下。
6. 切換到 ./logstash-1.4.0 目錄下，現在需要運行 logstash-kafka 的 gembag.rb 腳本去安裝 jruby-kafka 庫，執行以下命令： GEM_HOME=vendor/bundle/jruby/1.9 GEM_PATH= java -jar vendor/jar/jruby-complete-1.7.11.jar --1.9 ../logstash-kafka-0.4.2/gembag.rb ../logstash-kafka-0.4.2/logstash-kafka.gemspec。
7. 現在可以使用 logstash-kafka 插件運行 logstash 了。

logstash-1.5 安裝

logstash 從 1.5 版本開始才集成了 Kafka 支持。1.5 版本開始所有插件的目錄和命名都發生了改變，插件發佈地址見：https://github.com/logstash-plugins。 安裝和更新插件都可以使用官方提供的方式：

$bin/plugin install OR $bin/plugin update

小貼士

對於插件的安裝和更新，默認走的Gem源爲 https://rubygems.org,對於咱們國內網絡來說是出奇的慢或是根本無法訪問（爬梯子除外），在安裝或是更新插件是，可以嘗試修改目錄下 Gemfile 文件中的 source 爲淘寶源https://ruby.taobao.org，這樣會使你的安裝或是更新順暢很多。

插件配置

Input 配置示例

以下配置可以實現對 kafka 讀取端(consumer)的基本使用。

消費端更多詳細的配置請查看 http://kafka.apache.org/documentation.html#consumerconfigs kafka 官方文檔的消費者部分配置文檔。

input {
    kafka {
        zk_connect => "localhost:2181"
        group_id => "logstash"
        topic_id => "test"
        codec => plain
        reset_beginning => false # boolean (optional)， default: false
        consumer_threads => 5  # number (optional)， default: 1
        decorate_events => true # boolean (optional)， default: false
    }
}

Input 解釋

作爲 Consumer 端,插件使用的是 High-level-consumer API，請結合上述 kafka 基本概念進行設置：

• group_id

消費者分組，可以通過組 ID 去指定，不同的組之間消費是相互不受影響的，相互隔離。

• topic_id

指定消費話題，也是必填項目，指定消費某個 topic ，這個其實就是訂閱某個主題，然後去消費。

• reset_beginning

logstash 啓動後從什麼位置開始讀取數據，默認是結束位置，也就是說 logstash 進程會以從上次讀取結束時的偏移量開始繼續讀取，如果之前沒有消費過，那麼就開始從頭讀取.如果你是要導入原有數據，把這個設定改成 "true"， logstash 進程就從頭開始讀取.有點類似 cat ，但是讀到最後一行不會終止，而是變成 tail -F ，繼續監聽相應數據。

• decorate_events

在輸出消息的時候會輸出自身的信息包括:消費消息的大小， topic 來源以及 consumer 的 group 信息。

• rebalance_max_retries

當有新的 consumer(logstash) 加入到同一 group 時，將會 reblance ，此後將會有 partitions 的消費端遷移到新的 consumer 上，如果一個 consumer 獲得了某個 partition 的消費權限，那麼它將會向zookeeper 註冊， Partition Owner registry 節點信息，但是有可能此時舊的 consumer 尚沒有釋放此節點，此值用於控制，註冊節點的重試次數。

• consumer_timeout_ms

指定時間內沒有消息到達就拋出異常，一般不需要改。

以上是相對重要參數的使用示例，更多參數可以選項可以跟據 https://github.com/joekiller/logstash-kafka/blob/master/README.md 查看 input 默認參數。

注意

1.想要使用多個 logstash 端協同消費同一個 topic 的話，那麼需要把兩個或是多個 logstash 消費端配置成相同的 group_id 和 topic_id， 但是前提是要把相應的 topic 分多個 partitions (區)，多個消費者消費是無法保證消息的消費順序性的。

這裏解釋下，爲什麼要分多個 partitions(區)， kafka 的消息模型是對 topic 分區以達到分佈式效果。每個 topic 下的不同的 partitions (區)只能有一個 Owner 去消費。所以只有多個分區後才能啓動多個消費者，對應不同的區去消費。其中協調消費部分是由 server 端協調而成。不必使用者考慮太多。只是消息的消費則是無序的。

總結:保證消息的順序，那就用一個 partition。 kafka 的每個 partition 只能同時被同一個 group 中的一個 consumer 消費。

Output 配置

以下配置可以實現對 kafka 寫入端 (producer) 的基本使用。

生產端更多詳細的配置請查看 http://kafka.apache.org/documentation.html#producerconfigs kafka 官方文檔的生產者部分配置文檔。

 output {
    kafka {
        broker_list => "localhost:9092"
        topic_id => "test"
        compression_codec => "snappy" # string (optional)， one of ["none"， "gzip"， "snappy"]， default: "none"
    }
}

Output 解釋

作爲 Producer 端使用，以下僅爲重要概念解釋，請結合上述 kafka 基本概念進行設置：

• compression_codec

消息的壓縮模式，默認是 none，可以有 gzip 和 snappy (暫時還未測試開啓壓縮與不開啓的性能，數據傳輸大小等對比)。

• compressed_topics

可以針對特定的 topic 進行壓縮，設置這個參數爲 topic ，表示此 topic 進行壓縮。

• request_required_acks

消息的確認模式:

可以設置爲 0: 生產者不等待 broker 的迴應，只管發送.會有最低能的延遲和最差的保證性(在服務器失敗後會導致信息丟失) 可以設置爲 1: 生產者會收到 leader 的迴應在 leader 寫入之後.(在當前 leader 服務器爲複製前失敗可能會導致信息丟失) 可以設置爲 -1: 生產者會收到 leader 的迴應在全部拷貝完成之後。

• partitioner_class

分區的策略，默認是 hash 取模

• send_buffer_bytes

socket 的緩存大小設置，其實就是緩衝區的大小

消息模式相關

• serializer_class

消息體的系列化處理類，轉化爲字節流進行傳輸，請注意 encoder 必須和下面的 key_serializer_class使用相同的類型。

• key_serializer_class

默認的是與 serializer_class 相同

• producer_type

生產者的類型 async 異步執行消息的發送 sync 同步執行消息的發送

• queue_buffering_max_ms

異步模式下，那麼就會在設置的時間緩存消息，並一次性發送

• queue_buffering_max_messages

異步的模式下，最長等待的消息數

• queue_enqueue_timeout_ms

異步模式下，進入隊列的等待時間，若是設置爲0，那麼要麼進入隊列，要麼直接拋棄

• batch_num_messages

異步模式下，每次發送的最大消息數，前提是觸發了 queue_buffering_max_messages 或是queue_enqueue_timeout_ms 的限制

以上是相對重要參數的使用示例，更多參數可以選項可以跟據 https://github.com/joekiller/logstash-kafka/blob/master/README.md 查看 output 默認參數。

小貼士

logstash-kafka 插件輸入和輸出默認 codec 爲 json 格式。在輸入和輸出的時候注意下編碼格式。消息傳遞過程中 logstash 默認會爲消息編碼內加入相應的時間戳和 hostname 等信息。如果不想要以上信息(一般做消息轉發的情況下)，可以使用以下配置，例如:

 output {
    kafka {
        codec => plain {
            format => "%{message}"
        }
    }
}

作爲 Consumer 從kafka中讀數據，如果爲非 json 格式的話需要進行相關解碼，例如：

input {
    kafka {
        zk_connect => "xxx：xxx"
        group_id => "test"
        topic_id => "test-topic"
        codec => "line"
        ...........
    }
}

性能

隊列監控

其實 logstash 的 kafka 插件性能並不是很突出，可以通過使用以下命令查看隊列積壓消費情況：

$/bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --group test

隊列積壓嚴重，性能跟不上的情況下，結合實際服務器資源，可以適當增加 topic 的 partition 多實例化 Consumer 進行消費處理消息。

input-kafka 的 JSON 序列化性能

此外，跟 logstash-input-syslog 改在 filter 階段 grok 的優化手段類似，也可以將 logstash-input-kafka 的默認 JSON 序列化操作從 codec 階段後移到 filter 階段。如下：

input {
    kafka {
        codec => plain
    }
}
filter {
    json {
        source => "message"
    }
}

然後通過 bin/logstash -w $num_cpus 運行，利用多核計算優勢，可以獲得大約一倍左右的性能提升。

其他方案

• https://github.com/reachkrishnaraj/kafka-elasticsearch-standalone-consumer
• https://github.com/childe/hangout

原文來自：http://kibana.logstash.es/content/logstash/scale/kafka.html

目錄(?)[-]

1. 通過kafka傳輸
   1. kafka 基本概念
      1. 小提示
   2. 插件安裝
      1. logstash-14 安裝
      2. logstash-15 安裝
      3. 小貼士
   3. 插件配置
      1. Input 配置示例
      2. Input 解釋
         1. 注意
      3. Output 配置
      4. Output 解釋
         1. 消息模式相關
      5. 小貼士
      6. 性能
         1. 隊列監控
         2. input-kafka 的 JSON 序列化性能
         3. 其他方案

通過kafka傳輸

Kafka 是一個高吞吐量的分佈式發佈訂閱日誌服務，具有高可用、高性能、分佈式、高擴展、持久性等特性。目前已經在各大公司中廣泛使用。和之前採用 Redis 做輕量級消息隊列不同，Kafka 利用磁盤作隊列，所以也就無所謂消息緩衝時的磁盤問題。此外，如果公司內部已有 Kafka 服務在運行，logstash 也可以快速接入，免去重複建設的麻煩。

如果打算新建 Kafka 系統的，請參考 Kafka 官方入門文檔：http://kafka.apache.org/documentation.html#quickstart

kafka 基本概念

以下僅對相關基本概念說明，更多概念見官方文檔：

• Topic 主題，聲明一個主題，producer指定該主題發佈消息，訂閱該主題的consumer對該主題進行消費
• Partition 每個主題可以分爲多個分區，每個分區對應磁盤上一個目錄，分區可以分佈在不同broker上，producer在發佈消息時，可以通過指定partition key映射到對應分區，然後向該分區發佈消息，在無partition key情況下，隨機選取分區，一段時間內觸發一次(比如10分鐘)，這樣就保證了同一個producer向同一partition發佈的消息是順序的。 消費者消費時，可以指定partition進行消費，也可以使用high-level-consumer api,自動進行負載均衡，並將partition分給consumer，一個partition只能被一個consumer進行消費。

• Consumer 消費者，可以多實例部署，可以批量拉取，有兩類API可供選擇：一個simpleConsumer，暴露所有的操作給用戶，可以提交offset、fetch offset、指定partition fetch message；另外一個high-level-consumer(ZookeeperConsumerConnector)，幫助用戶做基於partition自動分配的負載均衡，定期提交offset，建立消費隊列等。simpleConsumer相當於手動擋，high-level-consumer相當於自動擋。

  simpleConsumer：無需像high-level-consumer那樣向zk註冊brokerid、owner，甚至不需要提交offset到zk，可以將offset提交到任意地方比如(mysql,本地文件等)。

  high-level-consumer：一個進程中可以啓多個消費線程，一個消費線程即是一個consumer，假設A進程裏有2個線程(consumerid分別爲1，2)，B進程有2個線程(consumerid分別爲1，2)，topic1的partition有5個，那麼partition分配是這樣的：

    partition1 ---> A進程consumerid1
    partition2 ---> A進程consumerid1
    partition3 ---> A進程consumerid2
    partition4 ---> B進程consumer1
    partition5 ---> B進程consumer2

• Group High-level-consumer可以聲明group，每個group可以有多個consumer，每group各自管理各自的消費offset，各個不同group之間互不關聯影響。

  由於目前版本消費的offset、owner、group都是consumer自己通過zk管理，所以group對於broker和producer並不關心，一些監控工具需要通過group來監控，simpleComsumer無需聲明group。

小提示

以上概念是 logstash 的 kafka 插件的必要參數，請理解閱讀，對後續使用 kafka 插件有重要作用。logstash-kafka-input 插件使用的是 High-level-consumer API。

插件安裝

logstash-1.4 安裝

如果你使用的還是 1.4 版本，需要自己單獨安裝 logstash-kafka 插件。插件地址見：https://github.com/joekiller/logstash-kafka。

插件本身內容非常簡單，其主要依賴同一作者寫的 jruby-kafka 模塊。需要注意的是：該模塊僅支持 Kafka-0.8 版本。如果是使用 0.7 版本 kafka 的，將無法直接使 jruby-kafka 該模塊和 logstash-kafka 插件。

安裝按照官方文檔完全自動化的安裝。或是可以通過以下方式手動自己安裝插件，不過重點注意的是 kafka 的版本，上面已經指出了。

1. 下載 logstash 並解壓重命名爲 ./logstash-1.4.0 文件目錄。
2. 下載 kafka 相關組件，以下示例選的爲 kafka_2.8.0-0.8.1.1-src，並解壓重命名爲 ./kafka_2.8.0-0.8.1.1。
3. 從 releases 頁下載 logstash-kafka v0.4.2 版，並解壓重命名爲 ./logstash-kafka-0.4.2。
4. 從 ./kafka_2.8.0-0.8.1.1/libs 目錄下複製所有的 jar 文件拷貝到 ./logstash-1.4.0/vendor/jar/kafka_2.8.0-0.8.1.1/libs 下，其中你需要創建 kafka_2.8.0-0.8.1.1/libs 相關文件夾及目錄。
5. 分別複製 ./logstash-kafka-0.4.2/logstash 裏的 inputs 和 outputs 下的 kafka.rb，拷貝到對應的 ./logstash-1.4.0/lib/logstash 裏的 inputs 和 outputs 對應目錄下。
6. 切換到 ./logstash-1.4.0 目錄下，現在需要運行 logstash-kafka 的 gembag.rb 腳本去安裝 jruby-kafka 庫，執行以下命令： GEM_HOME=vendor/bundle/jruby/1.9 GEM_PATH= java -jar vendor/jar/jruby-complete-1.7.11.jar --1.9 ../logstash-kafka-0.4.2/gembag.rb ../logstash-kafka-0.4.2/logstash-kafka.gemspec。
7. 現在可以使用 logstash-kafka 插件運行 logstash 了。

logstash-1.5 安裝

logstash 從 1.5 版本開始才集成了 Kafka 支持。1.5 版本開始所有插件的目錄和命名都發生了改變，插件發佈地址見：https://github.com/logstash-plugins。 安裝和更新插件都可以使用官方提供的方式：

$bin/plugin install OR $bin/plugin update

小貼士

對於插件的安裝和更新，默認走的Gem源爲 https://rubygems.org,對於咱們國內網絡來說是出奇的慢或是根本無法訪問（爬梯子除外），在安裝或是更新插件是，可以嘗試修改目錄下 Gemfile 文件中的 source 爲淘寶源https://ruby.taobao.org，這樣會使你的安裝或是更新順暢很多。

插件配置

Input 配置示例

以下配置可以實現對 kafka 讀取端(consumer)的基本使用。

消費端更多詳細的配置請查看 http://kafka.apache.org/documentation.html#consumerconfigs kafka 官方文檔的消費者部分配置文檔。

input {
    kafka {
        zk_connect => "localhost:2181"
        group_id => "logstash"
        topic_id => "test"
        codec => plain
        reset_beginning => false # boolean (optional)， default: false
        consumer_threads => 5  # number (optional)， default: 1
        decorate_events => true # boolean (optional)， default: false
    }
}

Input 解釋

作爲 Consumer 端,插件使用的是 High-level-consumer API，請結合上述 kafka 基本概念進行設置：

• group_id

消費者分組，可以通過組 ID 去指定，不同的組之間消費是相互不受影響的，相互隔離。

• topic_id

指定消費話題，也是必填項目，指定消費某個 topic ，這個其實就是訂閱某個主題，然後去消費。

• reset_beginning

logstash 啓動後從什麼位置開始讀取數據，默認是結束位置，也就是說 logstash 進程會以從上次讀取結束時的偏移量開始繼續讀取，如果之前沒有消費過，那麼就開始從頭讀取.如果你是要導入原有數據，把這個設定改成 "true"， logstash 進程就從頭開始讀取.有點類似 cat ，但是讀到最後一行不會終止，而是變成 tail -F ，繼續監聽相應數據。

• decorate_events

在輸出消息的時候會輸出自身的信息包括:消費消息的大小， topic 來源以及 consumer 的 group 信息。

• rebalance_max_retries

當有新的 consumer(logstash) 加入到同一 group 時，將會 reblance ，此後將會有 partitions 的消費端遷移到新的 consumer 上，如果一個 consumer 獲得了某個 partition 的消費權限，那麼它將會向zookeeper 註冊， Partition Owner registry 節點信息，但是有可能此時舊的 consumer 尚沒有釋放此節點，此值用於控制，註冊節點的重試次數。

• consumer_timeout_ms

指定時間內沒有消息到達就拋出異常，一般不需要改。

以上是相對重要參數的使用示例，更多參數可以選項可以跟據 https://github.com/joekiller/logstash-kafka/blob/master/README.md 查看 input 默認參數。

注意

1.想要使用多個 logstash 端協同消費同一個 topic 的話，那麼需要把兩個或是多個 logstash 消費端配置成相同的 group_id 和 topic_id， 但是前提是要把相應的 topic 分多個 partitions (區)，多個消費者消費是無法保證消息的消費順序性的。

這裏解釋下，爲什麼要分多個 partitions(區)， kafka 的消息模型是對 topic 分區以達到分佈式效果。每個 topic 下的不同的 partitions (區)只能有一個 Owner 去消費。所以只有多個分區後才能啓動多個消費者，對應不同的區去消費。其中協調消費部分是由 server 端協調而成。不必使用者考慮太多。只是消息的消費則是無序的。

總結:保證消息的順序，那就用一個 partition。 kafka 的每個 partition 只能同時被同一個 group 中的一個 consumer 消費。

Output 配置

以下配置可以實現對 kafka 寫入端 (producer) 的基本使用。

生產端更多詳細的配置請查看 http://kafka.apache.org/documentation.html#producerconfigs kafka 官方文檔的生產者部分配置文檔。

 output {
    kafka {
        broker_list => "localhost:9092"
        topic_id => "test"
        compression_codec => "snappy" # string (optional)， one of ["none"， "gzip"， "snappy"]， default: "none"
    }
}

Output 解釋

作爲 Producer 端使用，以下僅爲重要概念解釋，請結合上述 kafka 基本概念進行設置：

• compression_codec

消息的壓縮模式，默認是 none，可以有 gzip 和 snappy (暫時還未測試開啓壓縮與不開啓的性能，數據傳輸大小等對比)。

• compressed_topics

可以針對特定的 topic 進行壓縮，設置這個參數爲 topic ，表示此 topic 進行壓縮。

• request_required_acks

消息的確認模式:

可以設置爲 0: 生產者不等待 broker 的迴應，只管發送.會有最低能的延遲和最差的保證性(在服務器失敗後會導致信息丟失) 可以設置爲 1: 生產者會收到 leader 的迴應在 leader 寫入之後.(在當前 leader 服務器爲複製前失敗可能會導致信息丟失) 可以設置爲 -1: 生產者會收到 leader 的迴應在全部拷貝完成之後。

• partitioner_class

分區的策略，默認是 hash 取模

• send_buffer_bytes

socket 的緩存大小設置，其實就是緩衝區的大小

消息模式相關

• serializer_class

消息體的系列化處理類，轉化爲字節流進行傳輸，請注意 encoder 必須和下面的 key_serializer_class使用相同的類型。

• key_serializer_class

默認的是與 serializer_class 相同

• producer_type

生產者的類型 async 異步執行消息的發送 sync 同步執行消息的發送

• queue_buffering_max_ms

異步模式下，那麼就會在設置的時間緩存消息，並一次性發送

• queue_buffering_max_messages

異步的模式下，最長等待的消息數

• queue_enqueue_timeout_ms

異步模式下，進入隊列的等待時間，若是設置爲0，那麼要麼進入隊列，要麼直接拋棄

• batch_num_messages

異步模式下，每次發送的最大消息數，前提是觸發了 queue_buffering_max_messages 或是queue_enqueue_timeout_ms 的限制

以上是相對重要參數的使用示例，更多參數可以選項可以跟據 https://github.com/joekiller/logstash-kafka/blob/master/README.md 查看 output 默認參數。

小貼士

logstash-kafka 插件輸入和輸出默認 codec 爲 json 格式。在輸入和輸出的時候注意下編碼格式。消息傳遞過程中 logstash 默認會爲消息編碼內加入相應的時間戳和 hostname 等信息。如果不想要以上信息(一般做消息轉發的情況下)，可以使用以下配置，例如:

 output {
    kafka {
        codec => plain {
            format => "%{message}"
        }
    }
}

作爲 Consumer 從kafka中讀數據，如果爲非 json 格式的話需要進行相關解碼，例如：

input {
    kafka {
        zk_connect => "xxx：xxx"
        group_id => "test"
        topic_id => "test-topic"
        codec => "line"
        ...........
    }
}

性能

隊列監控

其實 logstash 的 kafka 插件性能並不是很突出，可以通過使用以下命令查看隊列積壓消費情況：

$/bin/kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --group test

隊列積壓嚴重，性能跟不上的情況下，結合實際服務器資源，可以適當增加 topic 的 partition 多實例化 Consumer 進行消費處理消息。

input-kafka 的 JSON 序列化性能

此外，跟 logstash-input-syslog 改在 filter 階段 grok 的優化手段類似，也可以將 logstash-input-kafka 的默認 JSON 序列化操作從 codec 階段後移到 filter 階段。如下：

input {
    kafka {
        codec => plain
    }
}
filter {
    json {
        source => "message"
    }
}

然後通過 bin/logstash -w $num_cpus 運行，利用多核計算優勢，可以獲得大約一倍左右的性能提升。

其他方案

• https://github.com/reachkrishnaraj/kafka-elasticsearch-standalone-consumer
• https://github.com/childe/hangout

原文來自：http://kibana.logstash.es/content/logstash/scale/kafka.html