We recently upgraded to 6.3 and I have been toying with using eval and search event handlers. In one of my dashboards I run a global base search and then post-process in a bunch of panels to focus in on different data. However, when I attach the following search event handler
<search id="s_base">
<query>index=foo_na ....</query>
</search>
.
.
.
<search id="s_bar" base="s_base">
<query> | where baz=="foobar" | timechart count by baz </query>
<done>
<eval token="t_test_token">'job.resultCount'</eval>
</done>
</search>
It seems to be evaluating to the job.resultCount value of the base search, not the post process search. Is this the expected behavior, or is there another job property that relates to the postprocessed count? Looking through the EventHandlerReference and ViewsearchjobpropertieswiththeJobInspector doc pages, I don't see anything that explicitly addresses how this should behave.
I don't think the postprocess search is technically a job, so there won't be any individual job properties.
As a workaround, you could hack yourself a hidden field with | eventstats count as _resultCount
and use $row._resultCount$
in a <finalized>
element (untested).
I don't think the postprocess search is technically a job, so there won't be any individual job properties.
As a workaround, you could hack yourself a hidden field with | eventstats count as _resultCount
and use $row._resultCount$
in a <finalized>
element (untested).
Thanks, I'll give that a shot. I also worked around it a bit when I found out that the <preview>
handler doesn't trigger if there are no events in the postprocess. So, I can do conditional <condition match=[eval expr]>
in that tag, then inside the <done>
tag I just handle the case of no results if the tokens are null.