Notes on ScopePort

A lot of well-grown and feature-rich remote monitoring solutions like Nagios, Zabbix or Cacti are out there but no company I ever worked in used one. What might be the reason for the low acceptance of remote monitoring in companies? It should be important for every company that the servers are running. Every minute of downtime annoys customers and administrators that might have to restart servers in the middle of the night. Wouldn’t it be better to be warned before something like this happens? Or at least be warned in the first minute of a downtime and not when you get an angry call of your customer or boss telling you about 404 errors and timeouts?

Whenever you think about the reasons of something that is missing in a business environment you will stumble over the same point: Costs. It takes time to set up a remote monitoring server. Working time costs money. But this is a task that only needs to be done once. The really expensive task is to set up the clients. These costs come with every new client. So every new client that gets monitored costs new money. The only way to reduce this costs is to reduce the time an administrator spends on settings up new monitored clients.

I think that a good remote monitoring system has very low running costs. You should be able to set up new clients in minutes and without reading manuals every time. Give an IP and Port, fire up the client and never think about it again.

Another point are annoying message floods. You should get warnings only when there is a real problem. So there is a need for well configurable notification methods and severity levels. You should be able to define who should get a message at what time of day/week/month/year in what case of error.

Very important is the avoidance of “single points of failure”. What happens if the connected database crashes or all threads get stuck? Who monitors the monitoring server? A good remote monitoring server should be cynical: It should be prepared to face multiple fails and still warn somebody then.

Comments are welcome!

• What is the first that comes in mind when you think about remote monitoring?
• What do you think is the biggest problem of current remote monitoring solutions?
• Do you think remote monitoring should follow a completely new concept?

This is the first post in this blog. It will inform you about the current state of ScopePort development.

Right now there is only one developer. Me. I am writing the Server itself (C++), the Linux and *BSD clients (C++), the Web Interface (PHP) and everything else related to ScopePort.

Current screenshots can be found on ScopePort.org: http://scopeport.org/see-it

Where I am right now

The following parts of ScopePort are ready to go into the next phase:

• Web Interface layout and structure
• Web Interface sections: User management, adding/deleting/updating service checks and hosts, notification groups, blacklist, service check details and overview, host overview and details, log, graphs.
• Server: Thread handling, client handling, service checks (with protocol checks), notifications in case of errors, fallback modes in case of failed database server, check for “dead” clients that stopped sending sensor data,
• Client: Sensors, profile sensors,

What needs to be done to reach a feature freeze?

• Web Interface install tool
• New features: “Global severity level”,  “public status” page and “user defined screens”
• General improvements in usability of the web interface
• More features that help you managing your servers. (Like the already completed features “Todo list” and “Detailed descriptions” that are available for every host)
• Packaging and correct GNU/Autotools usage for the server and client packages.
• remote.php API of the Web Interface that will be used by the ScopePort Console nCurses (which has no release plan yet)

What needs to be done to reach a public beta?

• Documentation
• Stability testing (especially checks for memory leaks)
• Security testing
• Testing of web interface in different browsers
• Checking for XHTML validity of web interface

Contact me if you are interested in joining development, beta testing or if you have questions.