In a recent MonitoringForge advisory board e-mail thread Tara Spalding initiated
a discussion on ways to spark content contributions to MonitoringForge, specifically Wiki documentation. She was at LISA ‘09 and discussed with David Nalley of Fedora project what would be most valuable initial contributions. To cut the long story short the opinion coalesced over the idea to organize the Wiki in form of monitoring design recipes for individual services e.g. email monitoring design, web monitoring design etc. These design documents would cover both types of monitoring ie.

• Service availability/validation ie. e-mail service up and down, etc.
• Performance monitoring/trending

Within those individual areas we would start with simple/easy approaches and work our way up ie. most people will want to know how to monitor whether their e-mail server is up (usually easy to do) however may not need or want to monitor SMTP authentication. David Nalley did a great job of outlining a sample mail monitoring design recipe as follows:

*Mail
**SMTP
***Availability Monitoring
****Port 25 open
****Port 25 providing expected response
****MTA accepting mail
***Performance Monitoring
****Messages Received/time unit
****Messages Sent/time unit
****4xx errors /time unit
****5xx errors/time unit
****Length of time from successful send till message received by MDA
**IMAP
***Availability Monitoring
****blah blah
***Performance Monitoring
**** blah blah

Where things get tricky is that there are a number of monitoring tools so the question is how do we deal with describing individual implementations. Do we first describe concept in abstract then address individual monitoring tools implementations or is there are better way ?

We would like to get consensus whether the approach outlined is a good approach and are seeking input on how to make this process more effective and more useful.

Last week MonitoringForge had a booth at the LISA 2009 show.  On Thursday November 4th, Amy and I recruited new members and projects by handing out MonitoringForge t-shirts and introducing the site to the attendees.

We had a lot of fun and also held some interesting conversations.  Some of which will be launched into programs shortly.

We have some large t-shirts left, so if you’d like one, send us an idea that is about monitoring and beckons participation from the masses (like an open article on the best practices to monitor a web server or an email server) and become the spark for knowledge sharing in MonitoringForge!  We’ll send you a shirt for your thoughts and contributions!

A few people have asked MonitoringForge to create a “Job Board” so that organizations can connect with MonitoringForge participants who are looking for work.

We like the sounds of that idea - connecting people with needs, but want to get a feel for what kind of activity will really happen according to this request.

What’s your thoughts?  Would you like this site to have widgets that made it more like Linked In from a hiring/ skill management perspective?

Do you have some immediate needs to find work?  Or, find help?  If so - let’s start by having the community participate in the wiki.  We created a Jobs posting page - have at it.

http://monitoringforge.org/plugins/mwiki/index.php/Www/Jobs

And while you’re posting, let us know how practical this idea is.

Another milestone achieved! A big WELCOME to the 2,000th project - Monitorix.

It shows that MonitoringForge is a great place for Sys-admins and Network admins to find the newest tools to help manage their IT better.

The MonitoringForge staff is here to get your projects and plugins on the site.  Please ask for help if you need assistance, or don’t have the time to post the content.  MonitoringForge is designed so that project admins can either host files on the site OR post a description and redirect traffic to their existing communities.

Let’s get to 2,500 projects and plugins on the site next!

Greetings, MonitoringForge community! As was mentioned in today’s press release, we have started a project to WTFMM: Write the Flippin’ Monitoring Manual. We are inviting you to participate in the world’s largest documentation project focused on open source monitoring tools. This project is located within the MonitoringForge wiki.

To participate, register as a member. Once logged in, you can contribute copy or link to external areas that contain knowledge information about the following topics:

• How to use popular monitoring tools such as Zenoss, Hyperic HQ, GroundWork Monitor, MRTG, Nagios®* and more
• How to integrate monitoring tools with Puppet or other Open Source tools
• How to develop plugins on different platforms such as Zenoss, Nagios and Hyperic HQ
• How to build and customize platforms such as GroundWork Monitor and others

We would also love to have your war stories, case studies, and anything else of use to someone interested in deploying or developing with Open Source monitoring tools. As an added bonus, we included a jobs section for those seeking and offering work requiring experience with Open Source monitoring.

When we launched this site, we made a promise to be inclusive of all Open Source monitoring projects. Help us by adding your knowledge borne from experience with all Open Source monitoring software.

Organizing all of the tools that are quickly being placed on MonitoringForge is no small feat. We knew that the site taxonomy would be “passable” but a much better job is possible, and the community would come up with the answer.

Thanks to those who have submitted feedback so far, but, we need more insight - especially from end-users/ sys-admins/ network admins.

bernardli shared valuable plugin insight that there needs to be a top category that is the project.  mrhinkle shared a different approach that makes the organization driven by what needs to be monitored. What are your thoughts?

Few clarifications about how the site taxonomy works from an architected POV - choosing multiple categories (top levels) will be permitted, but at this time it’s not (the bug is being worked on).  Then, multiple sub-categories can be selected as well.

So the question is - what should be the top categories?  Then how to parse out the sub-categories?  Our original structure was based on SourceForge.net, which appears to not work for this community.

Please post your thoughts or contact us with feedback.  What can the top structure look like?  Options in bold

feature functionality

• Alerting
• availability monitoring
• cmdbs (?)
• connectors
• event monitoring
• HPC
• Interface
• network monitoring
• performance monitoring
• syslog monitoring

what are you monitoring…

• applications
• cloud
• clusters/ grids
• network
• servers
• synthetic polling
• VM

Architecture

• c/c++
• java
• php
• python

As MonitoringForge.org’s beta is now publicly announced and accessible, we’ve passed over 100 active members who have joined the ranks in a single day.

Also there’s been some great articles and mentions by the press today that evokes the chance for your direct input if this site is what you hoped it to be.  

Check out these reads in your spare time.

Brian Proffitt at Linux.com: MonitoringForge Opens New Gateway to Open Management Projects

Joe Panettieri at MSPmentor: GroundWork Launched Hub for Open Source Monitoring Developers

Sam Dean at ostatic: GroundWork Launches MonitoringForge.org for Monitoring Tools

Sean Michael Kerner at InternetNews.com: MonitoringForge launches for open source network monitoring

Technical Dig: GroundWork Open Source Launches MonitoringForge.org

Glyn Moody at ComputerWorld UK: Forging the Meta-Forge

We appreciate your input and honesty about the intentions and offerings.  Do share your comments publicly as transparency will only rise the bar for all of us.

Yesterday I spoke to two journalists about the MonitoringForge site.  The intentions and ambitions to present all open source monitoring options in a single location with a professional community working together was pretty well received.

What was interesting was the skepticism that commercial entities will participate, encouraging a shared community and ultimately development.  It’s commonly done amongst pure open source project developers, as it’s not hard to find a developer that has contributed to several projects. But historically, companies are less willing to participate in a similar accord.

The last few days we’ve been reaching out and formally inviting many companies to post their projects and pointing to their own development sites. And, I hope they do eventually as MonitoringForge is a rising tide that all open source monitoring projects and companies can benefit from - ultimately sinking proprietary alternatives.

It’s important to us that this site is kept in a good check and balance of what IT Administrators need to what open source project developers need - to make this a helpful community that accomplishes its goals, and thrives with participation on both fronts.

We’d like to organize an advisory board that would bestow its opionion and experience about some critical community elements that really drive the purpose of the site.

The advisory board would discuss and decide points about:

• The site governance, policies and participation
• Conflict identification and resolution
• Project and member recruitment
• Philanthropy and events support
• Advertising policies and programs

It is important that the advisory board consists of members who meet one of the following criteria:

- key developer or project lead for an open source project

- key contributor or spokesperson for a commercial open source project

- IT administrator power-user who is savvy with open source projects and website experiences

- spokesperson for open source communities that parallel MonitoringForge.org

If you are interested in participating in the advisory board, please contact me (tspalding@gwos.com) and let me know why you are interested in doing so, the participation angle you best represent and other past community experiences you have.