Suggestion about new field in Service Object

[Andreas Ericsson]

Billow Gao wrote:
> Hi there,
> 
> Since I want to use nagios on a large network with thousands of
> server/services, it's very slow for nagios to load thousands of objects.
> Is it possible that we can add a new field in Service Object, like:
> service_alias and then add a macro in it.
> With the new field, we can add some useful data in it and reduce the cfg's
> size.
> 

The size of the configuration isn't the issue (well, certainly not the 
size of the text-files anyway).

This idea with a macro would actually make Nagios load the configuration 
slower rather than faster, since it would have to interpolate the macro 
at load-time as well.

> For example: For notification, since most of our services are using the same
> format of notification, just different email address.
> There will be thousands of different email address. And we have to create a
> contact object and a contact group for every single email address.

A nagios installation with thousands of different email-addresses? Are 
you quite sure that there is, literally, thousands of people actually 
administrating your network? If so, you have much worse problems than 
Nagios taking half a day to load its configuration.

> It's really annoy and increase the cfg size a lot.
>>From our test, when nagios load a 20MB file, it will need more than 10
> minutes. 10K small cfg files, it will need 5 minutes. It's too slow.
> 
> If we add a new field and a new macro for a service/host object, we can just
> add the email address in it and then use the same contactgroup, contact
> object. And the notification command, will just use the email address from
> the new macro. So just one contact/contactgroup for thoursand of services.
> 
> Yes we know there is a serviceextinfo object which can do the job but it's
> still more than just one line.
> 

Well, since you're configuring thousands of lines already, I don't 
really see a problem. One of the thousands of admins should be able to 
hack up a script to load the config for you in no-time.

> 
> Also, the performance for nagios on a large network with thousand of
> services are not good.
> Loading cfg files is very slow. And nagios only use few of the server's
> resources with lots of tasks in pending.
> The load in the server is also 1.xx, never go to 2.xx, memory usage is very
> low.
> And nagios only launch 350 process at the same time and leave lots of server
> recourses unused.
> 

This is configurable. Read the docs. To launch one process per admin 
though you'll most likely have to hack the sources, since the maximum 
number of open filedescriptors at any one time is usually somewhere 
around 8192 on most unices.

> Maybe need to think about how to use more resouces to do more job on a
> dedicated server which only run nagios.
> 

Sounds like a good plan. If you and your 3000 network adminis are really 
serious about monitoring it shouldn't be too hard to persuade the 
management to get you a server to run it on. You'll ofcourse have to 
hire four more people to administer the new server, but that'd be like a 
piss in mississippi compared to the current size of your IT department. 
The good part is that with a successful deployment you'll be able to 
fire round about 97% of the staff, so that'll make your configuration 
load a bit faster too.

Out of curiosity, just how many admins are you?

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
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