This is the fourth article in my series on systems monitoring for software developers. In this article I want to talk about using dashboards for displaying information generated by your monitors.
The system monitor discussed previously will collect a lot of data from different systems. The amount of information that is collected can be vast and in its raw form may not be that useful except to people who really understand what the data represents. The key thing with a dashboard is to break this information down for different users. This may be a complete view of the data, or just a subset for different purposes, so you have to think about the context in which the data is going to be provided and the intended audience.
For me, a key requirement of the dashboard I built was to make the data from the monitor available to my development and operations team in an easy to view format. This dashboard contains more technical information including exceptions as that is more appropriate for the intended audience. You may need to provide another dashboard to key business stakeholders. The level of information you provide here would most likely be different and contain more business level data.
Your dashboard may be viewed in different places. This might include a large TV attached to the wall, projected against a wall, or the dashboard might be run on a person’s desktop computer. If you are displaying the dashboard in a place where people cannot interact with it, i.e. on a large TV Screen, then you want to make sure the dashboard automatically refreshes itself. I will cover this more later on in the article.
Types of Dashboard
You really are spoilt for choice these days when it comes writing a dashboard. You can keep the display simple or you can really embellish the presentation. As I said earlier, it depends on your target audience. I personally find that keeping the display simple is the best thing to do. I have seen some dashboards that go overboard with dials, speedometers and other fancy graphics, and these can confuse the information you are trying to communicate if you are not careful.
You can develop your dashboard as a native application. This is what I did with my own solution for the company I work for. I work at a company that is based around the Microsoft stack, so this really gave me 2 choices as a .NET developer; Winforms or WPF. As I needed to get the dashboard up and running quickly I used Winforms, mainly because I am very familiar with this particular technology. WPF would also have been a very good choice.
My dashboard was aimed squarely at a technical audience, so the level of detail could be higher. The context of the dashboard was to allow developers spot any problems in our critical systems. I decided to keep the screen design very simple. I used a tabbed control, where each tab represented one sensor from the xml stream written out by the monitoring system.
I have an option in the monitor where the dashboard will cycle through each tab every 30 seconds. This mode is used for when the dashboard is running on a large wall mounted TV.
The dashboard application also updates automatically when a new version of the monitoring system xml file is written. For my system I have the task scheduler set to run the monitors every 15 minutes. The frequency of this is entirely down to you and your needs. For us, every 15 minutes was sufficient.
If you don’t want to develop a thick client, then another option is a webpage that lives on your intranet. The webpage can be made to directly pull in the monitor xml feed and display this onto the screen. This can be done directly through code extracting the XML data or via XSLT.
Whether you choose to use a website or a thick client is down to you and your developer’s skill sets, but either option is fine. You do have the added advantage that with a website, you can deploy to a web server and everyone can access the monitor via their browser.
Tablets / Smartphones
With the proliferation of tablet devices on the market, you also have the option of supporting these via native apps.
If you provide any of this information to customers external to the organisation, then this may be an option, but in all honesty it seems like an expensive luxury to develop these applications, especially if you want to support all the main favours, IOS, Android and Window 8. If you really want to use a tablet, then accessing an intranet site on your domain might be a better option, especially if you use a responsive design so that the formatting tailors itself to the smaller form factor.
Another way to display some of this information is via reports. These can be generated into PDF, CSV or customer email template reports. A good example of this is providing product performance metrics to senior management. The standard monitoring data would be far too much detail, but you could, for example, send a morning email stating:
- How many products were sold the previous day?
- How many new customers signed up?
- How many customers are repeat customers?
These management information reports can be very use to your management. This doesn’t mean you should always use this instead of any other business intelligence reports, but they can supplement the information generated by your BI system.
Types of Dashboard View
From the work I have been doing on custom dashboards, there are 4 main type of view that you may need to cater for depending on your requirements. These are:
- Technical Views
- Business Views
- Value Stream Views
- System Run Charts
The technical view is analogous to the black box data recorder. This dashboard view is aimed at developers and technical operations staff. This would give a complete view of what each monitor has reported, like metrics, stats, errors etc. This type of view can both be displayed on a large screen for everyone to see and also be run as a separate application on a developer’s machine.
The dashboard I developed also had buttons leading off each monitors display page so you could browse log files, and view exception data in more detail. Not the sort of data you would necessarily want on the main display page, but useful for a developer running the dashboard on their desktop machine who wants to dig a little deeper into the data.
The business view contains data that is less technical. For a member of the business looking at this dashboard they will not really be interested in exception detail and other system specific technicalities. They will be more interested in raw metrics from the systems, like number of loans transacted, money collected, credit scores requested etc. This view can also calculate additional data based on the data streamed from the monitors. For example you may report back the number of successful and declined transactions, but also additionally calculate the success rate.
The system view is designed to show the flow of information across your business process and aims to be a high level business system view. For example, using the idea of a consumer finance company, you have new loans appearing on the left in retail stores or on your website, and the flow of those loans through the head office as a live account and then potentially going into debt. The screen mock up below demonstrates this idea.
This type of view is not only useful for people in the business, but it gives your development teams some operation context and awareness of how their individual system fit together in the grand scheme of the business.
The final type of dashboard view I want to discuss is a Run Chart. This isn’t strictly a separate monitor view on its own, but you can access it as additional data from the other views. The views we have discussed already (technical, business, system) all represent snapshots of the system at that particular time based on the snapshot data created by the monitoring sensors. The run charts let you look at that data over time. This data can come from snapshot files or the database; it depends on how you have decided to build the system. Below is an example of a run chart from my monitor. I have had to remove some bits of information from the image as it is an actual screenshot, but you get the idea.
By looking at a run chart you can start to see trending information in your systems. If you use a database for storing your sensor snapshot you can of course plug Excel into the database and achieve the same thing, but you may also want to have these data accessible from the dashboard program it-self. It really depends on what you want to achieve, but whether you do it from Excel or the dash board doesn’t matter too much. Having access to the information is what’s important.
The basic architecture of the dashboard system is quite simple as you can see from the object diagram below.
Each monitor (or view in our case) implements an IMonitor interface. This interface provides access to that views UserControl (I used Winforms in my particular dashboard), the monitor’s name, and a method to update the view.
The DashboardMainForm and MonitorController maintain a list of IMonitor objects that get updated when the main application reads in the monitor snapshot data. The process flow is also shown in the sequence diagram below.
Here you can see the main program start executing and calling into the DashboardMainForm where all the dashboard controls are cleared. Then the DashboardMainForm makes a call into the MonitorController to read in the monitor snapshot file. My particular implementation uses an XML snapshot file, but this could be database call or however you choose to persist the monitor data.
Once the data is loaded in, each monitor control is instanced. The MonitorController then runs through a loop passing in the data for each control from the monitor snapshot and updates the views.
Then the DashboardMainForm gets all the active controls and adds them to a tab control ready for rendering to the screen.
As you can see, the basic architecture for a dashboard is actually very simple when you want to get a basic set of screens going. In my particular system I wrote a desktop application in .NET using Winforms, but there is no reason why you can use WPF or ASP.NET / MVC to create a website. It really depends on your requirements and how you choose to use the system.