Search actions and macros
Search actions and macros
Section titled “Search actions and macros”Two ways to make a search reusable. A macro packages part of a search statement (or its result) so another query can call it by name. A search action attaches clickable behaviors to a field or event value so a result can jump to a report, a dashboard, a URL, or POST somewhere else.
Both live under the search area of the platform: Search → Macro and Search → Search Action.
Search macros
Section titled “Search macros”A macro is a named, reusable piece of a search. Define
nginx_search = sourcetype="nginx" repo="nginx" once, and any query can
contain `nginx_search` in its place.
Create (Search → Macro → Create Macro).
| field | what it means |
|---|---|
| Name | begins with a letter; letters, digits, underscores; may take arguments (arg1,arg2) |
| Type | Static or Dynamic |
| Search Query | the statement the macro stands for |
| Parameters | argument names (when the name takes them) |
| Verify Statement | an expression the submitted arguments must satisfy |
| Verify Fail Message | what to show when verification fails |
Static vs dynamic is the decision that matters. A static macro is replaced textually — the search query text is substituted in where the macro name appears. A dynamic macro’s search statement is executed and its result is substituted instead. The bundle is explicit about the catch: when a dynamic macro’s search returns multiple rows/columns, only the first value of the first field is used. Static macros are for search terms; dynamic macros are for values that must be computed at run time.
A macro with arguments validates them: the verify statement runs against the submitted values and the macro refuses (with the fail message) when it fails.
Management: create, edit, copy, import, delete. Owner column — macros are owner-scoped like other objects.
The engine note applies to macros too. A macro that is inserted into a query whose engine is not pinned inherits the global default engine, and a macro containing a search2-only or search1-only command behaves accordingly. Macros are text, not objects; the engines do not re-verify them.
Search actions
Section titled “Search actions”A search action binds one or more behaviors to events that match a data limit (a filter), so that a value in a search result becomes an interactive jump. The classic uses still hold: look up an external domain from an IP field, file a ticket from an error event, run a secondary search on a field value, or search the web with it.
Create (Search → Search Action → New Search Action).
- Application — which app owns the action.
- Name / Description.
- Data Limit — a filter (field + condition, added as AND groups); only events satisfying it offer the action. A search action with no filter applies everywhere.
- Actions — one or more, each with a name (supports variables like
$topic$, must be unique) and a type:
| type | what it does |
|---|---|
| Jump to search | opens a search with the statement (variables allowed) |
| Jump to report | opens a report |
| Jump to Dashboard | opens a dashboard, with template-variable associations |
| Jump to URL | opens location_url; supports variables, e.g. https://www.google.com/search?q=$host$ |
| POST request | sends a POST to an endpoint URL with request parameters |
Parameters for the jump/POST are key-value pairs; variables like $field$
are replaced from the clicked event’s field values. Dashboard jumps can
associate template variables. Open in new window controls the target.
Management: create, edit, copy, enable/disable, delete.
Where actions show up. On a search result, a matching event’s fields become clickable and expand to the action menu; choosing one runs the jump or POST with the event’s values filled in.