Home / server / Questions / 218628
In Process
Geo Ego
Asked: 2011-01-05 09:18:25 +0800 CST

What are some techniques to monitor multiple instances of a piece of software?

  • 772

It was recommended that I ask this question here by a member of StackOverflow.

I have a piece of self-serve kiosk software that will be running at multiple sites. I'd like to monitor a small number of parameters remotely.

The kiosk application itself is pretty much finished. I am now in the process of creating a piece of software that will monitor all of the kiosks from a central location so that the customer can view particular details remotely (for instance, how much cash is in the kiosk, if the kiosk is on or off, if it is currently out of order, etc.). Because I am in such an early stage of development, my options are quite open. I understand that I'm not giving very many qualifications, but I'd like to try to get a good variety of potential solutions. Some details:

  • Kiosk software is a VB6 app running on Windows Embedded
  • Monitoring software will be run on a modern desktop version of Windows (either XP, Vista, or 7)
  • Database is SQL Server 2008

My initial idea was to develop a .NET app that would simply report the last database transaction for each kiosk at a set interval (say every second or so) but I'd really like for the kiosk software to report its status in real-time, perhaps just sending a packet with that small amount of information embedded. I'm not exactly sure where to begin in terms of what modifications may need to be made to the kiosk software, and what the monitoring software will require. Links to articles on these topics would be most welcome.

monitoring .net vb6 windows-embedded

2 Answers

  1. My suggestion: go with something that already has proved monitoring capabilities. Do not develop the SERVER SIDE monitoring tool.

    You can use open source solutions such as zabbix or nagios and even paid ones.

    Zabbix has something that is called UserParameter. You can use it to extend zabbix "standard" capabilities. For instance, you could create an application (or a VBS script, powershel, etc) that verifies how many logged users the kiosk has (or anything that you need). By using a local zabbix service, this application/script will be called and executed, and the gathered value will be sent to zabbix server.

    Using this technique, you could setup zabbix to send alerts/thresholds to inform you when the kiosk has too many logged users.

    By using a "professional" monitoring tool, you'll also be able to monitor other kiosk's aspects, such as cpu, memory, network, etc.

    The company that I work for has some kiosks, and we use zabbix to monitor it.

    --EDIT -- Regarding your statement "so that the customer can view particular details remotely", this is another requisite that, in my opinion, drives the solution to an already established one: security. Zabbix for instance can be "attached" to an LDAP server and it has a very good control over the users (what a user can see and what a user can do).

    • 2

  2. You can take Zabbix's functionality as a base and only implement what you actually need.

    For example: at our company, we have a Zabbix helper script that regularly sends monitoring data for the host over UDP in a very simple format: item value~item value etc Another part of the script runs at the Zabbix server host, receives these lines from a multitude of hosts and transfers them to Zabbix server, several at a time, using the more complex Zabbix native protocol. The price we pay is security (anyone can send a forged packet) and possible packet loss but inside our private net, that's OK.

    You can run similar agents at kiosks and make them start sending such data to a customer on its command. Of course, you will lack history and triggers but if you need them, it'll be easier to implement MSSQL support for Zabbix.

    For the latter, only the DB interface code is likely to require changes (well, just look for the engine-specific #ifdef's). The logic itself uses plain SQL during routine operation and doesn't use stored procedures. DB templates are engine-specific and are packaged as .sql files to be run by hand. To compile the server in Windows, MinGW or Cygwin (possibly with -mno-cygwin compiler option) are your friends.

    • 0