GelfTcpResponse not inserting "short_message" or "message" (as seen from Graylog GELF receiver machine)

[alago197]

Hi,

I'm puzzled that sending to the Gelf appender doesn't seem to produce the required short_message or message fields, at least with the latest build (1.4.7). "host", "version" and "timestamp" are passed, though (a tcpdump trace on the receiver/graylog-GELF listener is shown)

Is this a known issue? From https://github.com/spaghettidba/XESmartTarget/blob/c698355acfe6cf408b35688bac5423a26811b6b8/XESmartTarget.Core/Responses/GelfTcpResponse.cs#L97 it seems "impossible" an empty "short_message" ?

Regards,

--

root@stg-iljapp-0005:~# tcpdump -i ens192 -s 16384 -A   ip and dst port 12207

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), capture size 16384 bytes
20:15:05.906205 IP 192.168.203.12.12812 > stg-iljapp-0005.12207: Flags [S], seq 2364957333, win 64240, options [mss 1380,nop,wscale 8,nop,nop,sackOK], length 0
[email protected].....
.r.2./[email protected]........
20:15:05.936176 IP 192.168.203.12.12812 > stg-iljapp-0005.12207: Flags [.], ack 1509824531, win 1024, length 0
E..([email protected])....
.r.2./...b.Y...P.............
20:15:05.936258 IP 192.168.203.12.12812 > stg-iljapp-0005.12207: Flags [F.], seq 519, ack 1, win 1024, length 0
E..([email protected]'....
.r.2./...d.Y...P.............
20:15:05.936728 IP 192.168.203.12.12812 > stg-iljapp-0005.12207: Flags [P.], seq 0:519, ack 1, win 1024, length 519
E../[email protected]!....
.r.2./...b.Y...P...N...{"collection_time":"2022-06-30T20:15:02.9460546","name":"rpc_completed","cpu_time":172000,"duration":164066,"physical_reads":0,"logical_reads":76055,"writes":4,"result":"OK","row_count":2,"connection_reset_option":"None","object_name":"svp_siv_peticiones_mod_pro","statement":"exec [dbo].[svp_siv_peticiones_mod_pro] ","data_stream":"","output_parameters":"","client_hostname":"VMCOMPILANET","database_name":"iTareas","session_id":51,"transaction_id":0,"host":"PCALVARO","version":"1.1","timestamp":1656612902.9460545}.
20:15:05.961409 IP 192.168.203.12.12812 > stg-iljapp-0005.12207: Flags [.], ack 2, win 1024, length 0
E..([email protected]$....
.r.2./...d.Y...P.............

[spaghettidba]

Ah, I'm sorry, I know nothing about this. Hey @awickham10 , can you help please?

[awickham10]

It's been a while since I looked at this code but I believe it puts the "message" field in the XE in the "short_message" field in GELF.

Do you have a "message" field defined in your XE session?

[alago197]

Hi Andrew,

No, there is no "message" (nor "short_message") field in my XE session (see below, attached image, of autocreated fields / tested via a TableAppender too, see my config below):

    "Target": {
        // use a list of servers
        "ServerName": ["XXXXXX"],
        "SessionName": "queries_rpc_hosix5",   
        "FailOnProcessingError": false,
        "Responses": [
            {
                "__type": "TableAppenderResponse",   
                // each server will refer to itself with the {ServerName} placeholder
                // this means that in this case each server will upload the event to itself
                "ServerName": "{ServerName}",
                "DatabaseName": "testalvaro200",
                "TableName": "queriesrpc5",
                "AutoCreateTargetTable": true,   
                "UploadIntervalSeconds": 10    
            },
            {
                "__type": "GelfTcpResponse",
                "ServerName": "XX.XXX.XXX.XXX",
                "Port": "12207",
                "Encrypt": false  // ,
                //  "TrustServerCertificate": true
            },`

[alago197]

Just to clarify, my XE session captures the "rpc_completed" event in SQL Server....I don't have any "message" or "short_message" field in that event (I think that's the problem indeed)

[awickham10]

That probably explains it. It's not currently designed in a way to be able to map XE fields to GELF fields so the XE session must have a message field. It sounds like it won't work for your situation without modifications.

[alago197]

Yes. Finally, I've managed to use the CsvAppender (save to a local file, then send that file/log to Graylog via a normal input stream) for this situation. Anyway, I would like to suggest a "default" insertion of the "message" (or "short_message") field, if there's no such field in the session. Even a dummy "message: content" string would suffice to comply the GELF specs (and as we can see from the capture above, the rest of the fields are present). Feel free to close this issue, of course.