[ANNOUNCE] node-red-contrib-syslog-input

Share Your Nodes
1

Hi All,

A brief announcement.

Back in November, I floated the idea of a new node for receiving remote syslog log messages.

This post is to advise that the new node has been published under the name node-red-contrib-syslog-input.

The node can be used, such as is illustrated in the screenshot below:

screenshot
0.png1610Ă—514 59.8 KB

The msg object generated from the received syslog messages is formatted as follows:

{
  "facility": "daemon",
  "facilityCode": 3,
  "severity": "info",
  "severityCode": 6,
  "tag": "systemd[1]",
  "timestamp": "2018-12-26T17:53:57.000Z",
  "hostname": "localhost",
  "address": "::ffff:192.168.147.131",
  "family": "IPv6",
  "port": 38514,
  "size": 80,
  "msg": "Started Daily apt download activities."
}

There is plenty of documentation explaining how to use it. Refer to the README for full details.

Hope somebody finds it useful.

Cheers,
Damo

6 Likes
2

It doesn't appear to have appeared in flows? I had to install manually since that also means it doesn't appear in the manage palette feature.

Going to give it a go with my Ubiquiti Router and WiFi.

3

It doesn't have node-red listed as a keyword in its package.json file, so won't get picked up by the flow library.

4

Thanks Nick. Hopefully @damoclark will fix that shortly.

In the meantime, it works just fine with my Unifi EdgeRouter Lite and AP-Pro.

5

Oops.

An embarrassing oversight. :blush:

I'll fix it this afternoon.

Glad it is working well for you @TotallyInformation.

Cheers,
D.

6

Interesting node to gather syslog data, for my ubiquiti devices it works nicely thanks.
For my Synology NAS however, it states invalid message received:

3/13/2019, 5:27:18 AMnode: syslog
msg : string[285]
"Invalid message received: {"timestamp":"2019-03-13T04:27:18.487Z","address":"::ffff:10.0.0.200","family":"IPv6","port":59776,"size":137,"msg":"<14>1 2019-03-13T05:27:18+01:00 NAS System - - [meta sequenceId=\"1\"] Test message from Synology Syslog Client from (x.x.x.x)\n"}"

Not sure what is wrong in this format ?

7

This resembles syslog RFC 5424, which is a newer standard for bsd syslog. Check the settings for your synology device for an option to log using RFC 3164 which is more common.

D.

8

something to add to the ReadMe?

9

The support both and i tried both, same message.

10

If you get exactly the same message then I think that means it has not switched to the other protocol.

11

I meant an error, not the same message: this is RFC 3164:
<14>Mar 14 17:24:24 NAS System Test message from Synology Syslog Client from (x.x.x.x)

Then again, when I use a tcp-in I can parse it myself.

12

Hi All,

Just getting back to this again. @bakman2 this information has helped isolate the issue.

The problem stems from convention versus strict adherance to RF3164. This disparity is not uncommon, particularly for older RFCs. From section 4.1.3:

The MSG part will fill the remainder of the syslog packet [after the timestamp]. This will usually contain some additional information of the process that generated the message, and then the text of the message.
...
The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message.

Your syslog message above is missing the TAG field.

But its not a clear-cut case. Section 5.3 and 5.4 of the RFC expand on the TAG field further, with vague comments such as:

It has also been considered to be a good practice to include some information about the process on the device that generated the message - if that concept exists. This is usually the process name and process id (often known as the "pid") for robust operating systems. The process name is commonly displayed in the TAG field. Quite often, additional information is included at the beginning of the CONTENT field. The format of "TAG[pid]:" - without the quote marks - is common. The left square bracket is used to terminate the TAG field in this case and is then the first character in the CONTENT field. If the process id is immaterial, it may be left off.

From line 110, in the simple-syslog-server library used by this node, it assumes a tag field is provided and formatted according to the convention shown in the RFC.

@bakman2, just wondering how you generated the test syslog messages from your NAS? Did you craft them yourself, or did you simply click a button through the software to have it send one?

If the former, then you may be in luck in that your router does generate syslog messages conventionally.

If not, then the code for node-red-contrib-syslog-input that parses the syslog messages will need to be rewritten to comply more strictly to the RFC. Unfortunately, I don't have the capacity to undertake that sort of work at this time, but I will gratefully accept Github PRs if someone is able to prepare one.

Damo.

13

I appear to have a similar issue. However, my choices from the device that is generating the messages are limited to: Enable/Disable, Server IP, and Port #. Is it possible to modify the node to handle this? What is the "TCP in" stuff that was discussed? New guy, so not sure. Here is a repost of the error:

Invalid message received: {"timestamp":"2019-11-14T22:26:34.000Z","address":"192.168.15.39","family":"IPv4","port":20514,"size":142,"msg":"<22>24/09/2016      15:04:33        User Activity                   User admin of PDU 1 Rack:AA01-MS:SideA from host 192.168.15.160 logged in\u0000"}