This project implements a Sensu Go event filter library, providing a pair of functions which are used in conjunction with handlers and filters to provide contact routing capabilities in your Sensu monitoring pipeline.
The has_contact
function requires two arguments: the event object and a contact name string. Given these inputs, the function evaluates whether or not the specified contact name appears in comma separated values for the contacts
label, under either the entity or check scope.
The no_contacts
function accepts the event object as its sole argument. This function returns true if the event does not contain a contacts
label under either the event's entity or check scopes.
- Download the asset definition for the latest release from Bonsai.
- Install the asset definition using sensuctl (e.g.
sensuctl create -f sensu-sensu-go-has-contact-filter-0.1.2-any-noarch.yml
)
With the sensu-go-has-contact-filter
asset installed, you're ready to configure the rest of your Sensu pipeline.
Define one or more filters with sensu-go-has-contact-filter
as a runtime asset and using the has_contact
function in a filter expression. The following example shows a filter which will allow events when the entity or check labels contain dev
:
---
type: EventFilter
api_version: core/v2
metadata:
name: contact_dev
namespace: default
spec:
action: allow
runtime_assets:
- sensu-go-has-contact-filter
expressions:
- has_contact(event, "dev")
Likewise, this filter stipulates that contacts should include ops
---
type: EventFilter
api_version: core/v2
metadata:
name: contact_ops
namespace: default
spec:
action: allow
runtime_assets:
- sensu-go-has-contact-filter
expressions:
- has_contact(event, "ops")
To complement filters which test for specific contact names, you may also wish to have a filter which handles events without explicitly defined contacts:
---
type: EventFilter
api_version: core/v2
metadata:
name: no_contacts
namespace: default
spec:
action: allow
runtime_assets:
- sensu-go-has-contact-filter
expressions:
- no_contacts(event)
Define one or more handlers which make use of the filter. In this example, a handler named email_dev
is defined, using two built in filters in conjunction with the contact_dev
filter shown above:
---
type: Handler
api_version: core/v2
metadata:
name: email_dev
namespace: default
spec:
command: sensu-email-handler -f sensu@example.com -t dev@example.com -s smtp.example.com
-u sensu@example.com -p smtp_password
env_vars: null
filters:
- is_incident
- not_silenced
- contact_dev
handlers: null
runtime_assets:
- sensu-email-handler
timeout: 10
type: pipe
---
type: Handler
api_version: core/v2
metadata:
name: email_ops
namespace: default
spec:
command: sensu-email-handler -f sensu@example.com -t ops@example.com -s smtp.example.com
-u sensu@example.com -p smtp_password
env_vars: null
filters:
- is_incident
- not_silenced
- contact_ops
handlers: null
runtime_assets:
- sensu-email-handler
timeout: 10
type: pipe
---
type: Handler
api_version: core/v2
metadata:
name: email_default
namespace: default
spec:
command: sensu-email-handler -f sensu@example.com -t staff@example.com -s smtp.example.com
-u sensu@example.com -p smtp_password
env_vars: null
filters:
- is_incident
- not_silenced
- no_contacts
handlers: null
runtime_assets:
- sensu-email-handler
timeout: 10
type: pipe
For greatest effect, you can combine multiple handler definitions in a handler set:
---
type: Handler
api_version: core/v2
metadata:
name: email
namespace: default
spec:
type: set
handlers:
- email_dev
- email_ops
- email_default
With a handler set like this one in place, check results configured with the email
handler will spawn a handler pipeline for each handler in the set, each pipeline using the has_contact
function to evaluate whether or not the event matches a named contact. Based on the above examples, a check result with "dev" and/or "ops" will be routed to those contacts respective email addresses, whereas any check result without contacts defined will be handled by the email_default
handler.
See the included contact routing pattern diagram for a visual description of intended use cases.