[receiver/syslog] Optionally use IP address in hostname field

[llamafilm]

Component(s)

receiver/syslog

Is your feature request related to a problem? Please describe.

Some syslog sender devices use a generic hostname, so if I have 100 devices of the same model, it's impossible to differentiate which one sent a log message. Here's an example from a PDU that calls itself "ibootpdu".

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

Describe the solution you'd like

I'm not very familiar with otel so there might be a better solution, but I'd suggest adding a receiver configuration property like hostname_from_ip=true.

Describe alternatives you've considered

I'm currently using rsyslog to parse and forward messages to otel, with a config like this:

template(name="RFC5424_IP" type="string"
  string="<%PRI%>1 %timegenerated:::date-rfc3339% %fromhost-ip% %APP-NAME% %PROCID% %MSGID% %STRUCTURED-DATA% %msg%")

Additional context

No response

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

In principle I agree with allowing the receiver to capture the sender's IP as an attribute. However, it's not clear to me if this should be the same attribute or a separate one.

Looking at our semantic conventions, it seems source.address may be appropriate here as a single attribute which can take either value. If so, I agree we should use a config setting to indicate the users preference, and we should plan to deprecate the current "hostname" attribute.

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

[llamafilm]

this is still an issue

[crobert-1]

Removing needs triage based on code owner's response, with the understanding that final design is still up for discussion.

[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 @andrzej-stencel

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

[bacherfl]

if this issue is still available, I would like to look into this

[bacherfl]

@djaglowski I looked into this a bit and noticed that the sender IP seems to already be captured via the net.peer.ip attribute. This is done when the add_attributes of the udp/tcp input configuration is enabled:

https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/stanza/operator/input/tcp/input.go#L176-L181

https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/stanza/operator/input/udp/input.go#L215-L220

Would it be an option to rely on this attribute in this case? I noticed that this is currently not covered by unit tests though, so I would add some test cases to check for this attribute to be present if that's ok. Overriding the hostname attribute might actually also be a bit awkward to implement as this attribute is set by the syslog parser, which does not have access to the remoteAddress of the UDP/TCP input components: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/f81ecc3ddba56f80df84bfdea6555bba822c07ed/pkg/stanza/operator/parser/syslog/parser.go#L132

[andrzej-stencel]

Nice find, thanks @bacherfl! In this case, I'm not sure if we need a separate option in the Syslog receiver like the proposed hostname_from_ip=true or similar. Given that the user configures add_attributes=true, they can use Transform processor later in the pipeline (or a Stanza operator in the receiver) to take value from net.peer.ip into hostname.

[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 @andrzej-stencel

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.