logstash 消費數據到kafka異常
原因: 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異常