原因： logstash 日誌報錯生產數據到 kafka 失敗

解決辦法：

? ? ? ? ?查看kafka配置，默認單條消息最大為1M，當單條消息長度超過1M時，就會出現發送到broker失敗，從而導致消息在producer的隊列中一直累積，直到撐爆生產者的內存。

於是趕緊修改kafka配置，解決問題。主要修改步驟如下：

? ? ? ? ?1.修改kafka的broker配置：message.max.bytes（默認:1000000B），這個參數表示單條消息的最大長度。在使用kafka的時候，應該預估單條消息的最大長度，不然導致發送失敗。

? ? ? ?2.修改kafka的broker配置：replica.fetch.max.bytes?(默認: 1MB)，broker可復制的消息的最大字節數。這個值應該比message.max.bytes大，否則broker會接收此消息，但無法將此消息復制出去，從而造成數據丟失。

? ? ? 3.修改消費者程序端配置：fetch.message.max.bytes?(默認 1MB) – 消費者能讀取的最大消息。這個值應該大於或等於message.max.bytes。如果不調節這個參數，就會導致消費者無法消費到消息，並且不會爆出異常或者警告，導致消息在broker中累積，此處要註意。

? ? ? 根據需要，調整上述三個參數的大小。但是否參數調節得越大越好，或者說單條消息越大越好呢？參考http://www.mamicode.com/info-detail-453907.html的說法：

? ? ? 1.從性能上考慮：通過性能測試，kafka在消息為10K時吞吐量達到最大，更大的消息會降低吞吐量，在設計集群的容量時，尤其要考慮這點。

? ? ? 2.可用的內存和分區數：Brokers會為每個分區分配replica.fetch.max.bytes參數指定的內存空間，假設replica.fetch.max.bytes=1M，且有1000個分區，則需要差不多1G的內存，確保 分區數最大的消息不會超過服務器的內存，否則會報OOM錯誤。同樣地，消費端的fetch.message.max.bytes指定了最大消息需要的內存空間，同樣，分區數

? ? ?3.垃圾回收：更大的消息會讓GC的時間更長（因為broker需要分配更大的塊），隨時關註GC的日誌和服務器的日誌信息。如果長時間的GC導致kafka丟失了zookeeper的會話，則需要配置zookeeper.session.timeout.ms參數為更大的超時時間。

logstash 消費數據到kafka異常