Vor ein paar Wochen kontaktierte mich unser Partner Rok Ponikvar von S&T bezüglich eines Problems, mit dem sich einer seiner Kunden konfrontiert sah. Sein Kunde beschwerte sich, dass Enterprise Alert keine Warnungen zu aktuellen Problemen, die im OBM-System auflaufen, ausgibt. Selbst wenn er ein Test-Ticket in seinem OBM-System erstellte, wurde kein Event an Enterprise Alert gesendet und folglich auch kein Alarm. Nach ein paar weitern Mails kamen wir zu dem Schluss, dass Enterprise Alert noch immer damit beschäftigt war, ältere OBM Daten aus einer Eventflut früher am selben Tag vom zu verarbeiten. Dieses Problem löste sich dann recht schnell von allein, sodass der Impact für den Kunden nicht zu schwerwiegend war.

An dieser Stelle möchte ich möchte kurz erklären, wie eine solche Situation entstehen kann. Enterprise Alert fragt zum Schutz des eigenen und der Systeme von Drittanbietern nur eine bestimmte Anzahl von Ereignissen in einem bestimmten Intervall ab, zum Beispiel 500 Ereignisse oder Tickets alle 30 Sekunden. Wenn mehr als 500 Ereignisse oder Tickets erstellt werden, sagen wir 750, werden innerhalb dieser 30 Sekunden nur die 500 ältesten abgefragt und die restlichen, in diesem theoretischen Fall 250, bleiben für den nächsten Zyklus übrig. Wie Sie sich vorstellen können, kann sich so mit der Zeit ein ziemlicher Rückstau von Events aufbauen. Enterprise Alert arbeitet diesen Rückstand ab, sobald das Drittanbietersystem weniger Ereignisse oder Tickets generiert als von Enterprise Alert abgefragt werden.

Doch zurück zum eigentlichen Problem und seiner Lösung. In der weiteren Diskussion fragte Rok, ob es eine Möglichkeit gibt, das System auf eine Verzögerung zu überwachen. Ich wies ihn auf die Tabelle ModuleServiceProperties hin, da die meisten unserer modernen Smart Konnektoren dort Polling-Informationen speichern, um beim Neustart des Dienstes einen Anfangszeitstempel zu haben und um Synchronisierungsdaten für HA-Setup bereitzustellen. Rok hat daraufhin eine SQL-Abfrage geschrieben, um sein System auf ein eventuelles Sync-Problem zwischen Enterprise Alert und seinem OBM-System zu überwachen.

Er hat diese Abfrage freundlicherweise mit mir geteilt, damit alle davon profitieren können. Vielen Dank an Rok Ponikvar für diesen Beitrag.  😊

DECLARE @lastevent datetime
DECLARE @obmsynctime datetime
SELECT @obmsynctime= [Value]  FROM [<your_database_name>].[dbo].[ModuleServiceProperties]   WHERE [Name] = 'LastTimestamp' and [ModuleServiceID]= '<your_Service_ID>'
SELECT TOP (1) @lastevent =  [Timestamp]  FROM [<your_database_name>].[dbo].[EAEvents]   WHERE [ModuleServiceID]= '<your_Service_ID>'  order by [Timestamp]  desc
SELECT ABS(datediff(MINUTE, @lastevent , @obmsynctime )) as SyncDiff

Bitte beachten Sie, dass Sie <your_database_name > durch den Namen Ihrer Datenbank ersetzen müssen (Standard ist entweder MMEA oder EnterpriseAlert) und <your_Service_ID > durch die ID des Dienstes, den Sie überwachen möchten. Sie können die ID auch aus der Tabelle ModuleServiceProperties ablesen, da dort ein Eintrag für den Service Typ und einer für den Zeitstempel vorhanden ist. Wenn Sie mehrere Konnektoren desselben Typs verwenden, wird es etwas komplizierter, aber dafür gibt es ja support@de.derdack.com. 😉 .