Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add RFC5424 (IETF) syslog format handling #149

Open
philhagen opened this issue Feb 26, 2019 · 8 comments
Open

add RFC5424 (IETF) syslog format handling #149

philhagen opened this issue Feb 26, 2019 · 8 comments

Comments

@philhagen
Copy link
Owner

philhagen commented Feb 26, 2019

LS provides separate RFC5424 grok parsers[1], meaning conditional support is needed for that, in conjunction with necessary field normalization.

[1] https://github.com/logstash-plugins/logstash-patterns-core/blob/master/patterns/linux-syslog

@philhagen
Copy link
Owner Author

this may be more complicated than it at first looks... lots of grok hackery

logstash-plugins/logstash-input-syslog#15

@Melantrix
Copy link

@philhagen I have received another message from Synology, which clarifies the <136> integer at the beginning of the IETF message. this is their response:

After further investigation by our developers, they found that IETF format is designated in RFC 5424.

There is also RFC 5425, RFC 5426 and RFC 6587 designation of IETF format which split into TLS, UDP and TCP protocol.

According to RFC 6587 Section 3.4.1, this number refers to log length.
It's function is for splitting up multiple logs under TCP connections.
And accordingly, Log Center's syslog-ng framework adheres to RFC standard.

What might be a possibility is that the log aggregator in question that you are using may not be adhering to RFC standard. Could you kindly double check that to be sure?

Thank you!

Best regards,

If i understand correctly it is part of a 'sub' RFC, so they have the RFC police on their side :P

i guess it's something to take into account when parsing the IETF messages.

@philhagen
Copy link
Owner Author

This is still something that would likely need to be raised with the Logstash developers. I'm not likely going to be able to maintain a processing pipeline that is forked from their codebase. SOF-ELK relies on the Logstash syslog processor. I'll see if there is anything I can do within our scope, but it does not look promising.

While they are correct that this technically does adhere to an RFC definition, it is not commonly used - I have never seen a log shipper that uses it. Similarly, HTTP+STARTTLS is defined in an RFC, but I'd be shocked if any browser or server software supports it.

@Melantrix
Copy link

Okay, thanks for replying. Just to be clear, you are saying to raise this also with the logstash devs? Or should i wait to see if you can check this within the SOF-ELK scope?

@philhagen
Copy link
Owner Author

I don't plan to raise the issue, as it's not something I'm directly experiencing. I'll see if there is anything that can be done locally under the context of this issue, but initial research is not promising.

@SMAPPER
Copy link
Contributor

SMAPPER commented Mar 25, 2019 via email

@philhagen
Copy link
Owner Author

there are two fields at play - one is definitely the PRI and he totally handle that. The other is a mystery integer that may or may not be the message length. If you look at the screenshot on tagged ticket #144 (https://user-images.githubusercontent.com/4669661/52183368-90c19a80-2807-11e9-8976-0d4d04b334cf.png), you'll see a 136 prefix. The 1 prefix is a "version" field, provided by the IETF syslog variant. Even the Logstash standard grok syntaxes don't seem to address the supposed length.

@SMAPPER
Copy link
Contributor

SMAPPER commented Mar 25, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants