Systemwarnungen

Manchmal meldet das System einige Fehler, die oben rechts in der Kopfzeile des iAGENT Supervisor neben der Abmeldeschaltfläche angezeigt werden.
Diese könnten sein:

  • CTI-Fehler: Die Verbindung zum PBX-System wurde unterbrochen. Bitte überprüfen Sie die Telefonanlagen-Plugins und den Status der Telefonanlage.
  • Laufzeitfehler: Dieser Fehler tritt auf, wenn eine automatische Verarbeitung an einer Kategorie fehlgeschlagen ist (automatisches Schließen oder Weiterleiten aus irgendeinem Grund fehlgeschlagen).

System Logs und Mails

Indikatoren für eine schlechte Systemleistung oder sonstige besondere Vorkommnisse werden protokolliert und eine automatische Informationsmail an die entsprechend konfigurierte E-Mail-Adresse wird gesendet.

Fail point limit exceeded

Diese Meldung besagt, dass bestimmte Aktionen des Systems länger als erwartet gedauert haben. Es muss nicht direkt gehandelt werden. Kommt diese Meldung allerdings regelmäßig, sollte das System auf Schwachstellen untersucht werden.
Beispiele dafür wären:

  • Zu hohe Netzwerkauslastung / zu geringe Bandbreite
  • Zu hohe DB Auslastung (Reports gleichzeitig nach Monatsende?)
  • Zu wenig Arbeitsspeicher / zu wenig Festplattenplatz (I/O)
  • Proxy zu streng eingestellt (z. B. Caching, Buffering, Whitelisting)
  • Load Balancer nicht optimal eingerichtet?
  • Gestörte oder unnötig lange Route vom Webserver zum Datenbankserver / Client
  • Virenscanner auf der Strecke
  • Anzahl an Sessions auf dem Webserver zu gering limitiert
  • Zu wenig Threads auf Windows-Server Ebene?
  • ==> Performance Issues.

Ticket Cleanup Results

Ab der iAGENT Version 12.6 nimmt das System automatisch Bereinigungen von Anfragen vor, die durch verschiedene Umstände in einen Zustand geraten sind, der manuell nicht zu korrigieren ist. Die möglichen Fehlerzustände und die Art der Korrektur wird in der folgenden Tabelle erläutert. Es ist keine manuelle Aktion erforderlich. Die Informationsmail dient lediglich der Information, dass das System Anpassungen vorgenommen hat. Der Bereinigungslauf findet 10 Minuten nach dem Systemneustart (Routing-Prozess) einmalig und dann regelmäßig alle 24h statt. Da dieser Lauf erst mit der iAGENT Version 12.6 eingeführt wurde, ist es wahrscheinlich, dass dieser Lauf nach dem Update von einer Version < 12.6 auf >=12.6 beim ersten Start Einträge zur Bereinigung findet und diese mit der Informationsmail bekundet.

Technische Erläuterung zum Bereinigungslauf:

  • Die Ticketbereinigung findet 10 Minuten nach dem Start des Routing-Prozesses, und ab dann defaultmäßig alle 24 Stunden, statt.
  • Das Intervall ist in der Routing.conf konfigurierbar mit archive.ticketCleanup.interval (in Stunden, Minimum 1, Maximum 24, bei neg. Werten oder 0 wird die Ticketbereinigung gänzlich deaktiviert)
  • Die Verzögerung nach dem Start kann auch mit archive.ticketCleanup.initialDelay reduziert werden (anzugeben in Minuten)

Der Parameter für das max. Ticket-Alter ist initial der 01.01.1970 – am Ende eines Durchlaufs wird das Datum des zuletzt bereinigten Tickets in die Tabelle ROUTING_CONFIG mit Key imail.date.ticketcleanup im Format yyyyMMdd geschrieben und beim nächsten Durchlauf dann als max. Ticket-Alter verwendet. Damit wird die Laufzeit des Bereinigungsprozesses bei ständigem Betrieb immer nur auf die Menge an Tickets von einem Tag begrenzt und damit beschleunigt.

Es gibt folgende Gründe für eine Ticketbereinigung:

Grund Beschreibung Bereinigung
history empty History der Ticket-ID hat keine Einträge History-Eintrag mit Status = ERROR hinzufügen
queue failed History hat nur einen Eintrag mit Status = RECEIVED
(d.h. Ticket hat es nicht in Backlog geschafft)		 History-Eintrag mit Status = ERROR hinzufügen
unsent answered Neuester History-Eintrag hat Status = ANSWERED
(d.h. Mail ist im Postausgang, wurde aber nicht versendet, sonst wäre Status = PROCESSED)		 History-Eintrag mit Status = DELETED_ADMIN hinzufügen1
history corrupted History hat einen Abschluss-Eintrag, welcher aber nicht an letzter Stelle steht History-Eintrag mit Status = DELETED_ADMIN hinzufügen, außer der Status war bereits ERROR, dann erneut ERROR hinzufügen1
redundancy missing History korrekt, aber Redundanz in Archive nicht vorhanden oder unvollständig Redundanz in Archive ergänzen
undo processed failed Abschluss-Status (2) wurde durch Undo-Status (17) ersetzt, aber Reaktivierung war fehlerhaft (Ticket nicht im Backlog) History-Eintrag mit Status = DELETED_ADMIN hinzufügen1
undo deleted failed Abschluss-Status (3) wurde durch Undo-Status (18) ersetzt, aber Reaktivierung war fehlerhaft (Ticket nicht im Backlog) History-Eintrag mit Status = DELETED_ADMIN hinzufügen1
final state missing Ticket hat keinen Abschluss-Status (weder in History noch in Archive) History-Eintrag mit Status = ERROR hinzufügen

1 dadurch ist die Mail reaktivierbar. Der neu hinzugefügte Abschluss hat Einfluss auf das erreichte Servicelevel dieses Tickets. Daher wird ein Zeitstempel einen Tag nach dem letzten History- Eintrag für den neu hinzugefügten Eintrag benutzt.

  • Als COMMENT in den ergänzten History-Einträgen wird „{4381} – {1769}: <Grund>“ gesetzt (4381=“CleanArchive“, 1769=“Reason“)
  • Für alle durch die Bereinigung hinzugefügten History-Einträge wird die entsprechende Redundanz in Archive geschaffen (copyHistoryData) und die Ticket-ID für eine SOLR-Indexierung in die INDEX_QUEUE geschrieben.
  • Falls ein oder mehr Tickets ausgewählt wurden und die Kriterien für eine Bereinigung erfüllen, wird anschließend eine Mail mit einer Zusammenfassung an die Error-Adresse geschickt und ebenfalls in eine separate Datei in tomcat/logs/routing.ticketCleanup.yyyy-MM-dd.log geschrieben:
    • Ticket Cleanup Statistik – Wie viele Ticketleichen wurden in welcher Zeit selektiert und verarbeitet, welche Gründe lagen vor, wie viele Bereinigungen wurden geskippt oder waren nicht erfolgreich (diese Statistik wird auch ausgeloggt)
    • Details zu den einzelnen Tickets: ID, Bereinigungsgrund, einige Daten aus Archive, gesamte History des Tickets (inkl. hinzugefügter Einträge)