# UDP Messages Not Getting Logged **URL:** \ **Category:** Graylog Central (peer support)\ **Created:** [December 2, 2019, 4:04pm UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031 "2019-12-02T16:04:14Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![elkvis](https://avatars.discourse-cdn.com/v4/letter/e/3be4f8/32.png) [@elkvis](https://community.graylog.org/u/elkvis)\ **Post date:** [December 2, 2019, 4:04pm UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031/1 "2019-12-02T16:04:14Z")
I’m trying to send GELF messages to the UDP input on my Graylog server, using a custom C++ library that I wrote. Some of the messages are being silently ignored. Is there a log somewhere that I can look at, which will tell me if the packets are being received, and if so, why they are being dropped? I tried tailing the log output of the docker container, but nothing relating to my messages appears there. Alternately, is there a standardized tool available to validate a GELF message, to determine what about it, if anything, might be broken? ---
**Author:** ![jan](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jan/32/11_2.png) [@jan](https://community.graylog.org/u/jan)\ **Post date:** [December 2, 2019, 7:09pm UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031/2 "2019-12-02T19:09:25Z")
He @elkvis UDP messages might be dropped - that can happens because of UDP. If some messages make it into Graylog and some not, you might want to debug the system itself. Check for RX Errors on the interface, or similar debugging. ---
**Author:** ![elkvis](https://avatars.discourse-cdn.com/v4/letter/e/3be4f8/32.png) [@elkvis](https://community.graylog.org/u/elkvis)\ **Post date:** [December 2, 2019, 7:30pm UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031/3 "2019-12-02T19:30:16Z")
The thing that seems to be more-or-less guaranteed to elicit a failure is including a stack trace in my GELF message. If I have a `_stackTrace` field set to something meaningless like “Stack Trace,” the message is logged reliably every time. If that field contains an actual stack trace, it fails almost every single time. I’ve tried URL-encoding the stack trace, base-64 encoding it, lots of other things, and If there is an actual stack trace present, it fails. This is why I was hoping for a message validator of some sort, to see what’s actually broken. The message length seems to be irrelevant. If I log a very long message, it also works, as long as there’s no stack trace. ---
**Author:** ![jan](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/jan/32/11_2.png) [@jan](https://community.graylog.org/u/jan)\ **Post date:** [December 3, 2019, 9:22am UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031/4 "2019-12-03T09:22:42Z")
I guess the stack trace is a multi line event? that might be the reason. ---
**Author:** ![elkvis](https://avatars.discourse-cdn.com/v4/letter/e/3be4f8/32.png) [@elkvis](https://community.graylog.org/u/elkvis)\ **Post date:** [December 3, 2019, 3:47pm UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031/5 "2019-12-03T15:47:18Z")
The stack trace is multi-line, but newlines are being properly encoded with \r and \n as necessary. That doesn’t make sense. The official GELF documentation gives an actual example of a valid message with \n in one of the fields. ---
**Author:** ![elkvis](https://avatars.discourse-cdn.com/v4/letter/e/3be4f8/32.png) [@elkvis](https://community.graylog.org/u/elkvis)\ **Post date:** [December 3, 2019, 9:26pm UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031/6 "2019-12-03T21:26:33Z")
Well, newlines appear to be the problem after all. The absurd part of it is that my `full_message` field contains `\n` characters, and gets logged without issue. If I have a newline in an additional field, with a ‘\_’ prefix, such as my `_stackTrace` field, even when properly encoded, the whole message gets rejected, with no diagnostic information logged anywhere. There is no mention of this behavior anywhere in the [GELF format documentation](https://docs.graylog.org/en/3.1/pages/gelf.html) 😡 ---
**Author:** ![macko003](https://sea2.discourse-cdn.com/flex016/user_avatar/community.graylog.org/macko003/32/3175_2.png) [@macko003](https://community.graylog.org/u/macko003)\ **Post date:** [December 4, 2019, 11:50am UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031/7 "2019-12-04T11:50:02Z")
//known issue, GL drops UDP under java’s GC process If you can avoid to use UDP. ---
**Author:** ![elkvis](https://avatars.discourse-cdn.com/v4/letter/e/3be4f8/32.png) [@elkvis](https://community.graylog.org/u/elkvis)\ **Post date:** [December 4, 2019, 2:24pm UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031/8 "2019-12-04T14:24:16Z")
If it was a GC problem, I would expect it to be much more random. I can consistently make it happen if I include a newline character in the value of an additional field. ---
**Author:** ![system](https://us1.discourse-cdn.com/flex016/uploads/graylog/original/3X/c/7/c7c09c6b5099570133d6502b83f50ba4430de5b6.png) [@system](https://community.graylog.org/u/system)\ **Post date:** [December 18, 2019, 2:24pm UTC](https://community.graylog.org/t/udp-messages-not-getting-logged/13031/9 "2019-12-18T14:24:23Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.