Actions

Humio alerts can be set to trigger various acts, such as informing an administrator of a potential problem with your servers. Said another way, an action is a module that can be invoked from a trigger. A trigger runs a query in Humio, and if the query result contains any events, these are sent to the action. A trigger can be either an alert or a scheduled search.

Incidentally, prior to version 1.19 of Humio, actions were called notifiers.

Humio currently supports the following action types:

Configuring an Action

To configure an action in Humio, go to Alerts → Actions → New Action. From there, select a type of action from the Action Type dropdown list. You will need to assign each action a name.

For self-hosted installations, remember to set the PUBLIC_URL field in the Humio config. This will ensure that links in messages will go to the correct URL.

Custom Actions

If the built-in actions are not enough and you need to make something custom, Humio supports webhooks that allow you to call an external service with HTTP. You can add headers and customize the body of the message as seen below.

HTTP Proxy

If Humio is set up to use an HTTP proxy, it will per default be used for all actions communicating via HTTP. It is possible to configure an individual action to not use the globally configured HTTP proxy.

Message Templates

Humio uses message templates to create the messages sent by actions. They currently apply to Slack, Email and Webhook action. The template engine is a simple “search/replace” model, where the {…} marked placeholders are replaced with context-aware variables.

See the list for an explanation of the placeholders:

Placeholder(s) Description
{field:$FIELD_NAME} Extracts the value of $FIELD_NAME from the field in the first event from the trigger. Put field names with spaces in double quotes, {field"My Field"}.
{field_raw:$FIELD_NAME} Extracts the value of $FIELD_NAME from the field in the first event from the trigger without JSON escaping it. Put field names with spaces in double quotes, {field_raw"My Field"}.
{name}
{alert_name}
The user-made name of the trigger.
{description}
{alert_description}
A user-made description of the trigger.
{triggered_timestamp}
{alert_triggered_timestamp}
The time at which the trigger was triggered, formatted as ISO 8601.
{id}
{alert_id}
The id of the trigger.
{action_id}
{alert_notifier_id}
The id of the action used to deliver this message.
{event_count} The number of events from the trigger.
{url} A URL to open Humio with the trigger’s query.
{query_string} The query of the trigger.
{query_result_summary} A summary of data in the query result from the trigger.
{query_time_start} The specified query start time (e.g. 10m).
{query_time_end} The specified query end time (e.g. now).
{query_time_interval} The specified time interval for the alert’s query (e.g. 10m -> now).
{query_start_ms} The actual query start time as Unix Time in milliseconds.
{query_end_ms} The actual query end time as Unix Time in milliseconds.
{warnings} Any warnings that were generated by the query. Note that by default, triggers will not trigger if there are warnings from the query, see alerts and scheduled searches.
{repo_name} The name of the repository in which the query was executed.
{events_str} Events encoded as a string.
{events} Events encoded as a JSON array of event objects.
{events_html} Events encoded as an HTML table inside <table> tags.
All fields from all events are shown as columns. The columns are ordered by the order the fields are encountered, starting with the fields from the first event. If you want fewer fields, remove them in the alert query using e.g. table, select or drop. You can also specify the order of the fields using table or select.
{schedule} The cron schedule which the triggering search was executed according to. Only applicable when triggered by a scheduled search.
{time_zone} The time zone that the triggering search is performed within. Only applicable when triggered by a scheduled search.

In the above table, some placeholders, like {alert_id} and {id}, evaluate to the same value. This is, however, only the case when running Humio version 1.19 or later. For earlier versions, only the variant with the alert_ prefix will work.

Be aware that for placeholders which evaluate to some formatted version of the query result, like {events_str} {events} and {events_html}, you will per default receive a maximum of 200 events. If you want a larger part of the query result in your message, you can append your query with | tail(x), where x is the number of events your wish to receive.

Both the alert and scheduled search triggers have an implicit | tail(200) appended to their queries. This means that above placeholders, like {events}, {events_str} and {events_html}, which evaluate to a full list of events in the query result, will contain 200 entries at most. If you want a larger result set, you can append an aggregate like | tail(1000) to your trigger query.

It is also possible to use these placeholders in the name and description fields of your trigger. This is useful, if you want to use the same action for multiple triggers, and you want different templates for the different triggers. As an example, you can use different {field:$FIELD_NAME} placeholders in the name for the triggers to extract the value of different fields, and then use {name}/{alert_name} in the action to get the trigger names with the placeholders replaced.

You can also use this feature to save yourself from having to write near-identical triggers, if you use an action where you cannot specify the message template. This is currently the actions OpsGenie, PagerDuty and VictorOps. These all use the trigger name as part of the message. Also, the default email subject and email template for the Email action uses the trigger name.

The {field:$FIELD_NAME} placeholder will only extract the value of the field from the first event from the trigger.