Gelf::Notifier#extract_hash merges the default options hash into the message data hash, so your messages end up including all of the default options as if they were fields. May of them are fields, but protocol isn't; indeed if you wanted to include a field named protocol, you should be required to supply it as _protocol. A simple protocol field should be silently ignored by Graylog, but I end up with protocol => 0 in my received messages regardless.
This is a bit of a problem, since in my Elasticsearch indices protocol is supposed to be a string field, and when gelf-rb establishes it as a long field instead, future messages with actual data in the protocol field can't be indexed properly (and of course if one of the 'good' messages gets there first then no message submitted by gelf-rb can be indexed properly).
The whole things is unnecessary anyway, since the the result of the merge is never even checked for the protocol; the protocol is read straight out of default_options regardless.
Gelf::Notifier#extract_hashmerges the default options hash into the message data hash, so your messages end up including all of the default options as if they were fields. May of them are fields, butprotocolisn't; indeed if you wanted to include a field named protocol, you should be required to supply it as_protocol. A simpleprotocolfield should be silently ignored by Graylog, but I end up withprotocol => 0in my received messages regardless.This is a bit of a problem, since in my Elasticsearch indices
protocolis supposed to be a string field, and whengelf-rbestablishes it as a long field instead, future messages with actual data in the protocol field can't be indexed properly (and of course if one of the 'good' messages gets there first then no message submitted bygelf-rbcan be indexed properly).The whole things is unnecessary anyway, since the the result of the merge is never even checked for the protocol; the protocol is read straight out of
default_optionsregardless.