Part 1 – Building Better Monitoring for DotNetNuke Servers

6 December, 2012 CloudContent ManagementDotNetNukeHostingSecuritySoftwareStability

This is Part 1 of a 4-part series on the construction and implementation of our new server monitoring service … included with all our Business and Enterprise server plans.

– Tony Valenti

Why now?

For the past six years, an integral part of our DotNetNuke server offerings has been our Advanced Monitoring package.  Advanced Monitoring is designed to collect detailed information about your server so you know exactly how it is being utilized.  If it is over utilized or running slow,  the stats tell us why.  In addition to collecting stats and trends, an important feature of Advanced Monitoring is that it can send alerts to you and, when appropriate, to the PowerDNN support and infrastructure teams if something bad is happening – for example, if a rogue module is maxing out your CPU.

In the early years of Advanced Monitoring, we used an off-the-shelf product named OpManager.  It was a decent product, but we had some problems with it.  First, it was a Java / MySQL app.  It’s probably obvious that we’re a .NET / SQL Server environment.  Second, there was no API – meaning that every time a customer wanted advanced monitoring we had to set it up by hand.  There were also no templates – every customer had things set up differently.

For example, some customers may want to be alerted at 80% CPU utilization while others wanted 75% and yet others didn’t care at all.  And really, it never quite worked right.  Randomly, it might stop collecting stats from servers but it wouldn’t notify you of that.  The only way you knew was if you had an issue and didn’t get alerts. OpManager Screenshot

However, even with all of its faults, OpManager served us well for a number of years.  But in Q3 of 2012, I decided that it was time to look for a better solution.

What should be done?

Before I go any further, I think that it is important for you to know that I think it is important to know what you do best and to do everything in your power only to do that.  With us, we work really hard to be the most reliable, rock-solid hosting provider for DotNetNuke.  I’m a software developer by trade, many members of our support team are developers, and we have an internal development team that builds tools to make our lives and our customers’ lives easier. However, we’re not a software development company – we’re a hosting company.

Yoda - Do, or do not, there is no try

Do, or do not …

When we set out to implement a new monitoring solution, I wanted to make sure we did it right and, in my opinion, that involved making important decisions on whether to build or buy.  And if we did decide to build, what should be built and, more importantly, what should not.

In the next post I will discuss the path we selected, why it is a good starting foundation, and why we ultimately opted to build additional custom code onto that foundation.

– Read part 2 now. –