Suggestion about new field in Service Object

[Andreas Ericsson]

Billow Gao wrote:
> Yes, use a customized notify_email maybe the best solution.
> 
> Actually, we don't have so many servers now and just want to test the maxium
> services nagios can hold.
> 
> The result is not good.
> 
> Reloading is not a problem for some systems which doesn't change a lot.
> But in our situation, if we have 5000 servers, we may have to reload nagios
> many times in a day.
> Since every day, we have many new customers join or left. Also, customers
> may want to add new services,

So? Tell them the monitoring tool is restarted at 4pm every day. You 
won't be doing those configuration updates manually anyway, will you?

> change the notification email address and so on......

With a custom notification command you won't have to restart nagios for 
this.

> So how fast nagios can load the new configurations will be an issue in such
> situation.

Not if you cron it. Then you only have to check that it's up and running 
by half past four. Preferrably by using another cron-script that checks 
it and notifies you if it doesn't.

Also, the number of hash-buckets for contacts is very, very small. If 
you remove those contacts and use a custom notification script you'll 
get away with it.

> And that's why I am tying to let it run faster.
> 
> I can find a way to solve this problem and limit the reload times.
> 
> But I feel that the way nagios handle the configuration data is not good
> enough.
> 
> It should read the configuration files from some kind of databases in real
> time, if don't want to use sql, then cdb format like tinydns.
> So nagios administrator will just prepare some easy to understand
> configuration files, and use a program convert it to nagios's db format.
> Then, nagios will check the new configuration from time to time. If detected
> a change, then use the new configuration data...
> something like that.... So the nagios can be always up and don't need to
> reload/restart at all.
> 

This would require a complete rewrite of Nagios. As for reload/restart, 
nagios wouldn't be able to do any monitoring while it updates its 
configuration so while it wouldn't actually require a restart it would 
definitely be offline anyways, and definitely for a longer time if it's 
supposed to figure out just the bits that changed between the current 
running configuration and the new configuration and while it does that 
it will use huge amounts of memory.

> Actually, now nagios generate an object.cache files when it start/reload,
> but it's so in plain text format.
> The retention.dat is also in plain text format.....
> Why not use some kind of DB format so can create/read/update it faster and
> easier?
> 

Because plaintext files are easy to debug and easy to read, and many 
people appreciate that Nagios doesn't need a database to be able to run it.

You said in an earlier posting that you can patch it in a matter of 
hours (although I'm starting to doubt it since you seem more like the 
kind of person familiar to code through product sheets than actual 
source-files). Go ahead and deliver. I'll test it for you and if it's up 
to par I'll bang the patch on Ethans head until he accepts it.

-- 
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