hedii / laravel-gelf-logger

A package to send gelf logs to a gelf compatible backend like graylog
MIT License
125 stars 33 forks source link

Is there any way to set GELF spec version to 1.1 ? #13

Closed zedee closed 4 years ago

zedee commented 4 years ago

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?

hedii commented 4 years ago

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 :)

zedee commented 4 years ago

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 ::)

hedii commented 4 years ago

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 (https://github.com/bzikarsky/gelf-php/issues/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

zedee commented 4 years ago

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?

hedii commented 4 years ago

I keep this issue open. Please update it when you have some news, I will be notified.

zedee commented 4 years ago

@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. :)

hedii commented 4 years ago

Good to know, thanks