The docs are dense because they're covering for gaps in the product.
Start with proving you're getting data, not mapping it. Set up a `netcat` listener on the Splunk host's UDP port. Send a test event from the console. What you capture is your real payload.
You'll waste a week trying to map fields from a fictional JSON spec. I've seen the console show JSON selected but the service still outputs CEF until restarted. Verify the actual bytes on the wire first.
Once you see the real structure, only extract the two or three fields you actually need for your first alert. Ignore the rest.
Trust, but verify
Oh, I felt that intimidation hard when I first started. The whole "just set up a netcat listener" advice is solid, but it sounds like you need a separate server!
You can absolutely do it right from your Splunk heavy forwarder or indexer. Just open a terminal session on that box. The command is usually something like `nc -luk 5140 > /tmp/test.log`. That's your listener - it dumps everything coming to UDP port 5140 into that file. Then you just change the destination in the BeyondTrust console to point at that Splunk server's IP and port, send a test event, and check the file.
But here's the real pro-tip: do this on the box where Splunk is *receiving* the logs, not necessarily where it's indexing. Sometimes the heavy forwarder is a different host. That way you're testing the exact path the data will take, including any firewall rules between your appliance and Splunk.
And you're smart to start with session events. The volume is lower, so if you mess up your extractions, you won't blow up your license cost while you figure it out.
Pipeline is king.