This has been approved as a best practice for Jakarta.


General feedback is that the first iteration of these fields were focused on transactional events.  However there are other logging situations that are not transactional such as debug / informational logging.  So, some of the tweaks below are to make the fields fit a more general case.

NOTE:  The fields below should be outputted in the order indicate if the output format is positional like CSV.

CPS Implementation: CPS-986 - Getting issue details... STATUS

OrderField NameProperty NameDescriptionEELF FieldLog Spec FieldReferenceCPS Logging Field POC
GREEN FIELDS: Best Practice for Jakarta: Existing Fields Recommended

The container and container application MUST log the field “date/time” in the security audit logs. 

The value should be represented in UTC and formatted per ISO 8601, such as “2015-06-03T13:21:58+00:00”. The time should be shown with the maximum resolution available to the logging component (e.g., milliseconds, microseconds) by including the appropriate number of decimal digits. For example, when millisecond precision is available, the date-time value would be presented as, as “2015-06-03T13:21:58.340+00:00”.





v1.3 Spec

2Log Type NamelogTypeName

The container and container application MAY log the field "Log type" in security audit logs.

This field will adhere to the following ENUM ::= "AUDIT" | "METRICS" | "ERROR" | "DEBUG" | ""

This is here for legacy purposes.  Older projects used to generate 4 separate log files.  However since projects now will output all logs to STDOUT and STDERR this field is here to give projects adhering to the old standard a way to specify those log file types.

NOTE: This field is optional but a placeholder is still required to be outputted.  That is why the "" is included in the ENUM.



3Log LevellogLevel

The container and container application MUST use an appropriately configured logging level that can be changed dynamically.

The intention of this field is to not cause performance degradation via excessive logging. 

This field will adhere to the following ENUM ::= "FATAL" | "ERROR" | "WARN" | "INFO" | "DEBUG" | "TRACE"

The verbosity of the logging increases from left to right.

Category Log LevelLevel




Trace ID


The container and container application MUST log Trace ID

A trace ID is a universally unique value that identifies a single transaction request or a series of related log events within the ONAP platform. Its value is conformant to RFC4122 UUID. This value is readily and easily obtained in most programming environments. 

Request IDTransaction ID

v1.3 Spec


5Status CodestatusCode

The container and container application MUST log a "status code" in the security audit logs. 

This field indicates the high level status for transactional, APIs calls, or sub operational events.  

This field will adhere to the following ENUM ::= "SUCCESS" | "INPROGRESS" |"FAIL_WARN" | "FAIL_ERROR" | "FAIL_FATAL"

  • SUCCESS when the operation is successful.  This represents a normal case.
  • INPROGRESS for states that are not COMPLETE or one of the FAIL_* enums.
  • The following ENUMs represents when an event is not successful or abnormal / failure cases.
    • FAIL_WARN: Indicates that something has not worked as it should.  Program operation may continue without issue but depends on the particular circumstances of the execution environment.
    • FAIL_ERROR: Indicates that something serious has gone wrong.  Program may be recoverable through error routines.
    • FAIL_FATAL: Also indicates that something serious has gone wrong but is not recoverable.

From an end user perspective these categories should not be considered strict due to the absence of contextual information of holistic operations. There may be some circumstances where FAIL_WARN may be more serious than FAIL_ERROR.  Regardless, from a developer view, FAIL_WARN, FAIL_ERROR, and FAIL_FATAL should be viewed as increasing importance and understand that the end user will need to provide additional context for their comprehension and execute and potential action from the particular failure.

Status CodeStatus Code


v1.3 Spec


6Principal IDprincipalId

The container and container application MUST log the Principal identity of a requestor in the security audit logs. 

This field should contain the identification of the entity (user agent, client id, user, user id, login ID, non-person entity (NPE), Token,  etc.)  that made the request of the service or API indicated in the Service/Program Name field. For a serving API that is authenticating the request, this should be the authenticated username or equivalent.

NOTE: The CPS project uses a framework that provides this field. 




v1.3 Spec

7Service / Program NameserviceName

The container and container application MUST log the field “service or program used for access” in the security audit logs.

This intention is to capture the service name endpoint or an externally advertised API invoked, e.g., where are you connecting to. This is represented as a URI or URL. 

NOTE: The CPS project uses a framework that provides this field. 



v1.3 Spec


8Log MessagemessageThe free text payload of a log event. 



OrderField NameDescriptionEELF FieldLog Spec FieldReference
YELLOW FIELDS: This fields are not part of the best practice.  They are a work in progress and are intended to be added to generated logs via a logging architecture.

Container Image Name / Tag

The container and container application MUST log the Container Image Name/Tag.

The image name/tag is as returned by the docker images command.

NOTE:  Images are not required to have tags


Container Image Digest

The container and container application MUST log the container image digest.

The digest is a cryptographic digest as returned by the docker images --digests command.

N/AN/AT1036, T1525

Container ID

The container and container application MUST log the container ID.

The container ID is the same that is returned by the docker ps -q command.

NOTE: The container ID is unique for life time of the the container instance. Once the container is killed, this ID goes away.


Role / Attribute ID

The container and container application MUST log the Role or Attribute ID of the Principal identity of the entity accessing the requested service or API.

Note: The group ID is in reference to a Role or Attribute as part of a RBAC or ABAC scheme.

3/4/2022: Team decided this field is out of scope for yellow fields for now.  Potentially revisit for a later phase. 

  • This is a nice to have for forensics purposes.  Although this field could be looked up, in the course of a forensics investigation this information may no longer be available. 
  • Also, it is undecided that this field belongs in the yellow fields or green fields.


The container and container application MUST log the field “protocol” in the security audit logs.

This refers to the communication mechanism for a request.  The value of this field should be representative of the OSI application layer  protocol. This is represented as a decimal formatted TCP/IP port number.



Green Fields: Fields or data that is within the scope of a single ONAP sub-project

Yellow Fields: 

Fields or data that is broader in scope than a single project.  Maybe contain data that is only available at the container or orchestration level. Also may contain data that involves multiple ONAP sub-projects.

Results from comparison of existing logging

  • No labels


  1. Hello, I think there are two differents (and it's clear on the presentation shown at PTL) meeting:

    • the "application" part, which is fine for me and should be enforced accross all projects
    • the "platform" part, where for me the field seems also to be good (although I don't know how to simply retrieve Role / Attribute ID and Principal ID)

    But, I'm not at all in favor of mandating them (the platform ones).

    My main reason is that ONAP is a tool which will be deployed on a Kubernetes and the responsibility of the platform may not be in the hand of the ONAP deployment team.

    I would then prefer that we not put "must" but "should" on these one but highlight a  lot the benefits.

    An example on how it could be done with a reference implementation could be also given.

    • I reworked the above table to be more representative of the slides presented. Green for existing fields and yellow for the New fields.
    • Principal ID is user as specified in the LogSpecs v1.2.
    • Still processing the green field vs yellow fields comments.
  2. Sylvain Desbureaux After considering your comments, I think a sensible path forward would be to move forward with the green fields as a Best Practice for Jarkarta. There are good security reasons for including the yellow fields and other PTLs have commented that they believe they are important as well.  However, there is the excellent point you brought up on how applications access those fields.  So, I think the best path forward would be to work a POC for the yellow fields and if successful put forward as a Best Practice proposal for the K release. Do this seem reasonable?

  3. Robert Heinemann , Toine Siebelink  - The ENUM on statuscode - "SUCCESS" | "FAIL_WARN" | "FAIL_ERROR" | "FAIL_FATAL" is too restrictive. Log status could be information and also in-progress. Rather than defining separate status code, consider possible alignment with HTTP status code. Otherwise the structure/fields (defined under "green section") looks fine to me. 

  4. Thanks Vijay Venkatesh Kumar I added the inprogress to the enum.  I believe if we align the to HTTP status codes that it will make the use of this field to be more specific to HTTP requests.  We are trying to make the field to cover general cases like debug log which wouldn't be transactional in nature.