Hi,
We have a syslog input with non-syslog sourcetype over TCP. Everything looks good in Splunk. However, we have to forward these logs to a 3rd party syslog server.
We are facing with the 2nd and 3rd scenario on these links: (but with tcp input)
http://docs.splunk.com/Documentation/Splunk/latest/Data/HowSplunkEnterprisehandlessyslogdata
https://wiki.splunk.com/Community:Test:How_Splunk_behaves_when_receiving_or_forwarding_udp_data
2nd scenario: Splunk attach the originated host field: 3rd party server doesn't like it...
3rd scenario: attach a new timestamp and the originated host field. 3rd party system can handle, but event getting to be too long.
Is there any way to solve this problem? How to not attach originated host filed or any other suggestion?
Am I miss a documentation about it?
Regards,
István
Check out syslogSourceType
in outputs.conf:
syslogSourceType = <string>
* Specifies an additional rule for handling data, in addition to that
provided by the 'syslog' source type.
* This string is used as a substring match against the sourcetype key. For
example, if the string is set to 'syslog', then all source types
containing the string 'syslog' will receive this special treatment.
* To match a source type explicitly, use the pattern
"sourcetype::sourcetype_name".
* Example: syslogSourceType = sourcetype::apache_common
* Data which is 'syslog' or matches this setting is assumed to already be in
syslog format.
* Data which does not match the rules has a header, optionally a timestamp
(if defined in 'timestampformat'), and a hostname added to the front of
the event. This is how Splunk causes arbitrary log data to match syslog
expectations.
* Defaults to unset.
Try setting syslogSourceType to the sourcetype of your non-syslog data so Splunk will assume it is already in syslog format (even thought it's not).
Thank you. We tried it in our lab with no luck. We plan to test it with the specific, 'real' logs, but it will takes time. There are a lot of other scheduled task now.
Regards,
István