M3 Timers – improved server monitoring

Unleashing the power of M3 & timers

During the lifespan of M3 (Monitis Monitor Manager) there has always been something lacking – timers.

M3 execution procedure was outlined in this previous article.

The execution mentioned in the latter was a one-time-execution, whereas server monitoring requires periodic invocation of monitors in order to actually provide counters over time, graphing performance.

The periodic invocation method suggested up until today was to integrate M3 with crontab.

Crontab, in a nutshell, is a Linux/Unix service for periodic invocation of executables. Implementing M3 with crontab properly meant M3 would run every X minutes, producing a Monitis counter update every X minutes, should everything run properly.

In the following article I’ll outline the changes done to support timers in M3.

Design & implementation

When assessing a programming task, I usually stick to the KISS simple – “Keep it simple, stupid!”.

I had a few ideas of how to implement timers in M3, eventually I went with the simplest one, yes, for sake of simplicity.

If we’ll go back to M3’s XML hierarchy, we’ll discover again that the top most level is an agent. Every agent can have a few monitors and every monitor can have a few counters (metrics).

The simplest idea I had in mind was to simply spawn every agent in a different thread.

Simply put, what M3 would do when invoked in timer mode is to spawn a thread for every agent defined in the XML. Every one of these new spawned threads will:

  1. Run all the monitors of the agent and update their data in Monitis
  2. Sleep for X seconds (where X is the agent interval defined)
  3. Loop back

It’s true that if M3 is configured with dozens of agents, then dozens of threads would be spawned. If you are such a person using M3 with dozens of agents, please feel free to contact me and we’ll find a solution also for that.

Going to the beginning of the paragraph and mentioning dozens of spawned threads, I have to admit I was tempted to go with a single-threaded asynchronous design, but realized that implementing such a thing might take too long and cause too many bugs.

We at Monitis believe that monitoring your servers should be easy and never hamper performance. If you believe that the mentioned design of M3 might harm your performance, I’ll be more than happy to go forward with a single-threaded asynchronous implementation which would definitely yield better performance and a smaller memory footprint.


M3’s usage is still very simple. If you have M3 checked out, simply update it and you’ll find:

  • TimerRun.pl
  • TimerDryRun.pl

The former will invoke M3 in a loop, running monitors and updating counters. The latter will do exactly the same without updating counters.

Both executions can be terminated using ^C, which would terminate all threads cleanly. Be patient while terminating.

Invocation stayed the same. For the sake of simplicity we can use the etc_file_monitor.xml configuration file which is configured with an interval of 300 seconds (5 minutes). Invocation will be as follows:

 # TimerRun.pl etc_file_monitor.xml 

That’s it, go have lunch. M3 will do the rest for you!

Backward Compatibility

In case you wonder about backward compatibility or if you are just happy to run M3 via crontab – then worry no more. M3 functionality as a stand-alone single-execution behavior is still functional. Timers came as an addition and not as a replacement.

Enjoy it and remember that feedback is always more than welcome!

Integrating software into the powerful Monitis has never been easier, now that you have M3!

Monitis can monitor anything! Follow us also on Twitter and GitHub.