OpenIG 3.1 is almost out the doors… Just a few days of testing and it will be generally available.
The new version introduces a general purpose auditing framework, and some basic monitoring capabilities. Mark wrote a blog post describing the details of the auditing framework and the monitoring endpoint. I’ve started playing with it for demonstration purposes and wanted to get more out of it.
If you want to expose the monitoring endpoint, you need to add the following 00-monitor.json file under .openig/config/routes/ and decorate a few handlers as Mark describes in his post. You might also want to extend this configuration to require authentication and avoid letting anyone have access to it.
The monitoring endpoint allows to display basic statistics about the different routes: the counts of in progress requests, completed requests and failures. So the output looks like this:
{"Users":{"in progress":0,"completed":6,"internal errors":0},
"main":{"in progress":1,"completed":1074,"internal errors":0},
"groups":{"in progress":0,"completed":4,"internal errors":0},
"Default":{"in progress":0,"completed":16,"internal errors":0},
"monitor":{"in progress":1,"completed":1048,"internal errors":0}
}
Each tag represents a route in OpenIG, including the “monitor” one, “main” representing the sum of all routes.
I was thinking about a better way to visualise the statistics and came up with the idea of a monitoring console. A few lines of Javascript, using JQuery and Bootstrap, an additional configuration file for OpenIG and here’s the result:
As you can see, this adds a new endpoint with its own audit: /openig/Console. The endpoint can be protected like any other route using OAuth2.0, OpenID Connect, SAML or basic authentication.
Let’s look at what I’ve done.
I’ve added a new route under ~/.openig/config/routes: 00-console.json with a single StaticResponseHandler. Instead of adding the whole content in the json file, I’ve decided to let the handler load the whole content from a file (named console.html). This allows me to separate the logic from the content.
00-console.json
{
"handler":{
"type": "StaticResponseHandler",
"config" : {
"status": 200,
"entity": "${read('/Users/ludo/.openig/config/routes/console.html')}"
}
},
"condition": "${exchange.request.method == 'GET'
and exchange.request.uri.path == '/openig/Console'}",
"audit" : "Console"
}
Note that if you are copying the 00-console.json file, you will need to edit the file location to match the absolute path of your console.html file.
Now the console.html file is actually a little bit long to display here. But you can download it here.
But it’s a basic html page, which loads Jquery and Bootstrap:
<!DOCTYPE html> <html lang="en"> <head> <link rel="stylesheet" href="//maxcdn.bootstrapcdn.com/bootstrap/3.3.0/css/bootstrap.min.css"> <!-- Optional theme --> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.1/css/bootstrap-theme.min.css"> <!-- Latest compiled and minified JavaScript --> <script src="//code.jquery.com/jquery-1.11.1.min.js"></script> ...
And at regular interval (default is 3 seconds), it gets the statistics from the monitoring endpoint, and displays them as a table:
...
<script>
$(document).ready(function () {
setInterval(function () {
$.get("/openig/monitor").success(writeRoutesStats);
}, 3000);
});
...
The whole Console fits within 60 lines of html and javascript, including some logic to use different colours when internal errors occur on a route.
Finally, the nice thing about the Console, being based on BootStrap, it also has responsive design and allows me to monitor my OpenIG instance from anywhere, including my phone:
If you do install the Console on your instance of OpenIG 3.1 (or one of the latest nightly builds), please send me a screenshot. And if you do customize the javascript for an even nicer look and feel, don’t hesitate to send a pull request.
Ludo Sketches 