-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[receiver/syslog] Promote to beta stability #28551
Comments
Pinging code owners for receiver/syslog: @djaglowski. See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
I think the component is likely ready for beta. I don't believe there have been substantial changes in some time, and I'm not aware of any planned either. @astencel-sumo, I think you've had some interaction with the receiver. Do you have any thoughts on this? |
This receiver has worked great for receiving data from many systems using rsyslog forwarding 👍 |
Sure, let's move it to beta. |
I've only just started using this and I have an issue: Some of my syslog sender devices use RFC 5424 and others use RFC 3164 so I get errors like this:
It would be nice if this receiver could automatically recognize both formats. Some devices are hardcoded to use UDP port 514 so there is no way to separate the 2 protocols on different ports. |
Is there a way to make this receiver use the source IP address instead of hostname? This is important because some devices are hardcoded to use a generic hostname. Here's an example from a PDU that calls itself
|
Another problem is timezones. I have devices in multiple timezones sending syslog messages, so only one of them can be set correctly in this receiver. Changing the timezone on each sender device is not desirable; RFC 3164 says:
Promtail handles this nicely with an option to ignore the incoming timestamp and use the current time instead. |
@llamafilm thanks for your comments, I like your suggestions a lot. All seem like good candidates for addtions to the existing functionality. I'm not sure they are blockers to moving to beta though?
This could be non-breaking enhancement, for example by making the
Sounds like this can be solved by adding a new configuration property, which is not a breaking change.
Also can be solved by adding a new configuration property. What do you think? |
Sure, no problem with moving to beta. processors:
transform:
log_statements:
- context: log
statements:
- set(time, observed_time) I agree the other 2 ideas would be nice features to add to the receiver. In the meantime maybe I can use rsyslog as a pre-processor. |
@llamafilm, I think it would be helpful to look at each of your suggestions as separate issues. If any are blockers to stability, we can call them out on this issue. |
OK, I will make separate issues. I have not observed any stability problems with the current version. |
I think #30329 (comment) could result in a breaking change to the output of the receiver. I'm curious to hear thoughts on this. |
@djaglowski The breaking change you have in mind - is it for the Syslog receiver to write source address to |
@astencel-sumo, yes that's what I mean. |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
This issue has been closed as inactive because it has been stale for 120 days with no activity. |
Component(s)
receiver/syslog
Describe the issue you're reporting
The Syslog receiver's configuration has not had significant changes for roughly a year, so it is likely ready for beta stability. To validate that it's ready for broader usage, it would be nice to get input from anyone who has extensively used the receiver and can attest that it is working well for them. If you're actively using it and think it is ready, please let us know what your experience has been.
cc @djaglowski
The text was updated successfully, but these errors were encountered: