Building The Network Diagram Screen

Draw a picture of your network in an illustrator app with each host node as a rectangle. Inside the rectangle, add placeholder text blocks with recognisable dummy strings to describe the measurements. Add a separate text block for each value you intend to update with new results. Now save the diagram as a Scalable Vector Graphic (SVG) file.

Open the SVG in a code editor to see the raw SVG code.  Remove the unnecessary heading items. Look for your recognisable text string tags. They may be inside <text> or <tspan> tags. Incorporate the tag ID value constructed from the {target-hostname} and {measurement-symbolic-name} separated by an underscore character (_). These ID values must each be unique within the page, so append a suffix if they appear more than once. Do not alter any other attributes on the tags.

<text id="NODE_NAME_DISK_SPACE">{percentage-value}</text>

Embed the SVG into your web page when you are done. The SVG is a first-class citizen in a web page and JavaScript interacts directly with the object model constructed from it.

Manufacture the JavaScript to request the latest data from the database. Call the server with an XHR request to avoid reloading the page.  Implement the SQL query in PHP and return a JavaScript Object Notation (JSON) formatted payload as a response. Parse the JSON result with JavaScript to extract the hostname, symbolic measurement name and the new value for each measurement.

Iterate through the new results. Assemble the HTML Element ID in the script using the same rules as the diagram object and search for the object in the Document Object Model (DOM) using a getElementById() function call. The returned object has a textContent property. Store the new value there and the browser will update the display immediately. Here is a fragment of JavaScript to update a displayed item as an example:

myNewValue = "75%";

myTargetHostName = "NODE_NAME";

mySymbolicName   = "DISK_SPACE";

myTargetId = myTargetHostName + "_" + mySymbolicName;

myTargetObject = document.getElementById(myTargetId);

myTargetObject.textContent = myNewValue;

If you want to highlight the containing rectangle to indicate the host status, define the ID value to be just the host name:

<rect id="NODE_NAME" ... />

Use JavaScript to locate the host named rectangle object and change the fill property with a new colour to indicate the node status:

myTargetObject = document.getElementById("NODE_NAME");

myTargetObject.style.fill = "red";

Encapsulate the whole update process in a JavaScript function and call it with a setInterval() timer to schedule it to run on a regular basis. Every minute is fine since that is the granularity of cron when it runs the measurement probes.

Building The Status Board Screen

The status board is a web page whose layout is dynamically controlled by a database table. This layout steering table has the following columns:

The page building logic requests the display controlling records and iterates through them. Each one provides the information needed to dynamically create a <div> element and position it on the page:

Set the ID of the of the <div> block container to a unique value.

<div ID="widget_{primary-key-id}">

Construct a CSS style block from the database values and add this as a style="" attribute inside the opening <div> tag, the values shown here would be derived from the database query result:

style="position: absolute;
       top: {top-value}px;
       left: {left-value}px;
       height: {height-value}px;
       width: {width-value}px;
       background-color: {colour-value};"

The inner content of the <div> block depends on the type of widget. A simple value can place a number inside a <span> block. A series of values could have a small table grid. You could insert an SVG to draw a graph or insert an image (<img>) tag to mimic a display indicator LED or other iconic symbol. Carefully factor the design of these widgets, and create a library of reusable code to draw them.

Use the host and symbolic names to identify values within the widgets and update them periodically like the network status diagram. The refresh logic can update graphs, pie-charts and progress-bars. If you design your widget collection properly, the same drawing code can be reused multiple times.

Building the arrivals board screen

An arrivals board is similar to the one you see at an airport. Use this to display the media processing queues. Track the workflow job status dispositions in a simple table grid. Each row represents one job running through the workflow. The columns indicate the various attributes of the jobs. The workflow manager can update a cache with progress information as the jobs run. That cached progress status can be acquired by the arrivals board update logic.

Here are some ideas for the columns you might want to implement:

The report manager

Each morning. the central cortex gathers measurements from the caches and runs the daily analysis. Filter and process the results and deliver the daily, weekly, monthly and other reports automatically by email.

Collating the results into reports or aggregating them for display from a SQL database cache is very easy to do. Use TCPDF with PHP to manufacture PDF reports and PHP_MAILER to dispatch them. Both of these libraries are open source and very easy to use.

Conclusion

Very few code changes are needed to alter the behaviour when the measuring system is data-driven. This significantly reduces the maintenance overhead. Because things are controlled by data and configuration files, implementing a dashboard control surface is quite easy.

Create new measurement tools and drop them into one of the probe containers. The only new code to write is the kernel of each new measurement.

Modifying the layout and content of the status display just requires some minimal changes to the SQL database table that steers the display generator. The dashboard can manage changes to that.

The major key to flexibility in this design is the use of unique symbolic names for each measurement and how they are propagated through the entire monitoring complex.

In closing, here are some prime directives to bear in mind when designing your own monitoring solution:

• Always look for opportunities to pass data values to modify script behaviour rather than duplicating code.
• Go the extra mile in your code so your users do not have to perform complex actions.
• Design for easy maintainability at the expense of brevity and obfuscated single lines of code.
• Avoid namespace collisions with carefully designed file system structures.
• Use defensive coding techniques to pre-empt problems.
• Comment everything in the source code.
• Design your data flow so that things only need to defined and measured once.
• Document everything thoroughly and keep it up to date with changes.
• Provide contextual online help to the users where appropriate.
• Read the UNIX man pages in full for a command before using it and look online for examples that illustrate how it is used.