I have created a workflow through the GUI (the corresponding workflow_actions.conf is below).
The intention is to provuide the user with a similar action to "show source" which instead displays the application transaction that the event belongs to.
We have a macro search that can perform this search using two parameters (thread and host). And the workflow action triggers this search correctly.
The problem we have is narrowing the secondary search so only the transaction in question is displayed (at least a few extraneous are shown as possible). If the users original search is over 24 hours and they click on "Show transaction" then they get every transaction for 24 hours that matches the host and thread, which can be a very large number. Specifying a time range in the workflow setup does not work as it is relative to now.
Can we make the time range relative to the event that the workflow is triggered from? Or is there another way we could solve this?
[view_myapplication_transaction] display_location = event_menu eventtypes = myapplication_log_event fields = * label = Show transaction search.app = MYAPP search.earliest = -5m search.latest = +5m search.preserve_timerange = 0 search.search_string = `full_myapplication_transaction(thread=$thread$,host=$host$)` search.target = blank type = search
You need to use the now term. now= tells splunkd to interpret any relative time range arguments as though the current time was the specified epochtime.
Ideally you could do search.now=$_time$ and it would work as an API argument. However Im pretty sure that will not work.
So you'll have to put the now="$_time$" into the search_string itself. (make sure it ends up in the initial search clause)
The other problem is that unfortunately splunkd doesnt take the time terms sent to the API and merge them with the time terms specified in the search language. Instead if it sees anything in the search itself, it'll ignore the official API args entirely. So to workaround that problem you'll have to take your search.earliest and search.latest OUT of the config and instead put something like earliest="-10min" latest="+10min" into the search_string itself.
NOTE: Specifying time terms in the search string is normally not recommended cause a) its messy, b) it results in the UI nagging you about how 'your timerange was substituted using values in the search string'. However this is one case where I think it's the only way.
I think I need to convert the _time format as I am getting this error... "Invalid value "2010-07-02T14:32:33+1000" for time term 'now'". The problem is how do I get _time in epoch seconds in the initial search clause?
_time is always in epochtime format although in the UI it might appear that it's a string-formatted value. As for the error message, that sounds (very unfortunately) like the workflow actions code for some reason uses the converted ISO value instead of the raw epochTime value like it should.
I think that is what is happening. As a workaround I added a convert statement to a macro that is commonly used. "| convert mktime(time) as transactiontime". so instead of using _time i use time in the workflow action. the downside is that the action is only available to events generated from the macro that has been enhanced instead of all events of a particulat eventtype.
could this be considered a fault in workflow actions? if it is then perhaps a defect can be raised. otherwise a enhancement request to ensure workflow actions have a means to set now to the time of the event.
From an outside developer's perspective its definitely a bug. Go for it. Since you cant get the epochTime value it makes it really hard to use $_time$ in workflow actions in any meaningful way.
You can take the time out of a subsearch and apply it to a main search like this:
"main search term" [ search "subsearch term" | eval earliest=_time-2 | eval latest=_time+2 | fields earliest,latest | format "(" "(" "" ")" "OR" ")" ]
format is required because Splunk search queries won't accept
AND between time modifiers the way it will between other search terms. Personally, I think it's a bug. Anyway, since
AND is implicit, we can just remove it from the
Not sure if this helps you, but if you can get
_time out of the event in question, you might be able to use the above.
Everything seems to be coming together except using _time. The problem is that _time is being converted automatically when substituted. So instead of being in an epoch format it is in a date format... 2010-07-02T10:13:46+1000
this only happens when it is displayed in events or results, or at least it should only happen when it is displayed. _time is stored internally and usually passed around in epoch format. how exactly are you running the subsearch, or how are you getting the results to pass up. Note that if you have no other choice, you can use the
eval function or the