Please see my log entries below:
1
11-1-27 下午01:40:01.000
Jan 27 13:40:01 202.XX.XX.XX postfix/qmgr[2866]: B33BF163EF8: removed
host=202.XX.XX.XX | sourcetype=syslog | source=udp:514
2
11-1-27 下午01:40:01.000
Jan 27 13:40:01 202.XX.XX.XX postfix/smtp[14392]: B33BF163EF8: to=<root@mta1.abc.com>, orig_to=<root>, relay=172.16.5.222[172.16.5.222]:25, delay=0.09, delays=0.03/0.01/0.02/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C1D951582C2)
host=202.XX.XX.XX | sourcetype=syslog | source=udp:514
3
11-1-27 下午01:40:01.000
Jan 27 13:40:01 202.XX.XX.XX postfix/smtpd[14393]: disconnect from rep01[172.16.5.110]
host=202.XX.XX.XX | sourcetype=syslog | source=udp:514
I can't found the source machine's hostname from the logs entries, just display the machine's IP address. I want to re-route logs entries into specify index base on the source IP address and hostname, because I have a lot of devices forward logs into my splunk server behind a NAT network. Can somebody help me?
thanks.
I'm unclear what you'd like the host value to be set to exactly.
The default behavior for syslog is to pull the host out of the text of the event, because it should represent the host on which the event happened. This is accomplished by a transforms.conf entry referenced in etc/system/default/props.conf in [syslog]. You could turn it off by overriding the rule in local/props.conf in etc/system or your own app.
If you were to turn it off, then host would be set by the udp input to the tcpip address of the host which sent the packet. It may be possible to adjust this to reverse resolve the ip address to a hostname. I know this feature exists for tcp inputs. It suffers from the usual confusion points where the original hostname reversemaps to something unexpected, but should work fine.
If you want instead the hostname to be set to the name of the splunk forwarder, you may be able to disable the udp input hostname setting.
I'm not sure which of these options gets at your problem. It may be that the NAT is simply hiding the possibility to determine the originating device. Syslog items are timestamped on the receiving side, typically, so the information may already be lost. You may want to look into putting a syslog reciever closer to the data sources, or using syslog over tcp.