Why we started Drupalmonitor.com?
As a Drupal agency (www.netnode.ch) for years, we create a lot of Drupal websites. As a part of a development deal, we also take care of the maintenance of the website. This includes module updates, drupal core update, extend Drupal sites with new client wishes, lead generation monitoring, performance improvements etc.
Evolution
Years ago, we started to create a custommade intranet (based on Drupal 5) to manage our projects. One part of it was the documentation of the Drupal configuration. Over the years, our intranet as well as the website we created and maintain came somewhat closer. We started to gather "live information" about module status, node count, user count, not only for one website but all of the website. It's just a part of the routine to connect client projects with our intranet. We also use munin to monitor our webservers e.g. serverload, mysql stats, network stats, etc. Some months ago, we started to thought about using munin to monitor Drupal internals - drupalmonitor.com was born - RRD styled Drupal montioring... damn, this idea is just genious, we thought.
Existing solutions
Before we started, we checked the current market. Why should we create a new tool, if there are existing solutions available. Our criterias were:
- Quick installation
- Monitoring of Drupal internals
- Solution for lot's of Drupal sites
- No additional server side installations needed (just a module + a service)
- Reasonable price
We couldn't find a solution that worked for us. Here is what we've found:
- http://www.droptor.com
- http://acquia.com/products-services/acquia-network with New Relic
- Custom solution based on existing monitoring tools like Munin, Cacti, Nagios
- Custom homebrewed solution
We think it's an interesting opportunity to provide a Drupal monitoring service today. We can combine our long term experience to provide a unique, easy to use service to monitor Drupal.