Change Details

We currently have at least four different ways of logging the exception trace when logging messages to Logstash. 1. For fatal errors (channel:fatal), we use `fatal_exception => Exception $e` which results in fields like `fatal_exception.message`, `fatal_exception.trace`, `fatal_exception.class`, etc. 2. For uncaught exceptions (channel:exception), we use `exception => Exception $e` which results in fields like `exception.message`, `exception.trace`, etc. 3. For failed DeferredUpdates (channel:DeferredUpdates), we use `[ 'message' => …, 'trace' => ]`, which results in fields like `c_message`, `trace`, etc. (c_message because "message" is a reserved key). 4. For various other ad-hoc logging we seem to use `[ 'trace' => … ]` mostly. **Problem**: This currently means that Logstash dashboards for individual teams either have to repeat their searches several times (which is quite messy to do in Kibana last time I tried), or end up missing some variants. Keeping ad-hoc logging separate might be okay as they're not usually errors but rather traces we tacked onto debug messages that otherwise wouldn't have a trace. We're already consistent with those so they would only require 1 duplicate search to include. **Desired outcome**: Decide which way we want to log exceptions, for the first three cases above. **Proposal 1**: Use `exception`, `exception.trace` etc. Sub tasks: * {icon check-square-o} Fix DeferredUpdates logger in MW core. – <https://gerrit.wikimedia.org/r/549645> * {icon square-o} Fix MWExceptoinHandler for fatal errors in MW core. * {icon square-o} Fix ad-hoc uses of `trace` throughout MW core. * {icon square-o} Fix ad-hoc uses of `trace` throughout wmf-deployed MW extensions.

We currently have at least four different ways of logging the exception trace when logging messages to Logstash. 1. For fatal errors (channel:fatal), we use `fatal_exception => Exception $e` which results in fields like `fatal_exception.message`, `fatal_exception.trace`, `fatal_exception.class`, etc. 2. For uncaught exceptions (channel:exception), we use `exception => Exception $e` which results in fields like `exception.message`, `exception.trace`, etc. 3. For failed DeferredUpdates (channel:DeferredUpdates), we use `[ 'message' => …, 'trace' => ]`, which results in fields like `c_message`, `trace`, etc. (c_message because "message" is a reserved key). 4. For various other ad-hoc logging we seem to use `[ 'trace' => … ]` mostly. **Problem**: This currently means that Logstash dashboards for individual teams either have to repeat their searches several times (which is quite messy to do in Kibana last time I tried), or end up missing some variants. Keeping ad-hoc logging separate might be okay as they're not usually errors but rather traces we tacked onto debug messages that otherwise wouldn't have a trace. We're already consistent with those so they would only require 1 duplicate search to include. **Desired outcome**: Decide which way we want to log exceptions, for the first three cases above. **Proposal 1**: Use `exception`, `exception.trace` etc. Sub tasks: * {icon square-o} Fix DeferredUpdates logger in MW core. – <https://gerrit.wikimedia.org/r/549645> * {icon check-square-o} Fix MWExceptionHandler for fatal errors in MW core. – <https://gerrit.wikimedia.org/r/549645> * {icon square-o} Fix ad-hoc uses of `trace` throughout MW core. * {icon square-o} Fix ad-hoc uses of `trace` throughout wmf-deployed MW extensions.

We currently have at least four different ways of logging the exception trace when logging messages to Logstash. 1. For fatal errors (channel:fatal), we use `fatal_exception => Exception $e` which results in fields like `fatal_exception.message`, `fatal_exception.trace`, `fatal_exception.class`, etc. 2. For uncaught exceptions (channel:exception), we use `exception => Exception $e` which results in fields like `exception.message`, `exception.trace`, etc. 3. For failed DeferredUpdates (channel:DeferredUpdates), we use `[ 'message' => …, 'trace' => ]`, which results in fields like `c_message`, `trace`, etc. (c_message because "message" is a reserved key). 4. For various other ad-hoc logging we seem to use `[ 'trace' => … ]` mostly. **Problem**: This currently means that Logstash dashboards for individual teams either have to repeat their searches several times (which is quite messy to do in Kibana last time I tried), or end up missing some variants. Keeping ad-hoc logging separate might be okay as they're not usually errors but rather traces we tacked onto debug messages that otherwise wouldn't have a trace. We're already consistent with those so they would only require 1 duplicate search to include. **Desired outcome**: Decide which way we want to log exceptions, for the first three cases above. **Proposal 1**: Use `exception`, `exception.trace` etc. Sub tasks: * {icon check-square-o} Fix DeferredUpdates logger in MW core. – <https://gerrit.wikimedia.org/r/549645> * {icon check-square-o} Fix MWExceptoiionHandler for fatal errors in MW core. – <https://gerrit.wikimedia.org/r/549645> * {icon square-o} Fix ad-hoc uses of `trace` throughout MW core. * {icon square-o} Fix ad-hoc uses of `trace` throughout wmf-deployed MW extensions.