XML Logfile für SW-Applikationen

[Claus W. (claus_w)]

Eigen erstellte PC-Software (Hardware Testprogramm mit Multimeter) 
bringt komplizierte Nachverfolgung und Reporterstellung mit sich. 
Deshalb versuche ich jetzt, ein XML-Logfile zu erzeugen, das eine große 
Anzahl Ereignisse in der Form:

<LogEvent timestamp="" 
message=""><OptionalInfo>...</OptionalInfo></LogEvent>

stets mitschreibt. Ausnahmen von Threads, Testabläufen und grafischen 
Steuerlementen sollen auch mitgeschrieben werden. Auch Messergebnisse. 
Man könnte auch einen XSyslog-Dienst einrichten der eine Kopie hält. 
Wird eben bei dem Log-Event noch ein Herkunftsattribut eingefügt. 
Zunächst steht in dem Logfile aber noch kein XML Rootelement. Somit kann 
immer angehängt werden.

Zu Auswerten klammert man eine Kopie des Logfiles noch in ein

<root>...</root> - Element.

Wozu kann man es nutzen?

- Man muss auf den Schutz persönlicher Daten achten. Daher eher für 
Technik-SW geeignet.
- Aus dem Logfile kann man einen Auszug mit den Messergebnissen für ein 
bestimmtes Testobjekt anfertigen (wieder XML). Daraus kann XSLFO einen 
PDF-Report erzeugen.
- Es sind auch aufgetretene Ausnahmen in Zusammenhang mit 
Messergebnissen enthalten (z.B. Division durch NULL, zu Ende geführter 
Test trotz Ausnahme, der nicht gültig ist aber Fehlerinformationen 
enthält).
- Ein Editor, dessen Fensterposition mitgeloggt wurde, kann beim 
nächsten Start das Logfile fragen und mit dieser Fensterposition wieder 
öffnen.
- Undo-Funktionen würden auch weit zurückreichen.

Mal sehen, was sich aus dem XML alles so herausgreppen lässt...

[Purzel H. (hacky)]

Cool. Mach mal.

[JJ (Gast)]

2 cent:

Ich persönlich arbeite eigentlich lieber mit zeilenorientierten Daten 
weil die Weiterverarbeitung mit grep und Ecxel deutlich flüssiger von 
der Hand geht.

Für die coolen Leute ist sicher noch ein einfacher Input in R wichtig.

[Jack (Gast)]

Aha, XML. Was sagt die W3C, Hüterin des XML-Standards, noch mal über 
XML? Ach ja:
>> ... the main properties that are considered lacking from XML are
>> Compactness and Processing Efficiency, ...

Daher ist XML in der Tat ein hervorragender Ansatz wenn die Mission ist, 
dass jeder Embedded-Computer in Zukunft mindestens ein 8-Kern CPU mit 2 
GHz Taktfrequenz und 16 GB Hauptspeicher benötigt.

Für verbesserte Wirkung, und im Hinblick auf das Missionsziel, würde ich 
ein professionelles XML-Format empfehlen, wie es für wirklich große, 
komplizierte Systeme eingesetzt wird. Etwas, bei dem alleine schon der 
Titel der Spezifikation Fans der gepflegten Komplexität Freudentränen in 
die Augen treibt.

https://www.etsi.org/deliver/etsi_ts/132400_132499/132435/15.00.00_60/ts_132435v150000p.pdf
>>> Digital cellular telecommunications system (Phase 2+) (GSM);
>>> Universal Mobile Telecommunications System (UMTS);
>>> LTE;
>>> Telecommunication management;
>>> Performance measurement;
>>> eXtensible Markup Language (XML) file format definition
>>> (3GPP TS 32.435 version 15.0.0 Release 15)

[Claus W. (claus_w)]

Habe es jetzt propiert.

Jeder Logeintrag ist eine Zeile. Mit dem RandomAccessFile extrahierte 
ich Byte für Byte rückwärts aus dem File bis eine Zeile erreicht war. 
Bei falschem Treffer notierte ich die letzte Position und machte mit der 
vorletzten Zeile weiter. Ich kettete alle Bytes der Zeile zusammen. 
Dummerweise kam so das XML Element rückwärts raus. Seitdem kette ich 
rückwärts damit das XML Element vorwärts entsteht.

Somit startet die Anwendung stets mit der letzten Fensterposition.

[Dirk K. (merciless)]

Claus W. schrieb:
> Habe es jetzt propiert.
>
> Jeder Logeintrag ist eine Zeile. Mit dem RandomAccessFile extrahierte
> ich Byte für Byte rückwärts aus dem File bis eine Zeile erreicht war.
> Bei falschem Treffer notierte ich die letzte Position und machte mit der
> vorletzten Zeile weiter. Ich kettete alle Bytes der Zeile zusammen.
> Dummerweise kam so das XML Element rückwärts raus. Seitdem kette ich
> rückwärts damit das XML Element vorwärts entsteht.
>
> Somit startet die Anwendung stets mit der letzten Fensterposition.

???
Sorry, aber ich verstehe nur Bahnhof.
Welche Fensterposition? Warum XML von
Hand parsen?

merciless

[Claus W. (claus_w)]

Ich habe ein PC-Programm geschrieben, das Embedded-Geräte mit dem Dmm 
messen soll. Das PC-Programm macht ein Fenster auf und zeigt in einem 
Scrollbereich sämtliche Testschritte an. Beim Schließen des Fensters 
wird die Fensterposition, Fenstergröße, Scrollposition und der Name der 
geöffneten Datei in das Logfile geschrieben. Und zwar als einzelnes 
XML-Element das genau eine Zeile braucht. Für nähere Hinweise kann in 
dieses Element auch ein Kindelement eingebaut werden aber ohne die Zeile 
zu wechseln. Es kommt aber nicht alles in das Logfile, einige Dinge 
werden auch einfach verworfen.

Das Auslesen des Files erfolgt, indem vom Ende des Files jeweils eine 
Zeile kopiert wird. Aus dieser erzeuge ich ein Xml-Document das nur aus 
dem Inhalt dieser einen Zeile besteht. So kann ich von drei, vier 
letzten Zeilen mehrere kleine XmlDocumente erzeugen oder auch deren 
Inhalte kombinieren.

Auf die Art könnte ich auch eine Undo-Funktion implementieren oder die 
letzten fünf geöffneten Dateien auflisten, wenn es mal soweit kommt. Ein 
gesamter Testlauf könnte somit ein Start-Logeintrag und ein 
End-Logeintrag schreiben. Dazwischen kämen sämtliche Messergebnisse. 
Somit ist alles rückverfolgbar.

[DPA (Gast)]

Ich halte XML für keine gute Wahl für soetwas. Nimm lieber JSON. Es ist 
immer möglich ein JSON Objekt in eine einzige Zeile zu Packen, und die 
Datenstruktur ist einfacher.

[Dirk K. (merciless)]

Also ich denke du vermischst hier 2 Dinge:
Logfiles dienen normalerweise nur der Protokollierung.
Diese werden danach vielleicht ausgewertet.
Das was du aber auch darin speichern möchtest,
ist ein Zustand deines Programmes, den du
beim erneuten Start wiederherstellen willst
(so eine Art Session).

Hast du nur ein Logfile, oder erzeugst du
verschiedene (für jede Messung eines)? Willst
du diesen Zustand für alle Messungen gemeinsam
speichern oder für jede Messung separat?

Auch halte ich XML für diese Art Anwendung als
nicht geeignet: XML dient normalerweise dem
Datenaustausch mit anderen System, evtl. noch
als Ersatz für ini-Configfiles. Für alles
andere gibt es bessere Lösungen. Hast du mal
an eine Datenbank gedacht (SQLite)?

merciless

[Claus W. (claus_w)]

Es ergeben sich tatsächlich Performance-Probleme beim Programmstart wenn 
man um die 1000 Zeilen zurücklesen muss. Wahrscheinlich benötigt der 
Konstruktor für das XmlDocument einige CPU-Zeit.

[Claus W. (claus_w)]

Es kam zu Performance-Problemen weil das File 2MByte lang ist (und 
wächst) und öfter schnell mal gelesen werden muss. Festplatten benötigen 
eine geringere Zeit um den Schwenkarm zu positionieren und eine etwas 
längere Zeit damit sich die Platte auf den entsprechenden Winkel dreht. 
Das würde Vorwärtslesen gegenüber Rückwärtslesen bevorzugen. Z.B. wären 
6000 U/min => 600U/s => 600 Hz. Der Bereich des Rückwärtslesens wäre bei 
mir auf etwa 2MByte begrenzt aber Rückwärtslesen ohne Block dauert damit 
fünf Sekunden pro Suche. Falls Festplatten mit FLASH optimiert sind ist 
mir die Geschwindigkeit des Rückwärtslesens unbekannt (weiß nicht ob ich 
eine FLASH-Platte habe) aber ich rechne mit längerer Dauer für das 
Rückwärtslesen.

Somit habe ich optimiert auf jeweils einen Block von 4kByte vom Ende 
beginnend vorwärts zu lesen und in XML zu parsen worauf später der 
Vorgänger dieses Blockes folgt.

=> Parsen: Mit dem StringBuilder in das <root>-Element verpacken.

=> Beginn des Blockes finden: Ausnahmsweise byte für byte einzeln 
rückwärts lesen bis der Zeilentrenner erreicht ist.

Somit kann man die 2MByte in weniger als einer Schrecksekunde lesen. Im 
Taskmanager sieht man keinen hohen CPU-Verbrauch.

[A. S. (achs)]

Erde an Claus, Erde an Claus, hast Du die Kommentare hier verstehen 
können?
Warum XML, warum rückwärts, warum zeilenweise XML (statt zeilenweise 
ODER XML)?

[Bernd K. (prof7bit)]

Claus W. schrieb:
> Es kam zu Performance-Problemen weil das File 2MByte lang ist (und
> wächst) und öfter schnell mal gelesen werden muss.

Dann nimm eine Datenbank wenn du das Ding wie eine Datenbanktabelle 
benutzen willst, genau dazu wurden Datenbanken erfunden und hochgradig 
optimiert damit man eine Datenbank benutzen kann wenn eine Datenbank 
braucht und sich keine eigene Datenbank schreiben muss welche dann mit 
Unzulänglichkeit und unterirdischer Performance glänzen würde so wie 
Deine selbstgebastelte Datenbankattrappe.

[DPA (Gast)]

Als Datenbank könnte dann sqlite für dich interessant sein. Die 
Datenbank ist dann auch nur eine Datei.

[Märchenonkel (Gast)]

Wieder ein Fall von "Pfuscher verwendet wieder ohne Hirn und Verstand 
Technik X von der mal gehört hat dass das toll wäre".


Kennst du überhaupt die Vorteile wo man besser XML verwendet und wann 
nicht? Da würde ich erst mal ansetzen, sieht nämlich nicht so aus.

Denk mal nach warum XML für dein Vorhaben von Vorteil oder Nachteil 
wäre, danach entscheidet man sich.

Wenn ich schon lese "aus XML herausgreppen" da ist ja schon Hopfen und 
Malz verloren.

[Dein Freund und Helfer (Gast)]

Wegen 2MB rückwärts lesen? In mehrere 4KB Häppchen?

Das ist: Blödsinn.

Lies die 2MB am Stück, ganz normal, mit einem XML-Parser ein. Dann den 
letzten XML-Node, der interessiert, verwenden. Fertich.

Dauert ca. 50ms.