In this lesson, we will introduce Sensu Handlers, and show how to configure an alert handler and a metrics handler. This lesson is intended for operators of Sensu, and assumes you have set up a local workshop environment.
In this lesson we will introduce Sensu Handlers, and show how to configure an alert handler and a metrics handler. This lesson is intended for operators of Sensu, and assumes you have set up a local workshop environment.
Handlers are actions the Sensu backend executes on incoming observability events. Handler configurations are one of the most important building blocks within Sensu, because they determine what happens to events that flow through the Sensu pipeline.
Handlers can be used to send alerts, store observability data, create and resolve incidents, and trigger automated remediations. In the following exercises we will configure two handlers; one that send alerts to a chat app, and another that stores metrics to a time-series database.
The most common type of handler is a pipe handler.
A pipe handler can be any program that accepts event data as JSON input to STDIN
, even a shell script.
There are many existing handlers available in Bonsai.
Example pipe handler:
---
type: Handler
api_version: core/v2
metadata:
name: example_pipe_handler
spec:
type: pipe
command: do_something.sh
Your SRE team primarily communicates via a chat app like Slack or Mattermost. They want to recieve alerts as chat messages.
To accomplish this we will use the sensu-slack-handler. Because Mattermost is API-compatible with Slack, we can use the Slack handler with Mattermost. The handler will send event data to a channel in the workshop Mattermost instance.
Create a YAML File Containing the Handler Configuration
Copy and paste the following contents to a file named mattermost.yaml
:
---
type: Handler
api_version: core/v2
metadata:
name: mattermost
spec:
type: pipe
command: >-
sensu-slack-handler
--channel "#alerts"
--username SensuGo
--description-template "{{ .Check.Output }}\n\n[namespace:{{.Entity.Namespace}}]"
--webhook-url ${MATTERMOST_WEBHOOK_URL}
runtime_assets:
- sensu/sensu-slack-handler:1.4.0
timeout: 10
filters: []
secrets:
- name: MATTERMOST_WEBHOOK_URL
secret: mattermost_webhook_url
Understanding the YAML:
- The asset identifier
sensu/sensu-slack-handler:1.4.0
instructs the backend to download the handler executable from Bonsai.- The
--description-template
option uses a handler template to format the event into a message string.- The handler is configured using environment variables and secrets available to the Sensu backend.
Create the Handler Using the sensuctl create
Command
sensuctl create -f mattermost.yaml
This command will create the handler configuration contained in the YAML file by sending it to the Sensu Handler API.
Verify that the handler was successfully created.
sensuctl handler list
Output:
Name Type Timeout Filters Mutator Execute Environment Variables Assets
─────── ────── ───────── ───────────── ───────── ─────────────────────────── ─────────────────────── ─────────────────────────────────
mattermost pipe 10 is_incident RUN: sensu-mattermost-handler sensu/sensu-slack-handler:1.4.0
Do you see the mattermost
handler in the output?
If so, you’ve successfully created your first handler.
Sensu is designed to be a pipeline for observability events, but does not store the events directly. If you want to keep a historical record of the data, a handler can be used. The handler converts incoming events into the required format, then sends it to a database for storage.
In Sensu, observability data is modelled as events.
Some events contain metrics as part of their payload in the metrics
property.
Learn more about metrics in the metrics reference docs.
Handlers can apply a filter to ensure that they only operate on matching events. There are some built-in filters available for common use cases, or you can write your own using a JavaScript-based Sensu Query Expression.
In the exercise below, we will use the built-in filter has_metrics
to ensure that only events with a metrics
property are processed by the handler.
You want to store metrics in a data platform like Sumo Logic, Prometheus, or InfluxDB.
To accomplish this we will use the sensu-sumologic-handler. The Sumo Logic handlers send metrics to your Sumo Logic account.
Create a YAML file containing the handler configuration.
Copy and paste the following contents to a file named sumologic.yaml
:
---
type: Handler
api_version: core/v2
metadata:
name: sumologic-metrics
spec:
type: pipe
command: >-
sensu-sumologic-handler
--send-metrics
--source-host "{{ .Entity.Name }}"
--source-name "{{ .Check.Name }}"
runtime_assets:
- sensu/sensu-sumologic-handler:0.2.0
secrets:
- name: SUMOLOGIC_URL
secret: sumologic_url
timeout: 10
filters:
- has_metrics
Understanding the YAML:
- The asset identifier
sensu/sensu-sumologic-handler:0.2.0
instructs the backend to download the handler executable from Bonsai.- The built-in filter
has_metrics
is used to ensure that only events with metrics are processed by the handler.- The handler is configured using environment variables and secrets available to the Sensu backend.
Create the Handler Using the sensuctl create
command.
sensuctl create -f sumologic.yaml
Verify that the handler was created.
sensuctl handler list
Do you see the sumologic-metrics
handler in the output?
If so, you’ve successfully created the handler!
In this lesson, we’ve only scratched the surface of what handlers can do. You learned how to create a handler using a YAML file, use handler templating to format event data, use built-in filters, reference assets published to Bonsai, and view a list of running handler configurations.
Handlers are part of the process stage of the observability pipeline. That means all of this happens on the Sensu backend, running the handlers in the same place where agents and checks send their observability data.
Because Sensu is API-based, we were able to create the handlers remotely, using sensuctl
to push the desired configuration to the backend via the Handler API.
We used a Monitoring as Code workflow, authoring the handler configurations with YAML files. We did not need to send any executable code, environment variables, or secrets along with this configuration. This means you can safely store the YAML configuration files in a git repo.
The executables are stored as assets in Bonsai (or a private asset server), and the secrets are stored in Vault. The Sensu backend will automatically download them as needed.
All of this works together to allow you to quickly add, remove, or change handler configurations in a live system at any time, without the need to redeploy.
Handlers developed using the Sensu Plugin SDK have built-in support for templating using the Golang text/template
package.
This can be used to merge observability data directly into the output, providing meaningful context and actionable alerts.
For example, an email handler could use an HTML message template that includes information like the status, number of occurences, or a customized playbook link.
Example: HTML email Template
<html>
The entity {{ .Entity.Name }} has a status of {{ .Check.State }}. The entity has reported the same status for {{ .Check.Occurrences }} preceding events.<br>
<br>
The playbook for responding to this incident is available at https://{{ .Entity.Labels.playbook_host | default "wiki.example.com" }}/observability/alerts/{{ .Check.Labels.playbook_id }}.
</html>
Another feature of the SDK is the ability to override handler configuration using metadata embedded in the event.
For example, you may want to send certain events to the #ops
channel in Mattermost.
The channel can be specifed in an annotation like sensu.io/plugins/slack/config/channel
on a per-check basis.
Example: Check Configuration Using Annotations to Override Destination Channel
---
type: CheckConfig
api_version: core/v2
metadata:
name: nginx-status
annotations:
sensu.io/plugins/slack/config/channel: "#ops"
spec:
command: check-nginx-status.rb --url http://127.0.0.1:80/nginx_status
publish: true
subscriptions:
- nginx
interval: 30
timeout: 10
handlers:
- slack
For more examples of configuration overrides using annotations, read the handler documentation for some frequently-used handlers (i.e. Slack, Pagerduty, and ServiceNow).
With handlers, you can also send event data directly to a TCP or UDP socket, trigger automated remediations using tools like Rundeck or Ansible Tower, create and resolve incidents in Pagerduty, ServiceNow, or JIRA, and send alerts as Slack messages or emails.
For more complex workflows, multiple handlers can be stacked using handler sets.
Read more about handlers in the handler reference documentation.