OpenIG: A new audit framework

openig-logo This past week Guillaume added an audit framework to OpenIG. You can try it out by installing a new nightly build of OpenIG.

The audit framework follows a publish-subscribe pattern. You add “audit” decorations to OpenIG filter, handlers, and routes. The decorated objects trigger publication of audit events.

Each audit event holds a pointer to the exchange, the name of the object that triggered the event, a timestamp, and tags for the event. OpenIG provides built-in tags: a request when the object is first called; a response after the object is called; a completed tag on success; an exception tag on error. Audit agents subscribe to the audit events, and can select the audit events they want based on the tags. When you set “audit” decorations, you can define your own tags, too, such as “raise alarm” or “Default route”.

If your default route for example looks like this today:

{
  "handler": "ClientHandler"
}

Then you can update the route for audit like this:

{
  "handler": "ClientHandler",
  "audit": "default route"
}

OpenIG currently provides one audit agent out of the box: MonitorEndpointHandler. A MonitorEndpointHandler counts how many messages through the object are “active”, “completed”, or “failed”, sorts them by the tags used, and returns the result as JSON. You can set a monitor route up like this:

{
  "handler": {
    "type": "MonitorEndpointHandler"
  },
  "condition": "${exchange.request.method == 'GET'
      and exchange.request.uri.path == '/monitor'}",
  "audit": "monitor"
}

Suppose that your top level config.json file looks like this:

{
  "handler": {
    "type": "Router",
    "audit": "main"
  },
  "heap": [
        {
            "name": "LogSink",
            "type": "ConsoleLogSink",
            "config": {
                "level": "DEBUG"
            }
        },
        {
            "name": "ClientHandler",
            "type": "ClientHandler"
        },
        {
          "name": "capture",
          "type": "CaptureDecorator",
          "config": {
            "_captureEntity": true,
            "_captureExchange": true
          }
        }
    ],
    "baseURI": "http://www.example.com:8081"
}

Furthermore, suppose you have the default route shown above, plus another route that looks like this:

{
  "handler": {
    "type": "StaticResponseHandler",
    "config": {
      "status": 200,
      "reason": "OK",
      "entity": "Hello from a static route"
    }
  },
  "condition":
      "${matches(exchange.request.uri.path, '^/static')}",
  "audit": "static route"
}

After you access your routes through OpenIG a few times, you can see the monitoring results by accessing the /monitor endpoint, which returns the statistics in JSON:

{
    "static route": {
        "active": 0,
        "completed": 22,
        "failed": 0
    },
    "main": {
        "active": 1,
        "completed": 36,
        "failed": 0
    },
    "monitor": {
        "active": 1,
        "completed": 0,
        "failed": 0
    },
    "default route": {
        "active": 0,
        "completed": 14,
        "failed": 0
    }
}

Notice that “main” shows the sum for all exchanges, “static route” shows 22 successful exchanges, “default route” 14, and “monitor” (monitoring itself) has 1 active exchange in progress, the current one.

For more on auditing in OpenIG, start with the draft chapter, OpenIG Audit Framework.

Advertisements

Leave a comment

Filed under Access Management

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s