konzeptionelle Frage zum Logging

[julius.g]

Hallo,
ich habe gerade ein Projekt übernommen, bei dem das vorhandene Logging von Benutzeraktivitäten umgestaltet werden soll.

Bei jedem Öffnern, Speichern etc. eines Docs erfolgt ein Eintrag in ein Protokolldokument. Die Protokolldokumente befinden sich in der gleiche Datenbank, wie die "Nutzdokumente". Das Protokolldokument wird stets fortgeschrieben, also 1 Log-Doc je Nutz-Doc. Die DB befindet sich im Clustereinsatz, daher kommt es immer wieder zu Replizierkonflikten im Log, auch wenn die Dokuemte nur gelesen werden. Document locking in der LogDB ist nicht gewollt.

Die gesammelten Logginginformationen sollen im Nutzdokument über einen Actionbutton in einem Popupfenster angezeigt werden.
Das ganze muss recht performant sein, die DB hat, trotz geregelter Archivierung etc, gute 30.000 Dokumente und wird von 30 Usern täglich genutzt.

Welche Alternativen habe ich?
1.) Erzeugen einer Log - Datenbank und einzelne History - Docs je Zugriff
2.) Erzeugen einer Log - Datenbank und Fortschreiben eines History - Docs
3.) ??

und welche ist sinnvoll?

Besten dank für Eure Vorschläge!

[eknori]

gute 30.000 Dokumente und wird von 30 Usern täglich genu

keiner der 30 User wird jeden Tag alle Dokumente lesen/bearbeiten. Daher würde ich mir um die Performance nicht allzugrosse Sorgen machen.

Ich würde das Log in die selbe Datei wie die Nutzdaten schreiben ( oder in eine getrennte DB, wenn die Mimik auch bei anderen Dbs eingesetzt werden soll ).

Pro User ein HistoreienDoc, welches Alle Zugriffe dokumentiert; oder pro DocID ein LogDoc, welches alle Zugriffe der User enthält. Beides lässt sich dann in Ansichten entsprechen darstellen zwecks Auswertung.



Ulrich

[koehlerbv]

Mir ist noch nicht gany klar, woyu ein derartiges Logging dienen soll. Welche Informationen wollt Ihr dort herausholen und mit welchem Aufwand ?

Wenn es ein Log-Dokument pro Nutz-Dokument sein soll, muss das Logging in einem RTF gespeichert werden. Gleiches gilt für ein Dokument pro User (und gerade dort). Sonst ist irgendwann das Logging-Item voll.
Und damit gilt: Dieses Dokument lässt sich vernünftig nicht auswerten.

Wenn sowas schon sein muss:
- eigene Log-DB und damit nicht die Nutz-DB vollmüllen
- für jeden Vorgang ein eigenes Dokument. Der Erzeuger des Log-Dokuments erhält Leserrechte (+ Admin + Auswerter), damit jeder nur das sieht, was er selber fabriziert hat.
- Probleme mit der Log-DB müssen zum Abbruch jeder Aktion im Nutzdok führen.

Auf diese Weise trennt man sauber die Daten, schliesst Replizierkonflikte aus, kann sauber archivieren (was dann sicherlich notwendig wird) - und kann vor allem vernünftig Auswertungen via Views erzeugen.

Wie gesagt: Der Sinn der Aktion würde mich sehr interessieren, da ja bisher vor allem Daten gesammelt werden, Auswertungen aber wohl eher arg schwierig sind.

Bernhard

[julius.g]

Morgen,
erst mal schönen Dank für die Antworten.

Die Dokumente dienen dazu, dass jeder User nachvollziehen kann, welcher User wann, welche Dokumente betrachtet oder bearbteitet hat. Von daher muss jeder User diese Dokumente sehen können. 
Aus diesem Grunde ist ein LogDoc je Anwender meiner Ansicht nach nicht sinnvoll, oder hab' ich jetzt nen Denkfehler?

[flaite]

I second Bernhard (getrennte Log Datenbank).
Und: Es gibt präfabrizierte Lösungen von Lotus (aLog.ntf-Template*) und auch eine openSource Lösung, die ich mir an deine Stelle unbedingt anschauen würde.
http://www.openntf.org/Projects/codebin/codebin.nsf/CodeByDate/BE540FBC95AB8B4C86256DD700207C8A
(braucht imho nicht unbedingt Java).

Es ist zwar sehr einfach, sich selbst ein Logging zu basteln.
Was ich aber in größeren vorhandenen Anwendungen erlebe, dass da sich irgendwann ein Haufen von "einfachen" Elementen zusammenkommen und da wird es dann naturgemäss irgendwann schwieriger, den Überblick zu behalten.

Solche präfabrizierten Lösung führen zu einer Standardisierung des Codes. Und das macht ihn leichter verständlich. Ausserdem gibt es da Zusatzfeatures, die mit selbstgedrehten Logging nur mit gewissen Aufwand zu programmieren sind. 
Zwar hat das Beherrschen dieser Standardkomponenten eine gewisse Lernkurve. Es zahlt sich aber imho schon nach kurzer Zeit aus. Ich empfehle z.B. auch dringend Logging für Integrationsprojekte (etwa mit RDBMS) zu benutzen.

Das gute an der openSourceLösung log4dom ist, dass es an log4j angelehnt ist. Du lernst dann quasi eine Logging-Lösung für 2 Plattformen und Java-Entwickler benutzen log4j bzw. jdk14-Logging eigentlich immer.

Axel


* Genauere Infos findest du im Designer-Hilfe-Dokument Making a Domino Log. 

[julius.g]

ich habe mir mal die log4Dom angeschaut. Macht wirklich nen guten und schlanken Eindruck. Mein Bedenken geht nur dahin, dass ich aus den Nutzdokumenten einen Lookup auf die LogDB (anhand UnID) machen möchte, um den User alle Einträge anzuzeigen. Da ist nur die Frage, ob die Lösung performant genug sein wird. Ich rechne mit 15-20 Docs, in Summe ca. 150.000, kein User will darauf > 1 sekunde warten. Wird das passen? (Die Hardware drunter sollte kein Problem darstellen)

Archivieren kann ich das Log erst, wenn das NutzDoc ins Archiv gewandert ist...