SystemMonitoring erstellt Tickets statt FollowUp

Hilfe zu OTRS Problemen aller Art
Post Reply
xoh
Znuny newbie
Posts: 4
Joined: 10 Jul 2019, 16:02
Znuny Version: 6.0.19

SystemMonitoring erstellt Tickets statt FollowUp

Post by xoh »

Hallo!

Wir haben kürzlich von Zammad auf OTRS umgestellt (ja, ich weiß, lustige Richtung, aber wir hatten mit Zammad so unsere Probleme) und ich gerate momentan bei einem Problem ins Straucheln. Ich kann mir kaum vorstellen, dass dieses Problem so selten oder komplex ist, kann aber im Internet _wirklich_ nichts diesbezüglich finden - sollte ich etwas übersehen haben bitte ich im Vorfeld um Entschuldigung, normal kann ich mit Google und Suchfunktionen ganz gut umgehen, vielleicht fehlt mir einfach der richtige Suchbegriff? :)

Anforderung:
Wir bekommen von einem Monitoring-Tool E-Mails in unser Ticketsystem. Diese Mails kommen immer von der selben E-Mail Adresse (monitoring@company.tld) - von der Adresse kommt sonst nichts. Die Mails folgen im Betreff immer dem Aufbau "Produkt | Instanz | Fehlermeldung" (also bspw. "OracleDB | dbsrv01 | stuck transactions") oder "Instanz | Fehlermeldung" (also bspw. "dbsrv01 | stuck transactions"). Optional (bei wiederholtem Auftreten) ist der Betreff mit "Re: " prefixed. Das Monitoring ist nicht "OTRS-Aware", weshalb keine Werte für vorhandene FollowUpChecks (TicketID oder References) vorhanden sind. Ich möchte nun, dass diese Mails keine neuen Tickets erstellen, sondern automatisch als FollowUp erkannt werden, basierend auf dem Betreff.

Sämtliche bisherigen Versuche sind leider gescheitert. Einer meiner Versuche war ein eigener FollowUpCheck (unter /opt/otrs/Kernel/System/PostMaster/FollowUpCheck/Identical.pm):

Code: Select all

package Kernel::System::PostMaster::FollowUpCheck::Identical;

use strict;
use warnings;

use Kernel::System::ObjectManager;

our @ObjectDependencies = (
    'Kernel::Config',
    'Kernel::System::Ticket',
    'Kernel::System::Ticket::TicketSearch',
);

sub new {
    my ( $Type, %Param ) = @_;

    my $Self = {};
    bless( $Self, $Type );

    $Self->{ParserObject} = $Param{ParserObject} || die "Got no ParserObject";

    $Self->{CommunicationLogObject} = $Param{CommunicationLogObject} || die "Got no CommunicationLogObject!";

    return $Self;
}

sub Run {
    my ( $Self, %Param ) = @_;

    $Self->{CommunicationLogObject}->ObjectLog(
        ObjectLogType => 'Message',
        Priority      => 'Debug',
        Key           => 'Kernel::System::PostMaster::FollowUpCheck::Identical',
        Value         => 'Searching for identical tickets (customer and subject).',
    );

    my $Mail = $Param{GetParam};
    my $From = $Mail->{From};
    my $Subject = $Mail->{Subject};

    return 1 if $From !~ /monitoring\@company.tld/;

    my $ModifiedSubject = $Subject;
    $ModifiedSubject =~ s/\| (OracleDB|NiFi|ProduktXY)//;

    my $TicketObject = $Kernel::OM->Get('Kernel::System::Ticket');

    my @TicketIDs = $TicketObject->TicketSearch(
        Result        => 'ARRAY',
        Limit         => '1',
        StateType     => ['open', 'new', 'closed', 'pending reminder', 'pending auto'],
        Title         => [$Subject, $ModifiedSubject],
        MIMEBase_From => $From,
        UserID        => 1,
        Permission    => 'ro',
    );
    
    if ( @TicketIDs ) {
        return $TicketIDs[0];
    }
}

1;
Ich habe diesen Check dann in die Config eingebunden und es wird auch ausgeführt (bei Syntax-Fehlern erhalte ich eine Fehlermeldung im Webinterface/Systemprotokoll). Leider funktioniert es nicht. Ich muss auch ehrlich gestehen, ich habe nicht besonders viel Ahnung was ich da eigentlich genau mache. Ich klau mir nur günstig wirkende Code-Abschnitte aus anderen Files.

Ich habe auch einen anderen Ansatz versucht (https://lists.otrs.org/pipermail/otrs/2 ... 31700.html), konnte damit aber leider auch keine Erfolge erzielen. Da dieser Ansatz bereits relativ alt ist, könnte es an Änderungen in OTRS liegen (die haben 2010 vermutlich noch nicht von Version 6.0.19 gesprochen).

Nach einigen Tagen experimentieren bin ich nun mit meinem Latein am Ende und hoffe hier auf Hilfe. Ich kann leider überhaupt nicht einschätzen, wie komplex das Thema wird, kann mir aber kaum vorstellen, dass sonst niemand bereits dieses Problem hatte.

Vielen Dank im Voraus und LG
xoh
Last edited by xoh on 30 Jul 2019, 11:00, edited 1 time in total.
OTRS Community Edition 6.0.19 w/ SystemMonitoring 6.0.8 @ Ubuntu 16.04.6 LTS / MySQL 5.7.27-0ubuntu0.16.04.1
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Custom FollowUpCheck basierend auf Betreff (ohne Ticket#)

Post by jojo »

Dafür gibt es das Paket SystemMonitoring das Du in der ((otrs)) community edition über den Paketmanager installieren kannst
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
xoh
Znuny newbie
Posts: 4
Joined: 10 Jul 2019, 16:02
Znuny Version: 6.0.19

Re: Custom FollowUpCheck basierend auf Betreff (ohne Ticket#)

Post by xoh »

Hallo jojo,

Viele Dank für die rasche Antwort und deine Hilfe! Ich werde das Paket installieren und anschließend Rückmeldung geben.

Wie sähe es mit den leicht unterschiedlichen Mail-Subjects aus? Wir würden uns wünschen, dass "OracleDB | dbsrv01 | stuck transactions" und "dbsrv01 | stuck transactions" zu einem Ticket wird (das Prefix mit dem Produkt wird vom Monitoring leider nur bei "Es gibt ein Problem", nicht aber bei "Problem tritt nicht mehr auf" im Betreff mitgeschickt).

Vielen Dank und LG
xoh
OTRS Community Edition 6.0.19 w/ SystemMonitoring 6.0.8 @ Ubuntu 16.04.6 LTS / MySQL 5.7.27-0ubuntu0.16.04.1
jojo
Znuny guru
Posts: 15019
Joined: 26 Jan 2007, 14:50
Znuny Version: Git Master
Contact:

Re: Custom FollowUpCheck basierend auf Betreff (ohne Ticket#)

Post by jojo »

das SystemMonitoring Modul match nur bei bestimmten Absendern und nutzt die Kombination aus einem Service und einem Host zur FollowUp Erkennung.

Über den Status (z.B: OK, UP, DOWN, Critical) wird die Ticketerstellung oder das schliessen gesteuert.

Wahrscheinlich musst Du die Texte der Monitoring Mail noch anpassen, innerhalb von OTRS werden Regex beim parsen genutzt.
"Production": OTRS™ 8, OTRS™ 7, STORM powered by OTRS
"Testing": ((OTRS Community Edition)) and git Master

Never change Defaults.pm! :: Blog
Professional Services:: http://www.otrs.com :: enjoy@otrs.com
xoh
Znuny newbie
Posts: 4
Joined: 10 Jul 2019, 16:02
Znuny Version: 6.0.19

Re: Custom FollowUpCheck basierend auf Betreff (ohne Ticket#)

Post by xoh »

Hallo,

Ich konnte nun das SystemMonitoring Paket installiert und konfiguriert:
PostMaster::PreFilterModule###00-SystemMonitoring ist deaktiviert

PostMaster::PreFilterModule###1-SystemMonitoring ist aktiviert und wie folgt konfiguriert:
ArticleType: note-report
CloseActionState: closed successful
ClosePendingTime: 172800
CloseTicketRegExp: closed
DefaultService: Host
FreeTextHost: 1
FreeTextService: 2
FreeTextState: 1
FromAddressRegExp: monitoring@company.tld
HostRegExp: ([a-zA-Z0-9][a-zA-Z0-9 ]*[a-zA-Z0-9])\s\|.*
Module: Kernel::System::PostMaster::Filter::SystemMonitoring
NewTicketRegExp: reopened|opened|created
SenderType: system
ServiceRegExp: \|\s([a-zA-Z0-9 ]*):.*
StateRegExp: Issue was (\S+) by

Leider wird noch immer für open und close ein eigenes Ticket eröffnet. Im Kommunikationslog zu den einzelnen (open und close) Mails steht:
Bei open:

Code: Select all

SystemMonitoring Mail: New Ticket - Host: dbsrv01, State: reopened, Service: stuck transactions
Und bei close:

Code: Select all

SystemMonitoring Mail: Recovered - Host: dbsrv01, State: closed, Service: stuck transactions
Nach etwas Code lesen fiel mir auf, dass der folgende Funktionsaufruf in Zeile 587 in Kernel/System/PostMaster/Filter/SystemMonitoring.pm die korrekte TicketID liefert:

Code: Select all

my $TicketID = $Self->_TicketSearch();
Trotzdem wird ein neues Ticket erstellt.

Mir fällt weiterhin auf, dass nach dem SystemMonitoring Paket im Kommunikationslog die FollowUpCheck Module (BounceEmail, Subject, etc.) anlaufen. Nach den FollowUpChecks kommt folgende Meldung:

Code: Select all

Going to create new ticket.
Kann/muss man im SystemMonitoring Paket irgendwie konfigurieren, dass bei Match mit einem bestehenden Ticket keine FollowUpChecks mehr durchgeführt werden sollen?

MfG
xoh
OTRS Community Edition 6.0.19 w/ SystemMonitoring 6.0.8 @ Ubuntu 16.04.6 LTS / MySQL 5.7.27-0ubuntu0.16.04.1
xoh
Znuny newbie
Posts: 4
Joined: 10 Jul 2019, 16:02
Znuny Version: 6.0.19

Re: Custom FollowUpCheck basierend auf Betreff (ohne Ticket#)

Post by xoh »

Hallo zusammen!

Ich hatte nun wieder etwas Zeit, um mich dem Problem zu widmen. Dabei fiel mir auf, dass die Dynamic Fields nicht immer ausgefüllt werden. Beispiel:
1. Es kommt eine DOWN-Meldung für Service X. Die Dynamic Fields HostName, ServiceName und StateName werden korrekt laut E-Mail-Inhalt ausgefüllt.
2. Es kommt eine UP-Meldung für Service X. Es wird dafür ein neues Ticket angelegt, jedoch ohne ausgefüllte Dynamic Fields.
3. Es kommt (wieder) eine DOWN-Meldung für Service X. Dynamic Fields werden diesmal _nicht_ ausgefüllt, obwohl die E-Mail (bis auf Timestamps) identisch zur 1. ist.

Ich hab' mir auch die Inhalte der Dynamic Fields direkt in der Datenbank angesehen - keine trailing Spaces o.Ä. Alles soweit sauber.

Bei einem Re-Open (bspw. Mail 3 aus obigem Beispiel) wird im Kommunikationsprotokoll korrekt "New Notice" geloggt, leider aber trotzdem ein neues Ticket angelegt. Diese "New Notice" Logmeldung kommt aus Zeile 484 in SystemMonitoring.pm (https://github.com/OTRS/SystemMonitorin ... ng.pm#L484). Um dort hin zu gelangen, muss das Modul bereits das vorhergehende, zugehörige Ticket gefunden haben. Mir fällt hier auf, dass außer dem Loggen von "New Notice" nichts passiert - ich kann keinen Source Code finden, der tatsächlich einen Artikel an ein bestehendes Ticket anhängt.

Für Close/Resolve (bspw. via Mail 2 aus obigem Beispiel) wird bei mir ein neues Ticket angelegt. Auch hier sehe ich im Source (Zeile 456 in SystemMonitoring.pm: https://github.com/OTRS/SystemMonitorin ... ng.pm#L456) nichts, was das offene Ticket schließt.

Kann mir bitte irgendjemand beim suchen/finden helfen, wo im SourceCode diese Tasks ausgeführt werden?

MfG
xoh
OTRS Community Edition 6.0.19 w/ SystemMonitoring 6.0.8 @ Ubuntu 16.04.6 LTS / MySQL 5.7.27-0ubuntu0.16.04.1
Post Reply