I want to access the title, owner, etc., of the currently running scheduled alert via SPL syntax. I want to append this information to a lookup table so that a variety of alerts or saved searches with a variety of formatted outputs can be centralized into one output location. I understand that variables like $job.title$ and $results.count$ are available went setting up these jobs via the Alert or Scheduler UIs, but how do I access these environment variables via SPL?
Should I use the '| rest ....' command? Which REST APIs will have the job title/owner info?
Here is what I want to produce:
| <query for outlier info by hostname>
| <summarize data by hostname>
| <rest commands to extract job title/owner/etc info>
| table timestamp, hostname, error_count, <multi-value fields with alert specific data>, $job.title$, $job.owner$
| outputlookup append=t ..... <tracking_history_table.csv>
The 'answer' to my question involves simply using the 'collect' command to store the alert history in a summary index.
Having multiple alert scripts each appending to a csv lookup table does not work: Only one script can write/append to a csv table, but multiple scripts/queries can read. The summary index/collect command is a simple solution to my project.
The other benefit of using the collect command in a scheduled alert is that it will automatically set the 'server_name' value to the calling alert name's value...no hard coding!
Thanks to all who took the time to help me solve my problem.
How do a declare this question answered?
The 'answer' to my question involves simply using the 'collect' command to store the alert history in a summary index.
Having multiple alert scripts each appending to a csv lookup table does not work: Only one script can write/append to a csv table, but multiple scripts/queries can read. The summary index/collect command is a simple solution to my project.
The other benefit of using the collect command in a scheduled alert is that it will automatically set the 'server_name' value to the calling alert name's value...no hard coding!
Thanks to all who took the time to help me solve my problem.
How do a declare this question answered?
Apologies for not being clear enough.
I want to replicate what the $name$ value is when you configure an alert Action, ie, a Slack message. But I want to do that in SPL. I understand one knows the name of the owner and alert name when one creates it. However, I don't want to rely on hard coding these values in the SPL of each alert. Alerts can be cloned into differently named scripts and the hard coding is just an opportunity for getting the information wrong.
Instead of hardcoding like this:
| eval whats_my_name = "heisenberg_alert"
I want this:
| eval whats_my_name = $name$
However, $name$ (nor 'name') does not work for me in SPL. So, is there an equivalent way of getting JUST the name of the alert via SPL? I don't want the entire list of all scheduled alerts...I just want the one name of the currently executing alert script.
BTW, thank you all for taking the time to help me find an answer.
Bob Eubanks
As far as I understand workings of splunk internals (If I'm saying something wrong here, please correct me), the saved searches (reports, alerts) are no different than normal searches, they are just scheduled by scheduler. The whole $variable$ substitution however works on this additional processing level after the saved search will have already run - the alert action level. So you can't just put the variable into the search and expect the scheduler to resolve it because it just doesn't understand it.
Hi @chiliconbeano,
please try this:
| rest /services/saved/searches | where is_scheduled=1
then you have to rename the fields.
Ciao.
Giuseppe
I'm not sure what you're aiming at. If you want to "enrich" your report/alert with metadata about self, what's the point? When you define the report/alert you know what is its name, owner etc.
If you want to get a summarized view on - for example - all searches running at any given point in time, you can indeed do a REST call to list active searches (see the https://docs.splunk.com/Documentation/Splunk/8.2.4/RESTREF/RESTlist reference).
Anyway, | rest is a generating command and you don't put it further down the pipeline ( something | rest ). You put it at the beginning of the pileline.
If you want to use data returned by rest to enrich results of other search, you have to use it in a subsearch and joint it with the main search somehow (append, join, map).