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.

A guest blog post from Alexander Podelko, a performance expert currently working for Oracle:

A Few Thoughts about APM and Its Future

APM is a vague term. There is no agreement even on what it stands for: Application Performance Monitoring or Application Performance Management. Some background information can be found here Industry Watch: Behind the APM and DevOps buzzwords. If I had to define the terms, I’d say that the term Application Performance Monitoring befits the existing products on the market whereas Application Performance Management is more akin to what the industry wants and needs as it promises so much more than is currently available.

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.

Website visitors have a low attention span. We’ve mentioned many times how crucial it is not to let page load times exceed 2-3 seconds. This was demonstrated by a test done at Amazon which showed that every 100ms increase in load time resulted in a 1% drop in sales. With Amazon’s annual turnover close to $50B, that would result in lost sales of $5B if the site took just 1 second longer to load.

We analyzed our own website, which is based on Joomla Content Management System, and our blog, based on WordPress. We found that even from monitoring locations closest to our servers, there’s a 100ms wait to get first byte. That may sound reasonable, but if the browser is making multiple requests to your website (for media files or javascript, etc.) it reduces full page load times significantly.

To read the Zen of Python, type import this in your Python interpreter. A sharp reader new to Python will notice the word “interpreter”, and realize that Python is another scripting language. “It must be slow!”

No question about it: Python program does not run as fast or efficiently as compiled languages. Even Python advocates will tell you performance is the area that Python is not good for. However, YouTube has proven Python is capable of serving 40 million videos per hour. All you have to do is writing efficient code and seek external (C/C++) implementation for speed if needed. Here are the tips to help you become a better Python developer:

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.

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!

A lot of bloggers and technologists like to talk about Ruby as if it can’t perform on-par with other dynamic/interpreted programming languages; however, these critics tend to rely on specific benchmarking techniques and ignore the overall performance profile of the language.  They also tend not to take into consideration the various factors of their choice of libraries and application architecture before blasting Ruby as being non-performant.

Ruby’s various versions and implementations have different performance profiles also and this must be taken into consideration before a decision can be made definitively about Ruby’s overall performance.  Benchmarking is a flawed means of determining the real performance of a tool because it relies too heavily on the system configuration on which the tests are ran and what activity is occurring on the system during test runs.