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.

New feature provides significantly faster insight and root cause analysis

SAN JOSE, Calif., February, 15, 2012 – Monitis, the leading cloud and web application monitoring software provider, today announces that it has added comprehensive MySQL database monitoring to its award-winning Application Performance Management & Monitoring platform. The robust Software-as-a-Service (SaaS) tool enables users to gain significantly faster insight when conducting root cause analysis.

The MySQL monitoring feature includes 246 monitoring variables and more than 21 different metrics to provide one of the easiest to use, yet comprehensive database monitoring tools available. It was first introduced into the free Monitor.Us platform back in June last year and has seen the code battle hardened by many hundred free users over the last 8 months.

Monitoring In a previous Monitoring Performance on MongoDB – Mongo Basics article we went over some basics about Mongo and monitoring Mongo performance.  In this article we are going to examine some interesting services, that can help with our Mongo monitoring.

Basically, we have two sets of statistics we would like to collect from our Mongo instances.  First, the basic computer stats that you need to collect for any machine in your fleet, and second we want to collect all these great DB stats from the Mongo HTTP Console.

We want to collect all these statistics, but we also need somewhere to store and view them.  That’s where Monitis comes into play!

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!

Cassandra is a robust and highly scalable NoSQL datastore that usually consists of multiple nodes spread out across multiple datacenters.  If you are the system administrator for a large Cassandra deployment then you might be curious as to how your cluster is doing.  In fact your job probably depends on it!  So how can you combine a great service like Monitis with Cassandra to make sure you cluster is buzzing along smoothly?

M3 (Monitis Monitor Manager) framework usage and examples were outlined in a few previous articles:
M3 – introduction
Planning your vacation / HTTP extraction
However we’ve never explained the bits and bytes behind it and what was the initial motivation for implementing it.
This article will outline the motivation, design, implementation and perhaps also the future road map for M3.
Rereading my previous articles I realized that I generated a somewhat steep learning curve for using M3 with the complex examples provided, just because M3 can handle these complex scenarios.
However M3 was created in order to simplify things. I’m going to use an extremely simple example in the following article to explain the way M3 works this time, I promise!

Linux, Apache, MySQL and PHP — altogether they mean LAMP. I’m not talking about watts and bulbs.

And if you desire is for a comprehensive, robust server, your IT infrastructure has to include all of these systems.

Monitis has put together a checklist of 101 actions you can take to maximize security around LAMP.  Hopefully we’re shedding a little light around this issue for you to give you some new ideas on how to make administering your system easier — so that, in turn, you can focus on more strategic tasks. You can find previous posts about increasing security around Linux and Apache, but, in today’s post, we’ll offer tips on LAMP security around MySQL — a powerful open-source database.

Monitoring MongoDB is very similar to monitoring a normal relational database.  If it’s on its own machine then you need to care about things like how much CPU it’s taking up, how much RAM, how fast are the disks etc.   If Mongo starts grinding on any of your core compute resources then guess what, you’ve got a problem!

A good Database Administrator, which hopefully we all aspire to be, needs to monitor more then just the basics.  A good Database Administrator needs to monitor the actual database.  Not to mention in many cases especially with Mongo you will need to monitor a cluster of databases, not just one instance.  You’re in luck with Mongo, because fortunately the folks at 10gen, the makers of MongoDB, have written some excellent documentation for how to properly administer and performance tune MongoDB.