So we can monitor the rate of exceptions on PHP 7 and build dashboards, etc.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Add PHP version information to log entries | operations/mediawiki-config | master | +10 -0 |
Event Timeline
Comment Actions
Change 472498 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[operations/mediawiki-config@master] Add PHP version information to log entries
Comment Actions
Change 472498 merged by jenkins-bot:
[operations/mediawiki-config@master] Add PHP version information to log entries
Comment Actions
Tried and reverted. I deployed this onto mwdebug1001, set my X-Wikimedia-Debug to mwdebug1001 plus checked logging, and then no logs showed up. Switched to mwdebug1002 plus checked logging (which didn't have my patch), and logs showed up like normal. Reverted the patch on mwdebug1001, and logs start showing up again..
Do you have any ideas @bd808 why my patch wouldn't have worked?
Comment Actions
You should be able to check out the filter itself locally to see if there is some weird problem with the syntax that our eyeball review of the change missed. The \\Monolog\\Handler\\WhatFailureGroupHandler we install will mask runtime problems with the logging configuration by catching and discarding fatal errors from a specific handler.
The only other thing I can think of is that it caused some Elasticsearch schema error which kept the ELK servers from actually indexing the log events? The only way to check for that is by looking at the Elasticsearch logs on the backing servers. I don't think they are sent anywhere else that makes them available for review off the hosts themselves.