[receiver/syslog] expose the syslog parser config from the syslog receiver

[namco1992]

Description

The syslog receiver relies on the stanza syslog input. Among other inputs, the syslog input is a bit special because it's a wrapper of a TCP/UDP input with a syslog parser. The user can't configure the syslog parser because it's not exposed from the syslog input config, which means that some useful features like the on_error mode or parse_from/to is unavailable if you are using syslog receiver.

This PR adds the parser config to the syslog input config under the parser field. I chose not to flatten it because the existing InputConfig.WriterConfig will conflict with the ParserConfig.TransformerConfig.WriterConfig. We can override it later in the Build func, but I guess it's a bit implicit and error-prone, so I choose to add a new parser field. I'm open to changing it if the owners think otherwise.

This change should be backward-compatible.

Testing

Tested locally with newly added config.

Documentation

Added the parser config documentation to the syslog receiver README.

[namco1992]

https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/runs/12425577954/job/34692561655?pr=36906
It seems the TestComponentConfigStruct is unhappy with the ParserConfig. I indeed didn't find another example that exposes the ParserConfig on the receiver level, is it a controversial thing to do? Would appreciate any guidance on this.

[djaglowski]

I don't agree that there's any reason to expose most of these settings. The only one that makes any sense to me is on_error because it can provide useful behavior options.

All of the other fields suggested here are for things that instruct the parser where to find things, which is already defined due to the behavior of the tcp and udp inputs.

If you want to customize behavior further, why not use tcp or udp receivers and configure the syslog parser manually?

[namco1992]

Hi @djaglowski, thanks for the reply.

The only one that makes any sense to me is on_error because it can provide useful behavior options.

If this makes some sense, then is it possible to at least expose this config?

All of the other fields suggested here are for things that instruct the parser where to find things, which is already defined due to the behavior of the tcp and udp inputs.

Can you elaborate more on this point? The TCP/UDP inputs didn't really "define" any parser config other than init a default config. I'm also not sure why it would be a bad thing to grant users the power to config the parser.

If you want to customize behavior further, why not use tcp or udp receivers and configure the syslog parser manually?

Yes, I guess we would have to go down that route if this can't happen upstream. However, there is some config that we can't touch from the outside, like setting the SplitFuncBuilder to OctetSplitFuncBuilder:

opentelemetry-collector-contrib/pkg/stanza/operator/input/syslog/config.go

Lines 65 to 67 in f21f718

	if syslogParserCfg.EnableOctetCounting {
	tcpInputCfg.SplitFuncBuilder = OctetSplitFuncBuilder
	}

CMIIW, but it seems we can't really have a 1-1 replication of the syslog receiver by combining TCP/UDP receiver with syslog parser.

Lastly, the syslog_input documentation claims that it supports https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/f21f7183cafdb2ec61fbb23692e9ee37b4f871c2/pkg/stanza/docs/operators/syslog_parser.md#configuration-fields, but that's not true since the parser config is not configurable.

opentelemetry-collector-contrib/pkg/stanza/docs/operators/syslog_input.md

Line 13 in f21f718

| `syslog` | required | A [syslog parser config](./syslog_parser.md#configuration-fields) to defined syslog_parser operator. |

I understand that it might be a niche request, but I believe it's a reasonable one(or probably because I needed it 🙊 ). I'm ok with exposing the ones that you think make sense.