This post was originally published here.
UpGuard’s Events systems provides a communication hub to send the data that UpGuard gathers to external systems. Integration between technologies is critical to high performing digital businesses, and UpGuard’s Events system provides a simple way to get the information you need the places where you need it.
As UpGuard continuously analyzes the state of your infrastructure it will inevitably detect interesting things happening– what one might call “events.” And when those interesting things happen, you will likely want to know about them in a timely manner so that you can act on them. The Events feature set is really two components: the ability to curate views of events using a simple query syntax, and the ability to customize the actions taken on those events.
Event Types
Several common event views are provided by default. Policy failures, for example, are something that every UpGuard user would likely want to know about and act on. Looking at the query for this view, or any of the global views that UpGuard provides, gives a good idea of how to construct queries. There are several top level event types that can then be further filtered based on node group, environment, date, and the variables particular to that event type. Policy events, for example, have a “success” variable that describes whether the policy succeeded, whereas user logon events have variables for username and IP address. The variables are suggested in the query helper, or you can just look at the contents of an event to know what is available.
Saved views can be made public to other users in your organization– what we call “Organization Views”– or made private to only your account– “My Views.” As UpGuard detects events, they appear in the feed for matching views.
Taking Actions
Once a view has a name you can add actions. UpGuard provides native support for popular products like Jira, Slack, and ServiceNow, so setting up an integration simply requires creating a view and filling out the fields to populate the message to the target system. Additionally, events can be sent via email or to any REST endpoint, allowing for rapid integration with any modern system.
To make Actions even more extensible, we support liquid templating in any field. This provides an easy way to include variables in messages. For example, for messages about policy failures it would make sense to include the name of the policy and a URL that includes its ID. Liquid also has straightforward control flow syntax, making it easy to have a message body that lists all the failing checks on a policy.
The combination of Events and Actions avoids the pitfall of integration systems that lock you into a finite number of possible configurations. Event views have enough logic to filter to what matters without reinventing SQL, and Actions allow you to send any message to any destination without writing and running custom scripts.
