Is there any way to set GELF spec version to 1.1 ?
zedee opened this issue · 7 comments
I'm trying to set the GELF version output payload to 1.1 (as Graylog documentation require), instead of 1.0, but I cannot find any obvious way to do so.
I've observed that in Message class there's a setVersion() method, but I have no clue how could I reach that instance from a processor.
Any idea where to start?
Hi @zedee,
There is no way to do it as it is now.
As I can read here there is no disadvantage in using version 1.0 of gelf message over 1.1. I never had an issue with graylog using version 1.0.
Also, zikarsky/gelf-php (the underlying package for laravel-gelf-loger) uses 1.0 by default.
But if you really need it, a PR with tests is welcome :)
hi @hedii
Thanks for your answer.
Well, there's no disadvantage, but in the Graylog docs (latest):
https://docs.graylog.org/en/3.1/pages/gelf.html#gelf-payload-specification
It seems that they specify that 1.1 must be set there instead of 1.0
Actuallly I'm having an issue with a cloud service called "Log data platform" (from OVH provider). They use Graylog 2.5.1, but even all the stream is correctly set up, all logs set with version 1.0 are ignored, therefore Graylog shows nothing.
I tried to "hardcode" (for testing purposes) the version on the constructor, and changed to 1.1. After that, Graylog started to show up all the stream data. Maybe is a misconfiguration of the cloud provider? Maybe their API has an issue and it is filtering all packages without that version value (I already have to add a special token to the payload, which I do via processor)
Anyway,
So you suggest to make a PR where from the config file you can set the version, for instance?
Or just fork it and change the default on the constructor from 1.0 to 1.1?
cheers ::)
I never had any issue with gelf 1.0 messages, even when I was using graylog 2.x (I am on version 3 now).
I don't think ovh is blocking 1.0 messages, and they should be received by graylog.
Maybe take a look at indexes failures on graylog (System / Indices > Overview > Indexer failures).
Gelf message version is hardcoded in version 1.x of graylog2/gelf-php (the underlying composer package I use on this repo). They plan to change that in version 2 of graylog2/gelf-php (bzikarsky/gelf-php#23). Until version 2 of graylog2/gelf-php is released, there is nothing I can do.
But really, I think that version 1.0 of gelf messages is not your problem. You must have a misconfiguration somewhere else.
Maybe you can ask on the ovh community forum (you can write your topic in english), there is always an ovh staff member or a customer to reply: http://community.ovh.com/c/platform/data-platforms
Thanks for the update.
The thing is that when I "hardcode" on the Message class version prop from 1.0 to 1.1, Graylog shows logs. If I don't, there's no logs showing up.
I already contacted and opened a ticket to OVH, because I think the issue is between the log data stream and Graylog on the OVH part. I cannot see indexes failures on Graylog, because I'm using a free tier and lots of stuff are capped.
By now I think the issue can be closed. If I got response from OVH that explains what happen, will I be able to comment again just to point out what the problem came from?
I keep this issue open. Please update it when you have some news, I will be notified.
@hedii My apologies, forgot about this still open!
After a couple mails with OVH support, seems that the implementation they were using on their side, wasn't expecting nested objects as a field value, or at least that's what I understood as the reason (the communication was in spanish and it seem 'translated' from other language because the grammar / expressions on OVH's mail were a bit weird).
They made a patch and solved the issue.
TL,DR: Problem was on OVH side. :)
Good to know, thanks