All of this makes me think we need docs for users new to logging... Gary
On Mon, Aug 31, 2015 at 3:16 PM, Gary Gregory <[email protected]> wrote: > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <[email protected]> wrote: > >> All sounds reasonable to me. I'm not sure any of the statements you made >> go against anything I have stated. Please let me know if you think >> otherwise. >> >> In your authentication module, you log all levels through its logger, >> right? > > > Yes. > > >> You don't use separate loggers to log different levels do you? >> > > No separate loggers per levels. > > Gary > > >> >> Thanks, >> Nick >> >> > Date: Mon, 31 Aug 2015 15:02:09 -0700 >> > Subject: Re: approach for defining loggers >> > From: [email protected] >> > To: [email protected] >> > >> > I think of levels as "how important is this" and "who needs to know >> this". >> > Some of the art of logging is deciding who you audience is. To help your >> > development team chase down a bug, you want to make sure that the app >> logs >> > interesting events at the DEBUG and TRACE level. This is different that >> > "what it is I am telling this audience", which is where I use loggers. >> To >> > tell who comes in and out of the system, I have logging in the >> > authentication module. To tell what kind of SQL goes to the database, I >> > have DEBUG logging in my DB interface code. >> > >> > I think that once you start chasing down issues and bugs, and writing >> code >> > to help you do that, then it might become more obvious, as to what to >> do. >> > >> > Gary >> > >> > On Mon, Aug 31, 2015 at 2:51 PM, Nicholas Duane <[email protected]> wrote: >> > >> > > I did look through a bit of documentation on markers: >> > > >> > > https://logging.apache.org/log4j/2.0/manual/markers.html >> > > >> > > >> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them >> > > >> > > My initial impression is that I don't want to use markers. What I'd >> like >> > > to be able to say is: >> > > >> > > "log the way you have been logging in the past. You don't need to >> know >> > > about any special loggers. Use your own. Here is a new level for >> our new >> > > type of "event". Use that to log this new event." >> > > >> > > I guess I'm not understanding your vernacular in terms of levels. In >> my >> > > mind the different levels also define different "types" of events. >> For >> > > instance, DEBUG and less specific I would see as tracing type events >> which >> > > are non-functional in nature. They are purely for understanding the >> call >> > > flow, or for performance gathering, or detailed diagnosis. Those >> could be >> > > turned off totally without having much impact on system management. >> The >> > > same can't be said for FATAL to INFO. These levels should always be >> on so >> > > that you can properly manage the system. >> > > >> > > Thanks, >> > > Nick >> > > >> > > > Date: Mon, 31 Aug 2015 08:37:25 -0700 >> > > > Subject: Re: approach for defining loggers >> > > > From: [email protected] >> > > > To: [email protected] >> > > > >> > > > Hi Nick, >> > > > >> > > > Creating a single new level is seldom the right solution IMO. It's >> not >> > > like >> > > > you are missing a level of granularity (we have custom level >> examples >> > > that >> > > > demonstrate that, like a VERBOSE level that sits between INFO and >> DEBUG). >> > > > It sounds like you need to use _hierarchical_ loggers and/or >> markers. >> > > > >> > > > The fact that the level is called BUSINESS is also a hint that a >> level is >> > > > not quite right because it does not fit in the Level vernacular >> (INFO, >> > > > WARN, and so on). >> > > > >> > > > If you needed a different set of levels, that would be another story >> > > (like >> > > > the DEFCON levels example). >> > > > >> > > > Gary >> > > > >> > > > On Mon, Aug 31, 2015 at 8:10 AM, Nicholas Duane <[email protected]> >> wrote: >> > > > >> > > > > Thanks for the feedback. I will look into Markers and MDC. >> > > > > >> > > > > With respect to using a separate logger, it would seem I would >> lose the >> > > > > information about what application code, eg. the class logger, is >> > > sourcing >> > > > > the event. We would like to have this information. On top of >> that, it >> > > > > seems odd, maybe to me only, that for this new level we have our >> own >> > > > > logger. It seemed reasonable to me that this new event we want to >> > > capture >> > > > > is just a new level. Just like a DEBUG event is different from >> an INFO >> > > > > event. If I define a BUSINESS level why would that not follow >> the same >> > > > > design as the current levels? You wouldn't suggest having >> different >> > > > > loggers for TRACE DEBUG INFO WARN ERROR FATAL, would you? I >> think one >> > > of >> > > > > the reasons someone on our side is suggesting I have separate >> loggers >> > > is >> > > > > that they think the overhead of filtering at the appender is >> going to >> > > have >> > > > > a noticeable impact. Our plan, at least the one I have now in my >> > > head, is >> > > > > that we'll have some number of appenders in the root. We'll then >> > > filter x >> > > > > < INFO events to a tracing appender, INFO <= x <= FATAL to a >> logging >> > > > > appender, and our custom level will go to another appender. >> Thoughts? >> > > > > >> > > > > Thanks, >> > > > > Nick >> > > > > >> > > > > > Subject: Re: approach for defining loggers >> > > > > > From: [email protected] >> > > > > > Date: Sat, 29 Aug 2015 20:59:36 -0700 >> > > > > > To: [email protected] >> > > > > > >> > > > > > >> > > > > > > On Aug 29, 2015, at 7:44 PM, Nicholas Duane <[email protected]> >> > > wrote: >> > > > > > > >> > > > > > > I'm curious if there is a prescribed approach to defining >> loggers. >> > > > > Let me state what my assumption is. I assume that normally if >> some >> > > piece >> > > > > of code wants to log events/messages that it should create a >> logger for >> > > > > itself. I guess a reasonable name to use is the class name >> itself. In >> > > > > terms of logger configuration I would expect that no loggers are >> > > specified >> > > > > in the log4j configuration UNLESS is needs settings other than the >> > > > > default. The root logger would specify the default settings, eg. >> > > level and >> > > > > appenders. If some piece of code tied to a logger needs to enable >> > > tracing >> > > > > in order to debug an issue then you would add that logger to the >> > > > > configuration and set the level less specific for that logger. Is >> > > this a >> > > > > typical and reasonable approach? >> > > > > > >> > > > > > What you describe here is the common convention. It is a >> reasonable >> > > > > approach. >> > > > > > >> > > > > > > >> > > > > > > I asked because we have the need for a new type of event. To >> have >> > > > > this event flow to where we want it to flow the plan is to have a >> > > custom >> > > > > level and have all events at that level captured by a specific >> > > appender. >> > > > > My assumption was that for existing applications we'd just need >> to add >> > > our >> > > > > appender to the root and add our custom level. The app would >> need to >> > > be >> > > > > modified to log our new event at the custom level. However, >> someone >> > > > > suggested that we could also create a separate logger for this >> event. >> > > My >> > > > > thinking is that while we don't ever want to turn off logging of >> this >> > > > > event, loggers represent "event sources", e.g the code raising the >> > > events >> > > > > and thus having multiple different pieces of code use the same >> logger >> > > > > wouldn't allow you to turn on/off logging from those different >> > > sections of >> > > > > code independently. I think the current configuration includes >> all the >> > > > > loggers. Normally I would expect there to be many, on the order >> of >> > > 10's or >> > > > > 100's, loggers within an application. However, in the case I was >> given >> > > > > there were only a handful because I think this handful is >> shared. So >> > > as I >> > > > > mentioned, this doesn't sound like an ideal design as you have >> less >> > > > > granularity on what you can turn on/off. >> > > > > > >> > > > > > You have a few options. Using a CustomLevel would not be the >> option I >> > > > > would choose. Creating a custom Logger will certainly work and >> makes >> > > > > routing the message to the appropriate appender rather easy. >> Another >> > > > > approach is to use Markers. Markers are somewhat hierarchical so >> you >> > > can >> > > > > use them for a variety of purposes. If you look at how Log4j >> handles >> > > event >> > > > > logging it actually does both - it specifies EventLogger as the >> name >> > > of the >> > > > > logger to use and it uses Markers to identify the kind of event. >> > > > > > >> > > > > > A third option is to use the MDC or Logger properties. If you >> do that >> > > > > then you can have information included in the actual logging event >> > > that can >> > > > > affect how it is routed. I also built a system that uses the >> RFC5424 >> > > format >> > > > > so that the event could have lots of key/value pairs to identify >> the >> > > events. >> > > > > > >> > > > > > Unfortunately, without knowing more details I don’t know that I >> can >> > > give >> > > > > you a better idea on how I would implement it. >> > > > > > >> > > > > > Ralph >> > > > > > >> > > > > > >> --------------------------------------------------------------------- >> > > > > > To unsubscribe, e-mail: >> [email protected] >> > > > > > For additional commands, e-mail: >> [email protected] >> > > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > E-Mail: [email protected] | [email protected] >> > > > Java Persistence with Hibernate, Second Edition >> > > > <http://www.manning.com/bauer3/> >> > > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> > > > Spring Batch in Action <http://www.manning.com/templier/> >> > > > Blog: http://garygregory.wordpress.com >> > > > Home: http://garygregory.com/ >> > > > Tweet! http://twitter.com/GaryGregory >> > > >> > > >> > >> > >> > >> > -- >> > E-Mail: [email protected] | [email protected] >> > Java Persistence with Hibernate, Second Edition >> > <http://www.manning.com/bauer3/> >> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> > Spring Batch in Action <http://www.manning.com/templier/> >> > Blog: http://garygregory.wordpress.com >> > Home: http://garygregory.com/ >> > Tweet! http://twitter.com/GaryGregory >> >> > > > > -- > E-Mail: [email protected] | [email protected] > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
