ScopePort is searching for Rails developers
Posted by Lennart | Filed under ScopePort
ScopePort continues growing. We are going towards a first release to all those nice people who have announced their interest in ScopePort this year. A few weeks ago Ernesto Rocha joined the team. Welcome again! Ernesto is mostly developing the web interface: 100% Rails. I am still working on the server and the clients. (and also on the web interface)
We need all the help we can get now! If you just want to send some patches or join the team to be project member for a longer time: We need you!
All you need is experience with Rails and git. (Why git is better than X)
Please contact me if you are interested!
More information about ScopePort: http://www.scopeport.org/
Nasty bugs: std::logic_error because of NULL string
Posted by Lennart | Filed under Hacking, ScopePort
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;
}
};
Tags: bugs, c++, null, ScopePort, std::logic_error, string
New ScopePort feature: SMS Notifications
Posted by Lennart | Filed under Remote Monitoring, ScopePort
ScopPort SMS Notifications
Tags: mobile phone, notifications, page, ScopePort, sms
New ScopePort website online!
Posted by Lennart | Filed under ScopePort
The new ScopePort website is online now.
Let me know if there is anything you would change.
Tags: Ruby On Rails, ScopePort, website
Debbuging ScopePort service response time module
Posted by Lennart | Filed under Hacking, ScopePort
from my flickr.
Tags: code, debugging, eclipse, gnome, response time, ScopePort, screenshot, service, shell
ScopePort is now monitoring it’s own processes
Posted by Lennart | Filed under ScopePort
ScopePort process monitoring
Tags: Development, ScopePort
Current state of ScopePort development
Posted by Lennart | Filed under Hacking, ScopePort
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.
Tags: Development, Hacking, Remote Monitoring, ScopePort
