-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
feat(promtail): Support of RFC3164 aka BSD Syslog #12810
Changes from 2 commits
1a2ebf7
0320106
1426356
10f1033
d6818a9
e64f8a9
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -202,6 +202,9 @@ type SyslogTargetConfig struct { | |
// message should be pushed to Loki | ||
UseRFC5424Message bool `yaml:"use_rfc5424_message"` | ||
|
||
// IsRFC3164Message defines wether the log is formated as RFC3164 | ||
IsRFC3164Message bool `yaml:"is_rfc3164_message"` | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry @catap I thought I left this comment yesterday: Is there a way we can just detect whether each message is RFC3164 or RFC5424 format, rather than adding another config option? Is it possible that a single target could output logs in both formats? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @cstyan nope, it is impossible to determine which format is used. Usually sender sends in supported format, or it may have a selector where someone may choose the format. The best that I can do here is use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Okay that's fine. Lets keep the logic as is then, except can we change the config option to be And it's default value can be We also need a reference for this in the syslog section of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here the catch: right now we have two options:
and I feel that this should be reworked as weel. To something like:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
this makes sense to me, we would have to deprecate I can present your PR to the team as a "we should do this as a bug fix, it also technically requires these config changes" and we should be able to get it merged There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @cstyan I was wrong, RFC3164 hasn't got string method and implement it isn't something that seems easy. So, let keep it as is. |
||
// MaxMessageLength sets the maximum limit to the length of syslog messages | ||
MaxMessageLength int `yaml:"max_message_length"` | ||
|
||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we wanted a second new config option
PushFullSyslogMessage
? we still need to keep this one as well, and mark it as deprecatedThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't do it, because RFC3164 message has lack of
String()
method. See implementation for RFC5424: https://github.com/leodido/go-syslog/blob/v4.1.0/rfc5424/builder.go#L9348-L9408The issue that RFC3164 isn't well structured and quite flexible, and rebuild original message is quite a challenge.
Sorry to misslead you.