promtail: add RFC3164 syslog support #7845
Conversation
This is needed to parse RFC3164 syslogs. Signed-off-by: Paul Spooren <[email protected]>
both nontransparent and octetcounting use RFC5424 which isn't used by many devices, i.e. OpenWrt or Ubiquiti routers. Add a new function called NewParserRFC3164 to both. Signed-off-by: Paul Spooren <[email protected]>
This adds support for RFC3164 syslogs which are used by many devices, in my use case OpenWrt and Ubiquiti routers. A new option called `is_rfc3164_message` is added to the syslog which makes the incomming logs to be handled as RFC3164. Signed-off-by: Paul Spooren <[email protected]>
|
|
Signed-off-by: Paul Spooren <[email protected]>
|
This is a reasonable idea. Given this is setup as a configuration option, it'd probably be cleaner to implement it as it's own target rather than having Of course, also it'd need tests |
There was a problem hiding this comment.
How likely do you think it is to get influxdata/go-syslog#46 into the upstream library (the project is rather stale)?
| @@ -14,7 +14,7 @@ import ( | |||
| // the callback function with the parsed messages. The parser automatically | |||
| // detects octet counting. | |||
| // The function returns on EOF or unrecoverable errors. | |||
| func ParseStream(r io.Reader, callback func(res *syslog.Result), maxMessageLength int) error { | |||
| func ParseStream(isRFC3164Message bool, r io.Reader, callback func(res *syslog.Result), maxMessageLength int) error { | |||
There was a problem hiding this comment.
Can we put this new argument to the end?
I'm not sure about making a separate target, but I agree that we should have a better abstraction for the various syslog implementations. E.g. in the config, there are would now be options for Maybe the syslog target should have a single option That configuration change would probably be breaking and therefore something for Loki/Promtail 3.0? |
@MasslessParticle @aparcar What do you think about forking the |
|
@chaudum That sounds reasonable. This project doesn't change much. In the past, they've been generally responsive to PRs -- I've actually got one with a former teammate in there -- so I hope we don't have to sit on the fork forever. |
This is totally reasonable. Putting the syslog stuff behind an interface would help keep the implementation cleaner |
|
Closing this one for inactivity |
|
Sounds like there's still some demand for this but we may have to pick it up ourselves |
|
I've forked the parser to our org and merged the patch this depends on |
|
Uhm where can I follow your work? I can also give this another go |
|
@aparcar The forked library you can rely on is here: https://github.com/grafana/go-syslog
That would be great! |
|
@aparcar, @MasslessParticle any news? |
I'm no Go programmer so somewhat glued ends together, please be patient. If this is of general interest I'm happy to fill the gaps like testing, documentation and change log. Since this requires changes of a vendor package, I created a PR there as well.
What this PR does / why we need it:
It adds RFC3164 support to promtail. Commonly used for OpenWrt and Ubiquiti syslogs.
Which issue(s) this PR fixes:
I opened a PR directly instead of an issue first.
Special notes for your reviewer:
Checklist
CONTRIBUTING.mdguideCHANGELOG.mdupdateddocs/sources/upgrading/_index.md