Notes on ScopePort

Lennart just pushed a new rake task to master: graphfactory[:all|:hosts|:services]

Use it to generate all graphs at once – It is highly recommended  to use this task as a cronjob to avoid extremely long page generation times of host and service detail views.

Sample output:

$ rake graphfactory:all
=== Service 'Google' ===
Last stored value is from Sun Feb 07 01:29:51 +0100 2010
Inserting 240 values into RRD...
=== Service 'ScopePort SMTP' ===
Last stored value is from Sun Feb 07 01:29:36 +0100 2010
Inserting 36 values into RRD...
=== Service 'ScopePort SSH' ===
Last stored value is from Sun Feb 07 01:30:47 +0100 2010
Inserting 22 values into RRD...
=== Host 'scopeport.org' ===
 	== Graph: cpuload ==
	Last stored value is from Sat Jan 23 22:16:28 +0100 2010
	Inserting 13038 values into RRD...
 	== Graph: disk-read-ops ==
	Last stored value is from Fri Dec 04 03:39:41 +0100 2009
	Inserting 4347 values into RRD...
 	== Graph: disk-write-ops ==
	Last stored value is from Fri Dec 04 03:39:41 +0100 2009
	Inserting 4347 values into RRD...
 	== Graph: free-memory ==
	Last stored value is from Sat Jan 23 22:19:28 +0100 2010
	Inserting 4347 values into RRD...
 	== Graph: open-files ==
	Last stored value is from Sat Jan 23 22:19:28 +0100 2010
	Inserting 4346 values into RRD...
 	== Graph: processes ==
	Last stored value is from Sat Jan 23 22:18:28 +0100 2010
	Inserting 4347 values into RRD...

I am happy to announce the release of ScopePort version 0.3-dev. There is no packaged version, because this is still a pre-alpha development release. A lot of people already successfully installed ScopePort on their systems and had no problems so far. Use the installation guides to install ScopePort directly from out git repositories. Note that ScopePort is not yet feature complete as planned for the first real release. I am still working a lot on the whole system.

A few screenshots of the current state of the host monitoring parts:

Host details I

Host details II

Host details III

Defining sensor conditions for a host

High availability/Clustering configuration

Some replies of ScopePort users I am very happy about:

Cheers, it looks great, can’t wait to deploy it myself

WOW! Very slick, easy to navigate, great colors, very professional looking app

Clear and professional web interface! very nice work! Did you do all the CSS working as well? very cool one. I can’t wait to test the server side and see how much customized alerts that I can setup. Plus the graph looks very good

I like to know when the app is ready for beta testing, we have looked at allot of apps, yours has allot of potential to meet our needs.

I just wanted to say that the ScopePort project is looking great.

This is what you get immediately after somebody declared an emergency and selected a notification group you are a member of:

Email notification

XMPP/Jabber notification

SMS notification

The emergency view in the web interface

Sven Kinne – who has been involved in a lot of alpha testing – just sent me an account for his ScopePort installation. He monitors around 50 services on different hosts. Here is a screenshot:

We are always happy about screnshots of your ScopePort installations! Send them to lennart@scopeport.org.

I recently changed the Warning::getConditions() method of ScopePort. It now takes two parameters:

• string hostid – The ID of the host on which the sensor to check is running
• string st – The ID of the sensor to check.

I started up ScopePort and got the following error after about 2-3 minutes:

terminate called after throwing an instance of ’std::logic_error’
what():  basic_string::_S_construct NULL not valid

Because of the time delay I searched for the error in the recently changed Warning::getConditions() method. I expected that an usual alarm was causing something to fail. But as my investigations went on I noticed that the time delay was exactly 180 seconds. Each time. So I thought about it and remembered that the onlineStateChecks() thread was going into full operations after 180 seconds (That is to give the clients time to send data.). I quickly found out where the error was caused: Just at the time of the Warning::getConditions() method call. The debugger didn’t even let me step into the method. It failed right at the method call. As it was pretty late and I had to get up early the next day I went to sleep and planned to ask a friend the next day.

The next morning. At the time I was explaining my Problem to the friend I already found the error. (Sometimes it is really better to go to bed…): When I updated the onlineStateChecks and clientHandler() threads to use the new method I made a mistake: I used the wrong column of the database result. This ended in 0 as second parameter. Exactly. Not “0″ but 0.

My friend explained me that the compiler was not complaining because he just accepted the 0 as a NULL string. I didn’t even look for wrong parameter types because I thought the compiler wouldn’t even think about compiling 0 as string. Lesson learnt. Thank you.

Here is a little example program that reproduces the error:

#include "TestClass.h"
using namespace std;

int main(){
    TestClass test;
    test.testMe("foo", 0);
    return 0;
}

class TestClass {
     public:
         void testMe(string foo, string bar){
              return;
         }
};

The new ScopePort website is online now.

Let me know if there is anything you would change.

from my flickr.