Ideen gesucht zu gemeinsamen Fehlerlogging in Dienst und GUI

[Assertor]

Hi DPler,

ich will noch schnell in der Vorweihnachtszeit ein "Problem" lösen:

Ich brauche innerhalb einer GUI und eines Dienstes Fehler/Statuslogging. Auf Low-Level Ebene ist das kein Problem, hier wird alles per exclusiven Dateizugriff im Stil vergleichbar Log4D geloggt.

Es geht bei dieser Überlegung um das verständliche Logging für den Benutzer, also auf Ebene der Business Logic. Bisher erledigt das die GUI mit einer kleinen ObjectList, die Statusart, Uhrzeit und Meldung enthält (in Zielsprache des Benutzers).

Wenn nun der Service sich um die Verarbeitung kümmert, läuft die GUI nur als visueller Aufbereiter der vorhandenen Daten. Dabei sollen auch Events seit dem Service-Start angezeigt werden, da dieser ja zeitlich unabhängig gestartet werden kann.

Hansa hat in einem anderen Thread bezüglich Logging eine Datenbank vorgeschlagen. Das hätte den Vorteil, daß man sich die Arbeit für die IPC zwischen GUI und Service sparen kann.

Nachteil wäre, da das Logging erheblich umfangreich ist, die Datenbank müsste eine Umlauf-Rotation erhalten, sonst wird das schnell zu viel an Informationen.

Ich stehe also vor der Wahl:
1) IPC zwischen Dienst > GUI und dementsprechend alle bereits vorhandene Statusmeldungen per Pipe zu übermitteln (bei 10.000 Einträgen können das schnell mal 3 MB werden)
2) Datenbank in die der Dienst loggt. Die GUI schaut nur nach, ob etwas neues vorliegt und setzt den Status (OK, Fehler etc) abhängig vom letzten Eintrag - neben der vollständigen Anzeige der Logmeldung.

Was wäre hier der elegantere Weg?

Gruß Assertor
der gerade ein 48 Stunden QS Code-Audit hinter sich gebracht hat

[alzaimar]

Die Idee mit der Datenbank ist schon mal in Ordnung, irgendwie leichter Overkill, aber es funktioniert. Über Datenmengen würde ich mir keine Gedanken machen. Dann kommen eben ein paar GB zusammen. WTF.

Viel wichtiger sind komfortable Auswerte- und Filtermöglichkeiten für den Endanwender. Alte Daten kannst Du immern noch per periodischem Aufräum-Job vernichten/verdichten.

Ich würde mir eher ein paar Gedanken über die Tabellenstruktur machen. Denn was bringt ein Logging, wenn man mit den Informationen nichts anstellen kann. Windows hat da mit den Application-Logs ein paar nette Ansatze, um Speicherplatz zu sparen. Eigne Dir mal ein paar Basis DWH-Techniken an, dann hast Du eine schön schnelle DB.

[mjustin]

Zitat von Assertor:

Ich stehe also vor der Wahl:
1) IPC zwischen Dienst > GUI und dementsprechend alle bereits vorhandene Statusmeldungen per Pipe zu übermitteln (bei 10.000 Einträgen können das schnell mal 3 MB werden)
2) Datenbank in die der Dienst loggt. Die GUI schaut nur nach, ob etwas neues vorliegt und setzt den Status (OK, Fehler etc) abhängig vom letzten Eintrag - neben der vollständigen Anzeige der Logmeldung.

Eventuell ginge auch

3) Message Broker mit Publish/Subscribe Kommunikationsmodell: die loggenden Anwendungen schreiben auf einen zentralen Message Broker, dabei können Meldungen mit hoher Priorität (Warnungen, Fehler) ein Persistenzkennzeichen erhalten, alle weniger kritischen Meldungen würden nach Erreichen ihrer Time To Live oder beim Herunterfahren des Message Brokers automatisch entfernt. Beliebig viele Clients können lesend und schreibend auf das zentrale Log zugreifen. Diese Architektur kann dann auch leicht um Load Balancing und andere Anwendungen asynchroner Verarbeitung erweitert werden.

[Assertor]

Hi alzaimar,

schön noch mal vor den Feiertagen von Dir zu lesen

Zitat von alzaimar:

Die Idee mit der Datenbank ist schon mal in Ordnung, irgendwie leichter Overkill, aber es funktioniert. Über Datenmengen würde ich mir keine Gedanken machen. Dann kommen eben ein paar GB zusammen. WTF.

Lol. Prinzipiell absolut richtig.

Zitat von alzaimar:

Viel wichtiger sind komfortable Auswerte- und Filtermöglichkeiten für den Endanwender. Alte Daten kannst Du immern noch per periodischem Aufräum-Job vernichten/verdichten.

Ich würde mir eher ein paar Gedanken über die Tabellenstruktur machen. Denn was bringt ein Logging, wenn man mit den Informationen nichts anstellen kann. Windows hat da mit den Application-Logs ein paar nette Ansatze, um Speicherplatz zu sparen. Eigne Dir mal ein paar Basis DWH-Techniken an, dann hast Du eine schön schnelle DB.

Richtig, wobei die Techniken nicht das Problem sind

Ich bin skeptisch aus einem anderen Grund: Bei diesem Projekt gibt es eigentlich nur Geht/Geht nicht. Die Einträge sind dann u.U. durchgeschleifte Fehlermeldungen (1. Stufe Business Logic, 2. Stufe Low-Level soweit notwendig).

Das richtige Debug-Logging findet eine Ebene tiefer statt, also geht es hier nur um das schöne optische: Ja, es geht oder Nein, bei XYZ gab es einen Fehler (und zwar...).

Das Auswerten im Fehlerfall ist per Debug-Logfile viel einfacher, hier ist alles sprachlich genormt, in UTF8 mit ISO 8601 Zeiten etc.pp. Da nimmt der Support einfach einen Logfile-Reader und kann auch ohne DB schnell nach bestimmten Fehlern suchen.

Etwas mehr Hintergrund zum Verständnis:
Service und GUI sind entwickelt Bestellungen aus dem Internet abzuholen und das eigentliche Order-Processing durchzuführen (XSLT, Drucken etc). Wenn der Service läuft, schaltet die GUI die Abholung ab und überlässt das dem Service. Bisher zeigte die GUI im Fehlerfall noch einen schönen Status, steuerbar per Einstellungen, im Tray / per Audio usw. Ist hier ein Fehler aufgetreten besteht die Möglichkeit über ein Laufzeit-Protokoll nachzusehen, wann wo was schiefging (oder lief).

Ich weiß, daß die Zielgruppe der Anwendung keine manuell gefilterten Abfragen auf die Log-DB braucht. Dies wäre also oversized und unnötig. Im Bedarfsfall kann man die Datensätze nach Kategorie anzeigen (nur Fehler, nur Info etc). Das reicht schon vollkommen.

Die Anwendung muß nicht viel machen (neben der Datenumwandlung), sondern wir reden hier innerhalb der Haupt-DB von ~ 100.000 DS p.a. - das ist für eine DB lächerlich wenig. Da wäre die Log-DB um den Faktor 1000 größer

Deswegen tat es bisher auch eine In-Memory Tabelle, die eine feste Rotationsgröße hatte (z.B. 100.000 DS). Wegen so kleiner Infos war also eine DB unnötig und es wurde eine TObjectList genutzt.

Diese soll nun nicht nur GUI Events, sondern auch zurückliegende Service-Events anzeigen.

Für die eigentliche Fehlersuche gibt es, wie gesagt, eine umfangreiche Log-Möglichkeit mit vielen Abstufungen, Details etc.pp.

Gruß Assertor

Roter Kasten: Das klingt Interessant, Michael. Bevor ich (wieder mal) das Rad neu erfinde: Kennst Du hier einen Ansatz der nicht zu viel Overhead hat und in Delphi umgesetzt ist. Gibt es auch Lösungen in diesem Bereich ohne externe Abhängigkeiten (MOM im Service?).

[Oreaden]

Mein Orakle lässt mich leider in stich . Was mich interessieren würde ist, wer ist denn deine Zielgruppe? Ist das für eine Komponente welche x tausendfach installiert wird oder ist das eine fertige Anwendung deren Entwicklung rein in deinen Händen liegt?

Je nach Art der Zielgruppe gibt es einen anderen Lösungsansatz. Für eine Komponente, welche ein kleines Logging enthalten soll, ist eine Datenbank welcher Art auch immer absolut oversized. Da kämme dann eher ein Flatfile oder 'n XML in betracht. Ist das eine Anwendung, welche auch schon eine bestimmte größe aufweist und zudem Funktional einiges mitbringt, wird da sowieso eine Datenbank vorhanden sein. Hier kann man die Beschränkung der Datensätze einfach über einen Trigger realisieren.

Tut mir leid, daß ich nicht mehr liefern kann, aber ohne Orakel kann ich nur die benutzen und sie ist doch etwas unzuverläßig.

Noch schöne Weihnachten
OREADEN

[mjustin]

Zitat von Assertor:

Roter Kasten: Das klingt Interessant, Michael. Bevor ich (wieder mal) das Rad neu erfinde: Kennst Du hier einen Ansatz der nicht zu viel Overhead hat und in Delphi umgesetzt ist. Gibt es auch Lösungen in diesem Bereich ohne externe Abhängigkeiten (MOM im Service?).

Der Einsatz von Message Brokern / Message Oriented Middleware ist in Delphi Anwendungen noch nicht so oft zu finden wie z.B. der Einsatz von Datenbankservern. Dabei haben sie Vorteile, wenn man weg von einer "Pull"- (Polling) zu einer "Push"- Lösung will, bei der man zur Laufzeit einfach bestimmte Message Queues oder Topics auf dem Server 'abonniert', und sie dann über TCP/IP zugestellt bekommt. Auch die Möglichkeit, die Cross-Platform / Cross-Language Entwicklung damit zu unterstützen (Web-Frontend in PHP, Clients in Delphi, Order Processing in Java oder .NET) ist ein Vorteil, zum Beispiel bei einer Erweiterung in Richtung auf eine "Application Server" basierte Lösung.

Clients für bestehende Message Broker ganz ohne externe Abhängigeiten kenne ich leider noch nicht, die meisten Implementierungen sind in der Java Welt zu finden (ActiveMQ, IONA, xmlBroker, OpenJMS, WebSphere). Es gibt auch eine Windows-Lösung von Microsoft (MSMQ), zu der ich aber nicht viel sagen kann, aber vielleicht ist sie auf der Zielplattform deiner Anwendung verfügbar, und über eine C-API ansteuerbar.

Wenn man ohnehin einen Server hat, auf dem noch Resourcen frei sind, ist ein Message Broker einfach realisiert und in wenigen Minuten (zumindest in einer Standardkonfiguration für Tests) augesetzt.

Für die meisten Message Broker gibt es eine Vielzahl von Clients, man ist so durchaus nicht an Java oder C# (oder JMS) gebunden.

[Assertor]

Hi Oreaden,

Zitat von Oreaden:

Mein Orakle lässt mich leider in stich .

Was mich interessieren würde ist, wer ist denn deine Zielgruppe? Ist das für eine Komponente welche x tausendfach installiert wird oder ist das eine fertige Anwendung deren Entwicklung rein in deinen Händen liegt?

Letzteres.

Zitat von Oreaden:

Je nach Art der Zielgruppe gibt es einen anderen Lösungsansatz. Für eine Komponente, welche ein kleines Logging enthalten soll, ist eine Datenbank welcher Art auch immer absolut oversized. Da kämme dann eher ein Flatfile oder 'n XML in betracht. Ist das eine Anwendung, welche auch schon eine bestimmte größe aufweist und zudem Funktional einiges mitbringt, wird da sowieso eine Datenbank vorhanden sein. Hier kann man die Beschränkung der Datensätze einfach über einen Trigger realisieren.

Guter Punkte mit dem Trigger!

Zitat von Oreaden:

Tut mir leid, daß ich nicht mehr liefern kann, aber ohne Orakel kann ich nur die benutzen und sie ist doch etwas unzuverläßig.

Kein Problem, freu mich ja, daß Du soviel Text jetzt schon mitgemacht hast Man kann leider nicht immer ins Detail bei kommerzieller Entwicklung.

Das ganze ist ein Tool, welches Daten abholt und verarbeitet. Eingangsdaten XML werden per XSLT aufbereitet, in einer DB gespeichert und Weiterverarbeitet (ebenfalls XSLT, Druck etc.pp.). Es kann als GUI laufen, wobei dann die ganze Arbeit von der GUI gemacht wird und dem Benutzer nachträgliche Kontrolle und Weiterverarbeitung ermöglicht, oder als Kombination einer GUI/Service. Dies auf identischer Codebasis (Datenmodule etc).

Bei Nutzung der Service/GUI-Kombi verlagert sich dann die Automatisierung in den Service. Das ganze mit austauschbarer DB (im Falle einer GUI-Only Nutzung mit SQLite3 als DB zum portablen Einsatz).

@Michael: Die Idee gefällt mir. Leider stehen soweit ich es eben abprüfen konnte, wirklich keine fertigen Libraries zur Verfügung. Da die Anwendung zu 98% steht, wäre es jetzt sehr aufwändig hier selbst etwas zu bauen.

Ich verfolge gerade aber eine andere Idee. Wegen der geringen Größe der DB könnte ich per Default auf SQLite3 setzen. Das ganze könnte ich an DataSnap 2009 per Interface-Klasse binden. Ich stelle dann zwei Klassen für Haupt-DB und Log-DB bereit (keine zweite Tabelle, das soll von den Businessdaten getrennt gespeichert werden).

Über die DataSnap Server geh ich im Falle einer Service/GUI als C/S DB. Im GUI-Only Fall dann als LocalConnection.

Damit schlage ich zwei Fliegen mit einer Klappe: Selbe Datenbankbasis für Service und Service/GUI und keine IPC Notwendigkeit.

Ich muß nur mal sehen, ob es bei DS 2009 auch sowas wie Push-To-Clients gibt.

Gruß Assertor

[mjustin]

Zitat von Assertor:

@Michael: Die Idee gefällt mir. Leider stehen soweit ich es eben abprüfen konnte, wirklich keine fertigen Libraries zur Verfügung. Da die Anwendung zu 98% steht, wäre es jetzt sehr aufwändig hier selbst etwas zu bauen.

Naja, vielleicht beim nächsten Projekt dann - Auf meiner Homepage findest Du für den Fall der Fälle Delphi Client Bibliotheken für drei Message Broker / Message Queue Systeme. Einen einfachen STOMP-basierten Client für Apache ActiveMQ gibt es von codehaus als Open Source: http://stomp.codehaus.org/Delphi

Aber jetzt ist erst mal schon wieder Weihnachten

[Assertor]

Zitat von mjustin:

Naja, vielleicht beim nächsten Projekt dann - Auf meiner Homepage findest Du für den Fall der Fälle Delphi Client Bibliotheken für drei Message Broker / Message Queue Systeme. Einen einfachen STOMP-basierten Client für Apache ActiveMQ gibt es von codehaus als Open Source: http://stomp.codehaus.org/Delphi

Danke für den Hinweis, das werde ich mir auf jeden Fall mal ansehen!

Zitat von mjustin:

Aber jetzt ist erst mal schon wieder Weihnachten

Dir auch frohe Weihnachten!

Gruß Assertor