You’re monitoring a particular server for particular behavior–maybe patterns of filesystem usage, or the appearance in database server logs of specific faults, or cycles of CPU (central processing unit) usage. You’ve already scripted a little bash or PowerShell report that helps make sense of the events. It’s mildly tedious, though, to have to log in to the server every time you want to check in on progress–especially so because there are actually three servers that deserve oversight, and there are at least two other people on your DevOps team, and one manager, who also need or want to know what’s going on.
Longer term, it’s obvious what the formal “right thing” to do is: you define a Nagios plugin, or a Splunk filter, or SNMP MIB, and integrate the specific diagnostic under consideration in your larger monitoring framework.
Not too cold, not too hot
Those alternatives are uninviting, though: as refined as those technologies are, it takes expertise and care to code such extensions accurately. You have better things to do with the half-day that is the realistic minimum to get them right.
Web monitors are ideal, of course; it’s almost the definition of a modern sysad tool that it offers a Web view, because the latter are so easy to share (just pass on a URL) and demand no installation (what client display doesn’t already have a Web browser?). The trouble with a Web application is that you don’t have the time to learn PHP or Ruby or C# or whatever language your organization uses for Web pages.
The secret in all this is that you already know a Web language or two. Whether your servers run Linux or Windows, they almost certainly already have Apache or Internet Information Server or a close variant installed, configured with Common Gateway Interface (CGI) or perhaps its FastCGI or SCGI enhancements. You can leverage CGI to create small but useful Web pages with active content in about the same amount of time as it takes to read this article. The report you scripted to run on one server at a time instantly becomes available anywhere on the ‘Net that can reach that server.
I know perfectly well that CGI is obsolete; in fact, fifteen years ago I turned down a large project based on CGI because I was certain that the technology was diving rapidly to end-of-life. That it’s obsolete doesn’t mean it isn’t still useful, however. CGI can be a great choice for little one-off projects.
Plenty of Web tutorials are available to start you off at a “Hello, world!” level in your CGI career. The hardest part is generally to get the first CGI script to run satisfyingly, because so much about Web service is configurable. In a typical Apache installation, for instance, you might create a file called /var/www/cgi-bin/my_first.cgi with content
#!/bin/bash
content() {
# This is a model for more interesting computations and reports.
echo "<p>The time on server `hostname` is `date`."
}
echo "Content-type: text/html
<html>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'>
<title>My first example</title>
</head>
<body>
<h1>My first example</h1>"
content
echo "</body></html>"
exit 0
Exercise this page with a URL such as http://$SERVERNAME/cgi-bin/my_first.cgi. Make sure that you have set ownership and permissions appropriately for your configuration; in particular, you’ll probably need to chmod +x my_first.cgi.
Support the latest front-ends with the back-end scripting you know
Do you see what opportunities a simple approach like this opens for your DevOps team? Anything that you can script as a command-line or console application immediately becomes available as a Web application. This also means that you can marry your sysad scripting with all the functionality of modern HTML5. Not only can your CGI-based Web pages take advantage of basic HTML formatting such as <table> arrangements or colors, but you can use AJAX, geolocation, client-side programming, Web forms, and everything else HTML5 brings. It’s important to be clear on this: even though CGI is quite old and outmoded, it’s perfectly happy to serve up payloads from the latest standards. CGI lets you prototype “responsive” Web applications designed to be viewed on the trendiest mobile handsets. If your little monitors or reports need to be reworked some day for performance reasons into a more modern framework that you don’t know, that will be possible. In the meantime, though, you have benefited from extra weeks or months of CGI-based availability in a language you use every day.
Leave a Reply