I really like how the advent of mobile operating systems has allowed operating system designers to re-imagine how to create an operating system user interface. Isn't it great that even novice computer users can use pretty much any mobile operating system and common user interface behaviors are automatically intuitive and consistent--such as pinching to zoom or rotating a device, tap and hold, swiping. This is a good thing. We should have more revolutionary ideas like this in technology.
It took me a while to figure out how to use a Post-Process Search in a Splunk Dashboard, so I thought it would be a good idea to remind my future self how it's done.
This is a Simple XML dashboard. It is essentially the same as the example in my last post. The full source code is attached to this post.
In order to use a Post Process search, only three changes are needed:
Since it is so easy to search for data in Splunk, and then create a dashboard in just a couple of clicks, you might be tempted to do just that -- and release your dashboard into production. For some situations, that's absolutely fine. But as your organization becomes more reliant on Splunk dashboards, this approach can become unwieldy. And if there's anything we want, it's wieldy searches!
One of the most common scenarios I experience in Splunk is where I need to use data from two different indexes at once—typically in order to build management and reporting dashboards. With my background in developing applications on relational databases, my first attempts at this solution used the "join" command in Splunk. Once I realized that a combination of the "append" and "stats" commands can be a better choice, I started using those more. But today I will show an even better, faster approach!
I use Splunk to report on business objects moreso than typical security operation data. For instance, helpdesk tickets rather than firewall logs. I have created various Python scripts to import these business objects from various REST and SQL sources, and I want these import scripts to be idempotent. That is, I want to import helpdesk tickets every day, but no more than once per day, regardless of how many times the import script is called.
Well I don't care much for PowerShell, but sometimes it is a necessary evil. I needed to run some PowerShell scripts in parallel, so I wrote a wrapper to do this. Maybe it will help you also.
- You specify how many jobs to run in parallel
- When one job finishes, another will be started
Note: the Start-Job commandlet takes a few seconds to do its thing.
The repo lives here: https://github.com/northben/PowerShell-Parallel-Job-Runner
Normally, I prefer to send CSV or JSON data to Splunk. But sometimes XML can't be avoided. I recently needed to ingest an XML file, and through judicious use of 'MUST_BREAK_AFTER' and 'BREAK_ONLY_BEFORE' in props.conf, I was able to extract the events from the XML file that looked like this:
In this short tutorial I will show you how to create a dashboard table with dynamic columns. When the user selects the radio button toggles, the search does NOT run again -- only the display is updated. Demo: https://youtu.be/l-p83je4RgQ
I am including the full source code to the dashboard with this post for your review. But here's the secret sauce:
I've been having trouble indexing CSV files. In particular, CSV files from Tripwire. I'll show you the format and how I was able to index the files in Splunk
Node Name,Node Type,Policy,Parent Test Group,Test Name,Description,Element,Result Time,Result State,Actual Value
"192.168.1.1",Linux Server,"My Policy Name","My Test Group","My Test Name","My Test Description","Some Element",10/25/15 2:02 AM,passed,"ELEMENT=foo"
Here's my Props.conf stanza: