[JIRA] Created: (LBCORE-234) write a special line as the first line in any log file so that the file can be automatically parsed by a tool
write a special line as the first line in any log file so that the file can be automatically parsed by a tool ------------------------------------------------------------------------------------------------------------- Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Logback dev list So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu reassigned LBCORE-234: --------------------------------- Assignee: Ceki Gulcu (was: Logback dev list)
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] James Strachan commented on LBCORE-234: --------------------------------------- Hey Ceki! Would you like a patch for this? Wondered if it'd be good to add a little parser to LogBack too so it could automatically parse any log file using this first line to turn the log back into events again.
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-234: ----------------------------------- Hi James, Sorry I did not respond earlier. I am on vacation and will be back on Friday. Anyways, I very much like the idea and intend to implement it in the near future. Of course, a patch would accelerate things a little and is always welcome. (I'd also be quite interested to see and learn from your impl.)
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-234: ----------------------------------- The pattern is now output on top of each file. I will shortly start work on supporting output line to Event (object) conversion.
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] James Strachan commented on LBCORE-234: --------------------------------------- Awsome stuff Ceki!!
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Keegan Witt commented on LBCORE-234: ------------------------------------ I don't think the pattern should be written to files that are in appenders that aren't attached to any loggers. This seems to be happening currently in 1.0.2. Is it possible to change that?
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-234: ----------------------------------- I am not sure I understand. During default configuration (when no log file is found) the pattern is printed on the console (by ConsoleAppender). This has been corrected a few hours ago in the source repo. Do you mean something else?
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Julien Nicoulaud commented on LBCORE-234: ----------------------------------------- I think this feature is useful, but I'd rather have it turned off by default, ie changing outputPatternAsPresentationHeader default value to false.
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Benoit Sigoure commented on LBCORE-234: --------------------------------------- +1 on disabling this by default
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Greg Thomas commented on LBCORE-234: ------------------------------------ I agree, it should be disabled by default. Changing the format of a log file without changing the config on a minor release is a bad move, IMHO.
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-234: ----------------------------------- Some users wish the default value for outputPatternAsPresentationHeader to be false while others wish it to be true. You can express your opinion in the <a href="http://patternAsHeader.questionpro.com">survey</a> created for this issue.
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBCORE-234?page=com.atlassian.jira.plugin.system.i... ] Ceki Gulcu commented on LBCORE-234: ----------------------------------- Due to community demand, outputPatternAsPresentationHeader property renamed as outputPatternAsHeader and is now 'false' by default. See also https://github.com/ceki/logback/commit/22126c5c1
write a special line as the first line in any log file so that the file can be automatically parsed by a tool -------------------------------------------------------------------------------------------------------------
Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Ceki Gulcu
So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup'
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
participants (6)
-
Benoit Sigoure (JIRA) -
Ceki Gulcu (JIRA)
-
Greg Thomas (JIRA)
-
James Strachan (JIRA)
-
Julien Nicoulaud (JIRA)
-
Keegan Witt (JIRA)