search

emsearcy / fluent-plugin-gelf

Buffered fluentd output plugin to GELF (Graylog2)
Apache License 2.0
33 stars 57 forks source link

fluent-plugin-gelf breaks with fluentd 0.14.7 #24

Closed gcs-github closed 7 years ago

gcs-github commented 7 years ago

I'm getting the following type of stacktrace when running under fluentd 0.14.7.

2016-10-08 13:51:01 +0000 [warn]: failed to flush the buffer. plugin_id="object:62d79288514" retry_time=0 next_retry=2016-10-08 13:51:02 +0000 chunk="53e5ad1234b711b05fd1857ecc4320c0" error_class=NoMethodError error="undefined method `msgpack_each' for #<Fluent::Plugin::Buffer::FileChunk:0x0071f4d85c1fe0>\nDid you mean?  msgpack_packer"
  2016-10-08 13:51:01 +0000 [warn]: /usr/lib64/ruby/gems/2.3.0/gems/fluent-plugin-gelf-0.1.2/lib/fluent/plugin/out_gelf.rb:101:in `write'
  2016-10-08 13:51:01 +0000 [warn]: /usr/lib64/ruby/gems/2.3.0/gems/fluentd-0.14.7/lib/fluent/compat/output.rb:127:in `write'
  2016-10-08 13:51:01 +0000 [warn]: /usr/lib64/ruby/gems/2.3.0/gems/fluentd-0.14.7/lib/fluent/plugin/output.rb:995:in `try_flush'
  2016-10-08 13:51:01 +0000 [warn]: /usr/lib64/ruby/gems/2.3.0/gems/fluentd-0.14.7/lib/fluent/plugin/output.rb:1188:in `flush_thread_run'
  2016-10-08 13:51:01 +0000 [warn]: /usr/lib64/ruby/gems/2.3.0/gems/fluentd-0.14.7/lib/fluent/plugin/output.rb:393:in `block (2 levels) in start'
  2016-10-08 13:51:01 +0000 [warn]: /usr/lib64/ruby/gems/2.3.0/gems/fluentd-0.14.7/lib/fluent/plugin_helper/thread.rb:66:in `block in thread_create'

I haven't looked into the root cause yet, but it seems this line isn't working anymore: https://github.com/emsearcy/fluent-plugin-gelf/blob/master/lib/fluent/plugin/out_gelf.rb#L101

gcs-github commented 7 years ago

Looks like the breaking change in fluentd: https://github.com/fluent/fluentd/pull/1263

gcs-github commented 7 years ago

:point_up: PR created above to fix this issue.

repeatedly commented 7 years ago

JFYI. This is the fluentd bug, not plugin. v0.14.8 has already resolves this prpblem.

gcs-github commented 7 years ago

@repeatedly in your opinion, should we get rid of the workaround in #25 ?

repeatedly commented 7 years ago

@gcs-github No. It doesn't effect the behaviour.