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

[receiver/syslog] Promote to beta stability #28551

Closed
evan-bradley opened this issue Oct 24, 2023 · 17 comments
Closed

[receiver/syslog] Promote to beta stability #28551

evan-bradley opened this issue Oct 24, 2023 · 17 comments

Comments

@evan-bradley
Copy link
Contributor

evan-bradley commented Oct 24, 2023

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

@github-actions
Copy link
Contributor

Pinging code owners for receiver/syslog: @djaglowski. See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions
Copy link
Contributor

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@djaglowski
Copy link
Member

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?

@jsirianni
Copy link
Member

This receiver has worked great for receiving data from many systems using rsyslog forwarding 👍

@andrzej-stencel
Copy link
Member

Sure, let's move it to beta.

@llamafilm
Copy link

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:

Dec 21 07:32:38 i-0c7c2f22bd9881703 startup.sh[51677]: 2023-12-21T07:32:38.492Z error helper/transformer.go:98 Failed to process entry {"kind": "receiver", "name": "syslog", "data_type": "logs", "operator_id": "syslog_input_internal_parser", "operator_type": "syslog_parser", "error": "expecting a version value in the range 1-999 [col 4]", "action": "send", "entry": {"observed_timestamp":"2023-12-21T07:32:38.492596111Z","timestamp":"0001-01-01T00:00:00Z","body":"<30>Dec 20 23:32:38 ibootpdu iocontrold[247]: PDU_Event 3c1c1a5fEV002003[Ad-Hoc]~Group (Ad-Hoc) Cycle by admin via Web","severity":0,"scope_name":""}}

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.

@llamafilm
Copy link

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 ibootpdu, so if I have 100 of these devices there is no way to identify the source of log messages. Rsyslog has a setting for this called fromhost-ip.

startup.sh[55146]: LogRecord #0
startup.sh[55146]: ObservedTimestamp: 2023-12-21 09:03:00.996046314 +0000 UTC
startup.sh[55146]: Timestamp: 2023-12-21 09:03:00 +0000 UTC
startup.sh[55146]: SeverityText: info
startup.sh[55146]: SeverityNumber: Info(9)
startup.sh[55146]: Body: Str(<78>Dec 21 01:03:00 ibootpdu crond[221]: USER root pid 27068 cmd run-parts /etc/cron.minute)
startup.sh[55146]: Attributes:
startup.sh[55146]:      -> appname: Str(crond)
startup.sh[55146]:      -> proc_id: Str(221)
startup.sh[55146]:      -> facility: Int(9)
startup.sh[55146]:      -> message: Str(USER root pid 27068 cmd run-parts /etc/cron.minute)
startup.sh[55146]:      -> priority: Int(78)
startup.sh[55146]:      -> hostname: Str(ibootpdu)
startup.sh[55146]: Trace ID:
startup.sh[55146]: Span ID:
startup.sh[55146]: Flags: 0

@llamafilm
Copy link

llamafilm commented Dec 21, 2023

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:

If the originally formed message has a TIMESTAMP in the HEADER part, then it SHOULD be the local time of the device within its timezone.

Promtail handles this nicely with an option to ignore the incoming timestamp and use the current time instead.

@andrzej-stencel
Copy link
Member

@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?

automatically recognize syslog format

This could be non-breaking enhancement, for example by making the protocol configuration property optional or by adding to it a new possible value auto.

use the source IP address instead of hostname

Sounds like this can be solved by adding a new configuration property, which is not a breaking change.

ignore the incoming timestamp and use the current time instead

Also can be solved by adding a new configuration property.

What do you think?

@llamafilm
Copy link

Sure, no problem with moving to beta.
I found a way to fix timestamps like this:

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.

@djaglowski
Copy link
Member

@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.

@llamafilm
Copy link

OK, I will make separate issues. I have not observed any stability problems with the current version.

@djaglowski
Copy link
Member

I think #30329 (comment) could result in a breaking change to the output of the receiver. I'm curious to hear thoughts on this.

@andrzej-stencel
Copy link
Member

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 source.address attribute instead of hostname attribute?

@djaglowski
Copy link
Member

@astencel-sumo, yes that's what I mean.

Copy link
Contributor

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 @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions github-actions bot added the Stale label Mar 12, 2024
Copy link
Contributor

This issue has been closed as inactive because it has been stale for 120 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants