Sorry, I was unclear. There *will* still be stack traces IMO, they are critical to understand what is happening. I meant: the logs will *typically* be one-line. But when a given log entry has an associated exception, then it will be printed mostly like now, i.e. with a variable number of lines.
Joining lines when there are exceptions with log-analysis tools like logstash is mostly trivial, you typically detect "at ...", etc. and tell it that it goes with the previous log line. Note that I guess we _could_ consider making the stacktraces possible to disable, but I think this is a bad idea. When something goes wrong, this is the first thing typically, for instance on this mailing list, that we would ask reporters to re-enable and come back when the issue has reoccurred with (or in JIRA reports). Cheers 2018-04-12 15:21 GMT+02:00 Osborn, Tammy (DNR) <[email protected]>: > This sounds like a great idea to me. I haven’t had to deal with the logs > much but simpler is better when there’s no stack trace like Baptiste > suggested. > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Baptiste > Mathus > *Sent:* Thursday, April 12, 2018 12:41 AM > *To:* [email protected] > *Subject:* Fwd: [DISCUSS] Change Jenkins default logging format > > > > Hello everyone, > > > > I am transferring this email I originally posted in the dev list a few > days ago to gather more feedback. > > To sum up: I am proposing to change the current logging format to a more > consise and machine-friendly one-liner (when there's no stacktrace) > > > > If you wish to see it changed, or not, please comment on the subject > detailed below. > > > > Thanks! > > > > ---------- Forwarded message ---------- > From: *Baptiste Mathus* <[email protected]> > Date: 2018-04-04 15:17 GMT+02:00 > Subject: [DISCUSS] Change Jenkins default logging format > To: Jenkins Developers <[email protected]> > > Hello everyone, > > > > Having worked on more things related to Jenkins logging recently, I've had > the opportunity to remember my past pain when I was operating a Jenkins > instance and sending logs to an ELK cluster. > > Compared to almost everything else in the infrastructure, the logstash > rules for Jenkins logs were unnecessarily complex. > > > > The main pain-points, for me at least, had been the two-lines (sigh) per > log default, and also the localized date format (or log level...). > > Even now, so many years after reading those, I still struggle daily to > make sure I'm reading the right line/date associated to the message I'm > reading on the line above. > > > > I would like to propose we change the current logging format behavior to a > more readable and more operation-friendly one. > > This would result in something close to the following format: > > > > [ INFO][2018-04-04 12:40:49] Logging initialized @180ms to > org.eclipse.jetty.util.log.JavaUtilLog (from > org.eclipse.jetty.util.log.Log initialized) > > [ INFO][2018-04-04 12:40:49] Beginning extraction from war file (from > winstone.Logger logInternal) > > [WARNING][2018-04-04 12:40:49] Empty contextPath (from > org.eclipse.jetty.server.handler.ContextHandler setContextPath) > > [ INFO][2018-04-04 12:40:49] jetty-9.4.z-SNAPSHOT (from > org.eclipse.jetty.server.Server doStart) > > > > Instead of the usual: > > > > Apr 04, 2018 12:36:41 PM org.eclipse.jetty.util.log.Log initialized > > INFO: Logging initialized @354ms to org.eclipse.jetty.util.log.JavaUtilLog > > Apr 04, 2018 12:36:41 PM winstone.Logger logInternal > > INFO: Beginning extraction from war file > > Apr 04, 2018 12:36:42 PM org.eclipse.jetty.server.handler.ContextHandler > setContextPath > > WARNING: Empty contextPath > > Apr 04, 2018 12:36:42 PM org.eclipse.jetty.server.Server doStart > > INFO: jetty-9.4.z-SNAPSHOT > > > > > > WDYT? > > > > If this looks interesting to people, I'm ready to file the associated JEP > for it and possibly work on its implementation in the future. > > > > Obviously, we would need some way to revert to the "legacy" format, at > least for some time for users to adapt. But that is not something I'm > particularly worried about. > > > > -- Baptiste > > > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-users/CANWgJS60enT9U8n4Mu1X7dmifixdn > KoU0303GZwOKZCvQKeAhA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS60enT9U8n4Mu1X7dmifixdnKoU0303GZwOKZCvQKeAhA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-users/19E7B5A7F96E1C48B658A85C9D5091 > 0C4CA7B1CB%40WAXMXOLYMB011.WAX.wa.lcl > <https://groups.google.com/d/msgid/jenkinsci-users/19E7B5A7F96E1C48B658A85C9D50910C4CA7B1CB%40WAXMXOLYMB011.WAX.wa.lcl?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CANWgJS6Cie7RNu7aBXSsHRRJPuwzVtQT_uBr-epa9oVT7MNRpg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
