Monday, May 20th 2013, 5:58am UTC+2

You are not logged in.

  • Login
  • Register

NagTrap Downtime bzw. Traps Filtern

vmarc

Beginner

Posts: 15

Birthday: Oct 1st

Gender: male

Occupation: Fachinformatiker für Systemintegration

Number of monitoring servers: 1

Hobbies: Motorrad, Sport

Nagios Version: 3.3.1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 250

OS: Ubuntu Server 10.04.4 64Bit

Plugin Version: 1.4.15

NagVis Version: 1.6.6

Other Addons: MRTG, NagTrap

1

Thursday, July 26th 2012, 8:24am

NagTrap Downtime bzw. Traps Filtern

Hallo zusammen,

Ich habe im Rahmen eines Projekts in meinem Betrieb Nagios mit MRTG und NagTrap integriert.
Dies funktioniert auch alles wunderbar. Nun geht es noch um gewisse Feinheiten.

Ankommende Traps werden ganz normal in die Datenbank geschrieben und von NagTrap im Webinterface richtig angezeigt.
Auch Nagios setzt beim nächsten Service-Check den Service auf den entsprechenden Status.

Da nun aber z.B. unsere Telefonanlage jede Nacht neustartet kommen jede Nacht 2 Critical LinkDown Traps in die Datenbank.
Dadurch werden Mails an die Administratoren versandt.

Ich könnte natürlich auf den Service eine Downtime jede Nacht setzen, die Traps stehen aber dann ja trotz allem noch in der DB und werden dann eben später von Nagios gemeldet. Da die Downtime sich ja nur auf den Service bezieht.
Außerdem bezieht sich ja die Downtime auf den kompletten Host, also alles Interfaces was auch wieder nicht gewollt ist.

Gibt es eine Möglichkeit eine Downtime auf Traps eines bestimmten Interfaces von Switches zu setzen, bzw. die einkommenden Traps zu Filtern ?
Bisher wurden auf dem Switch bei weniger relevanten Geräten die viele Traps verursachen schlichtweg die LinkDown/Up Traps auf dem Interface deaktiviert.

Speziell die Telefonanlage sollte aber in der Überwachung bleiben.

Würde mich über Vorschläge Freuen !

Viele Grüße
Marc

pitchfork

Administrator

Posts: 18,436

Location: Kassel

Occupation: Sysadmin SAP / Linux / AIX

Number of monitoring servers: 2

Hobbies: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios Version: 3.2.3 ( OMD )

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 360

Number of services: 6700

OS: Debian 6.0

Plugin Version: 1.4.x

Other Addons: SNMPTT, NagTrap, check_mk, PNP-0.6.x. Thruk

2

Thursday, July 26th 2012, 8:27am

Wenn Link Down Traps nicht wichtig sind. warum wetest du Sie dann aus?
+++ PNP Developer +++ PNP 0.6.21 ist online ! +++
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution

vmarc

Beginner

Posts: 15

Birthday: Oct 1st

Gender: male

Occupation: Fachinformatiker für Systemintegration

Number of monitoring servers: 1

Hobbies: Motorrad, Sport

Nagios Version: 3.3.1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 250

OS: Ubuntu Server 10.04.4 64Bit

Plugin Version: 1.4.15

NagVis Version: 1.6.6

Other Addons: MRTG, NagTrap

3

Thursday, July 26th 2012, 8:51am

Nein ganz so meinte ich das nicht.
LinkDown Traps sind alles andere als unrelevant, nur suche ich eben eine Möglichkeit geplante Neustarts von Geräten herauszufiltern.
Denn diese sind schließlich bekannt und sollten keine Critical Trap in der Datenbank erzeugen.

pitchfork

Administrator

Posts: 18,436

Location: Kassel

Occupation: Sysadmin SAP / Linux / AIX

Number of monitoring servers: 2

Hobbies: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios Version: 3.2.3 ( OMD )

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 360

Number of services: 6700

OS: Debian 6.0

Plugin Version: 1.4.x

Other Addons: SNMPTT, NagTrap, check_mk, PNP-0.6.x. Thruk

4

Thursday, July 26th 2012, 9:08am

Dazu fällt mir dann keine Lösung ein.
+++ PNP Developer +++ PNP 0.6.21 ist online ! +++
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution

vmarc

Beginner

Posts: 15

Birthday: Oct 1st

Gender: male

Occupation: Fachinformatiker für Systemintegration

Number of monitoring servers: 1

Hobbies: Motorrad, Sport

Nagios Version: 3.3.1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 250

OS: Ubuntu Server 10.04.4 64Bit

Plugin Version: 1.4.15

NagVis Version: 1.6.6

Other Addons: MRTG, NagTrap

5

Thursday, July 26th 2012, 9:12am

Ok, trotzdem danke der Bemühung ;)
Kann mir allerdings noch nicht vorstellen dass ich der einzige bin den das stört.
Vielleicht sonst jemand eine Idee ?

pitchfork

Administrator

Posts: 18,436

Location: Kassel

Occupation: Sysadmin SAP / Linux / AIX

Number of monitoring servers: 2

Hobbies: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios Version: 3.2.3 ( OMD )

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 360

Number of services: 6700

OS: Debian 6.0

Plugin Version: 1.4.x

Other Addons: SNMPTT, NagTrap, check_mk, PNP-0.6.x. Thruk

6

Thursday, July 26th 2012, 9:15am

Ich für meinen Teil halte die Link up/down Traps für unnötig. Daher habe ich das Problem nicht.

Welchen Informationsgehalt hat der Trap für dich?
+++ PNP Developer +++ PNP 0.6.21 ist online ! +++
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution

vmarc

Beginner

Posts: 15

Birthday: Oct 1st

Gender: male

Occupation: Fachinformatiker für Systemintegration

Number of monitoring servers: 1

Hobbies: Motorrad, Sport

Nagios Version: 3.3.1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 250

OS: Ubuntu Server 10.04.4 64Bit

Plugin Version: 1.4.15

NagVis Version: 1.6.6

Other Addons: MRTG, NagTrap

7

Thursday, July 26th 2012, 9:55am

Natürlich bin auch für andere Lösungen offen !
Also den LinkDown Trap finde ich einfach Sinnvoll um eventuelle Netz-Komponenten Ausfälle bzw. Probleme an Ports zu erkennen.
Ein schlichter Ping Service hilft ja bei ausfällen im Sekunden-Bereich nichts da der Check ja nur in gewissen Intervallen vorgenommen wird.

pitchfork

Administrator

Posts: 18,436

Location: Kassel

Occupation: Sysadmin SAP / Linux / AIX

Number of monitoring servers: 2

Hobbies: Motorrad fahren, wenns die Zeit erlaubt :-)

Nagios Version: 3.2.3 ( OMD )

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 360

Number of services: 6700

OS: Debian 6.0

Plugin Version: 1.4.x

Other Addons: SNMPTT, NagTrap, check_mk, PNP-0.6.x. Thruk

8

Thursday, July 26th 2012, 10:54am

Quoted from "vmarc"

Also den LinkDown Trap finde ich einfach Sinnvoll um eventuelle Netz-Komponenten Ausfälle bzw. Probleme an Ports zu erkennen.


Bei Netzwerk Componenten gebe ich dir recht.
+++ PNP Developer +++ PNP 0.6.21 ist online ! +++
Hilfreiche Infos gefunden? Dann schnell ein paar Cent flattrn
OMD - Open Monitoring Distribution

bern

Master

Posts: 2,938

Number of monitoring servers: 2-5

Nagios Version: 3.x

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 80-200

Number of services: 1400-2000

OS: Linux

Plugin Version: Whatever I can download, patch, or cobble together myself :-)

Other Addons: n2rrd, PNP, livestatus

9

Friday, July 27th 2012, 1:01am

Man kann, jedenfalls laut Doku, in der snmptt.conf mit MATCHes auch Trap-Sender(-IP) ($A/$aA), Datum ($x) und Uhrzeit ($X) abprüfen. Du müßtest Dir halt zusammentesten, in welchem Format die Vars gefüllt werden - und ob in der snmptt.conf in so einem Fall first oder last match relevant ist.

vmarc

Beginner

Posts: 15

Birthday: Oct 1st

Gender: male

Occupation: Fachinformatiker für Systemintegration

Number of monitoring servers: 1

Hobbies: Motorrad, Sport

Nagios Version: 3.3.1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 250

OS: Ubuntu Server 10.04.4 64Bit

Plugin Version: 1.4.15

NagVis Version: 1.6.6

Other Addons: MRTG, NagTrap

10

Friday, July 27th 2012, 8:10am

Hallo Bern,

danke für deinen Tipp. Mit etwas Aufwand wäre es so vermutlich möglich, aber ob ich dadurch an das Interface von dem der Trap ausgeht rankomme ?
Und auch eine Filterung der Traps nur über einen gewissen Zeitraum (03.00 - 03.30 Uhr) wo unsere Telefonanlage neustartet scheint so ohne großen Aufwand nicht möglich zu sein.

Daher werde wir uns entweder mit den täglichen vier Traps abfinden oder für das Interface der Telefonanlage die Traps deaktivieren.
Trotzdem danke an euch beide !

Gruß Marc

Bastian Kuhn

Professional

Posts: 799

Gender: male

Location: München

Occupation: Berater/ Entwickler am besten Monitoring System der Welt :)

Number of monitoring servers: 8

Hobbies: Jiu Jitsu, Klettern, MTB, Reisen

Nagios Version: OMD/CMK GIT

Distributed monitoring: Ja

Redundant monitoring: Ja

Number of hosts: >5.000

Number of services: >95.000

OS: Linux, AIX, Windows

Plugin Version: OMD/CMK GIT

11

Friday, July 27th 2012, 8:14am

Wenn das alles in einer Mysql DB landet,

mach doch halt im zweifelfall einen kleinen Cronjob der die Events wieder aus der Datenbank löscht order quitiert bevor Nagios sie sieht oder meldet?
Mathias Kettner GmbH mathias-kettner.de
Das Check_MK Monitoring System | Check_MK

vmarc

Beginner

Posts: 15

Birthday: Oct 1st

Gender: male

Occupation: Fachinformatiker für Systemintegration

Number of monitoring servers: 1

Hobbies: Motorrad, Sport

Nagios Version: 3.3.1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 250

OS: Ubuntu Server 10.04.4 64Bit

Plugin Version: 1.4.15

NagVis Version: 1.6.6

Other Addons: MRTG, NagTrap

12

Friday, July 27th 2012, 9:58am

Das klingt eigentlich garnicht schlecht.
Die Telefonanlage startet jeden morgen um 03.22 - 03.24 Uhr neu.
Der Check von Nagios läuft im 10 Minuten Intervall und kommt auf die 7er Minute -> 03.27 Uhr.
Also wie du sagst ein Cronjob um sagen wir 03.25 Uhr mit einem kleinen Script das ein SQL Statement enthält das mir die entsprechenden Traps löscht.
Glaube daran werde ich mich mal versuchen. Vielen Dank für den Tipp !

bern

Master

Posts: 2,938

Number of monitoring servers: 2-5

Nagios Version: 3.x

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 80-200

Number of services: 1400-2000

OS: Linux

Plugin Version: Whatever I can download, patch, or cobble together myself :-)

Other Addons: n2rrd, PNP, livestatus

13

Friday, July 27th 2012, 10:19am

Quoted from "vmarc"

aber ob ich dadurch an das Interface von dem der Trap ausgeht rankomme ?
Ich kaufe ein "ach übrigens, die Traps kommen vom Switch, nicht von der Telefonanlage selbst" ... 8)

Wenn ich mich richtig erinnere, sieht der Varbind eines standardmäßigen Link-Down-Traps so aus, daß das Interface im letzten Teil der OID steckt und der passende Oper-Status-Code in der Value. Dafür findet man in den Variablenexpansionen von snmptt neben $n auch Formen, die den "Namen" mit expandieren ...

Quoted from "vmarc"

Der Check von Nagios läuft im 10 Minuten Intervall und kommt auf die 7er Minute -> 03.27 Uhr.
Also wie du sagst ein Cronjob um sagen wir 03.25 Uhr
Also den Plan wird Dir der Nagios-Scheduler eher früher als später gepflegt versenken. Da muß IMHO schon eine notification_period oder gar check_period mithelfen.

vmarc

Beginner

Posts: 15

Birthday: Oct 1st

Gender: male

Occupation: Fachinformatiker für Systemintegration

Number of monitoring servers: 1

Hobbies: Motorrad, Sport

Nagios Version: 3.3.1

Distributed monitoring: Nein

Redundant monitoring: Nein

Number of hosts: 100

Number of services: 250

OS: Ubuntu Server 10.04.4 64Bit

Plugin Version: 1.4.15

NagVis Version: 1.6.6

Other Addons: MRTG, NagTrap

14

Monday, July 30th 2012, 9:24am

Quoted

Ich kaufe ein "ach übrigens, die Traps kommen vom Switch, nicht von der Telefonanlage selbst" ... 8)

Das stand doch in meinem ersten Beitrag geschrieben ;D
Stimmt da hast du recht, das Interface ist normal die letzte Stelle in der OID. Vielleicht ließe sich damit etwas anfangen.

Similar threads