Perhaps wrapping the ldapfilter command in an appendpipe will give you what you're looking for: | makeresults | eval Sid="S-1-5-21-111111111-111111111-1111111111-11111" | appendpipe [| ldapfilter domain=mydomain search="(objectSid=$Sid$)" attrs=cn ] ... View more

If you have the resources for it, the suggestion by @p_gurav to implement search head clustering is a great one. If not, what you're talking about will involve moving/copying savedsearches.conf files and associated metadata. When I needed to move saved searches from one search head to another, I copied the entire app folder $SPLUNK_HOME/etc/apps/my_app to a backup location. I then used vim to modify the savedsearches.conf file to set enabled=0 for all of the searches. I copied the entire app folder from this backup location onto the second search head and systematically enabled saved searches on the new search head as I disabled them on the first search head. (I did this in batches by editing the savedsearches.conf files on both search heads and then using debug/refresh to cause Splunk to pick up the configuration changes.) ... View more

It's possible (but a bit of a kludge) to edit this directly in the configuration files. But the easiest way to do this is to clone the alert - giving the clone the name you want - and then delete the original alert. That's what I usually do. ... View more

How about using map instead? Something like this: | makeresults | eval server=host1 | append [| makeresults | eval server=host2 ] | append [| eval server=host3 ] | map maxsearches=3 [| forwarderquery server="$server$" api="/services/server/info" stanza="unix_forwarder" contenttype="json" | spath path="entry{}" output=entry | fields - _raw | mvexpand entry | spath input=entry ] Note that you'll need to change the value of maxsearches if you change the number of servers you want to run this over. It's generally not a great idea to use map if you can avoid it, but on a limited scale, it's not terrible. Also, if somebody else has an idea that doesn't use map , then theirs will almost certainly perform better than mine! ... View more

Based on your description of the search, I suspect the search is structured to use the data in the lookup file as a search filter, which will narrow the results of the base search to only events containing my_field values that are present in the lookup file. As @mayurr98 pointed out, the format command itself isn't really doing much in the context of this search, because it's used implicitly in subsearches anyway. If I'm correct about the intention of the user who wrote the search, it's probably structured like this: index=something sourcetype=whatever [| inputlookup <lookup table> | format ] | stats sum(field_b) by my_field ... View more

Depending on the type of data and duration of searches powering these panels, here are a few ideas. They both rely on having (or creating) a field that uniquely identifies a given event. That could be a field that already exists, or you could make it appending together some fields that, when taken together, uniquely characterize an event. Build a summary index (or set of summary indexes) supporting the data being displayed. Integrate logic into the dashboard that allows users to select events and submit them to the summary index with an additional field like acknowledged="true" . Then the searches powering individual panels can search their current data set and also the summary index, cross-apply the acknowledgment using eventstats like | eventstats values(acknowledged) AS acknowledged BY event_id and then look for only events where isnull(acknowledged) . I'd recommend also integrating some logic that grabs the username of the user who acknowledged the event and the time at which it was acknowledged. Create lookups that contain the event_id of acknowledged events, the the time at which the event was acknowledged, and the user who acknowledged it. The search powering a dashboard can then perform a lookup and only display events that are not found in the lookup. The downsides of this approach are that it's pretty easy to wipe out a lookup accidentally, and and your lookup may grow to unmanageable size unless you are routinely trimming out old events. ... View more