Page MenuHomePhabricator

Add global logging context
Open, MediumPublic


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 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" --
20:41 < bd808>

Event Timeline

bd808 triaged this task as Medium priority.Aug 8 2016, 3:19 PM

Implementation ideas can be cribbed from a logging project I wrote quite a while ago but never used much:

Basically we'd want to have:

  • An easy way to add a context variable
  • An easy way to get all current context variables
  • A Monolog handler to merge the global context into a log event
  • Docs on all of that

The entry points could be either static methods on LoggerFactory or another service object that is easy to get from MediaWiki code. Classes using the context would be tied to the MediaWiki implementation because there isn't anything like this in the PSR3 logging standard. That shouldn't be a horrible thing because the interesting data to decorate the logs is typically found in routing context code (which SpecialPage is being invoked, etc).

This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.