Laden...

EventLogRecord.FormatDescription -> Alternativen?

Erstellt von inflames2k vor 6 Jahren Letzter Beitrag vor 6 Jahren 1.896 Views
inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 6 Jahren
EventLogRecord.FormatDescription -> Alternativen?

Hallo,

in einem Programm zur Logauswertung werden die Einträge des Ereignisprotokolls ermittelt und angezeigt. Das funktioniert soweit super.

Verwendet wird der EventLogReader zum Auslesen der Einträge, da die EventLogEntry-Klasse nicht alle benötigten Informationen bereitstellt.

Nun ist allerdings das Problem, dass die Meldung des Ereignisses im EventLogRecord erst zur Abfragezeit ermittelt wird und dies z.T. bis zu 2 Sekunden dauert. Das führt teilweise dazu, dass schon bei nur 30 Einträgen eine Minute erforderlich ist zur Ermittlung der Meldungen.

Gibt es einen effizienteren Weg, die Meldung zu erhalten? Via google treffe ich leider nicht auf vielversprechende Beiträge.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 6 Jahren

Da bisher keiner eine Antwort hat, habe ich mal ein Minimalbeispiel für die Anzeige und Filterung erstellt. Im Anhang ist dieses zu finden.

Beschränkt habe ich mich auf Message und Kategorie zum FIltern, da dies die Problemkinder sind. Gefiltert wird über das Kontextmenü des DataGridViews.

// EDIT:
Je mehr Einträge vorhanden sind, desto länger dauert es. Aufgrund meiner "Speicherung" der Meldung und Kategorie im Objekt nachdem diese das erste mal gelesen wurden, betrifft dies zum Glück nur den ersten Filtervorgang.

// EDIT2:
Um noch Zeiten zu liefern, wie viel länger es dauert FormatDescription direkt bei der Initialisierung zu erstellen:

Elapsed Reading without initializing: 00:00:03.2891373
Elapsed Reading with initializing: 00:13:11.0264655

Bei gleicher Datenmenge, versteht sich.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 6 Jahren

Ich habe zwar nach all dieser Zeit nicht die Hoffnung, dass jemand nun eine Idee hat, aber eventuell täusche ich mich ja auch.

Hat denn noch keiner Ereignisprotokolle in eigene Anwendungen geladen und das extreme zeitliche Problem gehabt? Ich meine, das Laden der Einträge ist ja noch verflucht schnell für die teilweise großen Datenmengen. - Aber wenn man dann für den Meldungsinhalt z.T. mehrere Sekunden warten muss wenn man diesen auslesen will ist das schon grenzwertig.

Ich habe bereits mehrere Ansätze versucht um das ganze zu beschleunigen. Darunter:*Bei Lesen bereits ein FormatDescription aufrufen => Lesen wird extrem langsam *Nach Laden über Multithreaded Meschanismus FormatDescription für alle Einträge aufrufen => Extrem langsam, Einträge werden auch trotz Multithreaded Meschanismus seriell gelesen (FormatDescription blockiert intern, Instanzübergreifend)

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

1.029 Beiträge seit 2010
vor 6 Jahren

Hi,

um ehrlich zu sein besteht bei mir kein solches Problem.

In meinem Systemlog sind fast 5.000 Einträge - die Software startet in < 2 Sekunden - filtern geht auch erwartungsgemäß in < 1 Sekunde. (Sowohl im Debug als auch im Release)

Bei mir ist gefühlt die Anzeige des DataGridView der Flaschenhals...

LG

Edit:
Beim ersten Filtervorgang sind's vll auch 2 Sekunden wenn man vorher nicht durchscrollt... Was nutzt du denn für eine Maschine? Hab selbst nämlich eigentlich hier nix dolles - 700€.

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 6 Jahren

Naja, speziell bei größeren Logs mit mehr als 200K Einträgen fällt das schon ins Gewicht.

Wenn man Beispielsweise statt des "Application"-Logs das "Security"-Log nimmt startet die Beispielanwendung rasend schnell. - Beim Filtern kommt es dann aber zu ewigen Ladezeiten.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

1.029 Beiträge seit 2010
vor 6 Jahren

Hi,

bei der Menge kannst du mal probieren dich um das Problem herumzulavieren.

Laut folgendem Thread:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/f9a0e201-d5d0-4bbe-bc32-76a0657f57f6/eventrecords-formatdescription-is-super-slow?forum=csharpgeneral

wäre es den Versuch wert folgendes zu versuchen:
a) wevutil qe System /f:RenderedXml
b) Xml wieder parsen und dann damit erst arbeiten

Das wird zwar langsamer als ein Start ohne Laden sein - allerdings vermutlich um Welten besser als die einzelnen Aufrufe.

LG

PS: Feedback würde mich da wirklich interessieren - hab auch einen EventLogReader - der arbeitet allerdings nur im Hintergrund.

Edit: Folgender Link sieht nach PInvoke für das Thema aus - wenn's funktioniert sicher noch besser: https://blogs.technet.microsoft.com/david_bennett/2006/03/24/reading-in-crimson-logs/

inflames2k Themenstarter:in
2.298 Beiträge seit 2010
vor 6 Jahren

Hallo,

den Ansatz hatte ich bereits probiert aber nicht als praktikabel abgetan. - Gründe weiß ich gar nicht mehr. Irgend etwas hatte mich daran gestört.

Den zweiten Link sehe ich mir mal an. Wir nutzen die Anwendung aber auch auf Systemen < Vista. - Mal sehen ob sich daraus eine brauchbare Lösung erstellen lässt.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

T
708 Beiträge seit 2008
vor 6 Jahren

Bei Lesen bereits ein FormatDescription aufrufen => Lesen wird extrem langsam

Nach Laden über Multithreaded Meschanismus FormatDescription für alle Einträge aufrufen => Extrem langsam, Einträge werden auch trotz Multithreaded Meschanismus seriell gelesen (FormatDescription blockiert intern, Instanzübergreifend)

Dann ist das Bottleneck doch wohl lokalisiert.
Das EventLog ist Multilanguage-fähig, was sicherlich einige Resourcen erfordert um den Text darzustellen.

Bisher habe ich mir immer nur per EventLogReader die gefilterten Einträge geholt und erst bei der Anzeige den Eintrag.ToXml() in was einigermaßen lesbares umgewandelt.
Das geht schnell, ist aber ausschließlich englisch und nicht so sonderlich schön. Popel mir dann per Regex die wichtigsten Stellen aus dem XML und fertig.

Für meinen Anwendungsfall reicht es zumindest aus und ist performant. Egal wie viele Einträge im Log liegen. (Filter aber i.d.R. nur auf mein Programm und die letzten 30 Tage)