Generic server monitoring with Monitis & M3

Had I been told to monitor a cat chasing a mouse with Monitis, my answer would have been – “Yes, it’s probably possible”.
With the not-so-recent addition of M3 to the arsenal of monitoring tools Monitis can utilize, it is possible to monitor anything. However this alone is far from being enough. Smart implementations of proper applicative monitoring is what should be practiced.

One advantage of using Monitis to monitor your systems and applications is the flexibility to use either the native agent or custom monitor code written in virtually any language. For custom monitors, the REST API provides the basic foundation to interface programmatically with Monitis. For many popular languages, there are open source SDKs available to make the process of interfacing with Monitis even easier. You can find links to Java, Perl, PHP, Ruby, C#, PowerShell, and VisualBasic SDKs and example scripts at http://monitis.com/api/api.html#sdk.

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.

In this article we’ll create a Monitis custom monitor to measure your network bandwidth or throughput. The monitor will support multiple network adapters and should be intelligent enough to only collect results for the network adapters that are active.

First, let’s take a look at the performance counters we used for this monitor and the information each metric provides.

In this second part of our monitoring Hyper-V article we’ll discuss the details about Processor, Memory, and Storage monitoring. In part 1 we discussed the Overall Health metric set. Let’s start with the Processor Metrics.

Processor Metrics

There are three processor-related metric sets:

Scheduling Custom Monitors with Monitis and PowerShell

In last article, we talked about creating custom monitor updater commands that would run a script and upload the values to Monitis.  These custom updaters make it a snap to convert any PowerShell script to a Monitis monitor.  Simply plug the script in and start using it’s more logical name: Update-YourMonitor.

As we have discussed on the Monitis blog virtualization is one of the hottest IT subjects today.

One leader in this field is Citrix — with the XenServer product family. XenServer is the most known commercial implementation of of the open source Xen hypervisor. By the way, you should pronounced Xen like “zen.” It comes from a Greek word meaning “guest.”

In this article we’ll go into VDI (virtual desktop interface) monitoring on Windows Server Hyper-V and in particular what and where to monitor and what counters to utilize to determine of your virtual machine is overloaded and what resources are used. This article focuses on measuring networking, storage, and CPU usage.

Windows Hyper-V has three main components, each of which can be monitored; the virtstack, devices, and the hypervisor. When Windows 2008 boots the system it launches the virtstack and hypervisor. The virtstack handles the emulated devices, manages virtual machines, services I/O, etc. The Hypervisor schedules the virtual processors, manages interrupts, services timers, and controls other chip-level functions.

Pluggable M3 (Monitis Monitor Manager) Framework

Who needs an introduction about M3? – Perhaps no one!
After gaining some reputation with M3, providing extra-easy integration of any monitor into Monitis it was time to take it to the next level.

Generally speaking, the work flow of M3 was described in detail in this article.

After some thought and design, we’ve decided it’d be best if M3 was pluggable. Pluggable in terms of being able to easily add execution and parsing plugins.
The interface and behavior of M3 stayed exactly the same, however now it is much easier to obtain data from any source and parse the data the way you want it.
Saying that, it was time to put the new design for a test. We tried to integrate the DBI support into M3.
Guess what – it was much easier than expected!