Laden...

Zyklisches Logging von identischen Fehlern verhindern

Erstellt von mosspower vor 10 Jahren Letzter Beitrag vor 10 Jahren 1.950 Views
mosspower Themenstarter:in
456 Beiträge seit 2007
vor 10 Jahren
Zyklisches Logging von identischen Fehlern verhindern

Hi,

ich benutze log4net beim Logging und hätte mal eine Frage bezüglich von zyklisch auftretenden, identischen Fehlern - kann man das irgendwie innerhalb des Frameworks handeln oder muss man da was eigenes programmieren?

Ein Beispiel wäre eine Verbindung, die nicht zur Verfügung steht für 5 Minuten, aber in einem Thread wird jede Sekunde versucht auf die Verbindung zuzugreifen. Ohne weitere Anpassungen hat man jetzt im Logfile 300 identische Fehlermeldungen stehen, dass die Verbindung nicht vorhanden ist - klar, kann man da schnell selber was programmieren, dass nur beim 1. Auftreten des Verbindungsausfalles gelogged wird und danach nicht mehr ... war aber nur ein Beispiel von vielen, um die Problematik verständlich zu machen.

Meine Frage jetzt. Gibt es da schon was - Problematik tritt ja sehr häufig auf im Zusammenhang mit Threads und zeitkritischen Sachen, gerade bei Connections (Internet, Datenbanken) oder Fileverarbeitung auf.

Gruß und Danke schon einmal für etwaige Antworten im Voraus!

C
2.121 Beiträge seit 2010
vor 10 Jahren

Ich hab keine Ahnung ob sowas in log4net drin ist oder nicht. Ich stells mir nur aufwendig vor, denn du brauchst ja irgendwas wie ResetError und so weiter, damit du dem Framework sagst ob es den Fehler nächstes mal noch nicht loggen soll oder eben doch wieder.
Je nach Art des Fehlers/Netzwerls willst du vielleicht (evtl. nicht jetzt aber irgendwann) nicht den ersten Fehler gleich loggen, sondern erst wenn 10 Sekunden lang nichts mehr funktioniert hat oder so.

Da wär jetzt für mich die Frage, will ich was lernen oder will ich aktuell schnell weiterkommen. Ich weiß, heißt "not invented here syndrom". Aber solange ich mit was selbstgemachte, schneller und übersichtlicher bin als wenn ich ewig suche, ists mir egal 😃

849 Beiträge seit 2006
vor 10 Jahren

Log4Net kann das bestimmt,

aber ich glaube Du kommst nicht darum, einen eigenen Appender zu schreiben. Schau mal hier: Writing a Custom Appender

Hatte mal sowas ähnliches gemacht weil ich nicht im Sekunden takt Emails haben wollte, wenn mal die DB Verbindung weg war 😉

C
1.214 Beiträge seit 2006
vor 10 Jahren

Man könnte das bestimmt in log4net implementieren. Es gibt z.B. die IFilter Schnittstelle, oder man könnte wie unconnected geschrieben hat, auch einen eigenen Appender schreiben.

Ich bin mir nur nicht sicher, ob das sinnvoll wäre. Ich finde, sowas gehört eher an die Stelle, wo der Fehler auftritt. Im Logging Framework hast du zu wenig Informationen. Da hast du ja nur noch den Fehlerstring. Du könnest entweder ganz naiv schauen, ob der gleiche String in den letzten 2 Sekunden schon gekommen ist, oder du versuchst ihn zu parsen, aber das wär auch nicht sauber, und damit würdest du einen Teil der Logik ins Loggingframework verlagern, die da nicht reingehört. Am besten, weiter oben abfangen.
Muss vielleicht nicht genau an der Stelle sein, wo der Fehler auftritt, aber vielleicht kannst du eine Schnittstelle für Fehlerausgaben dazwischenschalten, die sich darum kümmert.

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo Coder007,

ich halte deinen Einwand bis zu einem gewissen Maße für gerechtfertigt. Allerdings teile ich deine Schlussfolgerung nicht. Natürlich muss dem login-Framework gesagt werden, was es tun soll. Und natürlich soll keine Anwendungslogik ins logging-Framework. Aber deshalb nun an allen Aufrufstellen rumdoktorn, kann auch nicht die Lösung sein.

Es kommt natürlich darauf an, was das logging-Framework für Informationen bekommt. Sicher wäre es ungünstig, wenn man nur an Hand eines fertig formatierten Fehlerstrings entscheiden müsste, ob dieser angezeigt werden soll. Aber wenn eine Fehlernummer übergeben wird (oder einheitlich im Fehlerstring steht), sieht das ganze schon viel freundlicher aus.

Ich denke also schon, dass man mit IFilter oder einem eigenen Appender recht weit kommen kann. Ohne das dies zwangsläufig schlechtes Design wäre.

herbivore

mosspower Themenstarter:in
456 Beiträge seit 2007
vor 10 Jahren

OK, vielen Dank für die Antworten.

Wäre jetzt ja nicht mein erster Appender: log4Net - ArchivRollingFileAppender ... ich dachte halt, ich frag erst mal hier nach, bevor ich mit einem Appender beginne, weil evtl. es schon eine Lösung gibt, die mir nicht bekannt ist - man soll ja net immer das Rad neu erfinden (sonst werden wir ja nie fertig)

Gruß und Danke für die Antworten und Anregungen.

C
1.214 Beiträge seit 2006
vor 10 Jahren

Sicher wäre es ungünstig, wenn man nur an Hand eines fertig formatierten Fehlerstrings entscheiden müsste, ob dieser angezeigt werden soll. Aber wenn eine Fehlernummer übergeben wird (oder einheitlich im Fehlerstring steht), sieht das ganze schon viel freundlicher aus.

In die Richtung ging mein Vorschlag mit der Schnittstelle für Fehlerausgaben, die man dazwischenschalten könnte. Logging Frameworks wie log4net sind zu weit unten angesiedelt und bekommen nur einen String. Dazwischen könnte man allerdings eine Schnittstelle wie IErrorLogger einhängen, die mehr Informationen bekommt und die entsprechend konfiguriert werden kann, z.B. bei Fehlern mit einer bestimmten Nummer (oder vielleicht auch nur bei einem bestimmten String) x Sekunden auf weitere Fehler warten und dann eine andere Fehlermeldung ins Log schreiben. Das wäre dann zentral implementiert und müsste nicht direkt ins Logging Framework.

849 Beiträge seit 2006
vor 10 Jahren

bekommen nur einen String

hmm.. hast Du log4net schonmal benutzt?

C
1.214 Beiträge seit 2006
vor 10 Jahren

Ja, aber hauptsächlich log4j und log4cxx. Machs nicht so spannend, sag einfach was du meinst.

849 Beiträge seit 2006
vor 10 Jahren

Ich meine das man gerade wenn man auf Appender ebene ist noch sehr viel mehr Informationen hat wie einfach nur einen String.
Unter anderem auch die Exception selber.. Falls man sie denn dem Logger übergeben hat.

C
1.214 Beiträge seit 2006
vor 10 Jahren

Naja, sehr viel mehr ist es ja nicht. Informationen wie Log Level und Position im Code sind hier ja eher irrelevant. Was noch mehr oder weniger interessant ist, ist tatsächlich die Exception. Konkrete Exceptions will man im Logging Framework natürlich nicht kennen. Was ich mir noch vorstellen könnte, wäre eine Zuordnung Exceptiontype -> Regel. Das könnte man vielleicht tatsächlich machen.
Was mir dabei immer noch nicht wirklich gefällt, ist dass man dafür einen Appender schreiben muss. Eigentlich würde es eher in einen Filter passen, aber das würde nicht funktionieren.

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo Coder007,

man braucht ja nicht möglichst viel Information, sondern es reicht, wenn man die Information hat, die man braucht. Natürlich sollte der Appender die konkreten Exceptions nicht kennen. Muss er aber auch nicht. Entweder er bekommt eine Liste von Type-Objekten für die zu filternden Exceptiontypen. Oder er implementiert selber eine Filterschnittstelle. Sprich er bekommt ein eigenes IFilter-Objekt oder einen Filter-Callback. Dann kann die eigentliche Filterlogik dort und nicht im Appender implementiert werden. Der Appender muss dann nur die Filter-Methode aufrufen und deren Rückgabewert anschauen, um zu wissen, ob loggen oder ignorieren soll.

herbivore

C
1.214 Beiträge seit 2006
vor 10 Jahren

Sprich er bekommt ein eigenes IFilter-Objekt oder einen Filter-Callback. Dann kann die eigentliche Filterlogik dort und nicht im Appender implementiert werden.

Das hilft aber auch nicht weiter. Man braucht dann trotzdem den eigenen Appender, der den Filter bekommt und kann nicht irgendeinen anderen (oder mehrere andere) Appender verwenden. Oder hast du das anders gemeint?
Was man aber wohl machen könnte, wäre ein "Filter Appender", der das LoggingEvent an andere Appender weitergibt. In der Config würde man dann als Eigenschaft des Appenders die Klasse des Zielappenders angeben.

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo Coder007,

wenn man einen Appender schreibt, dessen besonderes Feature ist, dass er - wie beschrieben - auf eine bestimmte Art filtern kann, weil das mit dem vorhandenen Filtermechanismus nicht möglich ist, ist klar, dass man keinen anderen Appender verwenden kann, wenn man filtern will. Das ist zwar schade, aber nicht wirklich schlimm. Auf jeden Fall hat man die Zuständigkeiten so klar getrennt, wie es aufgrund der Umstände eben geht. Alles was darüber hinausgeht, würde ich als Luxus ansehen, von dem unklar ist, ob man es überhaupt je braucht. KISS. Sollte man es irgendwann tatsächlich brauchen, kann man immer noch auf das umstellen, was du zuletzt vorgeschlagen hast. Wobei man das dann vielleicht besser über den Decorator-Pattern realisieren könnte.

herbivore