Escalation Option: "first_warning_notification" nicht nutzbar

terratectom

Trainee

Posts: 83

Gender: male

Number of monitoring servers: x

Nagios Version: keine

Icinga Version: 1.8.3

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: 600

Number of services: 6500

OS: SuSE SLES Linux

Plugin Version: 1.4.x

NagVis Version: 1.6.x

IDO-Version: 1.8.3

Other Addons: SNMPTT, PNP 0.6.x, Nagvis, Business Process AddOn, EventDB, mod_gearman

1

Friday, July 20th 2012, 4:46pm

Hallo,

beim einrichten von Service Escalationen bin ich auf ein Problem gestoßen. In der Icinga Dokumentation sind folgende Optionen angegeben, aber ein "icinga -v icinga.cfg" liefert hier nur den Fehler das es diese Optionen nicht geben soll. Ich setze Icinga 1.6.1 ein und diese Option soll schon ab 1.0.2 enthalten sein.

	Source code
1 2 3 4 5 6	first_warning_notification # last_warning_notification # first_critical_notification # last_critical_notification # first_unknown_notification # last_unknown_notification #

Auszug aus der Icinga Dokumentation:

Source code

1
2

first_warning_notification:
Diese Direktive ist eine Zahl, die die erste WARNING-Benachrichtigung angibt, für die diese Eskalation gilt. Wenn Sie beispielsweise den Wert auf 3 setzen, dann wird diese Eskalation nur dann benutzt, wenn der Service lang genug in einem nicht-OK-Zustand ist, damit eine dritte WARNING-Benachrichtigung versandt wird. Diese Direktive ist ab Icinga 1.0.2 verfügbar.

Dies Optionen könnten mir bei folgenden Problem helfen. Ziel ist es nach möglichst einer festen Zeit eine Escalation auszulösen. Dabei sollen die Fälle bei der ein Service von WARNING auf CRTICAL wechselt nicht mitgezählt werden.

1. Sind diese Optionen denn wieder entfernt worden?
2. Gibt es eventuell einen anderen Lösungsansatz für dieses Problem?

Grüße
Tom

Go to the top of the page

dnsmichi

Super Moderator

Posts: 5,986

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.1 / 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.1 / GIT MySQL/Postgresql/Oracle

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

2

Friday, July 20th 2012, 5:05pm

nachdem es damals mit livestatus gekracht hat, kam das optional via configure rein.

https://dev.icinga.org/projects/icinga-c…65244b07a6493be

es gibt da unschoene workarounds, die wir auch bei ack expiry time oder address6 verwenden, um das ohne configure bauen zu koennen, aber bisher habe ich diesen patch nicht angegriffen. der user demand danach war in 3 jahren genau ein user. du bist jetzt der zweite der danach fragt - also wenns ohne configure gehen soll, feature request aufmachen bitte.

+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

Go to the top of the page

dnsmichi

Super Moderator

Posts: 5,986

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.1 / 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.1 / GIT MySQL/Postgresql/Oracle

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

3

Friday, July 20th 2012, 7:27pm

so, ging hand in hand mit anderen patches. ist allerdings on top neben anderen core patches an denen ich arbeite - aber wenn du testen helfen willst, sehr gerne. target bleibt 1.8 ...

https://git.icinga.org/?p=icinga-core.gi…mfriedrich/core
https://git.icinga.org/?p=icinga-core.git;a=commit;h=df420f0

+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++

Go to the top of the page

terratectom

Trainee

Posts: 83

Gender: male

Number of monitoring servers: x

Nagios Version: keine

Icinga Version: 1.8.3

Distributed monitoring: Ja

Redundant monitoring: Nein

Number of hosts: 600

Number of services: 6500

OS: SuSE SLES Linux

Plugin Version: 1.4.x

NagVis Version: 1.6.x

IDO-Version: 1.8.3

Other Addons: SNMPTT, PNP 0.6.x, Nagvis, Business Process AddOn, EventDB, mod_gearman

4

Wednesday, July 25th 2012, 9:59am

Hallo,

danke für die Infos. Ich würde gern Testen helfen, aber auf unseren Testsystem läuft nicht alles mit.
So ist es mit den Escalationstests ein Problem. Versuche aber eine Lösung zu finden, damit ich dies testen kann!

Was mich aber verwundert das so wenige Probleme damit haben. Wie verwenden andere die Escalationen? Vielleicht ist mein Ansatz falsch.

Ziel ist es nach einem Tag nicht bearbeitet zu Escalieren. So muss ich einfach first_notification auf 2 setzen und es geht im Normalfall.
Nun kann ein Service in den WARNING State wechseln und kurz darauf in den CRITICAL State. Damit werden 2 Notification gezählt und die
Escalation wird an den Vorgesetzten ausgelöst. Dies kann so schnell gehen das der Admin nicht einmal reagieren kann.

Grüße
Tom

Go to the top of the page

dnsmichi

Super Moderator

Posts: 5,986

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.1 / 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.1 / GIT MySQL/Postgresql/Oracle

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

5

Wednesday, August 1st 2012, 12:40am

der ansatz ist ja nicht falsch. der patch war ja in ordnung und auch wunderbar lauffaehig - nur nachdem das die objekt strukturen angreift, ist dieser nicht neb module kompatibel (ausser man greift zu tricks, was ich jetzt getan habe).

nagios/icinga objekt strukturen im code sind nicht modular erweiterbar, sondern statisch gemapped (also kein json zb). und wenn livestatus somit lediglich die nagios header dateien verwendet, und du da mittendrin in der struktur was neues einschiebst, stimmt das nicht mehr zusammen. im klartext - livestatus greift auf einen speicherbereich zu den icinga anders bereitstellt. das ist der handelsuebliche segfault (SIGSEGV).
da wir leider keinerlei bereitschaft seitens der livestatus entwickler erkennen koennen, um auch spezielle icinga features zu unterstuetzen (was 2 verschiedene binary builds erfordert, und verstaendlicherweise mehr aufwand ist, der sich nicht unbedingt "bezahlt" macht), bleibt der icinga core lediglich "nagios kompatibel" zu livestatus.
icinga core verwendet damit all jene bunten features wie address6, acknowledgement expiry time und eben auch state based escalations mit 1.8, wo livestatus im gegenzug mit den gemappten nagios header alt aussieht, weil es diese werte in seinem speicherbereich einfach nicht sieht - und dementsprechend auch nicht zurueckgeben kann. das ist mitunter der grund warum thruk zb address6 oder die acknowledgement expiry time nicht auslesen kann. klingt bloed, ist aber so.

wenn du testen willst - ich hab dir hier mal einen next branch gemerged, der den patch drinnen hat.
https://git.icinga.org/?p=icinga-core.gi…refs/heads/next

sowie eine testconfig
https://dev.icinga.org/issues/2878

+++ Icinga / LConf Developer +++ Senior Consultant at []NETWAYS> +++
+++ Icinga 1.9 || Icinga 2 +++ Icinga Support || IRC +++