PolyMon is an open source agentless monitoring application written in the .Net Framework, and available, with source on CodePlex. It is designed as a client/service/server architecture, consisting of a WinForms management application, Windows Service monitoring engine, and uses SQL 2005 for it’s data store. I have written about Polymon before in my post about Network Monitoring, so you should check that out for some more details. I will re-iterate the available monitors here.
- CPU
- Disk
- File (Age and Counts)
- Windows Performance Counters
- Ping
- PowerShell Scripting
- SQL Monitor via Stored Procedures
- SNMP
- TCP Port
- URL
- Windows Service Monitor
- WMI Monitor
I set this up at home, with limited success, and at work (to monitor dev and test instances) with better success. The only difference between the 2 installs is I’m using integrated authentication at home, and SQL authentication at work. I’ve noticed some other issues with domain authentication at home, so I feel that it’s an AD issue at this point, and not a problem with Polymon, although there may be the opportunity for more robust error logging in Polymon if this turns out to be the case.
I setup Ping and SQL monitors based on our production monitoring system at work, and only had to monitor the SQL monitors slightly to support Polymon, which requires two output parameters defined in the stored procedures. I wanted to setup the WMI and Powershell monitors in place of some of the custom SQL monitors, but didn’t have the time. I’ve added some links at the bottom to BizTalk Powershell resources for future reference.
Pros:
- Free and Open Source
- Actively Developed with a road map that makes sense
- Extensible without modifying the core application
- Little need to extend given the excellent coverage provided by the default monitors, especially PowerShell
- Runs on SQL 2005, so you get all of the benefits of SQL 2005, plus you could write custom reports in Reporting Services and have those emailed.
- Monitor not just uptime, but other stats as well. For example, response times are logged, and the SQL monitor supports returning
Cons:
- Monitoring Engine is not multi-threaded – If you had 61 monitors set to run every minute, and they all took 1 second, you would start to see lag. This is a know limitation and can be worked around by not having that many monitors set to run that often. It is on the development roadmap for the project, and is going to be addressed in two ways. The first is to multi-thread the monitor engine, which will allow scale-up. However, any good developer would know that just multi-threading is not the end all solution, and you could run into additional limitations as a result of running multiple threads. Therefore, the second part is to allow monitoring engines installed on separate computers, to run off the same database, effectively adding scale-out capabilities. Another possible benefit to this, is it would allow you to install the service on the servers you want to monitor and not have to deal with as much security. However, this would be the same as a monitoring application that requires an agent.
- Database can grow large very quickly, which can also slow performance. You need to use some common sense, set appropriate retention policy, and possibly re-index to meet your individual needs.
- No web interface. I actually like the WinForm application, but can also see were a web app would have it’s advantages. There is a plan to replace the WinForm application with a Web Application. I’d like to see both, but can understand limited resources.
- No Operator Groups – Operators are defined individually. However, if you have a distribution list setup, it makes it a little easier.
- Only Email Alerts
- No email of reports that I can see, however, this could be considered a Pro, as you could use SQL Reporting Services to make your own reports
- Remote connections for monitors represent administrative and security considerations. For example, you need port 1433 open to make remote sql connections, WMI does not look very administrator friendly for remote connections, and the same would apply to WMI thru power shell. This is a limitation of the technologies themselves, and not Polymon, but worth pointing out.
Links