Welcome to the Open-Source Server Monitor Project created by BurnSoft.net. This application was initially designed to monitor our internal servers, after designing it, we started to use it to monitor more then just servers. The flat client admin GUI will allow you to create your own types to categorize the device that you wish to monitor. Since this application just pings the device DNS name or IP Address it didn’t matter if it was a server or not so it’s really more of a network Device Monitor. Why is this application free and open source considering everything else I find on the web is something you have to pay for just to ping a device. Well since we did publish the source code, it is free for you to change and compile as you like. We used Visual Studio 2005 for this application to start and Upgraded it to Visual Studio 2010 using .Net 4.0. Eventually we will upgrade it to the latest Visual Studio version. Secondly, if you have any questions you can email us and we will answer you questions as best we can. But there is no phone support or remote desktop service with our OpenSource application. Also it is not one of the easiest installs that we have considering it depends on MySQL being installed on the server the is going to be considered the Master Server. The collectors (if you choose to use them ) is a small client that will insert the results into the database. You don’t have to use a collector for a small environment but if you are pinging over 100 servers, you might want to consider putting collectors out there.
The Open-Source Server Monitor ( OSSM ) application was created by Joe Mireles to monitor the internal server farm for connectivity monitoring. Granted there are a lot of ping monitors out there, but some cost an insane amount or might not fit large scale operations. Granted BurnsSoft is not even close to large scale, but the thought was put into the ability of covering large scale environments.
The OSSM was created in Visual Basic.Net v2 using a MySQL Database as the backend DB solution. The OSSM also used NMAP to be able to gather trace data and port scan results. This was to be used later on in future version for port checking and the trace data was to be used to determine where the outage occurred. With Have two external vendors added into the project, it was decided that it would be best to release it as an open source system, allowing others to download the source and modify it to hit their needs.
I’m sure you are asking yourself “How was this created for a large scale environment?”. Some of the other ping monitoring system originate from the main server that host the application, as this application can do on a small scale environment. However, if you attempted to run the main application on the server with 1800 devices to ping every 15 minutes, this can cause performance issues on the application host. So to mitigate that issue we created the ability to deploy Collectors. These Collectors can be on their own machine or an existing machine. You add the Machine name in the main console, then install the software on that machine. After the installation you run the Configuration program to set the Collector ID, the Database Hostname, and what you want that collector to do ( ping every x minutes, run port & trace scans, Process scan results at a certain time, etc.). If you have existing devices in the GUI that are on the main host, you can transfer them to a Collector. If you have 4 collectors, you can set them to Load Balance in the GUI and when you add a server it will automatically add it to the collector with the least amount of clients.
What about if a collector died or was disconnected from the network? That was also take into consideration as well. The Main Server will check to see if the client has not reported back in x many minutes ( x being the number of minutes that the server starts it ping) times the number you set in configuration. So lets say you have it set to ping every 15 minutes, and you set the configuration threshold to 3. So the Collector fail alert will occur if it has not reported back in 45 minutes, ( 15 x 3) so after 45 minutes all the clients that where on that collector will be transferred the the master server, and the master server will start pinging those hosts. Once you get the issues with that collector resolved and the “last update” field is updated, it will return those clients to the collector that they belong to.
So it can load balance on a large scale, what makes this any different then the other pingers? Well, then you enter in the device DNS Name to ping, it will grab the IP Address for that DNS entry ( yes you can use the IP Address instead of the DNS Name ). When the device is pinged it will ping the DNS name and compare the IP Address that is pulled back, if that IP Address is different then what is in the Database, it will throw an Warning alert stating that the IP Address has changed. During the Ping cycle, a Device is pinged 10 times, if the ping if 3 or less of 10 ok, then it will send a Warning Alert saying that the device is slow. If all 10 fail it will double check by pinging the IP Address, if that fails as well it will Throw an Error Alert.
Most of the ping results are kept for a day by default ( can be changed ), but most of the results are averaged out for a daily count, then monthly, and year counts for reporting. in the GUI you are able to see the average result of uptime for daily and monthly.
The GUI Application comes in two versions, Master and Read-Only. The Read-Only is like the master accept that you are not able to delete, disable or add anything, it’s mostly used to make people aware of issues, while the master allow you to administer the application. A light read Only web console is also included in the source for those that do not want to install the flat clients.
There are still plans to grow the OSSM to give it the ability to perform and alert on port scans, smarter ping diagnostics, and even web page monitoring ( page up, content ok, etc ). The OSSM has been tested and running in a large environment since 2009 with a max of 2000 devices across the world with 4 collectors and one master server. So a lot of the theory that went into this application has been tested. More to come later in the future and the source will still be available for everyone to see and modify to fit their own needs.
It was decided to retire this application in the meantime since there has not been any work on it in a few years and a lot of the features can be handled by PandoraFMS comunity edition. This code will stil lbe available to anyone that still wishes to use it, but in the mean time, there will no be any additional code added to the project.