Suggestion about new field in Service Object
Andreas Ericsson
ae at op5.se
Thu Oct 20 20:08:23 CEST 2005
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
More information about the Users
mailing list