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) <tammy.osb...@dnr.wa.gov>: > 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:* bmat...@gmail.com [mailto:bmat...@gmail.com] *On Behalf Of *Baptiste > Mathus > *Sent:* Thursday, April 12, 2018 12:41 AM > *To:* jenkinsci-users@googlegroups.com > *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* <m...@batmat.net> > Date: 2018-04-04 15:17 GMT+02:00 > Subject: [DISCUSS] Change Jenkins default logging format > To: Jenkins Developers <jenkinsci-...@googlegroups.com> > > 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 jenkinsci-users+unsubscr...@googlegroups.com. > 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 jenkinsci-users+unsubscr...@googlegroups.com. > 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 jenkinsci-users+unsubscr...@googlegroups.com. 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.
