Other (open-source) monitorring software

[linux-guru]

Have a look at Zabbix (www.zabbix.com). I used this before I knew Pandora and were nearly happy with it.
Especially graphing is something they do very well.
The main disadvantage if compared with Pandora is that they use rrdtool (which of course makes better graphs than Pandora does at the moment). If you use a weak machine for monitoring and collect lots of data over a time of about more than 2 months, everything get very slow and the database grows extremely.
Maybe some gets some good ideas from Zabbix which can flow into Pandora...
If wished I can give more details since I used Zabbix for a certain time.

Cheers

linux-guru

[admin]

I have evaluated several monitoring solutions recently including Zabbix and ZenOSS.

I do not think using RRD is a problem with these systems. Nor is it a silver bullet which solves all problems. What Tobias did was very simply force people into something that is good practice, but what you can do with any database system. Archive or drop old data, and do some pre-calculation for speeding reporting.

What is a problem though is that both Zabbix and ZenOSS lack flexibility in terms of what they monitor and how. They work well for systems where you have boxes (PCs/servers) all running either your agent or SNMP over accessible networks in a monolithic server/agent architecture. If you want something else, expect trouble.

For the more complex then, Nagios and Pandora seems better. They have less silly design decissions hampering them. I have extensive experience with Nagios, which though ugly, works. Pandora architecture seems elegant and powerful by comparison. Nagios/Netsaint came a long way with all the disadvantages associated with that. They cobbled a lot more features on over time and it shows. It is still in my mind the monitoring flagship of opensource though.

HTH

[Sancho Lerena]

Your comparation it's very interesting. I just start with Pandora because the same reasons you have mentioned.

Pandora 1.x series core server was coded in Perl, but for next series, Pandora 2.x, will be coded in C++, this will be a almost rewrite of all server code, because for me, all "problems" we have now are related to PERL difficulties with debugging process and leaks in some external modules (we resolved almost all of them, but they was a pain in the ass for many months).
PERL was a nice enviroment to make a very quick development, and permits to implement many ideas. So, the next versions of Pandora will be more robust, efficient, and _VERY_ important, much more extensible, because we implement a modular system for making different things in the core (Server), coding Pandora will be easy because we are moving to a full GNU standard standards (autotools, docBook, Doxygen, SVN, etc).

We need people testing Pandora, running it and talking about it (and of course coding!!). Please tell us problems, suggerences and ideas.

Thanks for your comments.

[anonymous]

I have been busy installing and playing with Pandora.

Strangely I have though about exactly the same modular approach while playing with the current version. Modular components will be really good, especially if you can have them automatically add management interfaces to the web console.

The other things which are very important, at least to me, are snmp support for polling remote devices, and dependencies in the monitored items.

HTH