Saturday, May 18th 2013, 5:57pm UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to Monitoring-Portal.
Although this is a german monitoring forum, please don't hesitate to post in English. Nearly everybody here understands you and will answer in English as well.
If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form to register here or read more information about the registration process. If you are already registered, please login here.

reb

Beginner

Posts: 10

Location: Hamburg

Number of monitoring servers: 3

Nagios Version: none

Icinga Version: Icinga-1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: 140

Number of services: 1200

OS: Linux

Plugin Version: ?

NDO Version: 2

Other Addons: PNP4Nagios, Thruk, MK Livestatus

1

Friday, June 8th 2012, 8:46am

Distributed Monitoring in verschiedenen Zeitzonen

Moin,

wir haben die Tage in unserem Distributed Setup den ersten Monitor in einer anderen Zeitzone installiert und sind jetzt über die Timeperiods gestolpert, welche je nach Zeitzone wohl unterschiedlich interpretiert werden.

Im Web habe ich nicht wirklich etwas zum Thema gefunden. Ausser die Zeitzone in welche der Zentrale Monitor läuft auch auf die anderen Monitore zu übertragen (via icinga.cfg#use_timezone).

Hat hier wer ein ähnliches Setup laufen und eine Lösung dafür gefunden?

Gruß
Ralf

dnsmichi

Super Moderator

Posts: 5,976

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.0 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.0 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

2

Friday, June 8th 2012, 1:36pm

kannst du das mit einigen beispielen und logs illustrieren?
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

lausser

Professional

Posts: 1,459

Gender: male

Location: München

Occupation: Informatiker

Number of monitoring servers: 1

Nagios Version: 3.2.0

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 2000

Number of services: 50000

OS: Linux/SLES11, CentOS5.5

Plugin Version: 1.4.14

NDO Version: 1.4b7

Other Addons: PNP,mod_gearman,OMD,coshsh

3

Friday, June 8th 2012, 1:46pm

RE: Distributed Monitoring in verschiedenen Zeitzonen


Hat hier wer ein ähnliches Setup laufen und eine Lösung dafür gefunden?

Shinken :)
Hier kannst du am Remote-Standort einen Scheduler und einen Poller laufen lassen und ihnen in der shinken-specific.cfg jeweils eine individuelle Zeitzone verpassen.

Source code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
define scheduler{
    scheduler_name   scheduler-main
    address          localhost
    port             7768
    modules          PickleRetention
}
....
define scheduler{
    scheduler_name   scheduler-remote1
    address          remote1.remote.de
    port             7768
    modules          PickleRetention
    use_timezone  Asia/Shanghai
    realm asia
}
define poller{
    poller_name      poller-remote1
    address          remote1.remote.de
    port             7771
    use_timezone  Asia/Shanghai
    realm asia
}
....


In den Host/Servicedefinitionen musst du noch "realm asia" angeben, dann richten sich check_period und notification_period nach der lokalen Zeit.

Gerhard

reb

Beginner

Posts: 10

Location: Hamburg

Number of monitoring servers: 3

Nagios Version: none

Icinga Version: Icinga-1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: 140

Number of services: 1200

OS: Linux

Plugin Version: ?

NDO Version: 2

Other Addons: PNP4Nagios, Thruk, MK Livestatus

4

Tuesday, June 19th 2012, 11:53am

Hi,
kannst du das mit einigen beispielen und logs illustrieren?
jein. Folgende Überlegung steckt dahinter:
- für alle passiven Checks (der Monitor-only Instanzen) ist 'check_freshness' enabled
- die Icinga Hosts laufen in ihrer jeweilgen Zeitzone (hier PDT & CET)
- für Drucker in der PDT-Zeitzone ist eine Timeperiod von 9:00-16:00 Uhr definiert (in der die Drucker eingeschaltet sind)
- alle Icinga Hosts verwenden diese Definition der Timeperiod

Ich denke mir daher, dass die Icinga Hosts zu unterschiedlichen Zeiten die Checks durchführen bzw. passive Results erwarten.

Jetzt kann ich, wie zuvor erwähnt den PDT-Icinga Host via 'use_timezone' auf CET umbiegen und muss mir weiter keine Gedanken machen - die Checks laufen dann aber überwiegend, wenn in der PDT-Zeitzone Nacht ist.

Für die PDT-Zeitzone könnte ich natürlich die Zeiten entsprechend umrechen und in CET definieren. Also, Checks sollen in der PDT-Zeitzone von 9:00 bis 16:00 Uhr laufen - das wäre in CET umgerechnet: 18:00 bis 01:00. Muss diese Umrechnung aber entsprechend der Sommer-/Winterzeit anpassen.

Noch spannender wird es, wenn in der PDT-Zeitzone Checks zu unterschiedlichen Zeiten laufen sollen:
- wenn in der CET-Zeitzone Arbeitszeit ist und
- andere Checks wenn in der PDT-Zeitzone Arbeitszeit ist

Ich werde nochmal testen, ob meine eingangs genannten Überlegungen dahingehend richtig sind und der Freshness check zuschlägt...

Gruß
Ralf

reb

Beginner

Posts: 10

Location: Hamburg

Number of monitoring servers: 3

Nagios Version: none

Icinga Version: Icinga-1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: 140

Number of services: 1200

OS: Linux

Plugin Version: ?

NDO Version: 2

Other Addons: PNP4Nagios, Thruk, MK Livestatus

5

Tuesday, June 19th 2012, 11:56am

RE: RE: Distributed Monitoring in verschiedenen Zeitzonen

Hi Gerhard,

Hat hier wer ein ähnliches Setup laufen und eine Lösung dafür gefunden?

Shinken :)
Hier kannst du am Remote-Standort einen Scheduler und einen Poller laufen lassen und ihnen in der shinken-specific.cfg jeweils eine individuelle Zeitzone verpassen.
wenn ich das so auf die Schnelle richtig verstanden habe, ist Shinken ein eigenständiges Monitor-System und daher für unsere Icinga-Installation eher nicht geeignet. Oder habe ich da nicht weit genug gelesen?

Gruß
Ralf

dnsmichi

Super Moderator

Posts: 5,976

Birthday: May 30th 1983 (29)

Gender: male

Location: Nürnberg

Occupation: Consultant / Developer beim besten Arbeitgeber der Welt @netways

Number of monitoring servers: Icinga: 4x dev, 10++ prod, Icinga2: 2x dev

Nagios Version: s/nagios/icinga/

Icinga Version: 1.9.0 / GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: 1000+

Number of services: 15000+

OS: RHEL, Debian, SUSE

Plugin Version: 1.4.16

IDO-Version: 1.9.0 / GIT MySQL/Postgresql/Oracle

Other Addons: Icinga Web, PNP, check_multi, inGraph, EventDB, LConf

6

Tuesday, June 19th 2012, 1:27pm

gerhard hat das thema mit einem "verwend ein anderes tool" gehijacked, nachdem er fuer sein produkt gern werbung macht - was ich verstehe, dein problem aber nicht loest. also - *finger.klopf*.

ad tests - ja bitte. und beispielconfig zum nachstellen, inklusive logs.
+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

reb

Beginner

Posts: 10

Location: Hamburg

Number of monitoring servers: 3

Nagios Version: none

Icinga Version: Icinga-1.7

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: 140

Number of services: 1200

OS: Linux

Plugin Version: ?

NDO Version: 2

Other Addons: PNP4Nagios, Thruk, MK Livestatus

7

Tuesday, June 19th 2012, 2:20pm

ad tests - ja bitte. und beispielconfig zum nachstellen, inklusive logs.
Anbei - die Konfig des jeweiligen Icinga Hosts ('hh' & 'ca'; auf 'hh' laufen Monitor, GUI, Notifications etc.) habe ich aus dem Object-Cache geholt. Für 'ca' habe ich aktuell nur ein Log, welches beim Submit der Checkresults geführt wird.

Die Konfig entspricht jetzt nicht einem richtigen Host-/Servicecheck - in 'hh' würde Icinga normalerweise das Command 'host-is-stale'/'service-is-stale' ausführen.

In icinga.hh.log ist am Ende

Source code

1
2
Jun 19 13:10:17 icinga icinga: Warning: The results of service 'Dummy Service Check' on host 'dummy-host-ca' are stale by 0d 1h 10m 29s (threshold=0d 0h 30m 0s).  I'm forcing an immediate check of the service.
Jun 19 13:10:17 icinga icinga: Warning: The results of host 'dummy-host-ca' are stale by 0d 1h 10m 50s (threshold=0d 0h 30m 0s).  I'm forcing an immediate check of the host. 


enthalten. Diese Zeilen sind entstanden nachdem ich die Definition von 'use_timezone' kommentiert habe und die timeperiod somit in der Zeitzone PDT läuft. Das sagt mir, dass ich mit meiner Vermutung nicht ganz falsch liege und zu einem 'Host is stale' Error führen würde.

Die Zeitangaben in icinga.<xx>.log:
- 'hh' -> CET
- 'ca' -> PDT

Ralf
reb has attached the following file: