Log Message regardless of Log Level
Folks, Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive. So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable? Regards, Shane
Typically they are logged at the INFO level (Since they are informational). Which give the user the choice of logging them or not. Choice is usually seen by users as a good thing. (*Chris*) On Fri, Dec 14, 2012 at 2:42 PM, Shane Kelly <logback@ballinascreen.com>wrote:
Folks,
Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive.
So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable?
Regards,
Shane
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Use a Marker. Then set a Marker filter to always accept events with that Marker. Ralph On Dec 14, 2012, at 2:42 PM, Shane Kelly wrote:
Folks,
Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive.
So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable?
Regards,
Shane _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Ralph, Thanks for your suggestion - after a quick skim through the documentation it certainly looks like markers may provide the behaviour I'm looking for - will give that a try. Regards, Shane On 15 December 2012 00:21, Ralph Goers <rgoers@apache.org> wrote:
Use a Marker. Then set a Marker filter to always accept events with that Marker.
Ralph
On Dec 14, 2012, at 2:42 PM, Shane Kelly wrote:
Folks,
Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive.
So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable?
Regards,
Shane _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Shane, Were you able to make progress on this issue? On 15.12.2012 01:56, Shane Kelly wrote:
Ralph,
Thanks for your suggestion - after a quick skim through the documentation it certainly looks like markers may provide the behaviour I'm looking for - will give that a try.
Regards,
Shane
On 15 December 2012 00:21, Ralph Goers <rgoers@apache.org <mailto:rgoers@apache.org>> wrote:
Use a Marker. Then set a Marker filter to always accept events with that Marker.
Ralph
On Dec 14, 2012, at 2:42 PM, Shane Kelly wrote:
> Folks, > > Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive. > > So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable? > > Regards, > > Shane
-- Ceki http://twitter.com/#!/ceki
Ceki, Ralph, I did try the TurboFilter as suggested, however, something which I probably didn't make explicitly clear in my original post was that I configure a ThresholdFilter within each of my appenders to filter out messages below a certain level - as I said previously, its likely that the application I'm working on will be configured only to log messages of WARN and above. For example: <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter"> <Name>ALWAYSLOG</Name> <Marker>ALWAYSLOG</Marker> <OnMatch>ACCEPT</OnMatch> </turboFilter> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter> ... ... </appender> Although the Marker turbofilter is ACCEPTing messages which contain the appropriate 'marker' as expected, the message will then get filtered out by the subsequent the Threshold filter - I suppose I could extend the standard Threshold filter to look for the presence of the marker and bypass normal threshold filtering in these cases... or did I misunderstand something? Regards, Shane On 18 December 2012 14:46, ceki <ceki@qos.ch> wrote:
Shane,
Were you able to make progress on this issue?
On 15.12.2012 01:56, Shane Kelly wrote:
Ralph,
Thanks for your suggestion - after a quick skim through the documentation it certainly looks like markers may provide the behaviour I'm looking for - will give that a try.
Regards,
Shane
On 15 December 2012 00:21, Ralph Goers <rgoers@apache.org <mailto:rgoers@apache.org>> wrote:
Use a Marker. Then set a Marker filter to always accept events with that Marker.
Ralph
On Dec 14, 2012, at 2:42 PM, Shane Kelly wrote:
> Folks, > > Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive. > > So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable? > > Regards, > > Shane
-- Ceki http://twitter.com/#!/ceki
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
A minor correction to my earlier response - I defined the <turboFilter> in the <configuration> section, and *not* within the <appender> Regards, Shane On 18 December 2012 23:46, Shane Kelly <logback@ballinascreen.com> wrote:
Ceki, Ralph,
I did try the TurboFilter as suggested, however, something which I probably didn't make explicitly clear in my original post was that I configure a ThresholdFilter within each of my appenders to filter out messages below a certain level - as I said previously, its likely that the application I'm working on will be configured only to log messages of WARN and above. For example:
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter"> <Name>ALWAYSLOG</Name> <Marker>ALWAYSLOG</Marker> <OnMatch>ACCEPT</OnMatch> </turboFilter>
<filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>WARN</level> </filter>
... ...
</appender>
Although the Marker turbofilter is ACCEPTing messages which contain the appropriate 'marker' as expected, the message will then get filtered out by the subsequent the Threshold filter - I suppose I could extend the standard Threshold filter to look for the presence of the marker and bypass normal threshold filtering in these cases... or did I misunderstand something?
Regards,
Shane
On 18 December 2012 14:46, ceki <ceki@qos.ch> wrote:
Shane,
Were you able to make progress on this issue?
On 15.12.2012 01:56, Shane Kelly wrote:
Ralph,
Thanks for your suggestion - after a quick skim through the documentation it certainly looks like markers may provide the behaviour I'm looking for - will give that a try.
Regards,
Shane
On 15 December 2012 00:21, Ralph Goers <rgoers@apache.org <mailto:rgoers@apache.org>> wrote:
Use a Marker. Then set a Marker filter to always accept events with that Marker.
Ralph
On Dec 14, 2012, at 2:42 PM, Shane Kelly wrote:
> Folks, > > Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive. > > So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable? > > Regards, > > Shane
-- Ceki http://twitter.com/#!/ceki
______________________________**_________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/**listinfo/logback-user<http://mailman.qos.ch/mailman/listinfo/logback-user>
Hi Shane, In a similar situation, I used another approach. First I considered using markers on each initialization log message. Then I used a logger dedicated exclusively for initialization. This dedicated logger was configured to log everything, regardless of other loggers. Both solutions, markers or dedicated logger, require you to handle the initialization messages differently and to provide proper configuration for them. IMHO, the approach of a dedicated logger is much simpler to understand and to configure. Best regards, Daniel Felix Ferber 2012/12/14 Shane Kelly <logback@ballinascreen.com>
Folks,
Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive.
So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable?
Regards,
Shane
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
Hi Daniel, Thanks for the info - glad there are others out there with similar requirements. I guess a separate logger specifically for this purpose is another way to approach it alright - definitely worth considering. I think I'm gonna try extending the existing ThresholdFilter (or creating a new filter based on it) as a first attempt, see how that goes, and failing that try the separate logger route. Good to have options. Regards, Shane On 19 December 2012 00:12, Daniel Ferber <dffforum@gmail.com> wrote:
Hi Shane,
In a similar situation, I used another approach. First I considered using markers on each initialization log message. Then I used a logger dedicated exclusively for initialization. This dedicated logger was configured to log everything, regardless of other loggers.
Both solutions, markers or dedicated logger, require you to handle the initialization messages differently and to provide proper configuration for them. IMHO, the approach of a dedicated logger is much simpler to understand and to configure.
Best regards, Daniel Felix Ferber
2012/12/14 Shane Kelly <logback@ballinascreen.com>
Folks,
Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive.
So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable?
Regards,
Shane
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
I've now created my own simple filter which I've added as the first filter to each of my <appender> definitions - it checks for the presence of a predefined marker and always ACCEPTs those messages - giving the behaviour I required. Regards, Shane On 19 December 2012 00:30, Shane Kelly <logback@ballinascreen.com> wrote:
Hi Daniel,
Thanks for the info - glad there are others out there with similar requirements. I guess a separate logger specifically for this purpose is another way to approach it alright - definitely worth considering. I think I'm gonna try extending the existing ThresholdFilter (or creating a new filter based on it) as a first attempt, see how that goes, and failing that try the separate logger route. Good to have options.
Regards,
Shane
On 19 December 2012 00:12, Daniel Ferber <dffforum@gmail.com> wrote:
Hi Shane,
In a similar situation, I used another approach. First I considered using markers on each initialization log message. Then I used a logger dedicated exclusively for initialization. This dedicated logger was configured to log everything, regardless of other loggers.
Both solutions, markers or dedicated logger, require you to handle the initialization messages differently and to provide proper configuration for them. IMHO, the approach of a dedicated logger is much simpler to understand and to configure.
Best regards, Daniel Felix Ferber
2012/12/14 Shane Kelly <logback@ballinascreen.com>
Folks,
Just wondering if there is a capability within Logback for writing a log message regardless of whatever log level has been set in configuration. Consider the scenario where I want my web application to output some diagnostic information at startup or shutdown - for example, the Web Application version, build date etc. If I were to set the log level of these messages to be TRACE, DEBUG, or INFO then its possible they may never be displayed since the app may typically be configured to run with a log level of WARN. Similarly, I don't want to set the log level of the messages to WARN, ERROR or FATAL in order to ensure that they do get displayed since they're not really error messages, and if we monitor the log files for WARN, ERROR or FATAL messages then this would trigger a false positive.
So, is there some way to force a message to be logged at all times, independently of log level? Or some way to achieve this effect via existing configuration. Arguably I suppose this is bending the rules slightly, in that it could be abused - why offer the ability to filter certain log levels if an application can override/ignore them - but perhaps this is something which could be configurable/switchable?
Regards,
Shane
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user
participants (5)
-
ceki -
Chris Pratt -
Daniel Ferber -
Ralph Goers -
Shane Kelly