Getting Started with Triggers, Part III: Defining Applications

triggers

#1

You’ll want to head over to the Customer Portal and grab the latest firmware code. All set? Cool.

This is an awesome feature in the system, as it allows you to report on custom-defined applications as an entity, much like a device or even the capture itself. If this is confusing, hopefully it’ll become more clear with a use case.

Let’s say you’ve got a top-level application and you want to report and alert on. This app is defined by a portion of the URI. For example:

http://your-fqdn.bar.baz/app3/, and http://your-fqdn.bar.baz/app4/

Here, I’d like to treat the /app3/ path as an application, separate from /app4/. With triggers, the task is extremely easy:

var app = null;
if (HTTP.uri.search("app4") > -1) {
    app = "App4";
}
else if (HTTP.uri.search("app3") > -1) {
    app = "App3";
}
else {
    exit();
}
Application(app).commit();
Application(app).metricAddCount("rsp", 1);
Application(app).metricAddDetailCount("rsp", HTTP.host, 1);
Application(app).metricAddDetailCount("req_bytes", HTTP.host, HTTP.reqBytes);
Application(app).metricAddDetailCount("rsp_bytes", HTTP.host, HTTP.rspBytes);

That’s it. We’ll explore other ways to do this, but if you’ve only got a couple of entries (e.g. hostnames, uris, cookies, etc.) that define your application, this is a great, short way to solve the problem. Let’s walk through it:

var app = null;

this simply sets up an ‘empty’ variable. You don’t need to pre-declare variables, but this is a good practice.

if (HTTP.uri.search("app4") > -1) {
app = "App4";
}
else if (HTTP.uri.search("app3") > -1) {
    app = "App3";
}
else {
    exit();
}

Believe it or not, this is the meat of the trigger. And the trigger API is so well designed that it literally self describes: if one of our URIs has “app4” or “app3” in it, set a variable with the associated name of App3 or App4. If not, stop executing.

It’s a simple if/else if/else setup. If the tests match, do something. If they don’t match (the else block handles this), simply bail. Done. And finally, let’s create some data for our pages, alerts, etc:

Application(app).commit();
Application(app).metricAddCount("rsp", 1);
Application(app).metricAddDetailCount("rsp", HTTP.host, 1);
Application(app).metricAddDetailCount("req_bytes", HTTP.host, HTTP.reqBytes);
Application(app).metricAddDetailCount("rsp_bytes", HTTP.host, HTTP.rspBytes);

This one isn’t totally self describing, so we’ll dig in a bit.

Application(app).commit();

This line essentially defines our application. It preps data storage into the right place internally on the system. Notice the syntax, and recall that we set the app variable with the name App3 or App4. It’s just a user-friendly name for us to refer to in the GUI.

Application(app).metricAddCount("rsp", 1);
Application(app).metricAddDetailCount("rsp", HTTP.host, 1);
Application(app).metricAddDetailCount("req_bytes", HTTP.host, HTTP.reqBytes);
Application(app).metricAddDetailCount("rsp_bytes", HTTP.host, HTTP.rspBytes);

These for lines store some data of interest. You could store other metrics if you wanted to. Walking through each…

  • AddCount(“rsp”,1) is a basic counter. It’ll get incremented each time someone hits the app we’ve defined.
  • AddDetailCount(“rsp”, HTTP.host, 1) creates a “detail” view of this counter, but with the hostname and the associated count for that hostname.
  • AddDetailCount(“req_bytes”, HTTP.host, HTTP.reqBytes) stores the size of the request for a particular request, broken out by hostname.
  • AddDetailCount(“rsp_bytes”, HTTP.host, HTTP.rspBytes); same thing, but response bytes.

Obviously modify the URI and app names here to suit your needs. Once that is done, save this trigger off, and bind it to the web servers in question via your device list, device group, or custom group. Then let it run for a little bit and head over to the applications tab, click your app, then the “Overview” link and view the super useful results!

Enjoy.