Hi, Please be sure I do not try to derail this story. Actually I think it is very important, especially if we could go beyond System logs. There are other log types in Jenkins (E.g. build logs), and in the modern CD/DevOps/whatever world it would be preferable to have some unified logging within the entire automation system. Yes, for the entire system, not just for Jenkins.
Creating automation-friendly system logging with Logstash/Fluentd support OOTB would definitely help to unify logging. For other log types there are stories like JENKINS-38313 "External Task Log Storage" <https://issues.jenkins-ci.org/browse/JENKINS-38313> which also lean towards such direction. Thanks for sharing your thoughts Oleg, it makes me wonder: how could we > quantify the positive/negative impact of this (arguably) "bad default."I'm > reminded of some of the pre-Jenkins 2 discussions about security defaults > The current logging format is bad for sure, nobody argues with that from what I see :) > for example. I spent some time trying to discover Jenkins-log-parsing > projects, > tools, and their communities to which we could reach out. Unfortunately I > wasn't able to find anything big past a couple of blog posts :-/ WDYM? Parsing of system logs or logs in general? > And I don't think we should consider Jenkins Essentials to be the only > place where we make the OOTB experience as smooth as possible. Yes, we should not. But it definitely could be a place to start from. 1. We enable the new logging format in Essentials + immediately get benefit from it (e.g. via Logstash/fluentd) 2. We offer a feature flag in standard Jenkins. Start from opt-in, then maybe opt-out at some point 3. For installations passing through the installation wizard, we enable the feature by default (like we do with security defaults now) BR, Oleg On Wed, Apr 4, 2018 at 8:44 PM, Baptiste Mathus <m...@batmat.net> wrote: > > > 2018-04-04 18:12 GMT+02:00 Oleg Nenashev <o.v.nenas...@gmail.com>: > >> Hi Baptiste, >> >> Anyone can easily change the logging format in Jenkins by passing custom >> J.U.L properties file. >> > > Yes. But in practice, I'm convinced virtually nobody does this. > > >> So it should not be a problem to change logging format even if you do not >> add a custom logging appender for ELK. >> >> Changing a default logging format may cause regressions in existing >> monitoring systems. I would rather be conservative and keep the default >> logging format in Jenkins unless there is a strong justification to do >> that. New subprojects like Jenkins Essentials and Jenkins X could easily >> change the default format, because they have no compatibility commitment so >> far. >> > > FTR, I did consider this strategy about keeping the current behavior, and > introduce some sysprop to enable the new (and much much better, IMO) > behavior. > But this is IMO not the way we provide the best possible Jenkins > experience to users, especially newcomers. > > And I don't think we should consider Jenkins Essentials to be the only > place where we make the OOTB experience as smooth as possible. > > Do you really see a big issue if we offer a sysprop to revert to the > current behavior, *but* change the default to something more sensible? > I fail to see how hard it would be for people having built monitoring > about Jenkins logs to just temporarily use the sysprop while they adapt > their logstash or whatever parsing rules. > I can even probably provide it for logstash at least. > > And again, this is IMO for the good of the project and its users, so even > if there's some (small) disruption this is probably worth it. > > Thanks a bunch for your feedback in any case. > > -- Baptiste > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/jenkinsci-dev/4PTMMwQNfjw/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-dev/CANWgJS48-5JTQKOSjt9dtFRimET-%3DH9JKGNh0OoWnKwq6QS0Gg% > 40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS48-5JTQKOSjt9dtFRimET-%3DH9JKGNh0OoWnKwq6QS0Gg%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 Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDSPxVdKCjq13bC2dubhabmNugN%3DFXobO%3Db6jqKGfDX8A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
