The Benefits of Trace Level Logging in Production Without the Drawback of Enormous Files #14
Conversation
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.
|
Nice one. |
|
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. |
|
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). |
|
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 Olivier Guiglionda Mobile Phone : +33625031932 On Wed, Jan 2, 2013 at 10:39 PM, Jason LaFlair notifications@github.comwrote:
|
|
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. |
|
Link in the initial post is broken |
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.