Domino 9 und frühere Versionen > ND6: Entwicklung

konzeptionelle Frage zum Logging

(1/2) > >>

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:

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

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. 

Navigation

[0] Themen-Index

[#] Nächste Seite