It's not passed in the command line, nor as an environment argument, at least when run directly from the search bar. InterSplunk won't get it either.
You might be able to figure it out by having the script call back into the REST API but it would be messy at best.
sendemail script has it though, since it uses it in the embedded links. That may be something special about email alerting, or maybe it has to do with being called from a scheduled search.
What are you trying to accomplish? Is the job ID strictly necessary?
If you look in
alert_actions.conf, you'll see the argument
searchid=$search_id$ passed to the
sendemail search command. So this looks like
$search_id$ seems to be inherently known within the alert actions environment. So that explains that example. But doesn't really help in my use case.
Here's the best approach I've come up with so far. I would still like a better way to do this, so I'll leave this question open for a while.
Basically setup the search command to run the
addinfo command first. I have
supports_getinfo = True, so I used the following command in my script:
# streaming, generating, retevs, reqsop, preop splunk.Intersplunk.outputInfo(False, False, False, True, "addinfo")
Then it's simply a matter of grabbing the
info_sid field from the first record, like this:
(results, dummyresults, settings) = splunk.Intersplunk.getOrganizedResults() if len(results) > 0: search_id = results["info_sid"] else: search_id = None
Of course if there are no events/results found, then there is no first record. In my case I don't care because there's no work to do anyways. But I don't want an exception thrown just because there where no matching events in the base search.
Update: It appears that in order for the preop command to be executed, you have to set retevs=False (that is "retainsevents"=0). I'm not sure why this is, and if this is an intentional behavior or a bug. Either way it's annoying since I want the event view, and not the results view.