Page History

...

• Explicitly required by logging APIs:
  
  • Logger
  • Level
  • Message
  • Exception (note that exception is the only standard attribute that may routinely be empty).
• Implicitly derived by the logging provider:
  • Timestamp
  • Thread.

Which means you normally can't help but report them. 

See https://www.slf4j.org/api/org/slf4j/Logger.html and https://logback.qos.ch/manual/layouts.html#ClassicPatternLayout for their origins and use.

...

It is confusingly named, and since in Java logging it is normally given as a class or package name, it's commonly more often referred to as the logger "class" or "package".

...

Most other languages will fit one of those patterns.

Timestamp

Logged as an ISO8601 UTC datetime. Millisecond (or greater) precision is preferable.

For example:

2018-07-05T20:21:34.794Z

Offset timestamps are OK provided the offset is explicit. (In the above example, the "Z" is a shorthand indicating an offset of zero – UTC). 

Level

Severity, typically drawn from the enumeration {TRACE, DEBUG, INFO, WARN, ERROR}.

...

Some loggers define non-standard levels, like FINE, FINER, WARNING, SEVERE, FATAL or CRITICAL. Use these judiciously, or avoid them.

...

Message

The name of the thread from which the log message was emitted.

Thread names don't necessarily convey useful information, and their reliability depends on the thread model implemented by different runtimes, but they are sometimes used in heuristic analysis.

Message

freetext payload of a log event. 

This is the most important item of information in most log messages. See General guidelines.The freetext payload of a log event. 

Internationalization

Diagnostic log messages generally do not need to be internationalized.

...

Parameterized messages allow serialization to be deferred until AFTER level threshold checks. This means the cost is never incurred for messages that won't be written. 

• Favor parameterized messages, especially for INFO and DEBUG logging.
• Perform expensive serialization in the #toString method of wrapper classes.

...

logger.debug("ThisRelax - this won't hurt: {}", new ToStringWrapper(costlyToSerialize));

...

The error stacktrace, where applicable.

Log unabridged stacktraces upon error.

When rethrowing, ensure that frame information is not lost:

• By logging the original exception at the point where it was caught. 
• By setting the original exception as the cause when rethrowing.

...

Log unabridged stacktraces upon error.

When rethrowing, ensure that frame information is not lost:

...

Timestamp

Logged as an ISO8601 UTC datetime. Millisecond (or greater) precision is preferable.

For example:

2018-07-05T20:21:34.794Z

Offset timestamps are OK provided the offset is included. (In the above example, the "Z" is a shorthand indicating an offset of zero – UTC).

Thread

The name of the thread from which the log message was emitted.

Thread names don't necessarily convey useful information, and their reliability depends on the thread model implemented by different runtimes, but they are sometimes used in heuristic analysis.

Efficiency

There is tension between verbosity utility and efficiency. IO bandwidth is finite, and the cost of serialization can be significant, especially at higher diagnostic levels.

...

Many loggers can use reflection to emit the originating (Java) method, and even individual line numbers.

This information is certainly useful, but very expensive. Most logging implementations recommend that this not be enabled in production.

...

Logger output is typically filtered by logger and level. The default logging level is INFO, so particular consideration should be given to the efficiency of INFO-level logging.

...

WARN and ERROR-level messages are generally high-of higher value, and comparatively rare, so their cost is less of a concern.

...

A common pattern is to place conditionals around (expensive) debug loggingserialization.

For example:

if (logger.isDebugEnabled()) {
    logger.debug("ThisBut isthis going toWILL hurt: " + costlyToSerialize);
}

...