> > Could we still keep the Glog formatter class so folks who want to have the > same log formatting between the Aurora log lines and the Mesos driver > (which prints to stderr by default) just have to add a line to their > logging.properties?
I feel slightly uneasy about pseudo-public APIs like this in the long term, but it makes sense for now. FWIW you can almost match the current logging format with vanilla logging.properties configuration: java.util.logging.SimpleFormatter.format = %4$1.1s%1$tm%1$td > %1$tH:%1$tM:%1$tS.%1$tL %2$s %5$s%6$s%n which results in messages like this: I1229 10:24:46.099 org.apache.aurora.scheduler.app.local.FakeMaster > lambda$start$0 All offers consumed, suppressing offer cycle. This doesn't include the thread ID we currently have in our log lines, which has been useful in the past for forensics. If/when we switch to log4j, we should be able to jettison our formatter class as it appears you can include the thread name in the log format. On Mon, Dec 28, 2015 at 3:49 PM, Zameer Manji <zma...@apache.org> wrote: > +1 > > Could we still keep the Glog formatter class so folks who want to have the > same log formatting between the Aurora log lines and the Mesos driver > (which prints to stderr by default) just have to add a line to their > logging.properties? > > The alternative means users would have to build their own glog formatter > and add it to the classpath in addition to setting the formatter in > logging.properties which is not straight forward if you want to have > reasonably formatted log entries between the driver and the scheduler. > > On Mon, Dec 28, 2015 at 2:54 PM, Bill Farner <wfar...@apache.org> wrote: > > > We're currently using some logging scaffolding carried over from Twitter > > commons. I would like to propose that we dismantle some of this in favor > > of more standard java application logging conventions. > > > > Concretely, i propose we remove the following scheduler command line > > arguments: > > -logtostderr > > -alsologtostderr > > -vlog > > -vmodule > > -use_glog_formatter > > > > Instead of these, we can allow users to customize logging via standard > > java.util.logging inputs (e.g. logging.properties). We could explore > using > > an alternative to java.util.logging, but i suggest we retain that backend > > for now (since it's what we're currently using). > > > > -- > > Zameer Manji > > > > >
