SystemMonitoring acknowledge "no nagios ticket"

[fskd]

Hallo,

ich weiß, dass es hierzu schonmal ein Thema gab. Allerdings half uns das auch nicht so richtig weiter.

Über das Modul SystemMonitoring werden die Icinga-Tickets im OTRS korrekt angelegt und entsprechend der regexp auch wieder geschlossen, wenn sich das Problem im Icinga erledigt hat.

Leider funktioniert die andere Richtung nicht. Beim Sperren eines Tickets durch einen Agenten soll ja eigentlich ein ack an Icinga gegeben werden. Hier kommt aber die Fehlermeldung "no nagios ticket". Ok er hat ja Recht, weil wir ja Icinga im Einsatz haben, aber muss sich das Modul so zickig haben

Wir haben mal testweise die Ausgabe in Kernel::System::Ticket::Event::NagiosAcknowledge ergänzt:

Code: Select all

    # check if it's a Nagios related ticket
    my %Ticket = $Self->{TicketObject}->TicketGet( TicketID => $Param{TicketID} );
    if ( !$Ticket{ $Self->{Fhost} } ) {
        $Self->{LogObject}->Log( Priority => 'debug', Message => "No Nagios Ticket for host $Ticket{$Self->{Fhost}}, id=$Param{TicketID}!" );
        return 1;
    }

neue Ausgabe: "No Nagios ticket für host , id=12345" Das deutet doch irgendwie darauf hin, dass er das Objekt nicht korrrekt gefüllt hat?
In der Tickethistorie sehe ich allerdings: "Aktualisiert: FieldName=TicketFreeText1;Value=xxxxx;" (xxxx = hostname)

Hat jemand 'ne Idee wo wir weitersuchen können?

Danke
Frank

[fskd]

ich habe inzwischen etwas geforscht und festgestellt, dass u.a. die Funktion ... Ticket.pm::TicketGet in der neuesten OTRS-Version geändert worden ist. In den älteren Versionen sind im Prepare-Statement der SQL-Abfrage bereits die dynamischen Felder (freetextxxx) mit abgefragt worden. Das passiert jetzt erst hinterher separat. Derzeit hege ich die Vermutung, dass dort irgendwo etwas klemmt und damit die Werte für Host und Service bei der Abfrage nicht gefüllt werden.

[jojo]

dann mach bitte einen Bug auf

[bjoern]

Hallo,

dieser Thread ist zwar schon etwas älter, aber ...
Ich habe bzw. hatte das gleiche Problem.
Nach dem studieren des Quellcodes habe ich testweise folgende Zeile in System/Ticket/Event/NagiosAcknowledge.pm
geändert:

Code: Select all

--- System/Ticket/Event/NagiosAcknowledge.pm.ORIG       2012-05-18 12:57:32.691667961 +0200
+++ System/Ticket/Event/NagiosAcknowledge.pm    2012-05-18 12:34:45.133667971 +0200
@@ -57,7 +57,7 @@
     return 1 if !$Type;

     # check if it's a Nagios related ticket
-    my %Ticket = $Self->{TicketObject}->TicketGet( TicketID => $Param{TicketID} );
+    my %Ticket = $Self->{TicketObject}->TicketGet( TicketID => $Param{TicketID} , DynamicFields => 1 );
     if ( !$Ticket{ $Self->{Fhost} } ) {
         $Self->{LogObject}->Log( Priority => 'debug', Message => "No Nagios Ticket!" );
         return 1;

Danach funktionierte bei mir das Absenden des ACK an Icinga.
Soll ich einen Bug-Report öffnen bzw. kann jemand, der mehr Ahnung von OTRS/Perl etc. hat, sich die Änderung
einmal näher ansehen?

Folgende Versionen benutze ich:
OTRS: 3.1.5
SystemMonitoring: 2.3.2
ITSM: 3.1.3

[jojo]

Mach bitte einen Bug (und häng am besten den Patch an) auf und poste die Bug ID hier.

Danke

[bjoern]

Hallo,

Bug-Report eröffnet unter http://bugs.otrs.org/show_bug.cgi?id=8501.

Danke und Gruß!

Björn

[jpr]

Hallo,

Problem bei uns weiterhin vorhanden:

OTRS 3.1.10
SystemMonitoring 2.3.3

Icinga mails werden empfangen und als System-Tickets in die entsprechenden Queues geschoben. Auch das Schließen aus Icinga funktioniert ohne Probleme.

Allerdings wird beim Sperren des Tickets in OTRS das entsprechende Acknowledge in Icinga nicht gesetzt. Die URl wird nicht aufgerufen. Das Log (syslog) ist leer.

Woran erkennt OTRS, dass ein Ticket ein Icinga/Nagios Ticket ist, für dass NagiosAcknowledge eine Acknowledge-URL aufrufen muss?

Jan