Nagios and DB support.
Scott Sanders
scott at bftwave.com
Wed Nov 17 21:36:22 CET 2004
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. 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. 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.
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
More information about the Users
mailing list