{
"version": "1.1",
"host": "example.org",
"short_message": "A short message that helps you identify what is going on",
"full_message": "Backtrace here\n\nmore stuff",
"timestamp": 1385053862.3072,
"level": 1,
"_user_id": 9001,
"_some_info": "foo",
"_some_env_var": "bar"
}
The event does load successfully, but what I found for source:graylog-server is:
facility
runit-service
from_gelf
true
level
6
message
java.lang.IllegalStateException: GELF message is too short. Not even the type header would fit.
source
graylog-server
timestamp
2018-12-17T22:52:22.914Z
So does that mean the message are being received correctly? And that the GELF input is working and that you’re not missing any data? That’s our first priority. After that we can focus on cosmetics
YES
the log comes correctly.
But I have too much cosmectics (some 45 records) for each one uploaded, where the ERROR and java.lang.Illegal… are present too.
Sorry, I had misunderstood your previous post. I thought you said you received 45 correct messages, but what you means is that for every 1 correct message, you get 45 errors as well? Yikes! That’s not pretty.
What happens is that for every 1 record uploaded, I see some 45 generated as (it looks) internal graylog messages, where between them, I can find the highlighted:
ERROR and java.lang.IllegalStateException - related to my single upload
thank you very much for the image link, found where you pointed.
but now that I uploaded the TCP Input config as text, I guess you don’t need it anymore?
sorry for missing the point and answering to Tess someplace instead.
For your question: “how you set up the log sender?”:
I am sending logs directly from Oracle PL/SQ to GELF TCP Input by json.
Using the UTL_TCP package, and the way I successfully do with Splunk.
GELF expects a specific formatting of the data. You’ll need to use a “RAW” input instead @altink. What kind of input/receiver did you use back on Splunk?
The test record I am loading - displayed as above - is identical to what is given in the Documentation’s example.
As far as I have seen it, its looked to me that GrayLog’s and Splunk’s TCP Data Input mechanisms are the same. The only difference being in that in Splunk I have used XML for formatting the record, while JSON for Graylog
Cool! So that sounds good! I wasn’t sure whether you were just sending ASCII strings at the input, or more structured data. It seems that you are, which is awesome.
Yes - I want to prepare as much as possible right into Oracle before I send to Graylog.
But it seems you have missed something:
please refer the link I have mentioned at the body of this ticket - the “GELF - Graylog 2.5.0 documentation”. It the version 2.5 of the link you lastly suggested.
As for the data I am sending - they are exactly those presented in the end of that page under the paragraph named “Example Payload”.
These lines too are displayed by me in this ticket’s body, please refer to 1/15. Here they are as they are send by Oracle’s dbms_output.put_line(graylog_record) - and as you can see they do match 100% the example.
I don’t guess the Documentation is wrong, so do I have something wrong in my stuff?
Remarkable… So let’s try two extra troubleshooting steps! This is a fun problem
Can you start a Netcat listener somewhere and direct your Oracle app to send the logs to that listener? That will show you exactly what the outcome is that Graylog would receive.
Vice versa, could you use Netcat to send the exact JSON output that you are sending directly into the Graylog input? That way you can tell whether it does make its way into Graylog.
This did upload correctly and without (!) extra internal messages.
I tested again by removing the:
"\0" option
and I noticed that it was the “\0” option that made the difference. Without it - there are the ERROR, the java.Ilegal and the other 45 msg (in all). If it is present - it is OK.
But I still have my problem when I send it from Oracle’s UTL_TCP. I have the ERROR, java.Illegal and the messaged.
The string is identical to the one with the echo:
{ "version": "1.1", "host": "dataplus05", "short_message": "A short message", "level": 5, "_some_info": "foo" }"\0"
taken (dbms_output-ed) just before record send.
is there something that can be seen in the graylog internal events to identify the problem?
Why should the backslash-zero cause an impact on the result?
I mean when testing with echo. The docs, part “GELF via TCP”, notes:
“Each message needs to be delimited with a null byte ( \0 ) when sent in the same TCP connection.”
So it looks that its effect should happen only for multirecords sent in the same connection?
So why does it has an impact for a single record.
And my main problem still stands. echo does work, but in the real life, other things (like UTL_TCP) are supposeed to work too, cause it is with them the data comes, and not the echo.