Re: Mapped diagnostics context - Adding internal Mesos IDs as context to the logs

vote +1, how about add a epic on this concern topic? 2016-10-06 21:33 GMT+08:00 Joris Van Remoortere : > It's adding *an* extension to the header of the log. In this case after the > file name. > In the comment above the code you can see that it's: > > > often used to append

Re: Mapped diagnostics context - Adding internal Mesos IDs as context to the logs

It's adding *an* extension to the header of the log. In this case after the file name. In the comment above the code you can see that it's: > often used to append the port we're listening on to the logfile That means we can tag our own IDs in there such as Agent ID, Executor ID, Master ID, etc.

Re: Mapped diagnostics context - Adding internal Mesos IDs as context to the logs

> > This is technically feasible: > // > // Specify an "extension" added to the filename specified via > // SetLogDestination. This applies to all severity levels. It's > // often used to append the port we're listening on to the logfile > // name. Thread-safe. > // > GOOGLE_GLOG_DLL_DECL void

Re: Mapped diagnostics context - Adding internal Mesos IDs as context to the logs

I don't know if this is feasible or not, but I would be a strong +1 to this. This would make tracing failures much easier. On Tue, Oct 4, 2016 at 6:12 AM, Frank Scholten wrote: > Hi, > > On JIRA I found several issues about making logs less spammy as well > as making

Mapped diagnostics context - Adding internal Mesos IDs as context to the logs

Hi, On JIRA I found several issues about making logs less spammy as well as making them easier to understand for day to day operations. https://issues.apache.org/jira/browse/MESOS-4432 Condense (redundant) log messages related to task launch/status/finish