Nagios and DB support.

[Andreas Ericsson]

Scott Sanders wrote:
> Andreas,
> 
> Thanks for taking the time to respond so thoroughly. What you have said 
> has really helped me understand the objectives nagios wants to obtain. I 
> applaud you for sticking so diligantly to "digital" service checks. 
> However, speaking from an IT directors perspective, this is only a small 
> piece of networking monitoring. I hope the development team here decides 
> that they would like their product to better serve the needs of us who 
> have grown to enjoy using it. If changing the storage mechanism requires 
> such a monumental change to the source code, I now wonder what other 
> changes will be refused because of the time needed to upgrade the 
> source.

It won't. If noone else does it, I'll hack up a NEB-module to do IPC 
using sockets and then add the advanced storage mechanisms there. The 
main problem is that the presentation layer (cgi's) is written in C. 
This is supposed to change pretty soon, but until it actually does 
(officially) the code change really is monumental.

> Furthermore, at some point people will demand  the ability to
> interface nagios with their own file systems  and databases, and it seems
> you will be up the creek without a paddle.

I don't know how you came to the conclusion that the file system support 
is in Nagios. It is in fact in the kernel. As for databases, that will 
be resolved, as stated above, by socket IPC from a NEB-module to any 
separate socket-handling program/script/host that is willing, which will 
enable a lot more users to write their own code for storage. I expect it 
won't be long until mysql and postgresql storage options are back by 
then, but it will also need an upgrade of the presentation layer, as 
I've already told you.

> Perhaps nagios 3 (2 is still 
> alpha, right?) will integrate more effectively with the other products I 
> use, until then I will be looking for other solutions, and continue 
> hacking nagios support.
> 

That will also depend greatly on any other products you use. If they're 
terribly difficult to integrate I don't think it will be done solely by 
Nagios.

> Scott Sanders
> 
> P.S. Ben, I would glad to help with NEB module, at least for the time 
> being.
> 
> Andreas Ericsson wrote:
> 
>> Scott Sanders wrote:
>>
>>> Ben wrote:
>>>
>>>> Well, you must do what you feel is right, of course, but....
>>>>
>>>> Any solution you come up with would probably include alerting, and I've
>>>> found that Nagios is excellent at alerting. It's not so hot at running
>>>> historical reports or making trend reports, but I've got two things 
>>>> to say
>>>> about that. First, nagios can gather its metrics from your historical
>>>> trending tools, so you get both. Second, nagios 2 has NEB modules, 
>>>> which
>>>> you can use to send data to your historical trending tools, so you 
>>>> can get both going the other way too. It's flexible.
>>>>  
>>>>
>>> Sure, and this is probably what I will end up having to do for the time
>>> being. Don't get me wrong, I think nagios is great, it just seems that
>>> version 2 will hanicap it more than anything else. The flexibility
>>> should extend beyond just allowing you define custom checks and custom
>>> notify-by's. I would like to be flexible in how I store this data too.
>>
>>
>>
>> So write a NEB module. There are examples, and I'm sure Ben would be 
>> delighted to have someone help him with his project.
>>
>>> Heres an idea; leave the storage and logging functions seperate. Treat
>>> this backside of nagios like a module also, so we aren't forced to save
>>> everything in files and can write our own storage methods.
>>>
>>
>> This has been suggested and rejected before (by me actually). I 
>> believe that was mostly due to the fact that it is a rather major 
>> change in the code without any real value without even more code.
>>
>>>> Personally, I don't think it makes sense to have one tool that does
>>>> everything. The concept of small tools that do their job well and can
>>>> interact with other tools is what gives unix so much of its power, 
>>>> and I
>>>> don't see any reason to stop applying that concept when it comes to
>>>> monitoring, alerting, or trend analysis.
>>>>  
>>>>
>>> I couldn't agree more. Small tools also have the big advantage of being
>>> able to be upgraded independently. But as it currently is, all nagios
>>> does is collect data from a number of tools through its check functions
>>> and report them with other tools (read qpage, etc.).
>>
>>
>>
>> Have you even looked at the GUI part of Nagios?
>>
>>> The config files,
>>> escalations,  and the ability to group hosts/services/contacts, etc. are
>>> what makes nagios so powerful. I don't want to get away from using
>>> smaller tools, I just want a better way to manage everything. If someone
>>> made a php frontend that incorperated nagios, cacti, ntop, and snort it
>>> would be a huge benefit to the IT community.
>>
>>
>>
>> Apart from snort, that's exactly what we have done. Our customers seem 
>> very happy with it.
>>
>>> However, I think nagios can
>>> do all of this itself with only minor changes, so why not continue to
>>> expand nagios until it meats everyones needs?
>>>
>>
>> Because of the flexibility of the plugins. I've said this before; 
>> Digital checks aren't made for graphing, but they're crucial for 
>> network monitoring. This means you'd have to add extra variables just 
>> to decide which to graph, and then you'd have to standardize plugin 
>> output. I suggest you read up on perfparse and other Nagios add-ons 
>> for graphing, as it already does this (to some extent).
>>
>> If you want native graphing ability that bad, I suggest you sit down 
>> and write a patch for Nagios. Ethan almost always commits a good 
>> written patch that does something a lot of users want. This is also 
>> what opensource is all about; Giving users the option to make 
>> additions and have those included in future releases.
>>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when 
> reporting any issue. ::: Messages without supporting info will risk 
> being sent to /dev/null
> 

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null