You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Nicholas Duane <ni...@msn.com> on 2015/08/30 04:44:09 UTC
approach for defining loggers
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?
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.
Thanks,
Nick
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
For good or bad, a simple way folks use logger is one per class (in a final
static var). This can give you 100's or 1000's of loggers in a large app.
I've even see apps that use per-instance loggers, so that, for example, in
a server, each is named
com.example.requests.DoThis, com.example.requests.DoThat and so on.
When you have 100s of loggers, it can be hard to get the system to log just
what you need, but hierarchical loggers help here.
There's just no way to get around using a third party's logging naming like
the org.hibernate example you mention.
My experience is that splitting up your logging with appenders per levels
in only useful to split out FATAL and ERROR (and maybe WARN) levels. You
usually do not want to always log TRACE for example, because this can have
serious performance implications. For example, in some of my projects,
TRACE logging logs hex dumps for our on-the-wire network traffic.
This is one of the reasons I use FLOW markers to mark TRACE of API calls vs
another marker BUFFER used when hex dumps are logged at the TRACE level.
You might think that using a FLOW log level would be an alternative, but
would that be more or less detailed than TRACE? With markers, you do not
have to decide or worry about it.
Gary
On Mon, Aug 31, 2015 at 3:02 PM, Nicholas Duane <ni...@msn.com> wrote:
> But ideally I don't want to have to know about org.hibernate unless I need
> to do something special for it. Ideally I set up my appenders in <root>
> and set the level. One appender handles everything less specific than
> INFO. Another appender handles everything between INFO and FATAL, another
> appender handles our custom level.
>
> Everyone logs as they've done before, assuming they're currently logging
> all levels through their own logger. At least this is what I had
> envisioned. It seems the simplest approach to me. Though I'm new to log4j
> so what do I know.
>
> It's unlikely you would have everyone use the same logger for levels less
> than INFO because then you couldn't turn certain sections of code from
> logging these trace events on or off, unless you also required they use
> these markers or some other mechanism. I would rather each use their own
> logger and if we find we're getting a bunch of garbage from all org.foobar
> components they we can turn them all off.
>
> Thanks,
> Nick
>
> > Subject: Re: approach for defining loggers
> > From: ralph.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
It seems like you have already made up your mind. That’s fine if that is what you want to do. It just is using the system differently than the way we would recommend.
The idea with a Marker is that you can create a global Marker filter for BUSINESS where you would have onMatch=ACCEPT. if you do that then everything logged with a BUSINESS marker will be passed to its appropriate appenders regardless of the events logging level - which is what you asked for. In addition, you can create child markers of BUSINESS, such as FINANCIAL, LEGAL, HR, etc. Since all of these have BUSINESS as their parent they will all be accepted since they will match the marker filter.
Again, the intent of markers is to add meta-data regarding what an event is about. The level is a measure of how important the event is. So using a level of Business doesn’t really make sense since you have no idea whether it is more important or less important than any other level.
Ralph
> On Aug 31, 2015, at 3:02 PM, Nicholas Duane <ni...@msn.com> wrote:
>
> But ideally I don't want to have to know about org.hibernate unless I need to do something special for it. Ideally I set up my appenders in <root> and set the level. One appender handles everything less specific than INFO. Another appender handles everything between INFO and FATAL, another appender handles our custom level.
>
> Everyone logs as they've done before, assuming they're currently logging all levels through their own logger. At least this is what I had envisioned. It seems the simplest approach to me. Though I'm new to log4j so what do I know.
>
> It's unlikely you would have everyone use the same logger for levels less than INFO because then you couldn't turn certain sections of code from logging these trace events on or off, unless you also required they use these markers or some other mechanism. I would rather each use their own logger and if we find we're getting a bunch of garbage from all org.foobar components they we can turn them all off.
>
> Thanks,
> Nick
>
>> Subject: Re: approach for defining loggers
>> From: ralph.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
But ideally I don't want to have to know about org.hibernate unless I need to do something special for it. Ideally I set up my appenders in <root> and set the level. One appender handles everything less specific than INFO. Another appender handles everything between INFO and FATAL, another appender handles our custom level.
Everyone logs as they've done before, assuming they're currently logging all levels through their own logger. At least this is what I had envisioned. It seems the simplest approach to me. Though I'm new to log4j so what do I know.
It's unlikely you would have everyone use the same logger for levels less than INFO because then you couldn't turn certain sections of code from logging these trace events on or off, unless you also required they use these markers or some other mechanism. I would rather each use their own logger and if we find we're getting a bunch of garbage from all org.foobar components they we can turn them all off.
Thanks,
Nick
> Subject: Re: approach for defining loggers
> From: ralph.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
Re: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
I don't believe there is a severity to our compliance and business events. I could be wrong. If they had a severity it would certainly make them fit into the logging model more cleanly, but I just don't see it. And I just had this discussion with one of my colleagues. They were suggesting a result code for a business event. However, I pointed out that you'd only need that if you planned on logging failed business events, which is what he was thinking. Would you just log the failed business event or maybe the failed business event and an error event? Would a failure business event go into the business event store or the critical diagnostic (errors, warnings, info) store? We might have systems management people monitoring the critical diagnostics store to see what, if any, issues are currently happening thus just logging a failed business event might not set of any alarms. Though you could say that a failed business event it not a critical diagnostics events. Maybe it's just a business failure event. For instance, low balance. Though I probably see a low balance as yet another business event, not a failure of some other business event.
Just in case anyone is wondering I should probably make this clear, none of the logging we're doing is for auditing. We made it perfectly clear that events can be lost and thus you should not be using the logging frameworks and these events to audit. I have a clear definition for an audit, "if you fail to audit then you fail the application transaction".
I'm thinking our compliance and business events would have fit nicely into the EventLogger. As I mentioned, there are two issues I have with the event logger. Therefore I'm thinking that maybe we provide some methods to log these events to the All level in an attempt to implement something similar to the EventLogger but do it against a private logger. So something like this (pseudo code):
public class ExtensionMethods
{
public void LogEvent(Logger logger, object evnt);
or
public void LogEvent(Logger logger, String category, object evnt);
}
The other thing I'll need to make sure is that we have a way to distinguish between our different categories of events. I won't use Markers as they don't exist on log4net and we have a "category" property anyway so I think I can use that.
Thanks,
Nick
________________________________
From: Gary Gregory <ga...@gmail.com>
Sent: Monday, October 17, 2016 10:46 PM
To: Log4J Users List
Subject: Re: approach for defining loggers
On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane <ni...@msn.com> wrote:
> Sorry to revive this old thread. However, we're in the process of adding
> support for other "categories" of events and thus I wanted to first take a
> step back and try to ensure we're not convoluting things.
>
>
> There was a requirement to log a "compliance" event under certain
> conditions. We did not want to write our own logging framework and instead
> decided to use existing off-the-shelf logging frameworks. We have
> applications on both Linux/Java, Windows/.NET and Windows/Java. Initially
> we chose log4net for Windows/.NET and log4j2 for Windows/Java and
> Linux/Java. For these logging frameworks we wrote artifacts, appenders
> basically, to help facilitate getting these events to our system. By the
> way, our system will get the events centrally, possibly put them into a
> relational database and also hand them off to another system which will get
> them eventually to an HDFS backend. We also exposed methods for creating
> this compliance event. The compliance event is basically a map. We chose
> a map so that the event could also be extended by the application team in
> case they needed to add additional properties which made sense for them.
>
>
> We chose to create a custom level for this "compliance" event such that we
> could filter out only these events and get them into our system. The
> configuration example we created had our custom unix domain socket appender
> added to the root logger. It also contained a filter which filtered out
> any events that weren't compliance events. The level we chose for
> "compliance" was less critical than off and more critical than fatal as we
> wanted to ensure that as long as logging wasn't turned off altogether our
> events would get logged.
>
>
> I want to go over a few suggestions that were made and explain why I
> didn't make use of those suggestions.
>
>
> 1. Since our "compliance" level didn't fit within the "vernacular" of the
> existing levels we should not define this custom level. Instead we should
> look at using markers.
>
Yes, this is a use case for markers. The level should be used to note how
important is each compliance event.
>
> I am not that familiar with markers but did look into them when they were
> suggested. While I don't have anything against markers in general there
> were some downsides as I saw it.
>
>
> a. Markers are not available, as far as I know, in log4net so we'd still
> have to figure out something there.
>
Indeed, we really need a port of Log4j 2 to .NET.
>
> b. A bigger problem, at least I thought it was a bigger problem, was that
> there would be confusion about what level to log the event at. I would
> certainly not want to give an example as follows:
>
>
> logger.debug(COMPLIANCE_MARKER, evnt);
>
>
> or
>
>
> logger.info(COMPLIANCE_MARKER, evnt);
>
>
> or
>
>
> logger.error(COMPLIANCE_MARKER, evnt);
>
>
> ...
>
Think about: How important is this event? Are there different level of
importance to the audience?
>
>
> That just screams confusion to me.
>
>
> 2. Use a dedicated logger to log all compliance events.
>
>
> There were, as far as I could tell, a couple problems with this approach
> also.
>
>
> a. If everyone is using a single "well known" logger to log a specific
> event category then I lose the logger "context" of who's logging the
> event. As it stands now we're copying the logger name into a property we
> call "eventSource".
>
A practice is to use one logger per class. Another is to use a higher-level
logger to represent higher-level abstractions like a module.
>
>
> b. You cannot turn on/off logging for a specific set of code. If it turns
> out that we have some errant code which is using this well known logger
> then we can't just turn off that code from logging as turning off the well
> know logger would turn it off for everyone using it.
>
>
> I did look into the EventLogger and initially that seemed promising as I
> guess it logs any event you give it at the "all" level. However, as a well
> known logger it suffers from the same issues above.
>
>
> Now we're looking to add Business events. My initial thinking is that I
> can do the same thing we did before. Add an additional custom level called
> "Business" and expose methods for creating a business event.
I would NOT create a custom level. Instead, I would use a Logger called
"Business".
> Though unlike the compliance event, the application teams would be
> defining the schema more so than our framework team. Thus any method we
> expose would just be used as a starting point for setting the common
> properties. You would use another instance of our unix domain socket
> appender for these business events and forward them to a different location
> as business events would most likely have a different retention period than
> compliance events. Plus you might also want them in a different store as
> you may never need to query for both categories of events and thus no need
> to query against a larger set of data.
>
>
> In addition we're planning to capture centrally what we refer to as
> diagnostic events: error, info, warn, debug, trace, etc. However, we may
> need to separate these out into two different categories:
> critical-diagnostic and noncritical-diagnostic.
This could be a user case for custom levels IF one is more important than
the other which it sure sounds like it is.
> The reason is that we don't want the potential of a critical diagnostic
> event, let's say an error, queued up behind potentially thousands of
> non-critical diagnostic events. So you see, the category also defines
> aspects on how we handle events at the source. We separate at the source
> based on category as it seems a reasonable place to do so. Also, you may
> want different flush times for different categories. We have a process
> which buffers, compresses and sends events centrally so we have the notion
> of flush time. The buffers are flushed when they become full or the flush
> time elapses. Errors, since they are more critical in monitoring systems,
> we'll most likely want to flush more often than say debug and trace events.
>
>
> Sorry for the long winded explanation. Initially I was thinking that when
> we create an event we'd set its category. However, now I'm thinking the
> category should be set by the act of logging the event at a level. In some
> cases we have a 1:1 mapping from level to category, eg. compliance level ->
> compliance category. In some cases we have a many:1 mapping from level to
> category, eg. error, info, warn -> critical-diagnostic.
>
>
> We could also just define a single custom level, say "always_on", or
> something like that. Then we provide some helper method to log our "new"
> event categories (eg. business and compliance) at this level and have the
> user specify the category, I guess similar to a marker.
>
Log4j has a level called ALL.
I would really try to work hard to stay within the feature set before
thinking about anything custom.
If you can make critical-diagnostic and noncritical-diagnostic events to
stock levels, that much the better.
Gary
>
>
> logEvent(Logger logger, String category, object evnt);
>
>
> I guess it's similar to the EventLogger except that we're not using a
> single well known logger and thus don't have the downsides of that which I
> pointed out earlier.
>
>
> Any thoughts/suggestions would be appreciated.
>
>
> Thanks,
>
> Nick
>
> ________________________________
> From: Mikael Ståldal <mi...@magine.com>
> Sent: Wednesday, September 9, 2015 3:47 AM
> To: Log4J Users List
> Subject: Re: approach for defining loggers
>
> Then perhaps you should create your own facade for doing business event
> logging, which could then forward them to Log4j in an appropriate way.
>
> On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
>
> > I was just about to reply to your previous email about using a single
> > "business" logger, or some hierarchy of business loggers, to log business
> > events and say that we might go that route. However, now that you
> brought
> > up the post from Ralph, which I just replied to, I'm thinking a logger
> > won't work either for the same reason I listed in my reply to Ralph's
> post.
> >
> > You could do:
> >
> > logger.info("Hello");
> > logger.fatal("Hello");
> > logger.error("Hello");
> > ...
> >
> > It's confusing as there are n ways to log a business event that way and
> > they will all do the same thing. Which one should a developer choose.
> > Should I say pick any one, it doesn't matter?
> >
> > Thanks,
> > Nick
> >
> > > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > > Subject: Re: approach for defining loggers
> > > From: garydgregory@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > Or
> > > Logger logger = LogManager.getLogger("Business");
> > > ...
> > > logger.info("Hello");
> > >
> > > Gary
> > >
> > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> ralph.goers@dslextreme.com>
> > > wrote:
> > >
> > > > 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 <ni...@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.goers@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-
[http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/questions/16813032/what-is->
What is markers in Java Logging frameworks and that is a reason to use them?<http://stackoverflow.com/questions/16813032/what-is->
stackoverflow.com
First time I hear about markers when read: http://slf4j.org/faq.html I check available methods for Logger object: http://www.slf4j.org/api/org/slf4j/Logger.html http://logging.apache.org/log4j/2.x/
> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
> icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
> questions/16813032/what-is-markers-in-java-logging-
> frameworks-and-that-is-a-reason-to-use-them>
>
> What is markers in Java Logging frameworks and that is a ...<
> http://stackoverflow.com/questions/16813032/what-is-
> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
> stackoverflow.com
> This is a rehashed version my answer to the question "Best practices for
> using Markers in SLF4J/Logback". Markers can be used to color or mark a
> single log statement.
>
>
> > > > <
> > > >
> > http://stackoverflow.com/questions/16813032/what-is-
> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
> icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
> questions/16813032/what-is-markers-in-java-logging-
> frameworks-and-that-is-a-reason-to-use-them>
>
> What is markers in Java Logging frameworks and that is a ...<
> http://stackoverflow.com/questions/16813032/what-is-
> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
> stackoverflow.com
> This is a rehashed version my answer to the question "Best practices for
> using Markers in SLF4J/Logback". Markers can be used to color or mark a
> single log statement.
>
>
> > > > >.
> > > > >>
> > > > >> Ralph
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > > >>>>>> For additional commands, e-mail:
> > log4j-user-help@logging.apache.org
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > ---------------------------------------------------------------------
> > > > >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@
> logging.apache.org
> > > > >>>> For additional commands, e-mail:
> > log4j-user-help@logging.apache.org
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > 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
> [https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/>
>
> Gary Gregory<http://garygregory.wordpress.com/>
> garygregory.wordpress.com
> Software construction, the web, and other techs
>
>
> > > Home: http://garygregory.com/
> Gary Gregory<http://garygregory.com/>
> garygregory.com
> Rocket | Seagull . I am a Software Architect for Seagull Software, a
> division of Rocket Software. Rocket Seagull specializes in tools and
> expertise to modernize ...
>
>
> > > Tweet! http://twitter.com/GaryGregory
> Gary Gregory (@GaryGregory) | Twitter<http://twitter.com/GaryGregory>
> twitter.com
> The latest Tweets from Gary Gregory (@GaryGregory). Principal Software
> Engineer, author: Java Persistence Hibernate https://t.co/3F8sYxc0oq,
> JUnit https://t.co/yXU1DqAMDG, Spring Batch https://t.co/XwoMNoBxh7.
> U.S.A.
>
>
> >
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com<<http://www.magine.com<>
> http://www.magine.com>
> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<
> http://www.magine.com/>
>
> TV online with Magine TV<http://www.magine.com/>
> www.magine.com<http://www.magine.com>
> Watch the TV you love, on any device, anywhere in Germany and Sweden and
> find out more about our global OTT B2B solutions. Get started today.
>
>
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
The convention is to use the class name as the logger name and we find that useful information. Getting the class name, method name and line number dynamically I assume is costly and thus we'd probably want to just stick with the logger name.
We're not planning to turn off the business events by logger name, it's just a nice option to have in the event we have some code which is misbehaving. We wouldn't have that option if we use a "well known" logger.
Thanks,
Nick
________________________________
From: Ralph Goers <ra...@dslextreme.com>
Sent: Tuesday, October 18, 2016 10:01 AM
To: Log4J Users List
Subject: Re: approach for defining loggers
The “context” of the call is only grossly captured by the logger name, and that is only by convention. If you really want the name of the class then you need the location information, which gives you the class name, method name and line number of the caller.
If these are “business” events why do you want to turn them off by the name of the logger? I would think you might want to filter out certain event types, but that shouldn’t be represented by the logger name.
Ralph
> On Oct 18, 2016, at 6:47 AM, Nicholas Duane <ni...@msn.com> wrote:
>
> That's what I initially thought. However, as I pointed out it has the same downsides as a "well known" logger. We lose the context of what code is logging the call (e.g the class name which is usually used as the logger name), and there is no way to turn on/off a section of code from logging, in the case we find some errant code. Those two are big enough issues which are keeping me away from using "well known" loggers.
>
>
> Thanks,
>
> Nick
>
> ________________________________
> From: Matt Sicker <boards@gmail.com <ma...@gmail.com>>
> Sent: Monday, October 17, 2016 11:15 PM
> To: Log4J Users List
> Subject: Re: approach for defining loggers
>
> What about event logging? <
> https://logging.apache.org/log4j/2.x/manual/eventlogging.html <https://logging.apache.org/log4j/2.x/manual/eventlogging.html>>
> Log4j – Log4j 2 API - Apache Log4j 2<https://logging.apache.org/log4j/2.x/manual/eventlogging.html <https://logging.apache.org/log4j/2.x/manual/eventlogging.html>>
> logging.apache.org <http://logging.apache.org/>
> The EventLogger class provides a simple mechanism for logging events that occur in an application. While the EventLogger is useful as a way of initiating events that ...
>
>
>
> This sounds pretty similar to what you're asking about. You define a map
> message essentially, plus your other requirements seem to be met here.
>
> On 17 October 2016 at 21:46, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane <ni...@msn.com> wrote:
>>
>>> Sorry to revive this old thread. However, we're in the process of adding
>>> support for other "categories" of events and thus I wanted to first take
>> a
>>> step back and try to ensure we're not convoluting things.
>>>
>>>
>>> There was a requirement to log a "compliance" event under certain
>>> conditions. We did not want to write our own logging framework and
>> instead
>>> decided to use existing off-the-shelf logging frameworks. We have
>>> applications on both Linux/Java, Windows/.NET and Windows/Java.
>> Initially
>>> we chose log4net for Windows/.NET and log4j2 for Windows/Java and
>>> Linux/Java. For these logging frameworks we wrote artifacts, appenders
>>> basically, to help facilitate getting these events to our system. By the
>>> way, our system will get the events centrally, possibly put them into a
>>> relational database and also hand them off to another system which will
>> get
>>> them eventually to an HDFS backend. We also exposed methods for creating
>>> this compliance event. The compliance event is basically a map. We
>> chose
>>> a map so that the event could also be extended by the application team in
>>> case they needed to add additional properties which made sense for them.
>>>
>>>
>>> We chose to create a custom level for this "compliance" event such that
>> we
>>> could filter out only these events and get them into our system. The
>>> configuration example we created had our custom unix domain socket
>> appender
>>> added to the root logger. It also contained a filter which filtered out
>>> any events that weren't compliance events. The level we chose for
>>> "compliance" was less critical than off and more critical than fatal as
>> we
>>> wanted to ensure that as long as logging wasn't turned off altogether our
>>> events would get logged.
>>>
>>>
>>> I want to go over a few suggestions that were made and explain why I
>>> didn't make use of those suggestions.
>>>
>>>
>>> 1. Since our "compliance" level didn't fit within the "vernacular" of the
>>> existing levels we should not define this custom level. Instead we
>> should
>>> look at using markers.
>>>
>>
>> Yes, this is a use case for markers. The level should be used to note how
>> important is each compliance event.
>>
>>
>>>
>>> I am not that familiar with markers but did look into them when they were
>>> suggested. While I don't have anything against markers in general there
>>> were some downsides as I saw it.
>>>
>>>
>>> a. Markers are not available, as far as I know, in log4net so we'd still
>>> have to figure out something there.
>>>
>>
>> Indeed, we really need a port of Log4j 2 to .NET.
>>
>>
>>>
>>> b. A bigger problem, at least I thought it was a bigger problem, was that
>>> there would be confusion about what level to log the event at. I would
>>> certainly not want to give an example as follows:
>>>
>>>
>>> logger.debug(COMPLIANCE_MARKER, evnt);
>>>
>>>
>>> or
>>>
>>>
>>> logger.info(COMPLIANCE_MARKER, evnt);
>>>
>>>
>>> or
>>>
>>>
>>> logger.error(COMPLIANCE_MARKER, evnt);
>>>
>>>
>>> ...
>>>
>>
>> Think about: How important is this event? Are there different level of
>> importance to the audience?
>>
>>
>>>
>>>
>>> That just screams confusion to me.
>>>
>>>
>>> 2. Use a dedicated logger to log all compliance events.
>>>
>>>
>>> There were, as far as I could tell, a couple problems with this approach
>>> also.
>>>
>>>
>>> a. If everyone is using a single "well known" logger to log a specific
>>> event category then I lose the logger "context" of who's logging the
>>> event. As it stands now we're copying the logger name into a property we
>>> call "eventSource".
>>>
>>
>> A practice is to use one logger per class. Another is to use a higher-level
>> logger to represent higher-level abstractions like a module.
>>
>>
>>>
>>>
>>> b. You cannot turn on/off logging for a specific set of code. If it
>> turns
>>> out that we have some errant code which is using this well known logger
>>> then we can't just turn off that code from logging as turning off the
>> well
>>> know logger would turn it off for everyone using it.
>>>
>>>
>>> I did look into the EventLogger and initially that seemed promising as I
>>> guess it logs any event you give it at the "all" level. However, as a
>> well
>>> known logger it suffers from the same issues above.
>>>
>>>
>>> Now we're looking to add Business events. My initial thinking is that I
>>> can do the same thing we did before. Add an additional custom level
>> called
>>> "Business" and expose methods for creating a business event.
>>
>>
>> I would NOT create a custom level. Instead, I would use a Logger called
>> "Business".
>>
>>
>>> Though unlike the compliance event, the application teams would be
>>> defining the schema more so than our framework team. Thus any method we
>>> expose would just be used as a starting point for setting the common
>>> properties. You would use another instance of our unix domain socket
>>> appender for these business events and forward them to a different
>> location
>>> as business events would most likely have a different retention period
>> than
>>> compliance events. Plus you might also want them in a different store as
>>> you may never need to query for both categories of events and thus no
>> need
>>> to query against a larger set of data.
>>>
>>>
>>> In addition we're planning to capture centrally what we refer to as
>>> diagnostic events: error, info, warn, debug, trace, etc. However, we may
>>> need to separate these out into two different categories:
>>> critical-diagnostic and noncritical-diagnostic.
>>
>>
>> This could be a user case for custom levels IF one is more important than
>> the other which it sure sounds like it is.
>>
>>
>>
>>> The reason is that we don't want the potential of a critical diagnostic
>>> event, let's say an error, queued up behind potentially thousands of
>>> non-critical diagnostic events. So you see, the category also defines
>>> aspects on how we handle events at the source. We separate at the
>> source
>>> based on category as it seems a reasonable place to do so. Also, you may
>>> want different flush times for different categories. We have a process
>>> which buffers, compresses and sends events centrally so we have the
>> notion
>>> of flush time. The buffers are flushed when they become full or the
>> flush
>>> time elapses. Errors, since they are more critical in monitoring
>> systems,
>>> we'll most likely want to flush more often than say debug and trace
>> events.
>>>
>>>
>>> Sorry for the long winded explanation. Initially I was thinking that
>> when
>>> we create an event we'd set its category. However, now I'm thinking the
>>> category should be set by the act of logging the event at a level. In
>> some
>>> cases we have a 1:1 mapping from level to category, eg. compliance level
>> ->
>>> compliance category. In some cases we have a many:1 mapping from level
>> to
>>> category, eg. error, info, warn -> critical-diagnostic.
>>>
>>>
>>> We could also just define a single custom level, say "always_on", or
>>> something like that. Then we provide some helper method to log our "new"
>>> event categories (eg. business and compliance) at this level and have the
>>> user specify the category, I guess similar to a marker.
>>>
>>
>> Log4j has a level called ALL.
>>
>> I would really try to work hard to stay within the feature set before
>> thinking about anything custom.
>>
>> If you can make critical-diagnostic and noncritical-diagnostic events to
>> stock levels, that much the better.
>>
>> Gary
>>
>>>
>>>
>>> logEvent(Logger logger, String category, object evnt);
>>>
>>>
>>> I guess it's similar to the EventLogger except that we're not using a
>>> single well known logger and thus don't have the downsides of that which
>> I
>>> pointed out earlier.
>>>
>>>
>>> Any thoughts/suggestions would be appreciated.
>>>
>>>
>>> Thanks,
>>>
>>> Nick
>>>
>>> ________________________________
>>> From: Mikael Ståldal <mi...@magine.com>
>>> Sent: Wednesday, September 9, 2015 3:47 AM
>>> To: Log4J Users List
>>> Subject: Re: approach for defining loggers
>>>
>>> Then perhaps you should create your own facade for doing business event
>>> logging, which could then forward them to Log4j in an appropriate way.
>>>
>>> On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
>>>
>>>> I was just about to reply to your previous email about using a single
>>>> "business" logger, or some hierarchy of business loggers, to log
>> business
>>>> events and say that we might go that route. However, now that you
>>> brought
>>>> up the post from Ralph, which I just replied to, I'm thinking a logger
>>>> won't work either for the same reason I listed in my reply to Ralph's
>>> post.
>>>>
>>>> You could do:
>>>>
>>>> logger.info("Hello");
>>>> logger.fatal("Hello");
>>>> logger.error("Hello");
>>>> ...
>>>>
>>>> It's confusing as there are n ways to log a business event that way and
>>>> they will all do the same thing. Which one should a developer choose.
>>>> Should I say pick any one, it doesn't matter?
>>>>
>>>> Thanks,
>>>> Nick
>>>>
>>>>> Date: Tue, 8 Sep 2015 19:28:21 -0700
>>>>> Subject: Re: approach for defining loggers
>>>>> From: garydgregory@gmail.com
>>>>> To: log4j-user@logging.apache.org
>>>>>
>>>>> Or
>>>>> Logger logger = LogManager.getLogger("Business");
>>>>> ...
>>>>> logger.info("Hello");
>>>>>
>>>>> Gary
>>>>>
>>>>> On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
>>> ralph.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> 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 <ni...@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.goers@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-
> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/questions/16813032/what-is-> <http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded&a]%3Chttp://stackoverflow.com/questions/16813032/what-is-%3E>
>
> What is markers in Java Logging frameworks and that is a reason to use them?<http://stackoverflow.com/questions/16813032/what-is- <http://stackoverflow.com/questions/16813032/what-is->>
> stackoverflow.com <http://stackoverflow.com/>
> First time I hear about markers when read: http://slf4j.org/faq.html <http://slf4j.org/faq.html> I check available methods for Logger object: http://www.slf4j.org/api/org/slf4j/Logger.html <http://www.slf4j.org/api/org/slf4j/Logger.html> http://logging.apache.org/log4j/2.x/ <http://logging.apache.org/log4j/2.x/>
>
>
>>> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
>>> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
>>> icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
>>> questions/16813032/what-is-markers-in-java-logging-
>>> frameworks-and-that-is-a-reason-to-use-them>
>>>
>>> What is markers in Java Logging frameworks and that is a ...<
>>> http://stackoverflow.com/questions/16813032/what-is-
>>> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
>>> stackoverflow.com
>>> This is a rehashed version my answer to the question "Best practices for
>>> using Markers in SLF4J/Logback". Markers can be used to color or mark a
>>> single log statement.
>>>
>>>
>>>>>> <
>>>>>>
>>>> http://stackoverflow.com/questions/16813032/what-is-
>>> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
>>> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
>>> icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
>>> questions/16813032/what-is-markers-in-java-logging-
>>> frameworks-and-that-is-a-reason-to-use-them>
>>>
>>> What is markers in Java Logging frameworks and that is a ...<
>>> http://stackoverflow.com/questions/16813032/what-is-
>>> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
>>> stackoverflow.com
>>> This is a rehashed version my answer to the question "Best practices for
>>> using Markers in SLF4J/Logback". Markers can be used to color or mark a
>>> single log statement.
>>>
>>>
>>>>>>> .
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <
>> nickdu@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-unsubscribe@logging.apache.org
>>>>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-help@logging.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@
>>> logging.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-help@logging.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>> ---------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.
>> apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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
>>> [https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/>
>>>
>>> Gary Gregory<http://garygregory.wordpress.com/>
>>> garygregory.wordpress.com
>>> Software construction, the web, and other techs
>>>
>>>
>>>>> Home: http://garygregory.com/
>>> Gary Gregory<http://garygregory.com/>
>>> garygregory.com
>>> Rocket | Seagull . I am a Software Architect for Seagull Software, a
>>> division of Rocket Software. Rocket Seagull specializes in tools and
>>> expertise to modernize ...
>>>
>>>
>>>>> Tweet! http://twitter.com/GaryGregory
>>> Gary Gregory (@GaryGregory) | Twitter<http://twitter.com/GaryGregory>
>>> twitter.com
>>> The latest Tweets from Gary Gregory (@GaryGregory). Principal Software
>>> Engineer, author: Java Persistence Hibernate https://t.co/3F8sYxc0oq,
>>> JUnit https://t.co/yXU1DqAMDG, Spring Batch https://t.co/XwoMNoBxh7.
>>> U.S.A.
>>>
>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com<<http://www.magine.com<>
>>> http://www.magine.com <http://www.magine.com/>>
>>> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png <https://de.magine.com/content/uploads/2016/09/magine_global_social.png>
>> ]<
>>> http://www.magine.com/ <http://www.magine.com/>>
>>>
>>> TV online with Magine TV<http://www.magine.com/ <http://www.magine.com/>>
>>> www.magine.com<http://www.magine.com> <http://www.magine.com/><http://www.magine.com <http://www.magine.com/>>
>>> Watch the TV you love, on any device, anywhere in Germany and Sweden and
>>> find out more about our global OTT B2B solutions. Get started today.
>>>
>>>
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>> not
>>> copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
>> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>
>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
>> 1617290459>
>> JUnit in Action, Second Edition
>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
>> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
>>>
>>
>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
>> 1935182021>
>> Spring Batch in Action
>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
>> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
>> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
>> 1935182951>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
The “context” of the call is only grossly captured by the logger name, and that is only by convention. If you really want the name of the class then you need the location information, which gives you the class name, method name and line number of the caller.
If these are “business” events why do you want to turn them off by the name of the logger? I would think you might want to filter out certain event types, but that shouldn’t be represented by the logger name.
Ralph
> On Oct 18, 2016, at 6:47 AM, Nicholas Duane <ni...@msn.com> wrote:
>
> That's what I initially thought. However, as I pointed out it has the same downsides as a "well known" logger. We lose the context of what code is logging the call (e.g the class name which is usually used as the logger name), and there is no way to turn on/off a section of code from logging, in the case we find some errant code. Those two are big enough issues which are keeping me away from using "well known" loggers.
>
>
> Thanks,
>
> Nick
>
> ________________________________
> From: Matt Sicker <boards@gmail.com <ma...@gmail.com>>
> Sent: Monday, October 17, 2016 11:15 PM
> To: Log4J Users List
> Subject: Re: approach for defining loggers
>
> What about event logging? <
> https://logging.apache.org/log4j/2.x/manual/eventlogging.html <https://logging.apache.org/log4j/2.x/manual/eventlogging.html>>
> Log4j – Log4j 2 API - Apache Log4j 2<https://logging.apache.org/log4j/2.x/manual/eventlogging.html <https://logging.apache.org/log4j/2.x/manual/eventlogging.html>>
> logging.apache.org <http://logging.apache.org/>
> The EventLogger class provides a simple mechanism for logging events that occur in an application. While the EventLogger is useful as a way of initiating events that ...
>
>
>
> This sounds pretty similar to what you're asking about. You define a map
> message essentially, plus your other requirements seem to be met here.
>
> On 17 October 2016 at 21:46, Gary Gregory <ga...@gmail.com> wrote:
>
>> On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane <ni...@msn.com> wrote:
>>
>>> Sorry to revive this old thread. However, we're in the process of adding
>>> support for other "categories" of events and thus I wanted to first take
>> a
>>> step back and try to ensure we're not convoluting things.
>>>
>>>
>>> There was a requirement to log a "compliance" event under certain
>>> conditions. We did not want to write our own logging framework and
>> instead
>>> decided to use existing off-the-shelf logging frameworks. We have
>>> applications on both Linux/Java, Windows/.NET and Windows/Java.
>> Initially
>>> we chose log4net for Windows/.NET and log4j2 for Windows/Java and
>>> Linux/Java. For these logging frameworks we wrote artifacts, appenders
>>> basically, to help facilitate getting these events to our system. By the
>>> way, our system will get the events centrally, possibly put them into a
>>> relational database and also hand them off to another system which will
>> get
>>> them eventually to an HDFS backend. We also exposed methods for creating
>>> this compliance event. The compliance event is basically a map. We
>> chose
>>> a map so that the event could also be extended by the application team in
>>> case they needed to add additional properties which made sense for them.
>>>
>>>
>>> We chose to create a custom level for this "compliance" event such that
>> we
>>> could filter out only these events and get them into our system. The
>>> configuration example we created had our custom unix domain socket
>> appender
>>> added to the root logger. It also contained a filter which filtered out
>>> any events that weren't compliance events. The level we chose for
>>> "compliance" was less critical than off and more critical than fatal as
>> we
>>> wanted to ensure that as long as logging wasn't turned off altogether our
>>> events would get logged.
>>>
>>>
>>> I want to go over a few suggestions that were made and explain why I
>>> didn't make use of those suggestions.
>>>
>>>
>>> 1. Since our "compliance" level didn't fit within the "vernacular" of the
>>> existing levels we should not define this custom level. Instead we
>> should
>>> look at using markers.
>>>
>>
>> Yes, this is a use case for markers. The level should be used to note how
>> important is each compliance event.
>>
>>
>>>
>>> I am not that familiar with markers but did look into them when they were
>>> suggested. While I don't have anything against markers in general there
>>> were some downsides as I saw it.
>>>
>>>
>>> a. Markers are not available, as far as I know, in log4net so we'd still
>>> have to figure out something there.
>>>
>>
>> Indeed, we really need a port of Log4j 2 to .NET.
>>
>>
>>>
>>> b. A bigger problem, at least I thought it was a bigger problem, was that
>>> there would be confusion about what level to log the event at. I would
>>> certainly not want to give an example as follows:
>>>
>>>
>>> logger.debug(COMPLIANCE_MARKER, evnt);
>>>
>>>
>>> or
>>>
>>>
>>> logger.info(COMPLIANCE_MARKER, evnt);
>>>
>>>
>>> or
>>>
>>>
>>> logger.error(COMPLIANCE_MARKER, evnt);
>>>
>>>
>>> ...
>>>
>>
>> Think about: How important is this event? Are there different level of
>> importance to the audience?
>>
>>
>>>
>>>
>>> That just screams confusion to me.
>>>
>>>
>>> 2. Use a dedicated logger to log all compliance events.
>>>
>>>
>>> There were, as far as I could tell, a couple problems with this approach
>>> also.
>>>
>>>
>>> a. If everyone is using a single "well known" logger to log a specific
>>> event category then I lose the logger "context" of who's logging the
>>> event. As it stands now we're copying the logger name into a property we
>>> call "eventSource".
>>>
>>
>> A practice is to use one logger per class. Another is to use a higher-level
>> logger to represent higher-level abstractions like a module.
>>
>>
>>>
>>>
>>> b. You cannot turn on/off logging for a specific set of code. If it
>> turns
>>> out that we have some errant code which is using this well known logger
>>> then we can't just turn off that code from logging as turning off the
>> well
>>> know logger would turn it off for everyone using it.
>>>
>>>
>>> I did look into the EventLogger and initially that seemed promising as I
>>> guess it logs any event you give it at the "all" level. However, as a
>> well
>>> known logger it suffers from the same issues above.
>>>
>>>
>>> Now we're looking to add Business events. My initial thinking is that I
>>> can do the same thing we did before. Add an additional custom level
>> called
>>> "Business" and expose methods for creating a business event.
>>
>>
>> I would NOT create a custom level. Instead, I would use a Logger called
>> "Business".
>>
>>
>>> Though unlike the compliance event, the application teams would be
>>> defining the schema more so than our framework team. Thus any method we
>>> expose would just be used as a starting point for setting the common
>>> properties. You would use another instance of our unix domain socket
>>> appender for these business events and forward them to a different
>> location
>>> as business events would most likely have a different retention period
>> than
>>> compliance events. Plus you might also want them in a different store as
>>> you may never need to query for both categories of events and thus no
>> need
>>> to query against a larger set of data.
>>>
>>>
>>> In addition we're planning to capture centrally what we refer to as
>>> diagnostic events: error, info, warn, debug, trace, etc. However, we may
>>> need to separate these out into two different categories:
>>> critical-diagnostic and noncritical-diagnostic.
>>
>>
>> This could be a user case for custom levels IF one is more important than
>> the other which it sure sounds like it is.
>>
>>
>>
>>> The reason is that we don't want the potential of a critical diagnostic
>>> event, let's say an error, queued up behind potentially thousands of
>>> non-critical diagnostic events. So you see, the category also defines
>>> aspects on how we handle events at the source. We separate at the
>> source
>>> based on category as it seems a reasonable place to do so. Also, you may
>>> want different flush times for different categories. We have a process
>>> which buffers, compresses and sends events centrally so we have the
>> notion
>>> of flush time. The buffers are flushed when they become full or the
>> flush
>>> time elapses. Errors, since they are more critical in monitoring
>> systems,
>>> we'll most likely want to flush more often than say debug and trace
>> events.
>>>
>>>
>>> Sorry for the long winded explanation. Initially I was thinking that
>> when
>>> we create an event we'd set its category. However, now I'm thinking the
>>> category should be set by the act of logging the event at a level. In
>> some
>>> cases we have a 1:1 mapping from level to category, eg. compliance level
>> ->
>>> compliance category. In some cases we have a many:1 mapping from level
>> to
>>> category, eg. error, info, warn -> critical-diagnostic.
>>>
>>>
>>> We could also just define a single custom level, say "always_on", or
>>> something like that. Then we provide some helper method to log our "new"
>>> event categories (eg. business and compliance) at this level and have the
>>> user specify the category, I guess similar to a marker.
>>>
>>
>> Log4j has a level called ALL.
>>
>> I would really try to work hard to stay within the feature set before
>> thinking about anything custom.
>>
>> If you can make critical-diagnostic and noncritical-diagnostic events to
>> stock levels, that much the better.
>>
>> Gary
>>
>>>
>>>
>>> logEvent(Logger logger, String category, object evnt);
>>>
>>>
>>> I guess it's similar to the EventLogger except that we're not using a
>>> single well known logger and thus don't have the downsides of that which
>> I
>>> pointed out earlier.
>>>
>>>
>>> Any thoughts/suggestions would be appreciated.
>>>
>>>
>>> Thanks,
>>>
>>> Nick
>>>
>>> ________________________________
>>> From: Mikael Ståldal <mi...@magine.com>
>>> Sent: Wednesday, September 9, 2015 3:47 AM
>>> To: Log4J Users List
>>> Subject: Re: approach for defining loggers
>>>
>>> Then perhaps you should create your own facade for doing business event
>>> logging, which could then forward them to Log4j in an appropriate way.
>>>
>>> On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
>>>
>>>> I was just about to reply to your previous email about using a single
>>>> "business" logger, or some hierarchy of business loggers, to log
>> business
>>>> events and say that we might go that route. However, now that you
>>> brought
>>>> up the post from Ralph, which I just replied to, I'm thinking a logger
>>>> won't work either for the same reason I listed in my reply to Ralph's
>>> post.
>>>>
>>>> You could do:
>>>>
>>>> logger.info("Hello");
>>>> logger.fatal("Hello");
>>>> logger.error("Hello");
>>>> ...
>>>>
>>>> It's confusing as there are n ways to log a business event that way and
>>>> they will all do the same thing. Which one should a developer choose.
>>>> Should I say pick any one, it doesn't matter?
>>>>
>>>> Thanks,
>>>> Nick
>>>>
>>>>> Date: Tue, 8 Sep 2015 19:28:21 -0700
>>>>> Subject: Re: approach for defining loggers
>>>>> From: garydgregory@gmail.com
>>>>> To: log4j-user@logging.apache.org
>>>>>
>>>>> Or
>>>>> Logger logger = LogManager.getLogger("Business");
>>>>> ...
>>>>> logger.info("Hello");
>>>>>
>>>>> Gary
>>>>>
>>>>> On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
>>> ralph.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> 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 <ni...@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.goers@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-
> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/questions/16813032/what-is-> <http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded&a]%3Chttp://stackoverflow.com/questions/16813032/what-is-%3E>
>
> What is markers in Java Logging frameworks and that is a reason to use them?<http://stackoverflow.com/questions/16813032/what-is- <http://stackoverflow.com/questions/16813032/what-is->>
> stackoverflow.com <http://stackoverflow.com/>
> First time I hear about markers when read: http://slf4j.org/faq.html <http://slf4j.org/faq.html> I check available methods for Logger object: http://www.slf4j.org/api/org/slf4j/Logger.html <http://www.slf4j.org/api/org/slf4j/Logger.html> http://logging.apache.org/log4j/2.x/ <http://logging.apache.org/log4j/2.x/>
>
>
>>> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
>>> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
>>> icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
>>> questions/16813032/what-is-markers-in-java-logging-
>>> frameworks-and-that-is-a-reason-to-use-them>
>>>
>>> What is markers in Java Logging frameworks and that is a ...<
>>> http://stackoverflow.com/questions/16813032/what-is-
>>> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
>>> stackoverflow.com
>>> This is a rehashed version my answer to the question "Best practices for
>>> using Markers in SLF4J/Logback". Markers can be used to color or mark a
>>> single log statement.
>>>
>>>
>>>>>> <
>>>>>>
>>>> http://stackoverflow.com/questions/16813032/what-is-
>>> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
>>> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
>>> icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
>>> questions/16813032/what-is-markers-in-java-logging-
>>> frameworks-and-that-is-a-reason-to-use-them>
>>>
>>> What is markers in Java Logging frameworks and that is a ...<
>>> http://stackoverflow.com/questions/16813032/what-is-
>>> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
>>> stackoverflow.com
>>> This is a rehashed version my answer to the question "Best practices for
>>> using Markers in SLF4J/Logback". Markers can be used to color or mark a
>>> single log statement.
>>>
>>>
>>>>>>> .
>>>>>>>>
>>>>>>>> Ralph
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <
>> nickdu@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-unsubscribe@logging.apache.org
>>>>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-help@logging.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@
>>> logging.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-help@logging.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>> ---------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.
>> apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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
>>> [https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/>
>>>
>>> Gary Gregory<http://garygregory.wordpress.com/>
>>> garygregory.wordpress.com
>>> Software construction, the web, and other techs
>>>
>>>
>>>>> Home: http://garygregory.com/
>>> Gary Gregory<http://garygregory.com/>
>>> garygregory.com
>>> Rocket | Seagull . I am a Software Architect for Seagull Software, a
>>> division of Rocket Software. Rocket Seagull specializes in tools and
>>> expertise to modernize ...
>>>
>>>
>>>>> Tweet! http://twitter.com/GaryGregory
>>> Gary Gregory (@GaryGregory) | Twitter<http://twitter.com/GaryGregory>
>>> twitter.com
>>> The latest Tweets from Gary Gregory (@GaryGregory). Principal Software
>>> Engineer, author: Java Persistence Hibernate https://t.co/3F8sYxc0oq,
>>> JUnit https://t.co/yXU1DqAMDG, Spring Batch https://t.co/XwoMNoBxh7.
>>> U.S.A.
>>>
>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com<<http://www.magine.com<>
>>> http://www.magine.com <http://www.magine.com/>>
>>> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png <https://de.magine.com/content/uploads/2016/09/magine_global_social.png>
>> ]<
>>> http://www.magine.com/ <http://www.magine.com/>>
>>>
>>> TV online with Magine TV<http://www.magine.com/ <http://www.magine.com/>>
>>> www.magine.com <http://www.magine.com/><http://www.magine.com <http://www.magine.com/>>
>>> Watch the TV you love, on any device, anywhere in Germany and Sweden and
>>> find out more about our global OTT B2B solutions. Get started today.
>>>
>>>
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>> not
>>> copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
>> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>
>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
>> 1617290459>
>> JUnit in Action, Second Edition
>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
>> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
>>>
>>
>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
>> 1935182021>
>> Spring Batch in Action
>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
>> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
>> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
>> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
>> 1935182951>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
That's what I initially thought. However, as I pointed out it has the same downsides as a "well known" logger. We lose the context of what code is logging the call (e.g the class name which is usually used as the logger name), and there is no way to turn on/off a section of code from logging, in the case we find some errant code. Those two are big enough issues which are keeping me away from using "well known" loggers.
Thanks,
Nick
________________________________
From: Matt Sicker <bo...@gmail.com>
Sent: Monday, October 17, 2016 11:15 PM
To: Log4J Users List
Subject: Re: approach for defining loggers
What about event logging? <
https://logging.apache.org/log4j/2.x/manual/eventlogging.html>
Log4j – Log4j 2 API - Apache Log4j 2<https://logging.apache.org/log4j/2.x/manual/eventlogging.html>
logging.apache.org
The EventLogger class provides a simple mechanism for logging events that occur in an application. While the EventLogger is useful as a way of initiating events that ...
This sounds pretty similar to what you're asking about. You define a map
message essentially, plus your other requirements seem to be met here.
On 17 October 2016 at 21:46, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane <ni...@msn.com> wrote:
>
> > Sorry to revive this old thread. However, we're in the process of adding
> > support for other "categories" of events and thus I wanted to first take
> a
> > step back and try to ensure we're not convoluting things.
> >
> >
> > There was a requirement to log a "compliance" event under certain
> > conditions. We did not want to write our own logging framework and
> instead
> > decided to use existing off-the-shelf logging frameworks. We have
> > applications on both Linux/Java, Windows/.NET and Windows/Java.
> Initially
> > we chose log4net for Windows/.NET and log4j2 for Windows/Java and
> > Linux/Java. For these logging frameworks we wrote artifacts, appenders
> > basically, to help facilitate getting these events to our system. By the
> > way, our system will get the events centrally, possibly put them into a
> > relational database and also hand them off to another system which will
> get
> > them eventually to an HDFS backend. We also exposed methods for creating
> > this compliance event. The compliance event is basically a map. We
> chose
> > a map so that the event could also be extended by the application team in
> > case they needed to add additional properties which made sense for them.
> >
> >
> > We chose to create a custom level for this "compliance" event such that
> we
> > could filter out only these events and get them into our system. The
> > configuration example we created had our custom unix domain socket
> appender
> > added to the root logger. It also contained a filter which filtered out
> > any events that weren't compliance events. The level we chose for
> > "compliance" was less critical than off and more critical than fatal as
> we
> > wanted to ensure that as long as logging wasn't turned off altogether our
> > events would get logged.
> >
> >
> > I want to go over a few suggestions that were made and explain why I
> > didn't make use of those suggestions.
> >
> >
> > 1. Since our "compliance" level didn't fit within the "vernacular" of the
> > existing levels we should not define this custom level. Instead we
> should
> > look at using markers.
> >
>
> Yes, this is a use case for markers. The level should be used to note how
> important is each compliance event.
>
>
> >
> > I am not that familiar with markers but did look into them when they were
> > suggested. While I don't have anything against markers in general there
> > were some downsides as I saw it.
> >
> >
> > a. Markers are not available, as far as I know, in log4net so we'd still
> > have to figure out something there.
> >
>
> Indeed, we really need a port of Log4j 2 to .NET.
>
>
> >
> > b. A bigger problem, at least I thought it was a bigger problem, was that
> > there would be confusion about what level to log the event at. I would
> > certainly not want to give an example as follows:
> >
> >
> > logger.debug(COMPLIANCE_MARKER, evnt);
> >
> >
> > or
> >
> >
> > logger.info(COMPLIANCE_MARKER, evnt);
> >
> >
> > or
> >
> >
> > logger.error(COMPLIANCE_MARKER, evnt);
> >
> >
> > ...
> >
>
> Think about: How important is this event? Are there different level of
> importance to the audience?
>
>
> >
> >
> > That just screams confusion to me.
> >
> >
> > 2. Use a dedicated logger to log all compliance events.
> >
> >
> > There were, as far as I could tell, a couple problems with this approach
> > also.
> >
> >
> > a. If everyone is using a single "well known" logger to log a specific
> > event category then I lose the logger "context" of who's logging the
> > event. As it stands now we're copying the logger name into a property we
> > call "eventSource".
> >
>
> A practice is to use one logger per class. Another is to use a higher-level
> logger to represent higher-level abstractions like a module.
>
>
> >
> >
> > b. You cannot turn on/off logging for a specific set of code. If it
> turns
> > out that we have some errant code which is using this well known logger
> > then we can't just turn off that code from logging as turning off the
> well
> > know logger would turn it off for everyone using it.
> >
> >
> > I did look into the EventLogger and initially that seemed promising as I
> > guess it logs any event you give it at the "all" level. However, as a
> well
> > known logger it suffers from the same issues above.
> >
> >
> > Now we're looking to add Business events. My initial thinking is that I
> > can do the same thing we did before. Add an additional custom level
> called
> > "Business" and expose methods for creating a business event.
>
>
> I would NOT create a custom level. Instead, I would use a Logger called
> "Business".
>
>
> > Though unlike the compliance event, the application teams would be
> > defining the schema more so than our framework team. Thus any method we
> > expose would just be used as a starting point for setting the common
> > properties. You would use another instance of our unix domain socket
> > appender for these business events and forward them to a different
> location
> > as business events would most likely have a different retention period
> than
> > compliance events. Plus you might also want them in a different store as
> > you may never need to query for both categories of events and thus no
> need
> > to query against a larger set of data.
> >
> >
> > In addition we're planning to capture centrally what we refer to as
> > diagnostic events: error, info, warn, debug, trace, etc. However, we may
> > need to separate these out into two different categories:
> > critical-diagnostic and noncritical-diagnostic.
>
>
> This could be a user case for custom levels IF one is more important than
> the other which it sure sounds like it is.
>
>
>
> > The reason is that we don't want the potential of a critical diagnostic
> > event, let's say an error, queued up behind potentially thousands of
> > non-critical diagnostic events. So you see, the category also defines
> > aspects on how we handle events at the source. We separate at the
> source
> > based on category as it seems a reasonable place to do so. Also, you may
> > want different flush times for different categories. We have a process
> > which buffers, compresses and sends events centrally so we have the
> notion
> > of flush time. The buffers are flushed when they become full or the
> flush
> > time elapses. Errors, since they are more critical in monitoring
> systems,
> > we'll most likely want to flush more often than say debug and trace
> events.
> >
> >
> > Sorry for the long winded explanation. Initially I was thinking that
> when
> > we create an event we'd set its category. However, now I'm thinking the
> > category should be set by the act of logging the event at a level. In
> some
> > cases we have a 1:1 mapping from level to category, eg. compliance level
> ->
> > compliance category. In some cases we have a many:1 mapping from level
> to
> > category, eg. error, info, warn -> critical-diagnostic.
> >
> >
> > We could also just define a single custom level, say "always_on", or
> > something like that. Then we provide some helper method to log our "new"
> > event categories (eg. business and compliance) at this level and have the
> > user specify the category, I guess similar to a marker.
> >
>
> Log4j has a level called ALL.
>
> I would really try to work hard to stay within the feature set before
> thinking about anything custom.
>
> If you can make critical-diagnostic and noncritical-diagnostic events to
> stock levels, that much the better.
>
> Gary
>
> >
> >
> > logEvent(Logger logger, String category, object evnt);
> >
> >
> > I guess it's similar to the EventLogger except that we're not using a
> > single well known logger and thus don't have the downsides of that which
> I
> > pointed out earlier.
> >
> >
> > Any thoughts/suggestions would be appreciated.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > ________________________________
> > From: Mikael Ståldal <mi...@magine.com>
> > Sent: Wednesday, September 9, 2015 3:47 AM
> > To: Log4J Users List
> > Subject: Re: approach for defining loggers
> >
> > Then perhaps you should create your own facade for doing business event
> > logging, which could then forward them to Log4j in an appropriate way.
> >
> > On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
> >
> > > I was just about to reply to your previous email about using a single
> > > "business" logger, or some hierarchy of business loggers, to log
> business
> > > events and say that we might go that route. However, now that you
> > brought
> > > up the post from Ralph, which I just replied to, I'm thinking a logger
> > > won't work either for the same reason I listed in my reply to Ralph's
> > post.
> > >
> > > You could do:
> > >
> > > logger.info("Hello");
> > > logger.fatal("Hello");
> > > logger.error("Hello");
> > > ...
> > >
> > > It's confusing as there are n ways to log a business event that way and
> > > they will all do the same thing. Which one should a developer choose.
> > > Should I say pick any one, it doesn't matter?
> > >
> > > Thanks,
> > > Nick
> > >
> > > > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > > > Subject: Re: approach for defining loggers
> > > > From: garydgregory@gmail.com
> > > > To: log4j-user@logging.apache.org
> > > >
> > > > Or
> > > > Logger logger = LogManager.getLogger("Business");
> > > > ...
> > > > logger.info("Hello");
> > > >
> > > > Gary
> > > >
> > > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> > ralph.goers@dslextreme.com>
> > > > wrote:
> > > >
> > > > > 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 <ni...@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.goers@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-
[http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/questions/16813032/what-is->
What is markers in Java Logging frameworks and that is a reason to use them?<http://stackoverflow.com/questions/16813032/what-is->
stackoverflow.com
First time I hear about markers when read: http://slf4j.org/faq.html I check available methods for Logger object: http://www.slf4j.org/api/org/slf4j/Logger.html http://logging.apache.org/log4j/2.x/
> > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> > [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
> > icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
> > questions/16813032/what-is-markers-in-java-logging-
> > frameworks-and-that-is-a-reason-to-use-them>
> >
> > What is markers in Java Logging frameworks and that is a ...<
> > http://stackoverflow.com/questions/16813032/what-is-
> > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
> > stackoverflow.com
> > This is a rehashed version my answer to the question "Best practices for
> > using Markers in SLF4J/Logback". Markers can be used to color or mark a
> > single log statement.
> >
> >
> > > > > <
> > > > >
> > > http://stackoverflow.com/questions/16813032/what-is-
> > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> > [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
> > icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
> > questions/16813032/what-is-markers-in-java-logging-
> > frameworks-and-that-is-a-reason-to-use-them>
> >
> > What is markers in Java Logging frameworks and that is a ...<
> > http://stackoverflow.com/questions/16813032/what-is-
> > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
> > stackoverflow.com
> > This is a rehashed version my answer to the question "Best practices for
> > using Markers in SLF4J/Logback". Markers can be used to color or mark a
> > single log statement.
> >
> >
> > > > > >.
> > > > > >>
> > > > > >> Ralph
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <
> nickdu@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-unsubscribe@logging.apache.org
> > > > > >>>>>> For additional commands, e-mail:
> > > log4j-user-help@logging.apache.org
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > ---------------------------------------------------------------------
> > > > > >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@
> > logging.apache.org
> > > > > >>>> For additional commands, e-mail:
> > > log4j-user-help@logging.apache.org
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------------------------------
> > ---------
> > > > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > > > For additional commands, e-mail: log4j-user-help@logging.
> apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > 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
> > [https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/>
> >
> > Gary Gregory<http://garygregory.wordpress.com/>
> > garygregory.wordpress.com
> > Software construction, the web, and other techs
> >
> >
> > > > Home: http://garygregory.com/
> > Gary Gregory<http://garygregory.com/>
> > garygregory.com
> > Rocket | Seagull . I am a Software Architect for Seagull Software, a
> > division of Rocket Software. Rocket Seagull specializes in tools and
> > expertise to modernize ...
> >
> >
> > > > Tweet! http://twitter.com/GaryGregory
> > Gary Gregory (@GaryGregory) | Twitter<http://twitter.com/GaryGregory>
> > twitter.com
> > The latest Tweets from Gary Gregory (@GaryGregory). Principal Software
> > Engineer, author: Java Persistence Hibernate https://t.co/3F8sYxc0oq,
> > JUnit https://t.co/yXU1DqAMDG, Spring Batch https://t.co/XwoMNoBxh7.
> > U.S.A.
> >
> >
> > >
> > >
> >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.staldal@magine.com
> > Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com<<http://www.magine.com<>
> > http://www.magine.com>
> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png
> ]<
> > http://www.magine.com/>
> >
> > TV online with Magine TV<http://www.magine.com/>
> > www.magine.com<http://www.magine.com>
> > Watch the TV you love, on any device, anywhere in Germany and Sweden and
> > find out more about our global OTT B2B solutions. Get started today.
> >
> >
> >
> > Privileged and/or Confidential Information may be contained in this
> > message. If you are not the addressee indicated in this message
> > (or responsible for delivery of the message to such a person), you may
> not
> > copy or deliver this message to anyone. In such case,
> > you should destroy this message and kindly notify the sender by reply
> > email.
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: approach for defining loggers
Posted by Matt Sicker <bo...@gmail.com>.
What about event logging? <
https://logging.apache.org/log4j/2.x/manual/eventlogging.html>
This sounds pretty similar to what you're asking about. You define a map
message essentially, plus your other requirements seem to be met here.
On 17 October 2016 at 21:46, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane <ni...@msn.com> wrote:
>
> > Sorry to revive this old thread. However, we're in the process of adding
> > support for other "categories" of events and thus I wanted to first take
> a
> > step back and try to ensure we're not convoluting things.
> >
> >
> > There was a requirement to log a "compliance" event under certain
> > conditions. We did not want to write our own logging framework and
> instead
> > decided to use existing off-the-shelf logging frameworks. We have
> > applications on both Linux/Java, Windows/.NET and Windows/Java.
> Initially
> > we chose log4net for Windows/.NET and log4j2 for Windows/Java and
> > Linux/Java. For these logging frameworks we wrote artifacts, appenders
> > basically, to help facilitate getting these events to our system. By the
> > way, our system will get the events centrally, possibly put them into a
> > relational database and also hand them off to another system which will
> get
> > them eventually to an HDFS backend. We also exposed methods for creating
> > this compliance event. The compliance event is basically a map. We
> chose
> > a map so that the event could also be extended by the application team in
> > case they needed to add additional properties which made sense for them.
> >
> >
> > We chose to create a custom level for this "compliance" event such that
> we
> > could filter out only these events and get them into our system. The
> > configuration example we created had our custom unix domain socket
> appender
> > added to the root logger. It also contained a filter which filtered out
> > any events that weren't compliance events. The level we chose for
> > "compliance" was less critical than off and more critical than fatal as
> we
> > wanted to ensure that as long as logging wasn't turned off altogether our
> > events would get logged.
> >
> >
> > I want to go over a few suggestions that were made and explain why I
> > didn't make use of those suggestions.
> >
> >
> > 1. Since our "compliance" level didn't fit within the "vernacular" of the
> > existing levels we should not define this custom level. Instead we
> should
> > look at using markers.
> >
>
> Yes, this is a use case for markers. The level should be used to note how
> important is each compliance event.
>
>
> >
> > I am not that familiar with markers but did look into them when they were
> > suggested. While I don't have anything against markers in general there
> > were some downsides as I saw it.
> >
> >
> > a. Markers are not available, as far as I know, in log4net so we'd still
> > have to figure out something there.
> >
>
> Indeed, we really need a port of Log4j 2 to .NET.
>
>
> >
> > b. A bigger problem, at least I thought it was a bigger problem, was that
> > there would be confusion about what level to log the event at. I would
> > certainly not want to give an example as follows:
> >
> >
> > logger.debug(COMPLIANCE_MARKER, evnt);
> >
> >
> > or
> >
> >
> > logger.info(COMPLIANCE_MARKER, evnt);
> >
> >
> > or
> >
> >
> > logger.error(COMPLIANCE_MARKER, evnt);
> >
> >
> > ...
> >
>
> Think about: How important is this event? Are there different level of
> importance to the audience?
>
>
> >
> >
> > That just screams confusion to me.
> >
> >
> > 2. Use a dedicated logger to log all compliance events.
> >
> >
> > There were, as far as I could tell, a couple problems with this approach
> > also.
> >
> >
> > a. If everyone is using a single "well known" logger to log a specific
> > event category then I lose the logger "context" of who's logging the
> > event. As it stands now we're copying the logger name into a property we
> > call "eventSource".
> >
>
> A practice is to use one logger per class. Another is to use a higher-level
> logger to represent higher-level abstractions like a module.
>
>
> >
> >
> > b. You cannot turn on/off logging for a specific set of code. If it
> turns
> > out that we have some errant code which is using this well known logger
> > then we can't just turn off that code from logging as turning off the
> well
> > know logger would turn it off for everyone using it.
> >
> >
> > I did look into the EventLogger and initially that seemed promising as I
> > guess it logs any event you give it at the "all" level. However, as a
> well
> > known logger it suffers from the same issues above.
> >
> >
> > Now we're looking to add Business events. My initial thinking is that I
> > can do the same thing we did before. Add an additional custom level
> called
> > "Business" and expose methods for creating a business event.
>
>
> I would NOT create a custom level. Instead, I would use a Logger called
> "Business".
>
>
> > Though unlike the compliance event, the application teams would be
> > defining the schema more so than our framework team. Thus any method we
> > expose would just be used as a starting point for setting the common
> > properties. You would use another instance of our unix domain socket
> > appender for these business events and forward them to a different
> location
> > as business events would most likely have a different retention period
> than
> > compliance events. Plus you might also want them in a different store as
> > you may never need to query for both categories of events and thus no
> need
> > to query against a larger set of data.
> >
> >
> > In addition we're planning to capture centrally what we refer to as
> > diagnostic events: error, info, warn, debug, trace, etc. However, we may
> > need to separate these out into two different categories:
> > critical-diagnostic and noncritical-diagnostic.
>
>
> This could be a user case for custom levels IF one is more important than
> the other which it sure sounds like it is.
>
>
>
> > The reason is that we don't want the potential of a critical diagnostic
> > event, let's say an error, queued up behind potentially thousands of
> > non-critical diagnostic events. So you see, the category also defines
> > aspects on how we handle events at the source. We separate at the
> source
> > based on category as it seems a reasonable place to do so. Also, you may
> > want different flush times for different categories. We have a process
> > which buffers, compresses and sends events centrally so we have the
> notion
> > of flush time. The buffers are flushed when they become full or the
> flush
> > time elapses. Errors, since they are more critical in monitoring
> systems,
> > we'll most likely want to flush more often than say debug and trace
> events.
> >
> >
> > Sorry for the long winded explanation. Initially I was thinking that
> when
> > we create an event we'd set its category. However, now I'm thinking the
> > category should be set by the act of logging the event at a level. In
> some
> > cases we have a 1:1 mapping from level to category, eg. compliance level
> ->
> > compliance category. In some cases we have a many:1 mapping from level
> to
> > category, eg. error, info, warn -> critical-diagnostic.
> >
> >
> > We could also just define a single custom level, say "always_on", or
> > something like that. Then we provide some helper method to log our "new"
> > event categories (eg. business and compliance) at this level and have the
> > user specify the category, I guess similar to a marker.
> >
>
> Log4j has a level called ALL.
>
> I would really try to work hard to stay within the feature set before
> thinking about anything custom.
>
> If you can make critical-diagnostic and noncritical-diagnostic events to
> stock levels, that much the better.
>
> Gary
>
> >
> >
> > logEvent(Logger logger, String category, object evnt);
> >
> >
> > I guess it's similar to the EventLogger except that we're not using a
> > single well known logger and thus don't have the downsides of that which
> I
> > pointed out earlier.
> >
> >
> > Any thoughts/suggestions would be appreciated.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > ________________________________
> > From: Mikael Ståldal <mi...@magine.com>
> > Sent: Wednesday, September 9, 2015 3:47 AM
> > To: Log4J Users List
> > Subject: Re: approach for defining loggers
> >
> > Then perhaps you should create your own facade for doing business event
> > logging, which could then forward them to Log4j in an appropriate way.
> >
> > On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
> >
> > > I was just about to reply to your previous email about using a single
> > > "business" logger, or some hierarchy of business loggers, to log
> business
> > > events and say that we might go that route. However, now that you
> > brought
> > > up the post from Ralph, which I just replied to, I'm thinking a logger
> > > won't work either for the same reason I listed in my reply to Ralph's
> > post.
> > >
> > > You could do:
> > >
> > > logger.info("Hello");
> > > logger.fatal("Hello");
> > > logger.error("Hello");
> > > ...
> > >
> > > It's confusing as there are n ways to log a business event that way and
> > > they will all do the same thing. Which one should a developer choose.
> > > Should I say pick any one, it doesn't matter?
> > >
> > > Thanks,
> > > Nick
> > >
> > > > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > > > Subject: Re: approach for defining loggers
> > > > From: garydgregory@gmail.com
> > > > To: log4j-user@logging.apache.org
> > > >
> > > > Or
> > > > Logger logger = LogManager.getLogger("Business");
> > > > ...
> > > > logger.info("Hello");
> > > >
> > > > Gary
> > > >
> > > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> > ralph.goers@dslextreme.com>
> > > > wrote:
> > > >
> > > > > 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 <ni...@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.goers@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://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
> > icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
> > questions/16813032/what-is-markers-in-java-logging-
> > frameworks-and-that-is-a-reason-to-use-them>
> >
> > What is markers in Java Logging frameworks and that is a ...<
> > http://stackoverflow.com/questions/16813032/what-is-
> > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
> > stackoverflow.com
> > This is a rehashed version my answer to the question "Best practices for
> > using Markers in SLF4J/Logback". Markers can be used to color or mark a
> > single log statement.
> >
> >
> > > > > <
> > > > >
> > > http://stackoverflow.com/questions/16813032/what-is-
> > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> > [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
> > icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
> > questions/16813032/what-is-markers-in-java-logging-
> > frameworks-and-that-is-a-reason-to-use-them>
> >
> > What is markers in Java Logging frameworks and that is a ...<
> > http://stackoverflow.com/questions/16813032/what-is-
> > markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
> > stackoverflow.com
> > This is a rehashed version my answer to the question "Best practices for
> > using Markers in SLF4J/Logback". Markers can be used to color or mark a
> > single log statement.
> >
> >
> > > > > >.
> > > > > >>
> > > > > >> Ralph
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <
> nickdu@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-unsubscribe@logging.apache.org
> > > > > >>>>>> For additional commands, e-mail:
> > > log4j-user-help@logging.apache.org
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > ---------------------------------------------------------------------
> > > > > >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@
> > logging.apache.org
> > > > > >>>> For additional commands, e-mail:
> > > log4j-user-help@logging.apache.org
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > ------------------------------------------------------------
> > ---------
> > > > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > > > For additional commands, e-mail: log4j-user-help@logging.
> apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > 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
> > [https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/>
> >
> > Gary Gregory<http://garygregory.wordpress.com/>
> > garygregory.wordpress.com
> > Software construction, the web, and other techs
> >
> >
> > > > Home: http://garygregory.com/
> > Gary Gregory<http://garygregory.com/>
> > garygregory.com
> > Rocket | Seagull . I am a Software Architect for Seagull Software, a
> > division of Rocket Software. Rocket Seagull specializes in tools and
> > expertise to modernize ...
> >
> >
> > > > Tweet! http://twitter.com/GaryGregory
> > Gary Gregory (@GaryGregory) | Twitter<http://twitter.com/GaryGregory>
> > twitter.com
> > The latest Tweets from Gary Gregory (@GaryGregory). Principal Software
> > Engineer, author: Java Persistence Hibernate https://t.co/3F8sYxc0oq,
> > JUnit https://t.co/yXU1DqAMDG, Spring Batch https://t.co/XwoMNoBxh7.
> > U.S.A.
> >
> >
> > >
> > >
> >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.staldal@magine.com
> > Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com<
> > http://www.magine.com>
> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png
> ]<
> > http://www.magine.com/>
> >
> > TV online with Magine TV<http://www.magine.com/>
> > www.magine.com
> > Watch the TV you love, on any device, anywhere in Germany and Sweden and
> > find out more about our global OTT B2B solutions. Get started today.
> >
> >
> >
> > Privileged and/or Confidential Information may be contained in this
> > message. If you are not the addressee indicated in this message
> > (or responsible for delivery of the message to such a person), you may
> not
> > copy or deliver this message to anyone. In such case,
> > you should destroy this message and kindly notify the sender by reply
> > email.
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&
> linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&
> linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22
> >
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_
> tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&
> linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%
> 7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=
> 1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane <ni...@msn.com> wrote:
> Sorry to revive this old thread. However, we're in the process of adding
> support for other "categories" of events and thus I wanted to first take a
> step back and try to ensure we're not convoluting things.
>
>
> There was a requirement to log a "compliance" event under certain
> conditions. We did not want to write our own logging framework and instead
> decided to use existing off-the-shelf logging frameworks. We have
> applications on both Linux/Java, Windows/.NET and Windows/Java. Initially
> we chose log4net for Windows/.NET and log4j2 for Windows/Java and
> Linux/Java. For these logging frameworks we wrote artifacts, appenders
> basically, to help facilitate getting these events to our system. By the
> way, our system will get the events centrally, possibly put them into a
> relational database and also hand them off to another system which will get
> them eventually to an HDFS backend. We also exposed methods for creating
> this compliance event. The compliance event is basically a map. We chose
> a map so that the event could also be extended by the application team in
> case they needed to add additional properties which made sense for them.
>
>
> We chose to create a custom level for this "compliance" event such that we
> could filter out only these events and get them into our system. The
> configuration example we created had our custom unix domain socket appender
> added to the root logger. It also contained a filter which filtered out
> any events that weren't compliance events. The level we chose for
> "compliance" was less critical than off and more critical than fatal as we
> wanted to ensure that as long as logging wasn't turned off altogether our
> events would get logged.
>
>
> I want to go over a few suggestions that were made and explain why I
> didn't make use of those suggestions.
>
>
> 1. Since our "compliance" level didn't fit within the "vernacular" of the
> existing levels we should not define this custom level. Instead we should
> look at using markers.
>
Yes, this is a use case for markers. The level should be used to note how
important is each compliance event.
>
> I am not that familiar with markers but did look into them when they were
> suggested. While I don't have anything against markers in general there
> were some downsides as I saw it.
>
>
> a. Markers are not available, as far as I know, in log4net so we'd still
> have to figure out something there.
>
Indeed, we really need a port of Log4j 2 to .NET.
>
> b. A bigger problem, at least I thought it was a bigger problem, was that
> there would be confusion about what level to log the event at. I would
> certainly not want to give an example as follows:
>
>
> logger.debug(COMPLIANCE_MARKER, evnt);
>
>
> or
>
>
> logger.info(COMPLIANCE_MARKER, evnt);
>
>
> or
>
>
> logger.error(COMPLIANCE_MARKER, evnt);
>
>
> ...
>
Think about: How important is this event? Are there different level of
importance to the audience?
>
>
> That just screams confusion to me.
>
>
> 2. Use a dedicated logger to log all compliance events.
>
>
> There were, as far as I could tell, a couple problems with this approach
> also.
>
>
> a. If everyone is using a single "well known" logger to log a specific
> event category then I lose the logger "context" of who's logging the
> event. As it stands now we're copying the logger name into a property we
> call "eventSource".
>
A practice is to use one logger per class. Another is to use a higher-level
logger to represent higher-level abstractions like a module.
>
>
> b. You cannot turn on/off logging for a specific set of code. If it turns
> out that we have some errant code which is using this well known logger
> then we can't just turn off that code from logging as turning off the well
> know logger would turn it off for everyone using it.
>
>
> I did look into the EventLogger and initially that seemed promising as I
> guess it logs any event you give it at the "all" level. However, as a well
> known logger it suffers from the same issues above.
>
>
> Now we're looking to add Business events. My initial thinking is that I
> can do the same thing we did before. Add an additional custom level called
> "Business" and expose methods for creating a business event.
I would NOT create a custom level. Instead, I would use a Logger called
"Business".
> Though unlike the compliance event, the application teams would be
> defining the schema more so than our framework team. Thus any method we
> expose would just be used as a starting point for setting the common
> properties. You would use another instance of our unix domain socket
> appender for these business events and forward them to a different location
> as business events would most likely have a different retention period than
> compliance events. Plus you might also want them in a different store as
> you may never need to query for both categories of events and thus no need
> to query against a larger set of data.
>
>
> In addition we're planning to capture centrally what we refer to as
> diagnostic events: error, info, warn, debug, trace, etc. However, we may
> need to separate these out into two different categories:
> critical-diagnostic and noncritical-diagnostic.
This could be a user case for custom levels IF one is more important than
the other which it sure sounds like it is.
> The reason is that we don't want the potential of a critical diagnostic
> event, let's say an error, queued up behind potentially thousands of
> non-critical diagnostic events. So you see, the category also defines
> aspects on how we handle events at the source. We separate at the source
> based on category as it seems a reasonable place to do so. Also, you may
> want different flush times for different categories. We have a process
> which buffers, compresses and sends events centrally so we have the notion
> of flush time. The buffers are flushed when they become full or the flush
> time elapses. Errors, since they are more critical in monitoring systems,
> we'll most likely want to flush more often than say debug and trace events.
>
>
> Sorry for the long winded explanation. Initially I was thinking that when
> we create an event we'd set its category. However, now I'm thinking the
> category should be set by the act of logging the event at a level. In some
> cases we have a 1:1 mapping from level to category, eg. compliance level ->
> compliance category. In some cases we have a many:1 mapping from level to
> category, eg. error, info, warn -> critical-diagnostic.
>
>
> We could also just define a single custom level, say "always_on", or
> something like that. Then we provide some helper method to log our "new"
> event categories (eg. business and compliance) at this level and have the
> user specify the category, I guess similar to a marker.
>
Log4j has a level called ALL.
I would really try to work hard to stay within the feature set before
thinking about anything custom.
If you can make critical-diagnostic and noncritical-diagnostic events to
stock levels, that much the better.
Gary
>
>
> logEvent(Logger logger, String category, object evnt);
>
>
> I guess it's similar to the EventLogger except that we're not using a
> single well known logger and thus don't have the downsides of that which I
> pointed out earlier.
>
>
> Any thoughts/suggestions would be appreciated.
>
>
> Thanks,
>
> Nick
>
> ________________________________
> From: Mikael Ståldal <mi...@magine.com>
> Sent: Wednesday, September 9, 2015 3:47 AM
> To: Log4J Users List
> Subject: Re: approach for defining loggers
>
> Then perhaps you should create your own facade for doing business event
> logging, which could then forward them to Log4j in an appropriate way.
>
> On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
>
> > I was just about to reply to your previous email about using a single
> > "business" logger, or some hierarchy of business loggers, to log business
> > events and say that we might go that route. However, now that you
> brought
> > up the post from Ralph, which I just replied to, I'm thinking a logger
> > won't work either for the same reason I listed in my reply to Ralph's
> post.
> >
> > You could do:
> >
> > logger.info("Hello");
> > logger.fatal("Hello");
> > logger.error("Hello");
> > ...
> >
> > It's confusing as there are n ways to log a business event that way and
> > they will all do the same thing. Which one should a developer choose.
> > Should I say pick any one, it doesn't matter?
> >
> > Thanks,
> > Nick
> >
> > > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > > Subject: Re: approach for defining loggers
> > > From: garydgregory@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > Or
> > > Logger logger = LogManager.getLogger("Business");
> > > ...
> > > logger.info("Hello");
> > >
> > > Gary
> > >
> > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> ralph.goers@dslextreme.com>
> > > wrote:
> > >
> > > > 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 <ni...@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.goers@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://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
> icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
> questions/16813032/what-is-markers-in-java-logging-
> frameworks-and-that-is-a-reason-to-use-them>
>
> What is markers in Java Logging frameworks and that is a ...<
> http://stackoverflow.com/questions/16813032/what-is-
> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
> stackoverflow.com
> This is a rehashed version my answer to the question "Best practices for
> using Markers in SLF4J/Logback". Markers can be used to color or mark a
> single log statement.
>
>
> > > > <
> > > >
> > http://stackoverflow.com/questions/16813032/what-is-
> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> [http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-
> icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/
> questions/16813032/what-is-markers-in-java-logging-
> frameworks-and-that-is-a-reason-to-use-them>
>
> What is markers in Java Logging frameworks and that is a ...<
> http://stackoverflow.com/questions/16813032/what-is-
> markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
> stackoverflow.com
> This is a rehashed version my answer to the question "Best practices for
> using Markers in SLF4J/Logback". Markers can be used to color or mark a
> single log statement.
>
>
> > > > >.
> > > > >>
> > > > >> Ralph
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > > >>>>>> For additional commands, e-mail:
> > log4j-user-help@logging.apache.org
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > ---------------------------------------------------------------------
> > > > >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@
> logging.apache.org
> > > > >>>> For additional commands, e-mail:
> > log4j-user-help@logging.apache.org
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > 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
> [https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/>
>
> Gary Gregory<http://garygregory.wordpress.com/>
> garygregory.wordpress.com
> Software construction, the web, and other techs
>
>
> > > Home: http://garygregory.com/
> Gary Gregory<http://garygregory.com/>
> garygregory.com
> Rocket | Seagull . I am a Software Architect for Seagull Software, a
> division of Rocket Software. Rocket Seagull specializes in tools and
> expertise to modernize ...
>
>
> > > Tweet! http://twitter.com/GaryGregory
> Gary Gregory (@GaryGregory) | Twitter<http://twitter.com/GaryGregory>
> twitter.com
> The latest Tweets from Gary Gregory (@GaryGregory). Principal Software
> Engineer, author: Java Persistence Hibernate https://t.co/3F8sYxc0oq,
> JUnit https://t.co/yXU1DqAMDG, Spring Batch https://t.co/XwoMNoBxh7.
> U.S.A.
>
>
> >
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com<
> http://www.magine.com>
> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<
> http://www.magine.com/>
>
> TV online with Magine TV<http://www.magine.com/>
> www.magine.com
> Watch the TV you love, on any device, anywhere in Germany and Sweden and
> find out more about our global OTT B2B solutions. Get started today.
>
>
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
Sorry to revive this old thread. However, we're in the process of adding support for other "categories" of events and thus I wanted to first take a step back and try to ensure we're not convoluting things.
There was a requirement to log a "compliance" event under certain conditions. We did not want to write our own logging framework and instead decided to use existing off-the-shelf logging frameworks. We have applications on both Linux/Java, Windows/.NET and Windows/Java. Initially we chose log4net for Windows/.NET and log4j2 for Windows/Java and Linux/Java. For these logging frameworks we wrote artifacts, appenders basically, to help facilitate getting these events to our system. By the way, our system will get the events centrally, possibly put them into a relational database and also hand them off to another system which will get them eventually to an HDFS backend. We also exposed methods for creating this compliance event. The compliance event is basically a map. We chose a map so that the event could also be extended by the application team in case they needed to add additional properties which made sense for them.
We chose to create a custom level for this "compliance" event such that we could filter out only these events and get them into our system. The configuration example we created had our custom unix domain socket appender added to the root logger. It also contained a filter which filtered out any events that weren't compliance events. The level we chose for "compliance" was less critical than off and more critical than fatal as we wanted to ensure that as long as logging wasn't turned off altogether our events would get logged.
I want to go over a few suggestions that were made and explain why I didn't make use of those suggestions.
1. Since our "compliance" level didn't fit within the "vernacular" of the existing levels we should not define this custom level. Instead we should look at using markers.
I am not that familiar with markers but did look into them when they were suggested. While I don't have anything against markers in general there were some downsides as I saw it.
a. Markers are not available, as far as I know, in log4net so we'd still have to figure out something there.
b. A bigger problem, at least I thought it was a bigger problem, was that there would be confusion about what level to log the event at. I would certainly not want to give an example as follows:
logger.debug(COMPLIANCE_MARKER, evnt);
or
logger.info(COMPLIANCE_MARKER, evnt);
or
logger.error(COMPLIANCE_MARKER, evnt);
...
That just screams confusion to me.
2. Use a dedicated logger to log all compliance events.
There were, as far as I could tell, a couple problems with this approach also.
a. If everyone is using a single "well known" logger to log a specific event category then I lose the logger "context" of who's logging the event. As it stands now we're copying the logger name into a property we call "eventSource".
b. You cannot turn on/off logging for a specific set of code. If it turns out that we have some errant code which is using this well known logger then we can't just turn off that code from logging as turning off the well know logger would turn it off for everyone using it.
I did look into the EventLogger and initially that seemed promising as I guess it logs any event you give it at the "all" level. However, as a well known logger it suffers from the same issues above.
Now we're looking to add Business events. My initial thinking is that I can do the same thing we did before. Add an additional custom level called "Business" and expose methods for creating a business event. Though unlike the compliance event, the application teams would be defining the schema more so than our framework team. Thus any method we expose would just be used as a starting point for setting the common properties. You would use another instance of our unix domain socket appender for these business events and forward them to a different location as business events would most likely have a different retention period than compliance events. Plus you might also want them in a different store as you may never need to query for both categories of events and thus no need to query against a larger set of data.
In addition we're planning to capture centrally what we refer to as diagnostic events: error, info, warn, debug, trace, etc. However, we may need to separate these out into two different categories: critical-diagnostic and noncritical-diagnostic. The reason is that we don't want the potential of a critical diagnostic event, let's say an error, queued up behind potentially thousands of non-critical diagnostic events. So you see, the category also defines aspects on how we handle events at the source. We separate at the source based on category as it seems a reasonable place to do so. Also, you may want different flush times for different categories. We have a process which buffers, compresses and sends events centrally so we have the notion of flush time. The buffers are flushed when they become full or the flush time elapses. Errors, since they are more critical in monitoring systems, we'll most likely want to flush more often than say debug and trace events.
Sorry for the long winded explanation. Initially I was thinking that when we create an event we'd set its category. However, now I'm thinking the category should be set by the act of logging the event at a level. In some cases we have a 1:1 mapping from level to category, eg. compliance level -> compliance category. In some cases we have a many:1 mapping from level to category, eg. error, info, warn -> critical-diagnostic.
We could also just define a single custom level, say "always_on", or something like that. Then we provide some helper method to log our "new" event categories (eg. business and compliance) at this level and have the user specify the category, I guess similar to a marker.
logEvent(Logger logger, String category, object evnt);
I guess it's similar to the EventLogger except that we're not using a single well known logger and thus don't have the downsides of that which I pointed out earlier.
Any thoughts/suggestions would be appreciated.
Thanks,
Nick
________________________________
From: Mikael Ståldal <mi...@magine.com>
Sent: Wednesday, September 9, 2015 3:47 AM
To: Log4J Users List
Subject: Re: approach for defining loggers
Then perhaps you should create your own facade for doing business event
logging, which could then forward them to Log4j in an appropriate way.
On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
> I was just about to reply to your previous email about using a single
> "business" logger, or some hierarchy of business loggers, to log business
> events and say that we might go that route. However, now that you brought
> up the post from Ralph, which I just replied to, I'm thinking a logger
> won't work either for the same reason I listed in my reply to Ralph's post.
>
> You could do:
>
> logger.info("Hello");
> logger.fatal("Hello");
> logger.error("Hello");
> ...
>
> It's confusing as there are n ways to log a business event that way and
> they will all do the same thing. Which one should a developer choose.
> Should I say pick any one, it doesn't matter?
>
> Thanks,
> Nick
>
> > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > Subject: Re: approach for defining loggers
> > From: garydgregory@gmail.com
> > To: log4j-user@logging.apache.org
> >
> > Or
> > Logger logger = LogManager.getLogger("Business");
> > ...
> > logger.info("Hello");
> >
> > Gary
> >
> > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> > > 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 <ni...@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.goers@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://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
What is markers in Java Logging frameworks and that is a ...<http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
stackoverflow.com
This is a rehashed version my answer to the question "Best practices for using Markers in SLF4J/Logback". Markers can be used to color or mark a single log statement.
> > > <
> > >
> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
[http://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded&a]<http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
What is markers in Java Logging frameworks and that is a ...<http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>
stackoverflow.com
This is a rehashed version my answer to the question "Best practices for using Markers in SLF4J/Logback". Markers can be used to color or mark a single log statement.
> > > >.
> > > >>
> > > >> Ralph
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > >>>>>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > >>>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> > > >>>>
> > > >>>
> > > >>
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > 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
[https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/>
Gary Gregory<http://garygregory.wordpress.com/>
garygregory.wordpress.com
Software construction, the web, and other techs
> > Home: http://garygregory.com/
Gary Gregory<http://garygregory.com/>
garygregory.com
Rocket | Seagull . I am a Software Architect for Seagull Software, a division of Rocket Software. Rocket Seagull specializes in tools and expertise to modernize ...
> > Tweet! http://twitter.com/GaryGregory
Gary Gregory (@GaryGregory) | Twitter<http://twitter.com/GaryGregory>
twitter.com
The latest Tweets from Gary Gregory (@GaryGregory). Principal Software Engineer, author: Java Persistence Hibernate https://t.co/3F8sYxc0oq, JUnit https://t.co/yXU1DqAMDG, Spring Batch https://t.co/XwoMNoBxh7. U.S.A.
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com<http://www.magine.com>
[https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<http://www.magine.com/>
TV online with Magine TV<http://www.magine.com/>
www.magine.com
Watch the TV you love, on any device, anywhere in Germany and Sweden and find out more about our global OTT B2B solutions. Get started today.
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Sep 11, 2015 at 5:12 PM, Nicholas Duane <ni...@msn.com> wrote:
> I am a bit confused now. Previously someone said that if we used markers
> the level used in the log statement would be irrelevant. However, based on
> this thread it looks like that's not the case. Can someone give a
> definitive answer on what determines whether an event makes it to an
> appender?
>
What Ralph said.
Gayr
>
> Thanks,
> Nick
>
> > Date: Fri, 11 Sep 2015 16:46:14 -0700
> > Subject: Re: approach for defining loggers
> > From: garydgregory@gmail.com
> > To: log4j-user@logging.apache.org
> >
> > On Fri, Sep 11, 2015 at 4:23 PM, Ralph Goers <ralph.goers@dslextreme.com
> >
> > wrote:
> >
> > >
> > > > On Sep 11, 2015, at 3:50 PM, Gary Gregory <ga...@gmail.com>
> > > wrote:
> > > >
> > > >
> > > > This updated text I hope will help:
> > > >
> > > > "No new loggers needed, just an additional parameter to your log
> call,
> > > > <em>regardless</em> of the level API used.
> > > >
> > > > Now, I can configure Log4j to log only events that contain the marker
> > > DOOR
> > > > (if that level is enabled).”
> > >
> > > This isn’t necessarily true. If you have a global filter that accepts
> the
> > > event then the log level of the appropriate logger will not be checked.
> > > However, other filters on the AppenderRef and Appenders will still be
> > > checked.
> > >
> >
> > Hm, OK, but I am not sure I want to make that part of the article more
> > complicated. I could say "if that level is enabled and a global filter
> did
> > not accepts the event".
> >
> > Gary
> >
> > >
> > > Ralph
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > 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: garydgregory@gmail.com | ggregory@apache.org
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
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
I am a bit confused now. Previously someone said that if we used markers the level used in the log statement would be irrelevant. However, based on this thread it looks like that's not the case. Can someone give a definitive answer on what determines whether an event makes it to an appender?
Thanks,
Nick
> Date: Fri, 11 Sep 2015 16:46:14 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
>
> On Fri, Sep 11, 2015 at 4:23 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> >
> > > On Sep 11, 2015, at 3:50 PM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > >
> > >
> > > This updated text I hope will help:
> > >
> > > "No new loggers needed, just an additional parameter to your log call,
> > > <em>regardless</em> of the level API used.
> > >
> > > Now, I can configure Log4j to log only events that contain the marker
> > DOOR
> > > (if that level is enabled).”
> >
> > This isn’t necessarily true. If you have a global filter that accepts the
> > event then the log level of the appropriate logger will not be checked.
> > However, other filters on the AppenderRef and Appenders will still be
> > checked.
> >
>
> Hm, OK, but I am not sure I want to make that part of the article more
> complicated. I could say "if that level is enabled and a global filter did
> not accepts the event".
>
> Gary
>
> >
> > Ralph
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Sep 11, 2015 at 4:23 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
>
> > On Sep 11, 2015, at 3:50 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> >
> > This updated text I hope will help:
> >
> > "No new loggers needed, just an additional parameter to your log call,
> > <em>regardless</em> of the level API used.
> >
> > Now, I can configure Log4j to log only events that contain the marker
> DOOR
> > (if that level is enabled).”
>
> This isn’t necessarily true. If you have a global filter that accepts the
> event then the log level of the appropriate logger will not be checked.
> However, other filters on the AppenderRef and Appenders will still be
> checked.
>
Hm, OK, but I am not sure I want to make that part of the article more
complicated. I could say "if that level is enabled and a global filter did
not accepts the event".
Gary
>
> Ralph
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Sep 11, 2015, at 3:50 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>
> This updated text I hope will help:
>
> "No new loggers needed, just an additional parameter to your log call,
> <em>regardless</em> of the level API used.
>
> Now, I can configure Log4j to log only events that contain the marker DOOR
> (if that level is enabled).”
This isn’t necessarily true. If you have a global filter that accepts the event then the log level of the appropriate logger will not be checked. However, other filters on the AppenderRef and Appenders will still be checked.
Ralph
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Sep 11, 2015 at 1:36 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> See below
>
> > On Sep 11, 2015, at 12:33 PM, Nicholas Duane <ni...@msn.com> wrote:
> >
> > I think it's great that you took the time and effort to put this
> together. Hopefully it will help guide people in the correct direction as
> they work through these issues. Hopefully this link is found when they
> google 'log4j log levels' or 'log4j loggers' etc..
> >
> > 1. While your level examples elude to this you don't, as far as I can
> tell, specifically spell this out. I guess you're always assuming that
> level is a gradient or scale. Meaning if I turn on a specific level I will
> get events for that level and any level more specific. Would it be invalid
> to make level an enumeration and thus level would 'kind of' indicate event
> 'type’.
>
Yes, it would be invalid. Sadly, I must not have explained markers clearly
enough, because markers do indicate an event's "type" as you call it. The
event "types" could be specified as an enumeration if you so desired.
>
> All Java logging frameworks that I am aware of view the level as a
> gradient as Gary described it. If you look at RFC 3164 [1] you will see
> that unix syslog events have a severity that works exactly the same way.
> This is actually where Java logging levels were inspired from. If you look
> at the documentation for syslog [2] you will see mention that this is the
> way it works on unix systems.
> >
> > 2. Wording problems maybe:
> >
> > "What if others log from a third party library log"
>
Thank you for catching that. I changed this to: "What if doors from a third
party library log this kind of event at TRACE, another twist!"
> >
> > "Now, I can configure Log4j to log only all events"
>
Changed to: "Now, I can configure Log4j to log only events that contain the
marker DOOR."
> >
> > 3. In the part about markers you indicate that with a marker you can
> enable logging for an event no matter what level the event was logged at.
I can see the confusion. The level rules the roost, so if that level is not
enabled, the event will not be logged.
This updated text I hope will help:
"No new loggers needed, just an additional parameter to your log call,
<em>regardless</em> of the level API used.
Now, I can configure Log4j to log only events that contain the marker DOOR
(if that level is enabled)."
Gary
> In that case the below statement seems to contradict:
> >
> > "Here, start by setting the root logger to WARN, then we set the oven to
> > log at DEBUG because the oven logs door events at the DEBUG level, and
> > the garage to log at INFO because the garage logs door events at the
> > INFO level."
> >
> > I thought it shouldn't matter if the over door logs at DEBUG level.
> Can't I still set everything to WARN and use a marker to get the event
> logged?
>
> You can do both. If you choose to ignore the marker then you can filter
> only by log level. If you want one appender to handle all the BUSINESS
> events and another appender to handle only warnings and errors (including
> BUSINESS events) you can also do that. See the configuration I sent you
> the other day. It only separates between those with the marker and those
> without because that is what you asked for. However, I could have given you
> a configuration that also does the second case.
>
> >
> > 4. Your markers section seems geared toward showing how to enable
> logging of events even if the level is off. In my specific case, while I
> would of course need the event to be logged, I want to route specific types
> (/levels?) of events to specific appenders because different events are
> going to different locations.
>
> You should be able to extrapolate from the configuration I provided you to
> be able to do this.
>
> Ralph
>
>
>
> [1] https://www.ietf.org/rfc/rfc3164.txt <
> https://www.ietf.org/rfc/rfc3164.txt>
> [2] http://www.rsyslog.com/doc/v8-stable/configuration/filters.html <
> http://www.rsyslog.com/doc/v8-stable/configuration/filters.html>
>
>
>
>
> >
> >> Date: Thu, 10 Sep 2015 21:21:09 -0700
> >> Subject: Re: approach for defining loggers
> >> From: garydgregory@gmail.com
> >> To: log4j-user@logging.apache.org
> >>
> >> This thread inspired me to explain logging concepts:
> >>
> >>
> https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/
> >>
> >> I hope it helps!
> >>
> >> Gary
> >>
> >> On Wed, Sep 9, 2015 at 12:47 AM, Mikael Ståldal <
> mikael.staldal@magine.com>
> >> wrote:
> >>
> >>> Then perhaps you should create your own facade for doing business event
> >>> logging, which could then forward them to Log4j in an appropriate way.
> >>>
> >>> On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
> >>>
> >>>> I was just about to reply to your previous email about using a single
> >>>> "business" logger, or some hierarchy of business loggers, to log
> business
> >>>> events and say that we might go that route. However, now that you
> >>> brought
> >>>> up the post from Ralph, which I just replied to, I'm thinking a logger
> >>>> won't work either for the same reason I listed in my reply to Ralph's
> >>> post.
> >>>>
> >>>> You could do:
> >>>>
> >>>> logger.info("Hello");
> >>>> logger.fatal("Hello");
> >>>> logger.error("Hello");
> >>>> ...
> >>>>
> >>>> It's confusing as there are n ways to log a business event that way
> and
> >>>> they will all do the same thing. Which one should a developer choose.
> >>>> Should I say pick any one, it doesn't matter?
> >>>>
> >>>> Thanks,
> >>>> Nick
> >>>>
> >>>>> Date: Tue, 8 Sep 2015 19:28:21 -0700
> >>>>> Subject: Re: approach for defining loggers
> >>>>> From: garydgregory@gmail.com
> >>>>> To: log4j-user@logging.apache.org
> >>>>>
> >>>>> Or
> >>>>> Logger logger = LogManager.getLogger("Business");
> >>>>> ...
> >>>>> logger.info("Hello");
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>> On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> >>> ralph.goers@dslextreme.com>
> >>>>> wrote:
> >>>>>
> >>>>>> 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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> >>>>>>>>>>>> For additional commands, e-mail:
> >>>> log4j-user-help@logging.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail:
> >>> log4j-user-unsubscribe@logging.apache.org
> >>>>>>>>>> For additional commands, e-mail:
> >>>> log4j-user-help@logging.apache.org
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>>> 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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> [image: MagineTV]
> >>>
> >>> *Mikael Ståldal*
> >>> Senior software developer
> >>>
> >>> *Magine TV*
> >>> mikael.staldal@magine.com
> >>> Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
> >>>
> >>> Privileged and/or Confidential Information may be contained in this
> >>> message. If you are not the addressee indicated in this message
> >>> (or responsible for delivery of the message to such a person), you may
> not
> >>> copy or deliver this message to anyone. In such case,
> >>> you should destroy this message and kindly notify the sender by reply
> >>> email.
> >>>
> >>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> 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: garydgregory@gmail.com | ggregory@apache.org
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
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
See below
> On Sep 11, 2015, at 12:33 PM, Nicholas Duane <ni...@msn.com> wrote:
>
> I think it's great that you took the time and effort to put this together. Hopefully it will help guide people in the correct direction as they work through these issues. Hopefully this link is found when they google 'log4j log levels' or 'log4j loggers' etc..
>
> 1. While your level examples elude to this you don't, as far as I can tell, specifically spell this out. I guess you're always assuming that level is a gradient or scale. Meaning if I turn on a specific level I will get events for that level and any level more specific. Would it be invalid to make level an enumeration and thus level would 'kind of' indicate event 'type’.
All Java logging frameworks that I am aware of view the level as a gradient as Gary described it. If you look at RFC 3164 [1] you will see that unix syslog events have a severity that works exactly the same way. This is actually where Java logging levels were inspired from. If you look at the documentation for syslog [2] you will see mention that this is the way it works on unix systems.
>
> 2. Wording problems maybe:
>
> "What if others log from a third party library log"
>
> "Now, I can configure Log4j to log only all events"
>
> 3. In the part about markers you indicate that with a marker you can enable logging for an event no matter what level the event was logged at. In that case the below statement seems to contradict:
>
> "Here, start by setting the root logger to WARN, then we set the oven to
> log at DEBUG because the oven logs door events at the DEBUG level, and
> the garage to log at INFO because the garage logs door events at the
> INFO level."
>
> I thought it shouldn't matter if the over door logs at DEBUG level. Can't I still set everything to WARN and use a marker to get the event logged?
You can do both. If you choose to ignore the marker then you can filter only by log level. If you want one appender to handle all the BUSINESS events and another appender to handle only warnings and errors (including BUSINESS events) you can also do that. See the configuration I sent you the other day. It only separates between those with the marker and those without because that is what you asked for. However, I could have given you a configuration that also does the second case.
>
> 4. Your markers section seems geared toward showing how to enable logging of events even if the level is off. In my specific case, while I would of course need the event to be logged, I want to route specific types (/levels?) of events to specific appenders because different events are going to different locations.
You should be able to extrapolate from the configuration I provided you to be able to do this.
Ralph
[1] https://www.ietf.org/rfc/rfc3164.txt <https://www.ietf.org/rfc/rfc3164.txt>
[2] http://www.rsyslog.com/doc/v8-stable/configuration/filters.html <http://www.rsyslog.com/doc/v8-stable/configuration/filters.html>
>
>> Date: Thu, 10 Sep 2015 21:21:09 -0700
>> Subject: Re: approach for defining loggers
>> From: garydgregory@gmail.com
>> To: log4j-user@logging.apache.org
>>
>> This thread inspired me to explain logging concepts:
>>
>> https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/
>>
>> I hope it helps!
>>
>> Gary
>>
>> On Wed, Sep 9, 2015 at 12:47 AM, Mikael Ståldal <mi...@magine.com>
>> wrote:
>>
>>> Then perhaps you should create your own facade for doing business event
>>> logging, which could then forward them to Log4j in an appropriate way.
>>>
>>> On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
>>>
>>>> I was just about to reply to your previous email about using a single
>>>> "business" logger, or some hierarchy of business loggers, to log business
>>>> events and say that we might go that route. However, now that you
>>> brought
>>>> up the post from Ralph, which I just replied to, I'm thinking a logger
>>>> won't work either for the same reason I listed in my reply to Ralph's
>>> post.
>>>>
>>>> You could do:
>>>>
>>>> logger.info("Hello");
>>>> logger.fatal("Hello");
>>>> logger.error("Hello");
>>>> ...
>>>>
>>>> It's confusing as there are n ways to log a business event that way and
>>>> they will all do the same thing. Which one should a developer choose.
>>>> Should I say pick any one, it doesn't matter?
>>>>
>>>> Thanks,
>>>> Nick
>>>>
>>>>> Date: Tue, 8 Sep 2015 19:28:21 -0700
>>>>> Subject: Re: approach for defining loggers
>>>>> From: garydgregory@gmail.com
>>>>> To: log4j-user@logging.apache.org
>>>>>
>>>>> Or
>>>>> Logger logger = LogManager.getLogger("Business");
>>>>> ...
>>>>> logger.info("Hello");
>>>>>
>>>>> Gary
>>>>>
>>>>> On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
>>> ralph.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>>> 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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
>>>>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-help@logging.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail:
>>> log4j-user-unsubscribe@logging.apache.org
>>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-help@logging.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.staldal@magine.com
>>> Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may not
>>> copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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
>
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
I think it's great that you took the time and effort to put this together. Hopefully it will help guide people in the correct direction as they work through these issues. Hopefully this link is found when they google 'log4j log levels' or 'log4j loggers' etc..
1. While your level examples elude to this you don't, as far as I can tell, specifically spell this out. I guess you're always assuming that level is a gradient or scale. Meaning if I turn on a specific level I will get events for that level and any level more specific. Would it be invalid to make level an enumeration and thus level would 'kind of' indicate event 'type'.
2. Wording problems maybe:
"What if others log from a third party library log"
"Now, I can configure Log4j to log only all events"
3. In the part about markers you indicate that with a marker you can enable logging for an event no matter what level the event was logged at. In that case the below statement seems to contradict:
"Here, start by setting the root logger to WARN, then we set the oven to
log at DEBUG because the oven logs door events at the DEBUG level, and
the garage to log at INFO because the garage logs door events at the
INFO level."
I thought it shouldn't matter if the over door logs at DEBUG level. Can't I still set everything to WARN and use a marker to get the event logged?
4. Your markers section seems geared toward showing how to enable logging of events even if the level is off. In my specific case, while I would of course need the event to be logged, I want to route specific types (/levels?) of events to specific appenders because different events are going to different locations.
Thanks,
Nick
> Date: Thu, 10 Sep 2015 21:21:09 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
>
> This thread inspired me to explain logging concepts:
>
> https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/
>
> I hope it helps!
>
> Gary
>
> On Wed, Sep 9, 2015 at 12:47 AM, Mikael Ståldal <mi...@magine.com>
> wrote:
>
> > Then perhaps you should create your own facade for doing business event
> > logging, which could then forward them to Log4j in an appropriate way.
> >
> > On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
> >
> > > I was just about to reply to your previous email about using a single
> > > "business" logger, or some hierarchy of business loggers, to log business
> > > events and say that we might go that route. However, now that you
> > brought
> > > up the post from Ralph, which I just replied to, I'm thinking a logger
> > > won't work either for the same reason I listed in my reply to Ralph's
> > post.
> > >
> > > You could do:
> > >
> > > logger.info("Hello");
> > > logger.fatal("Hello");
> > > logger.error("Hello");
> > > ...
> > >
> > > It's confusing as there are n ways to log a business event that way and
> > > they will all do the same thing. Which one should a developer choose.
> > > Should I say pick any one, it doesn't matter?
> > >
> > > Thanks,
> > > Nick
> > >
> > > > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > > > Subject: Re: approach for defining loggers
> > > > From: garydgregory@gmail.com
> > > > To: log4j-user@logging.apache.org
> > > >
> > > > Or
> > > > Logger logger = LogManager.getLogger("Business");
> > > > ...
> > > > logger.info("Hello");
> > > >
> > > > Gary
> > > >
> > > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> > ralph.goers@dslextreme.com>
> > > > wrote:
> > > >
> > > > > 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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > > > >>>>>> For additional commands, e-mail:
> > > log4j-user-help@logging.apache.org
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > > > >>>>
> > > ---------------------------------------------------------------------
> > > > > >>>> To unsubscribe, e-mail:
> > log4j-user-unsubscribe@logging.apache.org
> > > > > >>>> For additional commands, e-mail:
> > > log4j-user-help@logging.apache.org
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > 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
> > >
> > >
> >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.staldal@magine.com
> > Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
> >
> > Privileged and/or Confidential Information may be contained in this
> > message. If you are not the addressee indicated in this message
> > (or responsible for delivery of the message to such a person), you may not
> > copy or deliver this message to anyone. In such case,
> > you should destroy this message and kindly notify the sender by reply
> > email.
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
This thread inspired me to explain logging concepts:
https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/
I hope it helps!
Gary
On Wed, Sep 9, 2015 at 12:47 AM, Mikael Ståldal <mi...@magine.com>
wrote:
> Then perhaps you should create your own facade for doing business event
> logging, which could then forward them to Log4j in an appropriate way.
>
> On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
>
> > I was just about to reply to your previous email about using a single
> > "business" logger, or some hierarchy of business loggers, to log business
> > events and say that we might go that route. However, now that you
> brought
> > up the post from Ralph, which I just replied to, I'm thinking a logger
> > won't work either for the same reason I listed in my reply to Ralph's
> post.
> >
> > You could do:
> >
> > logger.info("Hello");
> > logger.fatal("Hello");
> > logger.error("Hello");
> > ...
> >
> > It's confusing as there are n ways to log a business event that way and
> > they will all do the same thing. Which one should a developer choose.
> > Should I say pick any one, it doesn't matter?
> >
> > Thanks,
> > Nick
> >
> > > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > > Subject: Re: approach for defining loggers
> > > From: garydgregory@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > Or
> > > Logger logger = LogManager.getLogger("Business");
> > > ...
> > > logger.info("Hello");
> > >
> > > Gary
> > >
> > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> ralph.goers@dslextreme.com>
> > > wrote:
> > >
> > > > 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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > > >>>>>> For additional commands, e-mail:
> > log4j-user-help@logging.apache.org
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > ---------------------------------------------------------------------
> > > > >>>> To unsubscribe, e-mail:
> log4j-user-unsubscribe@logging.apache.org
> > > > >>>> For additional commands, e-mail:
> > log4j-user-help@logging.apache.org
> > > > >>>>
> > > > >>>
> > > > >>
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > 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
> >
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@magine.com
> Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or deliver this message to anyone. In such case,
> you should destroy this message and kindly notify the sender by reply
> email.
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: approach for defining loggers
Posted by Mikael Ståldal <mi...@magine.com>.
Then perhaps you should create your own facade for doing business event
logging, which could then forward them to Log4j in an appropriate way.
On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <ni...@msn.com> wrote:
> I was just about to reply to your previous email about using a single
> "business" logger, or some hierarchy of business loggers, to log business
> events and say that we might go that route. However, now that you brought
> up the post from Ralph, which I just replied to, I'm thinking a logger
> won't work either for the same reason I listed in my reply to Ralph's post.
>
> You could do:
>
> logger.info("Hello");
> logger.fatal("Hello");
> logger.error("Hello");
> ...
>
> It's confusing as there are n ways to log a business event that way and
> they will all do the same thing. Which one should a developer choose.
> Should I say pick any one, it doesn't matter?
>
> Thanks,
> Nick
>
> > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > Subject: Re: approach for defining loggers
> > From: garydgregory@gmail.com
> > To: log4j-user@logging.apache.org
> >
> > Or
> > Logger logger = LogManager.getLogger("Business");
> > ...
> > logger.info("Hello");
> >
> > Gary
> >
> > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> > > 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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > >>>>>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > >>>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> > > >>>>
> > > >>>
> > > >>
> > > >
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> > >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > 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
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior software developer
*Magine TV*
mikael.staldal@magine.com
Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
I was just about to reply to your previous email about using a single "business" logger, or some hierarchy of business loggers, to log business events and say that we might go that route. However, now that you brought up the post from Ralph, which I just replied to, I'm thinking a logger won't work either for the same reason I listed in my reply to Ralph's post.
You could do:
logger.info("Hello");
logger.fatal("Hello");
logger.error("Hello");
...
It's confusing as there are n ways to log a business event that way and they will all do the same thing. Which one should a developer choose. Should I say pick any one, it doesn't matter?
Thanks,
Nick
> Date: Tue, 8 Sep 2015 19:28:21 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
>
> Or
> Logger logger = LogManager.getLogger("Business");
> ...
> logger.info("Hello");
>
> Gary
>
> On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> > 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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>>>
> > >>>
> > >>
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
Or
Logger logger = LogManager.getLogger("Business");
...
logger.info("Hello");
Gary
On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> 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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>
> >>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
The bottom line is it doesn’t matter which log level they use. With the configuration below ALL business events will be accepted, meaning the log level on the logger will not be checked. Then every logger would have a marker filter to accept or deny the event
<Configuration>
<MarkerFilter marker=“Business” onMatch=“ACCEPT” onMisMatch=“NEUTRAL”/>
<Appenders>
<File name=“business” fileName=“business.log”>
<PatternLayout pattern=“%d %p %c{1.} [%t] %m%n/>
</File>
<Console name=“STDOUT” target=“SYSTEM_OUT”>
<PatternLayout pattern=“%d %p %c{1.} [%t] %m%n/>
</Console>
</Appenders>
<Loggers>
<Root level=“warn”>
<AppenderRef ref=“business”>
<MarkerFilter marker=“Business” onMatch=“ACCEPT” onMisMatch=“DENY”/>
</AppenderRef>
<AppenderRef ref=“STDOUT”>
<MarkerFilter marker=“Business” onMatch=“DENY” onMisMatch=“NEUTRAL”/>
</AppenderRef>
</Root>
</Loggers>
</Configuration>
If you tell them to use a “special” logger you can do the following, which is a bit simpler. All the events are accepted and passed to the business logger. The level is ignored so you don’t need to even specify it. All events on that logger will be passed to the business appender.
<Configuration>
<MarkerFilter marker=“Business” onMatch=“ACCEPT” onMisMatch=“NEUTRAL”/>
<Appenders>
<File name=“business” fileName=“business.log”>
<PatternLayout pattern=“%d %p %c{1.} [%t] %m%n/>
</File>
<Console name=“STDOUT” target=“SYSTEM_OUT”>
<PatternLayout pattern=“%d %p %c{1.} [%t] %m%n/>
</Console>
</Appenders>
<Loggers>
<Logger name=“BUSINESS” additvity=“false”>
<AppenderRef ref=“business”/>
</Logger>
<Root level=“warn”>
<AppenderRef ref=“STDOUT”/>
</Root>
</Loggers>
</Configuration>
If you want users to not specify an event then just create your own ExtendedLogger using the ExtendedLoggerWrapper and then implement a method such as
logBusiness(msg)
or similar. That would use the logMessage method.
Ralph
> On Sep 8, 2015, at 7:44 PM, Nicholas Duane <ni...@msn.com> wrote:
>
> Let's say we have a schema where one of the properties is "category". "category" could be "info", "warn", "business", "audit", etc. I could use that property to forward the events to the appropriate places. We don't have that property because I guess we don't think we need it. The current thinking is that level will tell us whether an event is a business event or some other type of event.
>
> The problem with:
>
> logger.info(BUSINESS, msg)
>
> is that you could also do:
>
> logger.debug(BUSINESS, msg);
> logger.fatal(BUSINESS, msg);
> logger.error(BUSINESS, msg);
>
> the users will ask us which one they should use. If they are all going to do the same thing then that's a problem. You don't want n ways to do the same thing as that will just cause confusion.
>
> Thanks,
> Nick
>
>> Subject: Re: approach for defining loggers
>> From: ralph.goers@dslextreme.com
>> Date: Tue, 8 Sep 2015 19:24:32 -0700
>> To: log4j-user@logging.apache.org
>>
>> 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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
Let's say we have a schema where one of the properties is "category". "category" could be "info", "warn", "business", "audit", etc. I could use that property to forward the events to the appropriate places. We don't have that property because I guess we don't think we need it. The current thinking is that level will tell us whether an event is a business event or some other type of event.
The problem with:
logger.info(BUSINESS, msg)
is that you could also do:
logger.debug(BUSINESS, msg);
logger.fatal(BUSINESS, msg);
logger.error(BUSINESS, msg);
the users will ask us which one they should use. If they are all going to do the same thing then that's a problem. You don't want n ways to do the same thing as that will just cause confusion.
Thanks,
Nick
> Subject: Re: approach for defining loggers
> From: ralph.goers@dslextreme.com
> Date: Tue, 8 Sep 2015 19:24:32 -0700
> To: log4j-user@logging.apache.org
>
> 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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>
> >>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
What you describes matches in my mind a Loggers. Your whole app can have a
"Business" logger and sub-categories if you need them like
"Business.Accounting", and "Business.HR".
Gary
On Tue, Sep 8, 2015 at 6:09 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>
> > >
> >
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
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.goers@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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >
>
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
Yeah, I'm aware of that feature in log4j/log4net. Very nice one by the way. One of the big pluses in my mind. Makes it very easy to control a while slew of loggers based on name.
Though in our case we probably won't know many, if any, of the logger names. We basically want to direct all traces to one location, all info to fatal to another location and business events to yet a third location.
Thanks,
Nick
> Date: Mon, 7 Sep 2015 18:35:13 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
>
> Don't forget that loggers can be controlled by their hierarchical names:
> com.example = DEBUG, usually sets all levels below it to DEBUG, like
> com.example.feature1.sub1, com.example.feature1.sub2, com.example.feature2,
> and so on.
>
> Gary
>
> On Mon, Sep 7, 2015 at 5:54 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > >>
> > > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
Don't forget that loggers can be controlled by their hierarchical names:
com.example = DEBUG, usually sets all levels below it to DEBUG, like
com.example.feature1.sub1, com.example.feature1.sub2, com.example.feature2,
and so on.
Gary
On Mon, Sep 7, 2015 at 5:54 PM, Nicholas Duane <ni...@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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
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.goers@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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
And I agree. Just letting you know I'm not a total noob when it comes to logging, just log4j and log4net are new to me.
Thanks,
Nick
> Date: Mon, 31 Aug 2015 15:56:40 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
>
> Roger that. I'm just wondering how we can better serve visitors to the
> site...
>
> Gary
>
> On Mon, Aug 31, 2015 at 3:47 PM, Nicholas Duane <ni...@msn.com> wrote:
>
> > While I'm new to log4j I would say I'm not new to logging. We've written
> > our own logging framework 14 or so years ago. It was on the Microsoft
> > platform and was originally targeting the unmanaged world. We later wrote
> > a managed wrapper on it so we could use it from .NET. Most of the events
> > flow through ETW and end up in log files which are then Ftp'd to a central
> > location.
> >
> > Thanks,
> > Nick
> >
> > > Date: Mon, 31 Aug 2015 15:38:55 -0700
> > > Subject: Re: approach for defining loggers
> > > From: garydgregory@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > 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 <ga...@gmail.com>
> > > wrote:
> > >
> > > > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <ni...@msn.com>
> > 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: garydgregory@gmail.com
> > > >> > To: log4j-user@logging.apache.org
> > > >> >
> > > >> > 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 <ni...@msn.com>
> > 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: garydgregory@gmail.com
> > > >> > > > To: log4j-user@logging.apache.org
> > > >> > > >
> > > >> > > > 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 <nickdu@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.goers@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 <
> > nickdu@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-unsubscribe@logging.apache.org
> > > >> > > > > > For additional commands, e-mail:
> > > >> log4j-user-help@logging.apache.org
> > > >> > > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > --
> > > >> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > >> > > > 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: garydgregory@gmail.com | ggregory@apache.org
> > > >> > 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: garydgregory@gmail.com | ggregory@apache.org
> > > > 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: garydgregory@gmail.com | ggregory@apache.org
> > > 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: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
Roger that. I'm just wondering how we can better serve visitors to the
site...
Gary
On Mon, Aug 31, 2015 at 3:47 PM, Nicholas Duane <ni...@msn.com> wrote:
> While I'm new to log4j I would say I'm not new to logging. We've written
> our own logging framework 14 or so years ago. It was on the Microsoft
> platform and was originally targeting the unmanaged world. We later wrote
> a managed wrapper on it so we could use it from .NET. Most of the events
> flow through ETW and end up in log files which are then Ftp'd to a central
> location.
>
> Thanks,
> Nick
>
> > Date: Mon, 31 Aug 2015 15:38:55 -0700
> > Subject: Re: approach for defining loggers
> > From: garydgregory@gmail.com
> > To: log4j-user@logging.apache.org
> >
> > 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 <ga...@gmail.com>
> > wrote:
> >
> > > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <ni...@msn.com>
> 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: garydgregory@gmail.com
> > >> > To: log4j-user@logging.apache.org
> > >> >
> > >> > 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 <ni...@msn.com>
> 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: garydgregory@gmail.com
> > >> > > > To: log4j-user@logging.apache.org
> > >> > > >
> > >> > > > 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 <nickdu@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.goers@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 <
> nickdu@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-unsubscribe@logging.apache.org
> > >> > > > > > For additional commands, e-mail:
> > >> log4j-user-help@logging.apache.org
> > >> > > > > >
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > --
> > >> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > >> > > > 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: garydgregory@gmail.com | ggregory@apache.org
> > >> > 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: garydgregory@gmail.com | ggregory@apache.org
> > > 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: garydgregory@gmail.com | ggregory@apache.org
> > 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: garydgregory@gmail.com | ggregory@apache.org
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
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
While I'm new to log4j I would say I'm not new to logging. We've written our own logging framework 14 or so years ago. It was on the Microsoft platform and was originally targeting the unmanaged world. We later wrote a managed wrapper on it so we could use it from .NET. Most of the events flow through ETW and end up in log files which are then Ftp'd to a central location.
Thanks,
Nick
> Date: Mon, 31 Aug 2015 15:38:55 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
>
> 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 <ga...@gmail.com>
> wrote:
>
> > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <ni...@msn.com> 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: garydgregory@gmail.com
> >> > To: log4j-user@logging.apache.org
> >> >
> >> > 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 <ni...@msn.com> 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: garydgregory@gmail.com
> >> > > > To: log4j-user@logging.apache.org
> >> > > >
> >> > > > 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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> >> > > > > > For additional commands, e-mail:
> >> log4j-user-help@logging.apache.org
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> > > > 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: garydgregory@gmail.com | ggregory@apache.org
> >> > 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: garydgregory@gmail.com | ggregory@apache.org
> > 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: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
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 <ga...@gmail.com>
wrote:
> On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <ni...@msn.com> 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: garydgregory@gmail.com
>> > To: log4j-user@logging.apache.org
>> >
>> > 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 <ni...@msn.com> 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: garydgregory@gmail.com
>> > > > To: log4j-user@logging.apache.org
>> > > >
>> > > > 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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
>> > > > > > For additional commands, e-mail:
>> log4j-user-help@logging.apache.org
>> > > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > > > 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: garydgregory@gmail.com | ggregory@apache.org
>> > 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: garydgregory@gmail.com | ggregory@apache.org
> 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: garydgregory@gmail.com | ggregory@apache.org
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
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
Gary, your examples are great and would be a good addition to the Introduction page.
Ralph
> On Sep 1, 2015, at 3:47 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Tue, Sep 1, 2015 at 3:26 PM, Nicholas Duane <nickdu@msn.com <ma...@msn.com>> wrote:
>
>> I was re-reading this and thought I should respond. You mentioned that
>> levels are used to indicate the importance of what you logged. The logger
>> helps you with "what is it that I'm trying to tell" the audience, if I have
>> that correct. Which I kind of agree. The logger, in my mind, indicates
>> the "area" of code which is sourcing the events. In your example you have
>> an authentication module which has its own logger. All events (hopefully
>> using the terms events is ok) logged from that logger has to do with
>> authentication.
>
>
> Yes, a "log event" is the right general term, which we happen to use
> internally with the interface org.apache.logging.log4j.core.LogEvent.
>
> The authentication module uses its logger to log events at different
>> levels.
>
>
> Right, for example, from the auth Logger:
>
> INFO - User Alice logged in.
> WARN - User Bob entered an invalid password.
> ERROR - User Bob entered an invalid password three times and is now locked
> out.
>
> Then from a different part of the app, the email agent Logger, for example:
>
> DEBUG: Read account for Bob from database connection jdbc://...
> INFO - Emailed user Bob that his account might be under attack because
> three login attempts were rejected.
> ERROR - Email bounced back to Alice@example.com <ma...@example.com>; subject: foo.
>
> So you can imagine that for different loggers, the meaning of what is
> normal vs. an error can be very different.
>
> Gary
>
> So in my scenario, the authentication module might want to log a "Business"
>> event. In reality this probably would not happen as the business events
>> would most likely be sourced from LOB application code. However, each
>> component of LOB application code might have its own logger and if it needs
>> to log a business event it should do so from its logger.
>>
>> I did look at markers and it would seem if I used them for these business
>> events I would still be logging the business events at some level and would
>> include a marker. This seems odd to me as the level would seem pointless
>> and thus picking one would be arbitrary.
>>
>> Someone had mentioned using the EventLogger. I still have to look into
>> that, but that sounds like a single logger which I initially thought was
>> not required and instead the advice would be to log via whatever logger
>> you're using for your other events. However, maybe the EventLogger will
>> work.
>>
>> Thanks,
>> Nick
>>
>>
>>> Date: Mon, 31 Aug 2015 15:16:49 -0700
>>> Subject: Re: approach for defining loggers
>>> From: garydgregory@gmail.com
>>> To: log4j-user@logging.apache.org
>>>
>>> On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <ni...@msn.com> 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: garydgregory@gmail.com
>>>>> To: log4j-user@logging.apache.org
>>>>>
>>>>> 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 <ni...@msn.com>
>> 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: garydgregory@gmail.com
>>>>>>> To: log4j-user@logging.apache.org
>>>>>>>
>>>>>>> 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 <ni...@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.goers@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 <
>> nickdu@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-unsubscribe@logging.apache.org
>>>>>>>>> For additional commands, e-mail:
>>>> log4j-user-help@logging.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>> 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: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ <http://www.manning.com/tahchiev/>>
> Spring Batch in Action <http://www.manning.com/templier/ <http://www.manning.com/templier/>>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Sep 1, 2015 at 3:26 PM, Nicholas Duane <ni...@msn.com> wrote:
> I was re-reading this and thought I should respond. You mentioned that
> levels are used to indicate the importance of what you logged. The logger
> helps you with "what is it that I'm trying to tell" the audience, if I have
> that correct. Which I kind of agree. The logger, in my mind, indicates
> the "area" of code which is sourcing the events. In your example you have
> an authentication module which has its own logger. All events (hopefully
> using the terms events is ok) logged from that logger has to do with
> authentication.
Yes, a "log event" is the right general term, which we happen to use
internally with the interface org.apache.logging.log4j.core.LogEvent.
The authentication module uses its logger to log events at different
> levels.
Right, for example, from the auth Logger:
INFO - User Alice logged in.
WARN - User Bob entered an invalid password.
ERROR - User Bob entered an invalid password three times and is now locked
out.
Then from a different part of the app, the email agent Logger, for example:
DEBUG: Read account for Bob from database connection jdbc://...
INFO - Emailed user Bob that his account might be under attack because
three login attempts were rejected.
ERROR - Email bounced back to Alice@example.com; subject: foo.
So you can imagine that for different loggers, the meaning of what is
normal vs. an error can be very different.
Gary
So in my scenario, the authentication module might want to log a "Business"
> event. In reality this probably would not happen as the business events
> would most likely be sourced from LOB application code. However, each
> component of LOB application code might have its own logger and if it needs
> to log a business event it should do so from its logger.
>
> I did look at markers and it would seem if I used them for these business
> events I would still be logging the business events at some level and would
> include a marker. This seems odd to me as the level would seem pointless
> and thus picking one would be arbitrary.
>
> Someone had mentioned using the EventLogger. I still have to look into
> that, but that sounds like a single logger which I initially thought was
> not required and instead the advice would be to log via whatever logger
> you're using for your other events. However, maybe the EventLogger will
> work.
>
> Thanks,
> Nick
>
>
> > Date: Mon, 31 Aug 2015 15:16:49 -0700
> > Subject: Re: approach for defining loggers
> > From: garydgregory@gmail.com
> > To: log4j-user@logging.apache.org
> >
> > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <ni...@msn.com> 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: garydgregory@gmail.com
> > > > To: log4j-user@logging.apache.org
> > > >
> > > > 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 <ni...@msn.com>
> 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: garydgregory@gmail.com
> > > > > > To: log4j-user@logging.apache.org
> > > > > >
> > > > > > 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 <ni...@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.goers@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 <
> nickdu@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-unsubscribe@logging.apache.org
> > > > > > > > For additional commands, e-mail:
> > > log4j-user-help@logging.apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > > > 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: garydgregory@gmail.com | ggregory@apache.org
> > > > 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: garydgregory@gmail.com | ggregory@apache.org
> > 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: garydgregory@gmail.com | ggregory@apache.org
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
Re: approach for defining loggers
Posted by Mikael Ståldal <mi...@magine.com>.
You probably want to use INFO level for most of your business events.
I would consider INFO as the "neutral" level. Below INFO (DEBUG, TRACE)
means "can be ignored" and above INFO (WARN, ERROR, FATAL) means "attention
please!".
On Wed, Sep 2, 2015 at 12:26 AM, Nicholas Duane <ni...@msn.com> wrote:
> I was re-reading this and thought I should respond. You mentioned that
> levels are used to indicate the importance of what you logged. The logger
> helps you with "what is it that I'm trying to tell" the audience, if I have
> that correct. Which I kind of agree. The logger, in my mind, indicates
> the "area" of code which is sourcing the events. In your example you have
> an authentication module which has its own logger. All events (hopefully
> using the terms events is ok) logged from that logger has to do with
> authentication. The authentication module uses its logger to log events at
> different levels. So in my scenario, the authentication module might want
> to log a "Business" event. In reality this probably would not happen as
> the business events would most likely be sourced from LOB application
> code. However, each component of LOB application code might have its own
> logger and if it needs to log a business event it should do so from its
> logger.
>
> I did look at markers and it would seem if I used them for these business
> events I would still be logging the business events at some level and would
> include a marker. This seems odd to me as the level would seem pointless
> and thus picking one would be arbitrary.
>
> Someone had mentioned using the EventLogger. I still have to look into
> that, but that sounds like a single logger which I initially thought was
> not required and instead the advice would be to log via whatever logger
> you're using for your other events. However, maybe the EventLogger will
> work.
>
> Thanks,
> Nick
>
>
> > Date: Mon, 31 Aug 2015 15:16:49 -0700
> > Subject: Re: approach for defining loggers
> > From: garydgregory@gmail.com
> > To: log4j-user@logging.apache.org
> >
> > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <ni...@msn.com> 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: garydgregory@gmail.com
> > > > To: log4j-user@logging.apache.org
> > > >
> > > > 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 <ni...@msn.com>
> 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: garydgregory@gmail.com
> > > > > > To: log4j-user@logging.apache.org
> > > > > >
> > > > > > 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 <ni...@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.goers@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 <
> nickdu@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-unsubscribe@logging.apache.org
> > > > > > > > For additional commands, e-mail:
> > > log4j-user-help@logging.apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > > > 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: garydgregory@gmail.com | ggregory@apache.org
> > > > 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: garydgregory@gmail.com | ggregory@apache.org
> > 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
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior backend developer
*Magine TV*
mikael.staldal@magine.com
Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
I was re-reading this and thought I should respond. You mentioned that levels are used to indicate the importance of what you logged. The logger helps you with "what is it that I'm trying to tell" the audience, if I have that correct. Which I kind of agree. The logger, in my mind, indicates the "area" of code which is sourcing the events. In your example you have an authentication module which has its own logger. All events (hopefully using the terms events is ok) logged from that logger has to do with authentication. The authentication module uses its logger to log events at different levels. So in my scenario, the authentication module might want to log a "Business" event. In reality this probably would not happen as the business events would most likely be sourced from LOB application code. However, each component of LOB application code might have its own logger and if it needs to log a business event it should do so from its logger.
I did look at markers and it would seem if I used them for these business events I would still be logging the business events at some level and would include a marker. This seems odd to me as the level would seem pointless and thus picking one would be arbitrary.
Someone had mentioned using the EventLogger. I still have to look into that, but that sounds like a single logger which I initially thought was not required and instead the advice would be to log via whatever logger you're using for your other events. However, maybe the EventLogger will work.
Thanks,
Nick
> Date: Mon, 31 Aug 2015 15:16:49 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
>
> On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <ni...@msn.com> 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: garydgregory@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > 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 <ni...@msn.com> 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: garydgregory@gmail.com
> > > > > To: log4j-user@logging.apache.org
> > > > >
> > > > > 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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > > > > > For additional commands, e-mail:
> > log4j-user-help@logging.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > > 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: garydgregory@gmail.com | ggregory@apache.org
> > > 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: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <ni...@msn.com> 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: garydgregory@gmail.com
> > To: log4j-user@logging.apache.org
> >
> > 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 <ni...@msn.com> 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: garydgregory@gmail.com
> > > > To: log4j-user@logging.apache.org
> > > >
> > > > 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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > > > > For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > > 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: garydgregory@gmail.com | ggregory@apache.org
> > 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: garydgregory@gmail.com | ggregory@apache.org
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
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
Your example sounds reasonable.
Thanks,
Nick
> Subject: Re: approach for defining loggers
> From: remko.popma@gmail.com
> Date: Tue, 1 Sep 2015 07:57:57 +0900
> To: log4j-user@logging.apache.org
>
> Not sure that I understand your use case, so let me give a concrete example of how I use loggers.
>
> At work I have a component that is responsible for handling marketdata.
> This component has two loggers: one that uses the component class name as its name, another called "RAW_FEED". The first logs stuff about initialization and for example when another component subscribes to market data. The second (RAW_FEED) one logs every market data event as it comes off the wire to a separate file (via a separate appender).
>
> This allows us to switch the RAW_FEED off on some systems and on on others.
>
> I suggest you simply do what achieves your goals. If there are multiple options then choose the one that is easiest for your team to maintain.
>
> Sent from my iPhone
>
> > On 2015/09/01, at 7:07, Nicholas Duane <ni...@msn.com> 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? You don't use separate loggers to log different levels do you?
> >
> > Thanks,
> > Nick
> >
> >> Date: Mon, 31 Aug 2015 15:02:09 -0700
> >> Subject: Re: approach for defining loggers
> >> From: garydgregory@gmail.com
> >> To: log4j-user@logging.apache.org
> >>
> >> 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 <ni...@msn.com> 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: garydgregory@gmail.com
> >>>> To: log4j-user@logging.apache.org
> >>>>
> >>>> 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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>> 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: garydgregory@gmail.com | ggregory@apache.org
> >> 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
Re: approach for defining loggers
Posted by Remko Popma <re...@gmail.com>.
Not sure that I understand your use case, so let me give a concrete example of how I use loggers.
At work I have a component that is responsible for handling marketdata.
This component has two loggers: one that uses the component class name as its name, another called "RAW_FEED". The first logs stuff about initialization and for example when another component subscribes to market data. The second (RAW_FEED) one logs every market data event as it comes off the wire to a separate file (via a separate appender).
This allows us to switch the RAW_FEED off on some systems and on on others.
I suggest you simply do what achieves your goals. If there are multiple options then choose the one that is easiest for your team to maintain.
Sent from my iPhone
> On 2015/09/01, at 7:07, Nicholas Duane <ni...@msn.com> 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? You don't use separate loggers to log different levels do you?
>
> Thanks,
> Nick
>
>> Date: Mon, 31 Aug 2015 15:02:09 -0700
>> Subject: Re: approach for defining loggers
>> From: garydgregory@gmail.com
>> To: log4j-user@logging.apache.org
>>
>> 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 <ni...@msn.com> 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: garydgregory@gmail.com
>>>> To: log4j-user@logging.apache.org
>>>>
>>>> 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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
>>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
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? You don't use separate loggers to log different levels do you?
Thanks,
Nick
> Date: Mon, 31 Aug 2015 15:02:09 -0700
> Subject: Re: approach for defining loggers
> From: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
>
> 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 <ni...@msn.com> 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: garydgregory@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > 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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > > 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: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
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 <ni...@msn.com> 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: garydgregory@gmail.com
> > To: log4j-user@logging.apache.org
> >
> > 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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > > >
> > >
> > >
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > 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: garydgregory@gmail.com | ggregory@apache.org
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
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
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: garydgregory@gmail.com
> To: log4j-user@logging.apache.org
>
> 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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-user-help@logging.apache.org
> > >
> >
> >
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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
Re: approach for defining loggers
Posted by Gary Gregory <ga...@gmail.com>.
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 <ni...@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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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
RE: approach for defining loggers
Posted by Nicholas Duane <ni...@msn.com>.
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.goers@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 <ni...@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
Re: approach for defining loggers
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Aug 29, 2015, at 7:44 PM, Nicholas Duane <ni...@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org