Log lines (particularly when run through resmoke) have been and are getting longer. The new information we want to add is useful (e.g: TIG-1791), but it comes at a cost. This ticket is to start a conversation to explore what can be done to reduce the need to scroll to the right.

The current log lines outputs the following information (as an example, not all log lines are the same):
a fixture, a job number, node identification, a timestamp, log level, loggger name, thread name, log message

[ReplicaSetFixture:job9:primary] 2019-07-02T02:09:03.027+0000 I  INDEX    [conn98] validated collection config.transactions (UUID: f6c6dde1-fc12-4608-b439-c09508cfee9e)

One workflow I have when debugging a failure in the server (as opposed to an unexpected response):

1. First find the failure (requires looking at the contents of the log message).
2. Look at which job/node the failure came from
3. Add a filter based on job/node identification
4. Filter out unrelated spammy loggers (for execution related failures that's often all of replication, and service arch logs)
5. Scan the log statements

Information like the job and loggers are necessary for filtering, but not looking at. The fixture name and log level are always irrelevant to me. The thread name, log message and at times, the timestamp (more for temporal locality or cross referencing) are most important. Node identification is sometimes only needed for filtering, and sometimes needed because I need to look at messages from multiple nodes simultaneously. Lobster coloring is often a sufficient for distinguishing between nodes in this case.

Common refrains in execution standups when going over new BFs that have come in (where the BB has already done an excellent job picking out the relevant log lines) are: "Scroll to the right [please]" and "keep going..."