In approximate order of how I'd do it:
First, double check for sure you aren't getting them in. index=* and start looking at all your flyouts for your host, events that may come from it and so on.
Double-check you are listening on both UDP and TCP port 514 in Splunk, or confirm that whichever one you are listening on is the one that Trend is sending in on. Double-check your inputs.conf to make sure there shouldn't be anything mishandling that source - the list of trickery that could be involved is long, but a careful look will most likely uncover anything odd looking.
Confirm that Trend is configured properly and pointing to the right IP address, is actually set to send something in (sometimes the configuration for syslog settings and the configuration to send syslog data are two entirely separate steps!) and that there are no firewalls or networking issues that would prevent the two machines from communicating.
Once you've double-checked all that work and found no improvement, I'd say to start a packet capture on your Splunk server watching for packets from the Trend box. If you see them coming in over the right ports and all that, you'll have to look at inputs. (Or separate syslog from Splunk and troubleshoot each piece separately, as below). If you don't see the inputs, then either the Trend box is misconfigured or there's a firewall or something in the way.
I, and others here, would heartily recommend to install syslog-ng or rsyslog and use THAT to listen to syslog, then use monitor stanzas to get the data from there: this is easy to do and has a lot of advantages in speed, reliability, scalability and troubleshooting. That last advantage would be quite useful at this point and would separate this problem into two independently easy problems. This is also best practice.
... View more