timezone adjustments for nagios 3

[Andreas Ericsson]

Grant Byers wrote:
> Hi Andreas, List,
> 
> Sorry about the delayed response, we were testing the multiple nagios server
> implementation you recommended. See comments below.
> 
> Regards,
> Grant
> 
>> On 10/23/07, Andreas Ericsson <ae at op5.se> wrote:
>>> Grant Byers wrote:
>>> Hi all,
>>>
>>> Does anyone have opinions on timezone adjustments per host or service?
>>>
> 
>> I do. Don't do it. It will lead to no end of confusion if states appear to
>> happen at different times when they are, in fact, nearly simultanous. If
>> the timezone directive is for the benefit of the branch offices, you
> should
>> simply set up a nagios server at each of those locations and have them
>> forward their check-results to the 'master' server.
> 
> Our business doesn't fit with the "branch office" model. We have a support
> relationship with many clients, but those clients do not have the same
> relationship with each other. Each client may have as many as 8 unique Unix
> systems which require monitoring and it is just not feasible to setup a
> nagios server on each of those systems.


Not one nagios at each system. Just one server in each timezone.


> Whilst each client may have some
> checks that are unique to them, there is a large sub-set of checks that are
> common across all clients, all servers. Each time we identify an issue with
> one of our checks, this would need to be fixed then pushed out to all
> clients. Each time the timeperiod for a common check changes, this needs to
> be manually configured on all clients, all servers. etc. etc.
> 
> It does make make sense however to run multiple nagios instances on our own
> systems, each initiating checks on our clients servers. We do this this via
> ssh. For this to work though, we don't want to have a seperate server
> (physical or virtual) for each nagios instance. What we'd like to see is the
> ability to run multiple nagios servers on the same Unix server, each running
> in a different timezone, each having their own timeperiods, services etc.,


This can be done, with the exception of the timezone option. I'm sure you could
hack up something to re-write the timeperiods to match the target tz though,
which would be a lot easier.


> but sharing as much "common" configuration with the master server as
> possible. This would include host/service templates, commands etc. We tried
> to do this by setting our server to run in UTC, then setting the "TZ"
> environment variable to the desired timezone we wanted that nagios instance
> to run in. This did not work, since nagios doesn't appear to have any
> concept of timezone offsets.
> 
> 
>>> We are wanting to replace our current in-house monitoring with nagios,
> but
>>> our single monitoring system pushes thousands of checks out to sites in
> half
>>> a dozen different timezones every hour. Some of these checks are
> timezone
>>> sensitive, whilst others aren't.
>>>
> 
>> Can you explain what you mean by "timezone sensitive"?
> 
> Yep. Some of our checks need to run in the timezone of the remote server,
> yet other checks scheduled for the same remote server need to run in our
> local timezone.
> 

You mean the timeperiods must take timezone offsets into calculation so that
the same timeperiod means different things in different timezones?

If I were you, I'd implement that either as a timeperiod rewriter that
launches before Nagios is started, or in the timeperiod parsing code in the
core. Touch as few places as possible, iow.

-- 
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: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/