Can you please clarify, “If we had some way to know an event is a business event we wouldn’t need level”? I do not understand how you can code logger.log(BUSINESS, msg) but you cannot code logger.info(BUSINESS, msg).
Ralph > On Sep 8, 2015, at 6:09 PM, Nicholas Duane <nic...@msn.com> wrote: > > > > > I looked over that stackoverflow post and I'm still not seeing a good match > as a way for us to log our business events. > > A business event I guess is an event which extends whatever schema we come up > with for a business event. While an instance of this schema could be logged > at any level, that really doesn't make sense in our scenario, regardless of > whether some marker was supplied. If we had some way to know an event is a > business event we wouldn't need level. We could of course add some property > to our schema which indicates the 'category' of the event, 'business' being > one such category. Instead we were thinking we could just use level to > indicate that an event is a business event. > > As I mentioned, we're looking to capture 'trace' level events to one store, > 'info' - 'fatal' level events to another store, and 'business' events to yet > another store. For 'trace' and 'info' - 'fatal' it seems reasonable to > filter on level within the appender to get those events to the appropriate > location. It seemed reasonable to do something similar for 'business'. > > I also looked into the EventLogger but not sure that's appropriate. For one > we lose the granularity to control a specific piece of code from generating > business events. This is most likely a non-issue as I have mentioned that we > don't want to turn business logging off. The other is that we lose the name > of the logger as it would be the same for everyone. Not sure this is that > big a deal either as I guess you might be able to capture component name, > though I would rather distinguish using logger name. > > Thanks, > Nick > >> From: ralph.go...@dslextreme.com >> Subject: Re: approach for defining loggers >> Date: Mon, 7 Sep 2015 20:39:11 -0700 >> To: log4j-user@logging.apache.org >> >> I still don’t understand why you don’t want to use Markers. They were >> designed exactly for the use case you are describing. >> >> You might set retention policies for debug vs info, error and fatal, but a >> BUSINESS marker could cross-cut them all. That is exactly why it is NOT a >> level. IOW, it gives you a second dimension for filtering. Ceki invented >> Markers when he created SLF4J. For his point of view see >> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them >> >> <http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>. >> >> Ralph >> >> >> >> >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <nic...@msn.com> wrote: >>> >>> If I'm attempting to control all the logging from the configuration and I >>> don't know the complete set of loggers in my application as there could be >>> 100's or 1000's, wouldn't it be hard to separate events based on loggers? >>> It would seem much easier to separate events based on level. In addition, >>> level might be a more reasonable approach for separating. For example, if >>> I want to send all events to some big-data backend I might want to separate >>> out traces and debug from info to fatal as traces and debug are most likely >>> less important from a systems management aspect. My retention period for >>> traces and debug might be just a couple days. The retention period for >>> info to fatal could be 30 days. Business level might be 2 years. Any >>> system management notifications would probably be driven off of info to >>> fatal events and not trace and debug events, which is another reason you >>> might want to separate by level. >>> >>> Thanks, >>> Nick >>> >>>> Subject: Re: approach for defining loggers >>>> From: ralph.go...@dslextreme.com >>>> Date: Mon, 31 Aug 2015 08:50:58 -0700 >>>> To: log4j-user@logging.apache.org >>>> >>>> A logging “Level” is a level of importance. That is why there is a >>>> hierarchy. If you want informational messages then you also would want >>>> warnings and errors. >>>> >>>> “BUSINESS” does not convey the same meaning. Rather, it is some sort of >>>> category, which is what Markers are for. >>>> >>>> Using the class name as the logger name is a convention. If you really >>>> want the class name, method name or line number then you should be >>>> specifying that you want those from the logging event, rather than the >>>> logger name. Unless location information is disabled you always have >>>> access to that information. >>>> >>>> In short, different loggers are used primarily as a way of grouping sets >>>> of messages - for example all org.hibernate events can be routed to a >>>> specific appender or turned off en masse. Levels are used to filter out >>>> noise across a set of logging events. Markers are used to categorize >>>> logging events by arbitrary attributes. >>>> >>>> Ralph >>>> >>>> >>>>> On Aug 31, 2015, at 8:10 AM, Nicholas Duane <nic...@msn.com> 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: ralph.go...@dslextreme.com >>>>>> Date: Sat, 29 Aug 2015 20:59:36 -0700 >>>>>> To: log4j-user@logging.apache.org >>>>>> >>>>>> >>>>>>> On Aug 29, 2015, at 7:44 PM, Nicholas Duane <nic...@msn.com> 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: log4j-user-unsubscr...@logging.apache.org >>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>>>>> >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org >>>> >>> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
