Getting Started with Triggers, Part I



This is the first of several short and informal posts on how to get started with triggers. If they’re useful, please comment. If you have follow on questions, edits, etc. feel free to add to it.

##What are triggers, anyhow?

Application inspection triggers allow you to collect custom, ad-hoc metrics. You can alert, monitor, characterize performance, etc. in an unprecedented number of ways. Nothing like them exist in the APM space today.

Trigger overview

The trigger language is based on Javascript. Javascript is universal, fast, and easy to learn. It’s been around for a very long time, and is just plain fun to write. Triggers are also based on an event model. The idea is this:


…which fires when the system sees and parses an HTTP request. If there’s not an HTTP request, the code won’t fire. Your code runs inside of this event block.

Look at the “docs” tab at the top of this page, and you’ll see a link to the triggers API. Open it up and you’ll see a set of classes - think of these as buckets of functionality tied to a specific thing. For example, and continuing on with the HTTP protocol:

HTTP.path // <- returns the 'path' of the request, minus any query strings.
HTTP.uri // <- returns the RFC-compliant URI of the request.

Both of these are found in the HTTP class of the API. This makes for an extremely clean, intuitive layout. But at the same time, the scope of use cases that can be addressed is staggering.

Also note that you’ll see lots and lots of ‘properties’ in triggers. These are a javascript-y way of accessing various attributes of a class. From our example above, you’ll see the dot “.” separate the class name and its attribute, e.g. HTTP “.” path.

What makes this cool is that it’s real intuitive. Think of a connection flow moving across the ExtraHop system. It’s an HTTP request. We’ve got our trigger set up to fire on HTTP_REQUEST. When this happens, it’ll create (instantiate) an HTTP class, inside of which is a ton of useful data, like the uri, headers, etc. - the list goes on and on. Have a look at the API to see what I mean.

Also take note of the classes available: DB, Memcached, HTTP, CIFS, NFS, DNS, etc. - all of which allow you to do extremely intelligent stuff with the system.

Anyhow, that’s probably enough for part one. For the next installment we’ll start writing a basic trigger or two.