Page MenuHomePhabricator

Add global information to debug logger context
Open, MediumPublic


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).


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 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.

Krinkle renamed this task from Add global logging context to Add global information to debug logger context.Mar 19 2024, 6:10 PM
Krinkle updated the task description. (Show Details)