The Benefits of Trace Level Logging in Production Without the Drawback of Enormous Files #14

Open
wants to merge 1 commit into
from

Projects

None yet

5 participants

If you're interested, this is something I'm working on. While I'm using it in production, the code is not "NLog project worthy". This is for your review to see if you'd like to a) take it and run with it, or b) pull it when I've fleshed it out and done things more properly.

See http://t.co/QKvsXj6o

Only the code for the wrapper target is done, nothing else has been added to the NLog project.
Also, I only added it to the .NET 4.0 project. I'm not familiar with the
innerds of the NLog project yet, so I'm sure there is plenty more to do,
like updating the XML Schema to include this wrapper type in the target
enumeration.

Michael Aaron Jansen Initial version of QueuedWrapperTarget
Only the code is done, nothing else has been added to the NLog project.
Also, I only added it to the .NET 4.0 project.  I'm not familiar with the
innerds of the NLog project yet, so I'm sure there is plenty more to do,
like updating the XML Schema to include this wrapper type in the target
enumeration.
2b71ba6

Nice one.

vincpa commented Jan 1, 2013

I'd love to see a feature like that become part of NLog.

What we've been using is LogFaces (http://www.moonlit-software.com/) in which you create a network target to log to the LogFaces server. The nice features it offers is only persisting the levels you want (ie Info or greater) but also allows you to see anything coming in in 'real time'. Take a look at their server and if anyone wants more info I can write up something with more details.

vincpa commented Jan 2, 2013

I have seen log faces before and it looks like a great tool. What would happen if the log server receiving log messages crashed? Does it freeze up the client app and more importantly, what do you log to then? I think there's always a need for logging locally to a file.

Just a side node, you can persist only the log levels you want in NLog too. You can configure it to log levels higher than Info as well. You can even write your own target to send messages to a server.

As for watching things in real time, I find the *nix util "tail" to be a nice poor mans version :-)

Being it's a logging server and it crashes - I'm assuming your environment would have a monitoring system notify you of a down time (if you are affording to maintain a dedicated logging server) plus we also always log Warn on up to the event log as well for fail-over need.

I'm not aware of how you can persist log levels in NLog, how? To clarify, I'm not talking about filtering based on the rules. I'm saying always fire the target for Debug (target sending to the server) and the server making the decision to persist for history (or not but displaying to those viewing real time data).

fxmozart commented Jan 2, 2013

Well , i m assuming ,the persist for level is a filtering wrapper such as :



but unless you put up a WCF, with an echo reply...not sure how you can be
notified of downtime straight out of nlog?

Olivier Guiglionda

Mobile Phone : +33625031932
Phone France :+33970461022
Fax: +33483330821

On Wed, Jan 2, 2013 at 10:39 PM, Jason LaFlair notifications@github.comwrote:

Being it's a logging server and it crashes - I'm assuming your environment
would have a monitoring system notify you of a down time (if you are
affording to maintain a dedicated logging server) plus we also always log
Warn on up to the event log as well for fail-over need.

I'm not aware of how you can persist log levels in NLog, how? To clarify,
I'm not talking about filtering based on the rules. I'm saying always fire
the target for Debug (target sending to the server) and the server making
the decision to persist for history (or not but displaying to those viewing
real time data).


Reply to this email directly or view it on GitHubhttps://github.com/jkowalski/NLog/pull/14#issuecomment-11825431.

I guess when I'm referring to persisting the data it's the idea that if you are not viewing it in real-time - will NEVER see the logging data. That is how we have our logging server setup.

As for the downtime notification - you could be creative with the FallbackGroup target wrapper - but if you're willing to spend the $$ for a logging server software, hardware and etc. then I'm making the assumption that you've also got a technical environment for monitoring servers and applications for downtime and response.

MNF commented Feb 6, 2013

Link in the initial post is broken

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment