Page tree
Skip to end of metadata
Go to start of metadata

Release A plan:

We will go ahead with the current implementation that is already existing in Acumos as of now for release A and will follow Key-value pair concept for release B.

We will follow default pattern(all in one line) for release A only addition will be MDC listed below in sequence so we will have four logs:

  • audit
  • metrics
  • debug
  • error

Each log will have same format with the below MDCs, log system values and standard attributes, in sequence starting with p_tim and ending with p_marker.

In the table below, the rows highlighted in green will be mandatory, while are log or system generated,  and the rows highlighted in yellow will be context dependent.

If no value is available for the mandatory fields, random generate one. If no value is available for the context dependent then we can leave it as empty string/blank.

Where it says log system, that required field is generated by the base log system, you need to include it in the logback.xml pattern only.

The logging format is pipe-delimited. Here is an example based on the table below:

WIP review until finalized

The following table summarizes the proposed standards for logging by Acumos components, via the ELKPaaS service. Prerequisites for complying to these standards are described by the ONAP project under the Dublin release at ONAP Logging Standards..

Release B plan:

Refer Acumos Log Standards

 We will follow Key-Value pair concept for Boreas release. We are not following EELF standards as part of this release therefore application should output log records to a single file i.e componentname.log.

In the table below, the rows highlighted in green will be mandatory,  while others are Library or context dependent.

If no value is available for the mandatory fields, random generate one. If no value is available for the context dependent then we can leave it as empty string/blank.

Where it says log system, that required field is generated by the base log system, you need to include it in the logback.xml pattern only.



(per log file)

Marker Associations



(Y = Yes

C= context dependent

L = Library Provided

N = not required)

Use CasesCode References
LogTimestamplog systemDate and time in UTC. use same format as *Timestamp below %date{"yyyy-MM-dd'T'HH:mm:ss.SSSXXX",UTC}




Tracks the processing of each client request across all the ACUMOS components involved in its processing - used for %X{RequestId}.

ACUMOS logging uses a universally unique "RequestID" value in log records to track the processing of each client request across all the ACUMOS components involved in its processing. RequestID be propagated across all interfaces, not just REST Interfaces.

This value:

  • Is logged as a RequestID MDC. 
  • Is propagated between components in REST calls as an X-ACUMOS-RequestID HTTP header.

Receiving the X-ACUMOS-RequestID will vary by component according to APIs and frameworks.


Threadlog systemthread - standard attribute - defined in logback.xml - used for %thread



This field indicates the high level status of the request - one of (COMPLETE, ERROR, INPROGRESS)

It must have the value COMPLETE when the request is successful and ERROR when there is a failure.  And INPROGRESS for states between the two.



This field contains application-specific error and success codes.

For consistency, common error categorizations should be used


ResponseDescriptionMDCThis field contains a human readable description of the ResponseCode



log system

standard attribute - defined in logback.xml - used for %.-5level

The default log level is INFO.



Logging level by default aligned with the reported log level - one of INFO/TRACE/DEBUG/WARN/ERROR/FATAL - used for %X{Severity}

OPS specific

Use/Map existing


By default - align this severity with the reported log level

(optionally a way to map actual level from reported level if required)



The VM FQDN if the server is virtualized. Otherwise the host name of the logging component. - used for %X{ServerFQDN}



This field contains the requesting remote client application’s IP address if known. Otherwise empty. - used for %X{ClientIPAddress}



The name of the ACUMOS component or sub-component, or external entity, at which the operation activities captured in this log record is invoked.



It contains the name  of the API or operation activities invoked (name on the remote/target application) at the TargetEntity.  

Example: Class name of rest endpoint


User MDCUser - used for %X{user}    C

Loggerlog system

The name of the class doing the logging (in my case the ApplicationController – close to the targetservicename but at the class granular level - this field is %logger


Mdclog system

The key/value pairs ( this field is %mdc)

Allows forward compatability with ELK indexers that read all MDCs in a single field - while maintaining separate MDCs above.


Messagelog systemstandard attribute - defined in logback.xml - Message - used for %msg%n  L

Markerlog system


Markers unambiguously assign semantics to individual log messages. They allow messages that have a specific meaning to be cheaply and easily identified in logger output, without inherently unreliable (and more costly, and less easily enforced) schemes like scanning for magic strings in the text of each log message. 

ACUMOS logging can use the emission of Markers reporting entryexit and invocation as the execution of requests pass between ACUMOS components. This information is used to generate a call graph.

ACUMOS components are also free to use Markers for their own purposes. Any Markers that are logged will be automatically indexed by Logstash. 

Markers differ from MDCs in two important ways:

  1. They have a name, but no value. They are a tag - like a label. 

They are specified explicitly on invocation. They are not ThreadLocal, and they do not propagate.

Marker - ENTRY

This should be reported as early in invocation as possible, immediately after setting the RequestID MDCs.

Marker - EXIT

This should be reported as late in invocation as possible, immediately before unsetting the RequestID MDCs.

Marker - INVOKE

This should be reported by the caller of another ACUMOS component via REST.


This should be reported by the caller of another ACUMOS component via REST on return


This should accompany INVOKE when the invocation is synchronous.


This should accompany INVOKE when the invocation is asynchronous.


  • No labels


  1. One dump question: Is there any short sample implementation.  I have gone through ONAP Application Logging Specification, but its too lengthy material to understand and not aware whether to do all in Acumos too.  

    Anther query is : Have we finalized the pattern of MDC (some e.g. below) and any feasibility check whether all the considered MDC values are available with all components. If in case for any particular MDC, values is missing then what would be the default value (viz., will it be blank or some string like "NA", etc.)  


    1. Different pattern for debug with some default patter (all in one line) : log output with this pattern is not that readable, but may be good for call tracing.

    <property name="defaultPattern" value="%date{ISO8601}|%X{RequestId}|%X{ServiceInstanceId}|%thread|%X{VirtualServerName}|%X{ServiceName}|%X{InstanceUUID}|%.-5level|%X{AlertSeverity}|%X{ServerIPAddress}|%X{ServerFQDN}|%X{RemoteHost}|%X{ClassName}|%X{Timer}| %msg%n" />
    <property name="debugLoggerPattern" value="%date{ISO8601}|%X{RequestId}|%X{ServiceInstanceId}|%thread|%X{VirtualServerName}|%X{ServiceName}|%X{InstanceUUID}|%.-5level|%X{AlertSeverity}|%X{ServerIPAddress}|%X{ServerFQDN}|%X{RemoteHost}|%X{ClassName}|%X{Timer}| %msg%n" />


    2. Only one default pattern with some formatting and newline char.  This pattern improve readability, but may not be good for call tracing.

    <property name="defaultPattern" value="%nopexception%logger

    Depending on the our requirement we need to decide or come up with pattern of MDC.

    1. Some of your questions are answered on the ONAP logging standards page

    2. Vaibhav Shirsat We will go ahead with the current implementation that is already existing in Acumos as of now for release A and will follow Key-value pair concept for release B. We will follow default pattern(all in one line) for release A only addition will be MDC listed above in sequence so we will have four logs audit,metrics,debug,error and each log will have same format with the above MDC in sequence starting with RequestID and ending with Thread. Highlighted in green will be mandatory and others will be context dependent. If no value is available for context dependent then we can leave it as empty string/blank.

    3. I am doing a PoC with the latter format.  It works fine, puts everything on one line for convenience of machine analysis.  In my configuration the console output has the newlines for the convenience of users (smile) can share if you like.

      1. Chris, can you share this as a sub=page from this main spec page which will help in release B planning.  This is cool that you went ahead and did a PoC for experimentation purposes.

  2. As a developer I find it extremely hard to get started here.  For example, required field StatusCode is limited to values COMPLETE, ERROR.  But the vast majority of the logging invocations will be made DURING processing of a request, when it's neither complete nor failed. What should be shown?  I'm not sure what to do about TargetElement; in Acumos we don't have virtual network functions.  What does the description text "bring back" mean; e.g., "bring back ServerIPAddress MDC" ?

    The old-style log format had defined columns by position; e.g., column 1 was date, column 2 was log level, and so on. Based on that experience I expected to see a statement from the logging-standards committee about the log-file output COLUMNS. But maybe that's not actually the case.  In the new MDC world, is every column (every value) tagged with a key?  In other words, could the columns be different on each log output entry?

    Vaibhav Shirsat the all-on-one-line format is the traditional method, but maybe ELK actually prefers something else?

    1. Chris Lott Removed bring back from description.  Key-value pair concept will be part of release B. Columns will be same across all components and across all four files i.e audit,metric,error and debug.

      TargetElement is context dependent so if no value is available then it should be kept blank.

      Michael O'Brien Please comment on StatusCode query.

      We need to follow old-style log format that has defined positions as in below format.


  3. Questions/answers for parichay gupta answered on,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,24231150

        Hi, answers in-line in italic-red


    1. required field StatusCode is limited to values COMPLETE, ERROR.  But the vast majority of the logging invocations will be made DURING processing of a request, when it's neither complete nor failed. What should be shown?

    Michael: good question – limiting the enumeration was too restrictive – in the call yesterday we added INPROGRESS based on feedback from Acumos and from Dave on the spec page and Chris on the acumos page

    In general we will try to sync the two spec pages onap/acumos – where the onap page drives the common parts of the acumos spec

    The larger logging/acumos logging team has been working with Portal – as of today I will be looking to use their aspect advice class in portal/sdk as a concrete RI in addition to our WIP aspect wrapper


    1. what to do about TargetElement, in Acumos we don't have virtual network functions. 

    Michael: for targetElement – yes this is ONAP specific – this has come up a couple times – I will add a column in the spec table for non-general/industry logging MDC’s (beyond the standard request/invocation ones for example)  - the same type off issue that occurs in spec/proprietary jpa/orm or cloud native/agnostic artifacts in onap.

    I expect we will have 2 categories (industry, native(ONAP/Acumos)


    1. Can we get one example of log file output columns, with all the MDC’s value populated as it is generated in logs? Ex: value under RequestID, InvocationID, InstanceUUID, ServiceName, etc..

    Michael: We published some examples in the spec page table – there are clickable MDC links on each line – some are missing – I will fix them.

    Some of the older examples before we updated the spec need to be adjusted – however the developer section has output of the logging library which is being coded to implement/demo the spec

    see example here

    1. If we don’t get RequestID from header of REST calls then do we need to generate one? If so then what is the rule of generating random number?

    Michael: Yes, the rule is pass-through or generate - there is an example in the SLF4J library in

    private static UUID sInstanceUUID = UUID.randomUUID();

  4. I would vastly prefer to use the MDC key=value style of log format lines now, in Athena release, instead of doing some disruptive changes now and further disruptive changes later.  This change is localized to the logback.xml configuration file - nowhere else in component code.  ONAP community provides a logback.xml file and I have a version I can also share.

  5. Adding email conversation:

    Sent: Wednesday, August 15, 2018 4:48 PM
    To: DEY, SPONDON <>
    Subject: Re: Logging Specs Review: Attention ACUMOS PTLs


    I see critical omissions from that 25-column format/table:


      Date/time of log output

      Log level

      Java class name

      Log message (currently the last column)


    All that other data (e.g., "TargetElement") may be valuable to some analysis system, but the above items are critical for developer/debug use.


    So how many columns is the format, really?

    1. Response from Lorraine Welch Lorraine Welch :



      25 columns


      I propose:

        Date/time of log output in EntryTimestamp

        Log level - %X{AlertSeverity} in Severity and %.-5level in Level

        Java class name %X{ClassName} in TargetServiceName

            Log message (currently the last column) in Message



      1. Adding Comment from Michael O'Brien :

        Good point, those are non-MDC fields (standard fields) and should be defined in the format string of logback.xml – I’ll verify the EELF and non-EELF examples there.

        I’ll make sure these non-MDC fields are described properly there.


        For example  - this is not the final logback pattern but illustrates how timestamp, level, classname (with embedded MDCs) and message make it through



        <property name="debugPattern" value="%d{&quot;yyyy-MM-dd'T'HH:mm:ss.SSSXXX&quot;, UTC}|%X{RequestId}|%msg%n\t${p_mdc}\t${p_msg}\t${p_exc}\t${p_mak}\t%n" />



        2018-07-09T14:48:01.014Z    http-nio-8080-exec-8    INFO    org.onap.demo.logging.ApplicationService   








         ServerFQDN=localhost   Running /health





  6.  Here is the powerpoint that I presented at this mornings Architecture meeting

  7. Lorraine Welch and I updated the table based on the onap/portal/sdk logback.xml pattern for audit  - use this pattern for all 4 logs (audit, error, metrics, debug)

     original onap portal/sdk  20180806
      <property name="auditPattern" value="%X{BeginTimestamp}|%X{EndTimestamp}|%X{RequestId}|%X{ServiceInstanceId}|%thread||%X{ServiceName}|%X{PartnerName}|%X{StatusCode}|%X{ResponseCode}|%X{ResponseDesc}|%X{InstanceUUID}|%.-5level|%X{AlertSeverity}|%X{ServerIPAddress}|%X{Timer}|%X{ServerFQDN}|%X{RemoteHost}||||||||%msg%n" />
    modified acumos - 25 fields
      <property name="auditPattern" value="%X{EntryTimestamp}|%X{InvokeTimestamp}|%X{RequestId}|%X{InvocationId}|%X{InstanceUUID}|%X{ServiceInstanceId}|%thread|%X{ServiceName}|%X{PartnerName}|%X{StatusCode}|%X{ResponseCode}|%X{ResponseDesc}|%.-5level|%X{Severity}|%X{ServerIPAddress}|%X{ElapsedTime}|%X{ServerFQDN}|%X{ClientIPAddress}|%X{VirtualServerName}|%X{ContextName}|%X{TargetEntity}|%X{TargetServiceName}|%X{TargetElement}|%X{User}|%msg%n" />

    • application.log will be error.log from now on
    • missing {p_log} for logger field 

        <property name="p_log" value="%logger"/>

    • missing marker field and mdc field
    • Working in the following review (in-progress) - as a shared reference
    1. For the p_log or logger field missing from acumos that I added back to onap - I was wrong this is not for markers - this is the logger itself on the class - usually the same as the class name.

      notice new field p_logger at pos 25 - after user

      notice new field p_mdc at pos 26 and p_marker at 28 (after Message at 27)

        <property name="p_log" value="%logger"/>

      The marker field I am adding back a p_mak so it displays what lukes slf4j library already emits

        <property name="p_mak" value="%replace(%replace(%marker){'\t', '\\\\t'}){'\n','\\\\n'}"/>

      For the msg to Message field - need to adjust the code because

      -<property name="p_message" value="%replace(%replace(%msg){'\t', '\\\\t'}){'\n','\\\\n'}"/>

      +<property name="p_message" value="%replace(%replace(%Message){'\t', '\\\\t'}){'\n','\\\\n'}"/>



      for the serverFQDN that outputs the dns entry of the host vm for the k8s cluster - i am retesting on a cluster so we would expect instead of


        <property name="p_tim" value="%d{&quot;yyyy-MM-dd'T'HH:mm:ss.SSSXXX&quot;, UTC}"/>

        <property name="p_lvl" value="%level"/>

        <property name="p_logger" value="%logger"/>

        <property name="p_mdc" value="%replace(%replace(%mdc){'\t','\\\\t'}){'\n', '\\\\n'}"/>

        <property name="p_message" value="%replace(%replace(%msg){'\t', '\\\\t'}){'\n','\\\\n'}"/>

        <property name="p_exc" value="%replace(%replace(%rootException){'\t', '\\\\t'}){'\n','\\\\n'}"/>

        <property name="p_marker" value="%replace(%replace(%marker){'\t', '\\\\t'}){'\n','\\\\n'}"/>

        <property name="p_thr" value="%thread"/>

        <!--  property name="pattern" value="%nopexception${p_tim}\t${p_thr}\t${p_lvl}\t${p_log}\t${p_mdc}\t${p_msg}\t${p_exc}\t${p_mak}\t%n"/-->

        <property name="pattern" value="%nopexception${p_tim}|%X{EntryTimestamp}|%X{InvokeTimestamp}|%X{RequestId}|%X{InvocationId}|%X{InstanceUUID}|%X{ServiceInstanceId}|%thread|%X{ServiceName}|%X{PartnerName}|%X{StatusCode}|%X{ResponseCode}|%X{ResponseDesc}|%.-5level|%X{Severity}|%X{ServerIPAddress}|%X{ElapsedTime}|%X{ServerFQDN}|%X{ClientIPAddress}|%X{VirtualServerName}|%X{ContextName}|%X{TargetEntity}|%X{TargetServiceName}|%X{TargetElement}|%X{User}|${p_logger}|${p_mdc}|${p_message}|${p_marker}%n" />



      2018-08-28T16:26:57.887Z||2018-08-28T16:26:57.883Z|||7741c447-cd4f-4f0a-9e7a-9abc3eebe8c1||http-nio-8080-exec-30|/logging-demo/rest/health/health|||||INFO||||localhost|0:0:0:0:0:0:0:1|||||||org.onap.demo.logging.ApplicationService|ResponseCode=, InstanceUUID=7741c447-cd4f-4f0a-9e7a-9abc3eebe8c1, RequestID=c897a12f-fa51-4450-8645-3ee907946695, ServiceName=/logging-demo/rest/health/health, ResponseDescription=, InvocationID=067ba289-9017-462a-8d68-aa2670a04205, Severity=, InvokeTimestamp=2018-08-28T16:26:57.883Z, PartnerName=, ClientIPAddress=0:0:0:0:0:0:0:1, ServerFQDN=localhost, StatusCode=||EXIT

    2. As of today's meeting , application.log was going to go into audit.log, so why is it now going to error.log?

      And the numbering of the new fields should be (don't forget about the new LogTimestamp in position 1): 

      ${p_logger}| 26


      ${p_marker}%n" 29

      Michael - Can you explain the use of these 3 fields and their type: log system, MDC or Standard Attribute?

      1. ${p_logger}| 26

        The name of the class doing the logging (in my case the ApplicationController – close to the targetservicename but at the class granular level


        The key/value pairs all in one pipe field (will have some duplications currently whit MDC’s that are in their own pipe – but allows us to expand the MDC list – replaces customvalue1-3 older fields)

        ${p_marker}%n" 29

        The marker labels INVOKE, ENTRY, EXIT – and later will also include DEBUG, AUDIT, METRICS, ERROR when we go to 1 log file

  8. In the wiki we describe some of these as “system log type (SL)” or “Standard Attribute (SA)” and some as L library provided and some as C Context dependent


    From logback.xml (



    SL type      <property name="p_tim" value="%d{&quot;yyyy-MM-dd'T'HH:mm:ss.SSSXXX&quot;, UTC}"/>

    SA type    <property name="p_lvl" value="%level"/>

    SL type    <property name="p_logger" value="%logger"/>

    SL type      <property name="p_mdc" value="%replace(%replace(%mdc){'\t','\\\\t'}){'\n', '\\\\n'}"/>

    SA type     <property name="p_message" value="%replace(%replace(%msg){'\t', '\\\\t'}){'\n','\\\\n'}"/>

    Not in wiki, in logback.xml not used yet  <property name="p_exc" value="%replace(%replace(%rootException){'\t', '\\\\t'}){'\n','\\\\n'}"/>

    SL type      <property name="p_marker" value="%replace(%replace(%marker){'\t', '\\\\t'}){'\n','\\\\n'}"/>

    SA type   <property name="p_thr" value="%thread"/>


    What’s the difference, is the wiki incorrect?

    Also on the wiki ( I changed LogTimestamp to p_tim and Message to p_message to be in sync with logback.xml

  9. V30 of this page Log Standards has been finalized by Lorraine Welch with the team and Michael O'Brien  - this is for the Athena release of Acumos and the Casablanca release of ONAP.  Any further changes to the spec will be in the B and D  releases of the two teams

    synced version 111 of

    details on

    1. 29 fields updated in the review - adjusted wikis - note InstanceUUID to InstanceID change

      <!-- MDC and MARKER specific for Cassablanca -->
        <property name="LogTimestamp"   value="%d{&quot;yyyy-MM-dd'T'HH:mm:ss.SSSXXX&quot;, UTC}"/>
        <property name="Level"          value="%.-5level"/>
        <property name="Logger"         value="%logger"/>
        <property name="Mdc"            value="%replace(%replace(%mdc){'\t','\\\\t'}){'\n','\\\\n'}"/>
        <property name="Message"        value="%replace(%replace(%msg){'\t','\\\\t'}){'\n','\\\\n'}"/>
        <property name="RootException"  value="%replace(%replace(%rootException){'\t', '\\\\t'}){'\n','\\\\n'}"/>
        <property name="Marker"         value="%replace(%replace(%marker){'\t','\\\\t'}){'\n','\\\\n'}"/>
        <property name="Thread"         value="%thread"/>
        <!-- indexed  -->
        <!--  for Casablanca we support both position dependent pipe delimited - and position independent KVP MDCs -->
        <property name="p_1_LogTimestamp"       value="${LogTimestamp}" />
        <property name="p_2_EntryTimestamp"     value="%X{EntryTimestamp}" />
        <property name="p_3_InvokeTimestamp"    value="%X{InvokeTimestamp}" />
        <property name="p_4_RequestID"          value="%X{RequestId}" />
        <property name="p_5_InvocationID"       value="%X{InvocationId}" />
        <property name="p_6_InstanceID"         value="%X{InstanceUUID}" /> <!--  previously InstanceUUID -->
        <property name="p_7_ServiceInstanceID"  value="%X{ServiceInstanceId}" />
        <property name="p_8_thread"             value="${Thread}" />
        <property name="p_9_ServiceName"        value="%X{ServiceName}" />
        <property name="p_10_PartnerName"       value="%X{PartnerName}" />
        <property name="p_11_StatusCode"        value="%X{StatusCode}" />
        <property name="p_12_ResponseCode"      value="%X{ResponseCode}" />
        <property name="p_13_ResponseDesc"      value="%X{ResponseDesc}" />
        <property name="p_14_level"             value="${Level}" />
        <property name="p_15_Severity"          value="%X{Severity}" />
        <property name="p_16_ServerIPAddress"   value="%X{ServerIPAddress}" />
        <property name="p_17_ElapsedTime"       value="%X{ElapsedTime}" />
        <property name="p_18_ServerFQDN"        value="%X{ServerFQDN}" />
        <property name="p_19_ClientIPAddress"   value="%X{ClientIPAddress}" />
        <property name="p_20_VirtualServerName" value="%X{VirtualServerName}" />
        <property name="p_21_ContextName"       value="%X{ContextName}" />
        <property name="p_22_TargetEntity"      value="%X{TargetEntity}" />
        <property name="p_23_TargetServiceName" value="%X{TargetServiceName}" />
        <property name="p_24_TargetElement"     value="%X{TargetElement}" />
        <property name="p_25_User"              value="%X{User}" />
        <property name="p_26_logger"            value="${Logger}" />
        <property name="p_27_mdc"               value="${Mdc}" />
        <property name="p_28_message"           value="${Message}" />
        <property name="p_29_marker"            value="${Marker}" />
        <property name="pattern"
          value="%nopexception${p_1_LogTimestamp}|${p_2_EntryTimestamp}|${p_3_InvokeTimestamp}|${p_4_RequestID}|${p_5_InvocationID}|${p_6_InstanceID}|${p_7_ServiceInstanceID}|${p_8_thread}|${p_9_ServiceName}|${p_10_PartnerName}|${p_11_StatusCode}|${p_12_ResponseCode}|${p_13_ResponseDesc}|${p_14_level}|${p_15_Severity}|${p_16_ServerIPAddress}|${p_17_ElapsedTime}|${p_18_ServerFQDN}|${p_19_ClientIPAddress}|${p_20_VirtualServerName}|${p_21_ContextName}|${p_22_TargetEntity}|${p_23_TargetServiceName}|${p_24_TargetElement}|${p_25_User}|${p_26_logger}|${p_27_mdc}|${p_28_message}|${p_29_marker}%n" />
      1. Is the property InstanceUUID or InstanceID ?  I see value="%X{InstanceUUID}

        1. InstanceUUID with an alias of InstanceID

  10. Why are the MDC key-value pairs repeated in field 27?  Data items like client IP address are emitted twice, once in field 19 and again in field 27.  Department of redundancy department?

  11. Addressing above discrepancies hopefully by the end of the academic summit next week.

    The onap spec has moved to dublin - so we can use the previous beijing level spec without changes for casablanca - we will coordinate changes in dublin

    Attempting formal coordination via


  12. Requiring serverFQDN is a throwback to the days when a server ran directly on a bare metal (or virtual) machine.  What is the committee's recommendation on the value to report from a running docker container?  A container really cannot obtain details about the host, see link below. Further in a kubernetes deployment I don't know at all what value might be meaningful.