This is specifically about Palo Alto Traps (or as it's now called Cortex XDR Prevent) logs inside Splunk.  I am having a specific issue with elements of the Palo Alto Networks App dashboards showing no data. I have Cortex XDR (Palo Alto's Cloud version of Traps EMS) sending data via TCP SSL to Splunk to a dedicated index and I see events. In the dashboard "Endpoint Operations", "Total Endpoints Reporting" is always 0, even though other elements of that same dashboard are showing data correctly.   When I look at the search "| tstats summariesonly=t values(log.content_version) AS log.content_version, values(log.type) AS log.type, values(log.severity) AS log.severity, values(log.dest_name) AS log.dest_name, values(log.src_host) AS log.src_host count FROM datamodel="pan_traps" WHERE nodename="log.operations" """" log.severity="*" GROUPBY _time log.log_subtype log.user | rename log.* AS * | dedup dest_name | stats dc(dest_name)"  Everything is great until the last dedup/dc part.  "dest_name" is always null for all of my values for some reason.  So this suggests that the data that Cortex XDR sends into Splunk does not have what the add-on expects. I'm curious if anyone has any experience with this and can advise a workaround or solution. ... View more

Hi, we are using Splunk for many different things, but for this question the relevant part is that we use it to get the Java server log into Splunk. Currently, whenever there's an exception we notify our entire team, however, as the team size has grown we need a smarter solution to reduce the noise in everyone's inbox. We maintain a CSV locally that maps module name (listed in the java exceptions) to email address of the module owner. Is it possible to have Splunk continually read this mapping from some source (we can maintain it on the server itself, or in the cloud, google docs, etc) and then extract the module name from the Java exception and route the email to the correct recipient? I'm not sure how to implement this logic in Splunk so any advice that can be provided would be appreciated. ... View more