C. Bensend wrote:
>> C. Bensend wrote:
>>> Hey folks,
>>>
>>> I'm in the process of designing a system to integrate our
>>> existing systems database and Nagios. It will query our database,
>>> stuff the results into an interim database, that I will use to
>>> build a Nagios config.
>>>
>>> However, I'd appreciate any suggestions on how to handle users
>>> with different time zones. We have a number of admins that will be
>>> accessing this from many areas, including the US zones and India.
>>>
>>> I realize this is borderline relevant, but I'm sure some of you
>>> have had to deal with this in the past. How do you do it? I'm
>>> trying to avoid having times displayed in a single time zone and
>>> having the local admins do time calculations and offsets just to
>>> get their systems monitored. I REALLY don't want to have a Nagios
>>> server in each time zone if I can in any way avoid it.
>>>
>>> I'd also be open to any third-party front ends that may handle
>>> this more gracefully than I might. :) As of right now, I'm using
>>> PHP and PostgreSQL, and will be building the config files with
>>> perl.
>>>
>> What's the main issue? Timeperiods with india-workhours and so on
>> should work nicely for both *check_period and *notification_period,
>> shouldn't it? Since you'd probably want templates to up timeouts
>> and stuff when checking the really remote things anyway, I'm thinking
>> it won't be much of a chore.
>
> Functionally, I don't have any real huge issues. I can get it
> done.
>
> What I'm unsure of, is how much the presentation of the data
> will confuse the remote guys. Everyone will *presume* the
> numbers and times they're seeing are in their local time, and
> that might present some confusion. This can be handled somewhat
> with education and clearly-written help, but it will still be
> an issue.
>
> And since this is likely a common thing for people that do this
> type of thing globally, I thought I'd ask to see how others are
> handling it.
>
Ah. If it weren't for the fact that the C-based cgi's are going
away, I'd suggest creating tz-aware wrapper functions around
all the time-displaying commands, or perhaps just trying to get
the tz from the browser. I'm unfamiliar with such things, but I
assume most modern browsers somehow communicate their timezone
information to the server when connecting.
That's still an option, ofcourse, but you might be better off
waiting for the next gui to come along. ymmv.
--
Andreas Ericsson andreas.ericsson@...
OP5 AB http://www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
|
