Nagios in OTRS integrieren

[Jarode]

Hallo Usergemeinde,

ich versuche meine Nagios Benachrichtigungen in Otrs zu bekommen. Ich benutze Nagios 3.2 und OTRS 2.4.7.
Ich bekomme die Tickets auch erstellt, aber egal ob UP oder DOWN State er erzeugt immer ein neues Ticket.

Ich habe auch schon versucht die Whitepapers zu bekommen, aber die Links gehen nicht mehr.

Kann mir irgendjemand helfen ?

Wenn ich im Falschen Froum bin bitte Thread ins richtige verschieben.

MFG
Thorsten

[flashstyler]

prüfe mal die Queue Einstellung "Follow up Option" bzw. "Nachfrage Option" ob diese möglich ist.

[jojo]

Bitte füllt beide erstmal Eure Signatur aus.

Es muss das System Monitoring Paket via Paketmanager installiert werden, damit die Kopplung funktioniert.

[flashstyler]

Es muss das System Monitoring Paket via Paketmanager installiert werden, damit die Kopplung funktioniert.

ja stimmt, sry das system monitoring package muss natürlich installiert sein.

[Jarode]

Ja na klar muss das Modul installiert sein!

Was mich ein bischen Stört ist das er folgendes im Systemlog schreibt:

Code: Select all

SystemMonitoring Mail: SystemMonitoring: Could not find host address and/or state in mail =>  Ignoring

Das würde ja bedeuten das der Filter nich geht, oder?

[jojo]

Das bedeutet das die Nagios Mail nicht so aussieht, wie Du sie im Filter konfiguriert hast

[Jarode]

Das ist der Body der E-Mail von Nagios:

***** Nagios 3.2.0 *****

Benachritigungstype: PROBLEM
Host: wil-ws-tank
Status: DOWN
Address: 192.168.20.240
Info: PING CRITICAL - Packet loss = 0%, RTA = 631.01 ms

Datum/Uhrzeit: Fri Jun 4 10:53:31 CEST 2010

Und die Einstellung im Filter sind Standart:

Code: Select all

ArticleType: note-report
CloseActionState: closed successful
ClosePendingTime: 172800
CloseTicketRegExp: OK|UP
DefaultService: Host
FreeTextHost: 1
FreeTextService: 2
FreeTextState: 1
FromAddressRegExp: nagios@domän.local
HostRegExp: \s*Host: \s+(.*)\s*
Module: Kernel::System::PostMaster::Filter::SystemMonitoring
NewTicketRegExp: CRITICAL|DOWN
SenderType: system
ServiceRegExp: \s*Service: \s+(.*)\s*
StateRegExp: \s*Status: \s+(\S+)

[jojo]

Auf den ersten Blick sieht das in Ordnung aus, bitte schau nochmal in den Plaintext der Nachricht.

[sluyty]

Hallo Thorsten,

prüf doch mal, ob in Deiner Mail die von Nagios geschickt wird auch alle Inhalte drin sind wie gewünscht. Dazu gehören neben den in dem Modul SystemMonitoring abgefragten Begriffen ("Host" und "Service") auch die zugehörigen Werte aus der entsprechenden Nagios-Meldung.
Evtl. sind hier einfach die mitgegebenen Variablen falsch und werden "leer" übergeben. (Unterschiedliche Bezeichnungen z.B. bei Nagios und Icinga)

Wie hast du das System denn aufgebaut? Es scheint es ist eine Mischung aus "alter" und "neuer" Systemintegration Nagios + otrs.
Im "alten" System von Nagios wurde ein Mail geschickt die das Ticket geöffnet hat und nach "recovery" eine zweite Mail die das Ticket automatisch geschlossen hat. Das ist zwar bequem hat aber den Nachteil dass bestimmte Meldung gar nicht mehr wahrgenommen werden und letztlich auch die Systeme in der Eskalation konkurrieren können.

Die jüngste Lösung schlägt vor eine Mail zur Ticketeröffnung nach erfolgtem "ACKNOWLEDGE" zu senden.
Nach Übernahme/Sperren des Tickets wird dann die generierte Ticketnummer als Comment im Nagios zu dem entsprechenden Host/Service eingetragen. (Somit ist auch allen Agenten auf einem Blick in Nagios klar, dass das Problem bearbeitet wird und unter welcher Ticketnummer)
Im Systemmonitoring ist hinterlegt mit welchem command die Ticketnummer übergeben wird. Je nach Nagiosversion gibt es hier Abweichungen welche Werte für die Art des Comentars und ob persistent oder nicht übergeben werden. Wird die Ticketnummer nach Sperren des Tickets NICHT übergeben, dann bieg in dem SystemMonitoring mal die nagios.cmd auf xyz.cmd um und schau mal ob das korrekt ist bzw. funktioniert, was da reingeschrieben wird.

Bei einer Statusänderung im Nagios sollte dann die Rückmeldung per Eventhandler laufen. Schau Dir mal diese Scripte an. Dort sollte dann auch die Ticketnummer übergeben werden, bzw. Host und Service sollten auch genau wie bei der Ticketerstellung angegeben sein um eine Eindeutige Zuordnung zu ermöglichen.
Ich hoffe Du kommst damit schon mal ein Stückchen weiter - konnte mich leider nicht kürzer fassen. Sorry wenn ich es nicht 100%ig korrekt formuliert haben sollte - sehe gerade dass jojo auch was geschrieben hat.

Grüße
Jürgen

[Andre Bauer]

(Unterschiedliche Bezeichnungen z.B. bei Nagios und Icinga)

Wenn ich mich rechte erinner, funktionierte die Icinga Integration bei mir out of the box. Die Filter mussten also nicht angepasst werden.

[Jarode]

Danke Jürgen und Jojo,

ich habe es jetzt hinbekommen. Es war eine Falsche Einstellung in der queue die ich benutzt habe und ein falscher eintrag in E-Mailfilter. Aber jetzt klappt es nach der "alten Version".
Gibt es für die neue Version ein Handout wie ich das machen muss???? Ich habe mir schon die Finger wund gesucht nach einem Howto.
Für mich ist es erstmal wichtig das die Fehler in einem Ticket-System dokumentiert werden. Für uns sind die Nagiosmeldungen die wir per Mail bekommen immernoch ausschlaggebend.
Aber das kann sich ja ändern.......

MFG
Thorsten

PS: Bestend Dank für die schnelle Reaktion.

[jojo]

Was meinst Du mit "jüngster Lösung"?

DasSystem Monitoring Modul funktioniert seit der 1. Version immer gleich. Ist nur um einige Funktionalitäten z.B. bzgl. der OTRS::ITSM Integration erweitert worden.

Es sollte per Mail auch OotB mi Icinga laufen

[Wolfgangf]

Hallo Thorsten,

prüf doch mal, ob in Deiner Mail die von Nagios geschickt wird auch alle Inhalte drin sind wie gewünscht. Dazu gehören neben den in dem Modul SystemMonitoring abgefragten Begriffen ("Host" und "Service") auch die zugehörigen Werte aus der entsprechenden Nagios-Meldung.
Evtl. sind hier einfach die mitgegebenen Variablen falsch und werden "leer" übergeben. (Unterschiedliche Bezeichnungen z.B. bei Nagios und Icinga)

Wie hast du das System denn aufgebaut? Es scheint es ist eine Mischung aus "alter" und "neuer" Systemintegration Nagios + otrs.
Im "alten" System von Nagios wurde ein Mail geschickt die das Ticket geöffnet hat und nach "recovery" eine zweite Mail die das Ticket automatisch geschlossen hat. Das ist zwar bequem hat aber den Nachteil dass bestimmte Meldung gar nicht mehr wahrgenommen werden und letztlich auch die Systeme in der Eskalation konkurrieren können.

Die jüngste Lösung schlägt vor eine Mail zur Ticketeröffnung nach erfolgtem "ACKNOWLEDGE" zu senden.
Nach Übernahme/Sperren des Tickets wird dann die generierte Ticketnummer als Comment im Nagios zu dem entsprechenden Host/Service eingetragen. (Somit ist auch allen Agenten auf einem Blick in Nagios klar, dass das Problem bearbeitet wird und unter welcher Ticketnummer)
Im Systemmonitoring ist hinterlegt mit welchem command die Ticketnummer übergeben wird. Je nach Nagiosversion gibt es hier Abweichungen welche Werte für die Art des Comentars und ob persistent oder nicht übergeben werden. Wird die Ticketnummer nach Sperren des Tickets NICHT übergeben, dann bieg in dem SystemMonitoring mal die nagios.cmd auf xyz.cmd um und schau mal ob das korrekt ist bzw. funktioniert, was da reingeschrieben wird.

Bei einer Statusänderung im Nagios sollte dann die Rückmeldung per Eventhandler laufen. Schau Dir mal diese Scripte an. Dort sollte dann auch die Ticketnummer übergeben werden, bzw. Host und Service sollten auch genau wie bei der Ticketerstellung angegeben sein um eine Eindeutige Zuordnung zu ermöglichen.
Ich hoffe Du kommst damit schon mal ein Stückchen weiter - konnte mich leider nicht kürzer fassen. Sorry wenn ich es nicht 100%ig korrekt formuliert haben sollte - sehe gerade dass jojo auch was geschrieben hat.

Grüße
Jürgen

Jürgen,
wo/wie ist jüngste Lösung dokumentiert?
LG

[sluyty]

Hallo nochmal zurück,

ich versuche mal das ein bißchen transparenter zu machen:
@ jojo:
gut möglich dass das Systemmonitoring Tool seit der Version 1 immer gleich lief - ich habe jetzt keine Möglichkeit das nochmal nachzuvollziehen. Ich kann Dir nur sagen, dass vor gut einem Jahr als ich Nagios mit otrs getestet habe das System ootb lief. Ohne Probleme. Klar auch dass die Schnittstelle von nagios nach otrs über die E-Mails läuft. Der Weg von otrs nach nagios/icinga dann über die Pipe, also die nagios.cmd oder eben jetzt (bei mir) die icinga.cmd

In den Shell-Scripten müssen dann natürlich noch die Variablen ggf. angepaßt werden - zumeist von "NAGIOS_" nach "ICINGA_". Sonst werden halt keine Werte übergeben. Zur Info: Ich nutze als Basis die Shell Scripte von Wolfgang Barth vom 08-09-2008.

@jojo
@Wolfgangf
Bei meiner Suche bin ich im Netz neben den exemplarischen Shell Scripten im wesentlichen auf zwei Präsentationen gestossen die eine Anbindungsmöglichkeit beschreiben: Zum einen von Wolfgang Barth und dann noch von Jens Oliver Bothe. Auf meinem ersten Testsystem vor einem Jahr lief einfach alles ootb, sprich mail mit problem an otrs: neues Ticket wurde automatisch erstellt - mail mit recovery an otrs: bestehendes Ticket geschlossen.
Jetzt - nmach einem Jahr, einem neu aufgestzten System und der Wahl von icinga anstelle nagios habe ich mich beim nochmal damit beschäftigt und dabei sind mir eben zwei Sachen in der nagios/icinga Konfiguration aufgefallen die immer wieder gerne nicht oder nicht richtig beachtet werden: Zum einen ist das die notwendige Anpassung der Scripte auf die Variablen und zum anderen das Thema Nutzung von eventhandlers, konkret wer wird bei einem Statuswechsel in nagios/icinga benachrichtigt.

So, bin gerne bereit hinzuzulernen bitte korrigiert mich wenn hier jetzt Fehler drin sind.
Grüße
Jürgen

[skamp]

Guten Tag!

Ich bin neu hier im Forum und habe bislang schon einige spannende Beitraege hier gefunden. Sehr schoen anzusehen ist, dass die Mehrzahl aller Beitraege einem hohen Niveau entsprechen und den Hilfscharakter der Benutzer widerspiegeln. In diesem Sinne hoffe ich, dass auch mir hier in aehnlicher Form geholfen werden kann.
Im Rahmen meiner Bachelorarbeit stehe ich vor der Aufgabe der Konzepterstellung fuer eine Monitoringloesung in Verbindung mit einem Ticketsystem. Natuerlich besteht darueber hinaus der Anspruch, dass dies ITIL-konform geschieht. Mit ORTS::ITSM ist das auch ohne grosse Probleme moeglich. Schwierig ist aber - und da tuen sich viele bis alle Monitoringprodukte namhafter Hersteller schwer - die logische Filterung von Fehlermeldungen. Ergebnis meiner Arbeit soll eine Empfehlung werden, welche sowohl in der Lage ist Relationen von Geraeten untereinander zu beruecksichtigen als auch die benutzerorientierte Praesentation dieser Fehler dann via Ticket. Konkret bedeutet es, dass durch z.B. den Ausfall eines Routers ihm nachstehende Clients, Server oder auf ihnen laufende Dienste nicht weiter beobachtet werden und schon gar nicht ein Ticket erzeugen. Im groessen Massstab waeren das vielleicht schon >200 Fehler (respektive >200 Tickets), die die Kerninformation des eigentlichen Fehlers - naemlich der Ausfall des intermediary device - unter ihnen begraben. Darueber hinaus gilt, dass Fehlermeldungen nicht an Aussage gewinnen, je haeufiger sie protokolliert werden. Waehrend Nagios durchaus des oefteren eine Benachrichtung fuer den Ausfall eines Geraets/Dienstes generiert, soll zumindest nur ein Ticket beim Serviceteam dafuer eintreffen. Loesungen in der Form von: "Weitere Fehlermeldungen an das erste Ticket anzuhaengen" belassen zwar den Fehler innerhalb nur eines Tickets, jedoch ist der Benachrichtungsaufwand und das letztendlich wachsende Ticket wieder "unschoen".
In Bezug auf diese Informationen stelle ich daher die Frage, ob die Verbindung aus Nagios und OTRS(::ITSM) diesen Anspruechen ueberhaupt gerecht werden kann. Mir ist bewusst, dass einiges in meiner Situationsbeschreibung eher als Frage im Nagiosforum auftauchen sollte, jedoch geht es mir nicht primaer um die Konfiguration einer Komponente, weswegen ich ergebnisorientiert die Frage an einem Ort stelle, wo beide Softwareprodukte ihre Schnittstelle definieren - hoffentlich hier

Ich freue mich auf einen Austausch und verbleibe mit freundlichen Gruessen,

Uwe

[Wolfgangf]

Also ich habe es jetzt hinbekommen

Grundsätzlich dem Weg von Wolfgang Barth folgend
http://www.netways.de/uploads/media/Wol ... TRS_02.pdf

1) Nagios -> OTRS

hier http://exchange.nagios.org/directory/Ad ... RS/details
sind die scripts für die eventhandler, ....

2) OTRS -> Nagios

Ich habe mir einen eigenen Postmaster::Filter::SystemMonitoring gebaut (kleine Änderungen beim CI handling)

Ausserdem habe ich das Acknowldge nach Nagios etwas angepasst. Ich möchte, dass das ACK sofort beim Anlegen des
Tickets erfolgt und nicht erst bei Veränderung des Lock-status.
Somit kleine Anpassungen in /Kernel/System/PostMaster/NewTicket.pm
Vielleicht gibt es da ja noch eine bessere Methode?!


Etwas anderes ist mir auch noch aufgefallen: bei mir sind Nagios und OTRS auf 2 verschiedenen Rechnern
Das ACK muss daher übers Netz geschickt werden. In meinem Fall wollte ich es mit

Code: Select all

ssh@nagiosrechner -C "echo .... > nagios.cmd"

machen. So ein Kontrukt scheitert derzeit mit dem Code Kernel/System/Ticket/Event/NagiosAcknowledge.pm an den
Shell-Escape Zeichen.

[opossum_shrimp]

Hallo Wolfgang,

genau wie du möchte ich, dass das Acknowledge sofort beim anlegen des Tickets erfolgt.
Könntest Du die Anpassungen die Du vorgenommen hast evtl. genauer erläutern?

Und genau wie Du hab ich Nagios und OTRS auf zwei verschiedenen Servern laufen.

Allerdings hab ich noch Probleme beim Acknowledgen generell.
Ich bekomme den Debug-Hinweis [Kernel::System::Ticket::Event::NagiosAcknowledge::Run][61] No Nagios Ticket!.
Diesen kann ich mir auch leider nicht erklären. Stammt dieser von Nagios oder von OTRS

Ach so, ich sollte noch erwähnen, dass ich die Nagios-Maschine nur per https erreichen kann.

Evtl. hat ja noch jemand einen Tip für mich.

mfg
Dirk

[opossum_shrimp]

Hallo,

mittlerweile bin ich zwar etwas schlauer geworden.
Der Debug-Hinweis

Code: Select all

[Kernel::System::Ticket::Event::NagiosAcknowledge::Run][61] No Nagios Ticket!

kommt natürlich dadurch zustande, dass OTRS erkennt, dass das Ticket nicht durch Nagios erstellt wurde.

Allerdings hab ich immer noch Probleme mit dem Acknowledge per HTTP.
Ich habe bewusst unter SysConfig im Bereich SystemMonitoring einen falschen Pfad eingegeben um auf dem Nagios Server zu erkennen ob ich dort überhaupt ankomme. Dieser Test ist erfolgreich gelaufen. Es wird in der Apache-Error.log ein Fehler protokolliert, dass der Pfad wie erwartet nicht korrekt ist.

Dann habe ich den Pfad wieder korrigiert. Als Benutzer habe ich meine persönliche Kennung eingesetzt und natürlich auch mein Passwort.
Wenn ich jetzt ein Ticket, welches von Nagios erzeugt wurde, sperre, sollte ja ein Acknowledge an Nagios gesendet werden.
Leider kommt diese dort nicht an. Gibt es noch irgendwo eine Log-Datei in der ich dies sehen kann?

mfg
Dirk

[Wolfgangf]

Hallo Wolfgang,

genau wie du möchte ich, dass das Acknowledge sofort beim anlegen des Tickets erfolgt.
Könntest Du die Anpassungen die Du vorgenommen hast evtl. genauer erläutern?

Und genau wie Du hab ich Nagios und OTRS auf zwei verschiedenen Servern laufen.

Allerdings hab ich noch Probleme beim Acknowledgen generell.
Ich bekomme den Debug-Hinweis [Kernel::System::Ticket::Event::NagiosAcknowledge::Run][61] No Nagios Ticket!.
Diesen kann ich mir auch leider nicht erklären. Stammt dieser von Nagios oder von OTRS

Ach so, ich sollte noch erwähnen, dass ich die Nagios-Maschine nur per https erreichen kann.

Evtl. hat ja noch jemand einen Tip für mich.

mfg
Dirk

Dirk,

ich habe nicht den "Normalen" Weg eingeschlagen, sondern ein bisschen Code modifiziert
1) mein eigenes "SystemMonitoring" Module; macht etwas mehr als der Standard bei den CIs ... und hier ist auch der 2. ACK an Nagios enthalten
2) System/Kernel/Ticket/Postmaster/NewTicket.pm angepasst: hier wird das erte ACK an Nagios geschickt; Standardmässig ist es ja als event "on Status Change" implementiert, und das war mir zu spät

Viele Grüsse

[opossum_shrimp]

Hallo an alle,

ich habe jetzt den Versand von Acknowledges auch realisieren können.
Der Grund weshalb diese nicht korrekt per HTTP an Nagios übermittelt wurden, lag in meinem Fall aber bereits an der Erstellung der Benachrichtigungen auf Nagios-Seite. Und zwar wurde dort der Wert der Variable "Host" mit dem Hostalias belegt und dafür dann eine neue Variable "Hostname" eingesetzt und gefüllt.

Somit wurde unter OTRS zwar ein Ticket erstellt aber die Variablen nicht korrekt gefüllt, weil in unserem Fall der Hostalias aber nicht identisch mit dem Hostnamen und schon gar nicht unbedingt eindeutig ist.

Nachdem ich also im Nagios zwei korrekte Benachrichtigungs-Befehle (für Hosts und Services) erstellt und dem Kontakt "OTRS" zugewiesen habe, funktioniert das Acknowledge auch.

Jetzt versuche ich nur noch, die Acknowledges sofort beim Eintreffen eines Tickets zu erzeugen. Mein Ziel ist es jedoch dabei möglichst keine Skripte anzupassen, die dann ggf. bei irgendwelchen Updates vergessen werden.

Für Tips in dieser Richtung wäre ich sehr dankbar.

mfg
Dirk