• Refactoring the patterns in logback.xml - (ONAP and Acumos) - plus implications for teams
    • Lorraine and I started aligning the patterns in logback.xml last thursday in the acumos meeting - however we all need to discuss this and the implications
    • currently
      • acumos -

      • onap - ONAP Application Logging Specification v1.2 (Casablanca)

         <property name="pattern" value="%nopexception${p_tim}|%X{EntryTimestamp}|%X{InvokeTimestamp}|%X{RequestId}|
        |${p_msg}%n" />
        InstanceUUID=1ff4ba60-4b23-4e81-a5fc-0b8055bbf1de, RequestID=7ddbb889-0c6d-418e-b59a-df0450e57d76, 
         InvocationID=e16e8b3e-01c6-4578-a3fc-d802ab31d91a, InvokeTimestamp=2018-08-27T14:08:47.233Z, 
        PartnerName=, ClientIPAddress=,
        |Running /health

    • onap and acumos teams are looking for a standard logback.xml - see
      • However we have the following considerations
      • Moving MDC attributes to standard attributes (defined in logback.xml)
      • (Yes pipe) pipe/tab delimited - portal and a lot of onap is still pipe (align with acumos where pipes are used)
        • plan for migration needs pipeline change
      • implications for the pipeline yml in elasticsearch
      • implications for our and other logging libraries in use - setting these field as mdcs or standard attributes
      • (Yes for single) A single pattern for all 4 log files (debug, error, metrics, audit)
      • Acumos reference
      • !) Log levels are still as defined in the spec (INFO/TRACE/DEBUG/WARN/ERROR/FATAL) no fine/finer/finest
      • What to do with application.log (it is the default for a lot of components - but is being migrated to audit.log)
        • plan: for code migration - ie portal/sdk application logs that would break if application appender is removed
          • move app to audit? yes
        • Do we make audit.log the default (info logs)  - yes
        • Adjust msg to Message
    • migration story
    • default log level - still info (yes)
    • Note p_log (logger field (one of debug,audit etc) - not needed once markers is implemented - markers only available via Luke's slf4j lib currently 
      • for now hardcode the name in the 4 pattern strings
    • default debug state true/false (default should be false) 
      • need to test if changing a onap/values.yaml helm variable requires a bounce of the container (–set component.enabled=false/true)

single logback.xml for all of OOM - is this feasible (yes going ahead with it) -  LOG-630 - Getting issue details... STATUS  - lowers config map size issue


LOG-631 - Getting issue details... STATUS



logback.xml rework

Answer serverFQDN question from Dave - ONAP Application Logging Specification v1.2 (Casablanca)#Logback - testing on clustered system to see if becomes dev0/dev1

  • No labels


  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.

      <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

  2. TODO working with Prudence Au 

    LOG-635 - Getting issue details... STATUS

    LOG-634 - Getting issue details... STATUS