Good day,
I'm trying to setup the HF to forward to an additional syslog target which expects the RFC5424 (Grafana Alloy) so far the HF is reaching the syslog target but then the target complains about missing priority and I'm not sure if this because of the RFC5424 vs RFC3164
I've tried the following outputs.conf option:
[syslog:my_syslog_group]
disabled = false
server = grafana-alloy.svc.cluster.local:51898
type = tcp
#other tested variant priority = <NO_PRI>
priority = <34>
#tested with or without timeformat
timestampformat = %b %e %H:%M:%S
How can i make sure that the HF syslog forward is using the RFC5424 format?
The documentation for outputs.conf.spec specifically mentions RFC3164 so I don't believe Splunk has the configuration to support RFC5424 the way you want.
Honestly I would look at a packet capture at the destination from a good source and a relayed via Splunk HF to confirm. However, I wouldn't get your hopes up that Splunk will relay the way you want.
The documentation for outputs.conf.spec specifically mentions RFC3164 so I don't believe Splunk has the configuration to support RFC5424 the way you want.
Honestly I would look at a packet capture at the destination from a good source and a relayed via Splunk HF to confirm. However, I wouldn't get your hopes up that Splunk will relay the way you want.
How are you getting the original data? Splunk has many great features but it's not a fully-blown syslog receiver/processor. If you're receiving them using syslog as well it would probably be better to use rsyslog/syslog-ng to receive the event and forward it from there (and send another copy to Splunk over HEC)
inputs.conf is used for the incoming data.
It's the chain: inputs, props and transforms to syslog described here
It would be great to transform to RFC5424 this way but i doubt it's possible or is it?
Of course you're using inputs.conf. Without it you'd have no inputs. Question is what inputs you get your data from. Is it a simple tcp:// or udp:// input and you're receiving data directly on your indexer (which you shouldn't)? Is it an intermediate syslog daemon writing to files which are read by UF? Is it something else?