[receiver/syslog] Promote to beta stability

[evan-bradley]

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[bot]]

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

[github-actions[bot]]

Pinging code owners:

• receiver/syslog: @djaglowski

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

[djaglowski]

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]

This receiver has worked great for receiving data from many systems using rsyslog forwarding :+1:

[andrzej-stencel]

Sure, let's move it to beta.

[llamafilm]

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 3c1c1a5f~EV002003~[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]

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]

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]

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

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]

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

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

[djaglowski]

I think https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/30329#issuecomment-1881713915 could result in a breaking change to the output of the receiver. I'm curious to hear thoughts on this.

[andrzej-stencel]

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]

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

[github-actions[bot]]

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:

• receiver/syslog: @djaglowski

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

[github-actions[bot]]

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