Page History

...

Use a spring based Aspect library that emits Markers automatically around function calls and retrofit your code to log via Luke's SLF4J for internal log messages.

LoggingWithAOP48534506

Logging Library Location and Use

...

1. By selection of a logging provider such as Logback or Log4j, typically via the classpath. 
2. By way of a provider configuration document, typically logback.xml or log4j.xml. See Providers48534506.

SLF4J

SLF4J is a logging facade, and a humble masterpiece. It combines what's common to all major, modern Java logging providers into a single interface. This decouples the caller from the provider, and encourages the use of what's universal, familiar and proven. 

...

Logback is the most commonly used provider. It is generally configured by an XML document named logback.xml. See Configuration 48534506.

See HELM template https://git.onap.org/logging-analytics/tree/reference/provider/helm/logback

...

Log4j 2.X is somewhat less common than Logback, but equivalent. It is generally configured by an XML document named log4j.xml. See Configuration 48534506.

Log4j 1.X

Strongly discouraged from Beijing onwards, since 1.X is EOL, and since it does not support escaping, so its output may not be machine-readable. See https://logging.apache.org/log4j/1.2/.

...

• Use a logging facade such as SLF4J or EELF. 
• Write log messages in English.
• Write meaningful messages. Consider what will be useful to consumers of logger output. 
• Log at the appropriate level. Be aware of the volume of logs that will be produced.
• Safeguard the information in exceptions, and ensure it is never lost.
• Use errorcodes error codes to characterise characterize exceptions. 
• Log in a machine-readable format. See Conventions.
• Log for analytics as well as troubleshooting.

...

This is the most important item of information in most log messages. See General 48534506 guidelines.

Internationalization

...

if (logger.isDebugEnabled()) {
    logger.debug("But this WILL hurt: " + costlyToSerialize);
}

Parameterized logging is preferable.

Context

MDCs

A Mapped Diagnostic Context (MDC) allows an arbitrary string-valued attribute to be attached to a Java thread via a ThreadLocal variable. The MDC's value is then emitted with each message logged by that thread. The set of MDCs associated with a log message is serialized as unordered name-value pairs (see Text Output 48534506).

A good discussion of MDCs can be found at https://logback.qos.ch/manual/mdc.html. 

...

Used as valuable URI - to annnote invoke marker

Review in terms of Marker 48534506 - INVOKE - possiblly add INVOKE-return - to filter reporting

...

EELF example of SYNCHRONOUS reporting, without changing published APIs. 

...

Error Codes

Errorcodes Error codes are reported as MDCs. 

TODO: add to table

Exceptions should be accompanied by an errrorcodeerror code. Typically this is achieved by incorporating errorcodes error codes into your exception hierarchy and error handling. ONAP components generally do not share this kind of code, though EELF defines a marker interface (meaning it has no methods) EELFResolvableErrorEnum.

A common convention is for errorcodes error codes to have two components:

1. A prefix, which identifies the origin of the error. 
2. A suffix, which identifies the kind of error.

...

1. Choose a Logging provider and/or EELF. Decisions, decisions.
2. Create a configuration file based on an existing archetype. See Configuration48534506.
3. Read your configuration file when your components initialize logging.
4. Write logs to a standard location so that they can be shipped by Filebeat for indexing. See Output Location48534506.
5. Report transaction state:
   1. Retrieve, default and propagate RequestID. See MDC - RequestID 48534506.
   2. At each invocation of one ONAP component by another:
      1. Initialize and propagate InvocationID. See MDC - Invocation ID 48534506.
      2. Report INVOKE and SYNCHRONOUS markers in caller. 
      3. Report ENTRY and EXIT markers in recipient. 
6. Write useful logs!

...