feat: Support configuring behavior of loki.source.syslog setting the year of an incoming timestamp

[dehaansa]

PR Description

Add a new configuration setting to the loki.source.syslog configuration rfc3164_default_to_current_year that allows users to set the year of an incoming timestamp to the current year in local time. The existing behavior is to leave the year at 0 (this behavior comes from promtail).

This PR also moves any remaining promtail code for syslog into Alloy, as promtail is now officially deprecated as of Loki 3.4.

Which issue(s) this PR fixes

Fixes #2287

Notes to the Reviewer

This is currently pointing to the develop branch of go-syslog, we may want to wait for a release before merging this.

PR Checklist

• CHANGELOG.md updated
• Documentation added
• Tests updated
• Config converters updated

[github-actions]

💻 Deploy preview available: https://deploy-preview-alloy-2755-zb444pucvq-vp.a.run.app/docs/alloy/latest/

[dehaansa]

It appears this is a breaking change to the go-syslog library, and as otel's syslog receiver depends on that library as well as loki, there are build issues to work out, this may have to wait to be merged until it's released & otel integrates & releases with it.

[Nachtfalkeaw]

Imagine the Situation where a remote system Stores its logs until loki.source.syslog is available after an outage and then sends its old logs from december 2024-12-31 23:00 to alloy which is in 2025-01-01 01:00. This will results in wrong year? Or Log to far in Future?

another Situation maybe could be time Zone shifts, right?

Don't know a solution right now and this is a rare Situation i think.

[dehaansa]

Imagine the Situation where a remote system Stores its logs until loki.source.syslog is available after an outage and then sends its old logs from december 2024-12-31 23:00 to alloy which is in 2025-01-01 01:00. This will results in wrong year? Or Log to far in Future?

another Situation maybe could be time Zone shifts, right?

Don't know a solution right now and this is a rare Situation i think.

That's correct. It's a hard problem to solve, but we could add a different year behavior to the go-syslog machine to use current year, but then if the resulting timestamp is nearly a year in the future, reduce the year by 1. There's definitely no perfect solution to the problem of not having a precise enough timestamp.

Edit: went to look at implementing a YearOperator from go-syslog and it doesn't have the ability to modify a specific message's parsing. We would need to put this behavior directly into Alloy after using the syslog parser instead, which should be fine. At that point we wouldn't need the changes to go-syslog at all. 🙃

[clayton-cornell]

Docs look OK

[mattdurham]

Is this pulled from somewhere or maybe documented as a magic number? An example of what the stream would look like may help here.

[dehaansa]

This is copied straight from promtail, but I'll add some comments.