Das Thema würde ich in 3 Schritte unterteilen:

1. log4Net lauffähig machen
   Bei uns auf Arbeit ist l4n so konfiguriert, dass in einem bestimmten Ordner eine bestimmte .log-Datei erzeugt wird, und wenn die grösser als glaub 5000 Zeilen wird, dann benennt die sich um, kriegt ein Nümmerken, und eine neue .log wird angefangen.
   Und wenn 50 solche Logfiles voll sind, dann wird die älteste gelöscht, und die anneren werden umbenannt, sodass wir immer die .log haben und 50 weitere, durchnumerierte.
   Damit können wir log-mässig glaub 6 Monate in die Vergangenheit blicken, aber nicht mehr.
   
2. Dann ist ein Konzept wichtig, was einen Log-Eintrag wie einen Datensatz definiert
   Also dass die .log gelesen werden kann wie eine Tabelle mit festen Spalten - sowas wie Zeit, LogLevel, CodeFile, Method, CodeKey (optional), Exception (optional)
   Also das ist jetzt ein sehr verboser Vorschlag, evtl. wählst du etwas einfacheres - auch im Hinblick auf SystemResourcen (man kann sich auch tot-loggen)
   
3. Es gibt LogFile-Editoren, die automatisch immer die neuesten Zeilen anzeigen.
   Also ungefähr was dir vorschwebt, nur nicht als selbstprogrammierter Bestandteil deiner Anwendung, sondern ein fertiges externes Tool.
   Da gibts bestimmt noch Haufenweise weitere Tools, da sollteste dich erst umsehen, ehe du anfängst, das Rad neu zu erfinden
   

Insgesamt beschleichen mit Zweifel, ob ein so hoch aufgehängtes Logging-Brimborium in deim Fall ühaupt sinnvoll ist.
Grade dass du dir vorstellst, zur Laufzeit geloggte Exceptions anzugucken ist mir verdächtig.
Exceptions sind dazu da, das Programm zu beenden. Also es ist Absicht, und notwendig, dass ein Proggi beendet, wenn ein ungültiger Zustand auftritt.
Weil ansonsten läuft das Proggi innem undefinierten Zustand weiter, und kann den grössten Mist bauen.
Also keinesfalls anfangen, und um jede Zeile einen TryCatch machen und das gecatchte weg-loggen.
Dassis einerseits eine hochriskante Fehlerquelle (!!!),
und erschwert ausserdem dem Entwickler ein effizientes Debuggen - denn der Entwickler braucht die Exceptions ungecatcht
siehe TryCatch ist ein heißes Eisen

Aber eins nachm anneren - l4n einzurichten, und sinnreiche Log-Datensätze definieren, ist sicherlich ein gottgefälliges Werk.
Und sich Methoden schreiben, mit denen man maximal komfortabel LogEinträge abfeuern kann ebenfalls.