Change Details

Certain kinds of information would be useful to have in the log context, but not possible or convenient to add manually. When such information is available from the log processing code, we use a Monolog processor to add it (e.g. IP, URL) but that's not always possible. For example, logging the canonical special page name or the job name would be handy but that's controller-level information and the log processing code has no access to the controller (and if it is logging an exception, the controller might be in some unexpected state). The straightforward solution is to have some globally available temporary storage which application code can write into and log processing code can read from. (log4j calls this a [[https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html|diagnostic context]].) ``` 20:28 < bd808> One feature that monolog is missing that I loved from log4j is a global diagnostic context. That's basically a thread local dict that any code can grab and stick key=value data into that then ends up in all log events ... 20:31 < bd808> at $DAYJOB-1 we tagged logs with lots of things as we found out about them in the app stack. customer id, databases used, services called, etc ... 20:37 < bd808> and we could expose it via LoggerFactory 20:39 < bd808> log4j (and some academic papers I can't find right now) call this thing a "diagnostic context" -- https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html 20:41 < bd808> http://c2.com/cgi/wiki?PatternsForLoggingDiagnosticMessages ```

Certain kinds of information would be useful to have alongside each log message (e.g. in Logstash), but are not possible or inconvenient to add manually to a message. For information that is available from a log processor, we currently use a Monolog Processor plug-in to automatically it (e.g. URL, PHP version, server/host, etc.). But, this is not always possible. For example, adding the canonical name of the current special page or the job name would be handy, but that's controller-level information and the log processing code has no access to the "current" controller (and if it is logging an uncaught exception, the controller might be in some unexpected state). ### Proposal Create a globally available static location, where application code may write into at runtime to stash "current" information for a log processor to pick up. (log4j calls this a [[https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html|diagnostic context]].) ``` 20:28 < bd808> One feature that monolog is missing that I loved from log4j is a global diagnostic context. That's basically a thread local dict that any code can grab and stick key=value data into that then ends up in all log events ... 20:31 < bd808> at $DAYJOB-1 we tagged logs with lots of things as we found out about them in the app stack. customer id, databases used, services called, etc ... 20:37 < bd808> and we could expose it via LoggerFactory 20:39 < bd808> log4j (and some academic papers I can't find right now) call this thing a "diagnostic context" -- https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html 20:41 < bd808> http://c2.com/cgi/wiki?PatternsForLoggingDiagnosticMessages ```

Certain kinds of information would be useful to have in the log contextalongside each log message (e.g. in Logstash), but are not possible or inconvenient to add manually to a message. When suchFor information that is available from thea log processing codeor, wewe currently use a Monolog pProcessor plug-in to addautomatically it (e.g. URL, IPPHP version, URL) but that's not always possible.server/host, For example,etc.). logging the canonical special page name or the job name would be handy but that's controller-level information and the log processing code has no access to the controller (and if it is logging an exceptionBut, the controller might be in some unexpected state)this is not always possible. The straightforward solution is to have some globally available temporary storage which application code can write into and log processing code can read fromFor example, adding the canonical name of the current special page or the job name would be handy, but that's controller-level information and the log processing code has no access to the "current" controller (and if it is logging an uncaught exception, the controller might be in some unexpected state). ### Proposal Create a globally available static location, where application code may write into at runtime to stash "current" information for a log processor to pick up. (log4j calls this a [[https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html|diagnostic context]].) ``` 20:28 < bd808> One feature that monolog is missing that I loved from log4j is a global diagnostic context. That's basically a thread local dict that any code can grab and stick key=value data into that then ends up in all log events ... 20:31 < bd808> at $DAYJOB-1 we tagged logs with lots of things as we found out about them in the app stack. customer id, databases used, services called, etc ... 20:37 < bd808> and we could expose it via LoggerFactory 20:39 < bd808> log4j (and some academic papers I can't find right now) call this thing a "diagnostic context" -- https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html 20:41 < bd808> http://c2.com/cgi/wiki?PatternsForLoggingDiagnosticMessages ```