-
Epic
-
Resolution: Unresolved
-
Highest
-
None
-
Standardized logging fields
-
Best Practice (new code only)
-
4
-
Not yet performed
-
Original Scope
-
M
-
GO
-
Not used for this release
-
Not used for this release
Description of Use Case / Requirement:
ONAP containers SHALL include the following metadata (event attributes) with log messages for Java-based containers.
| Field Name | Property Name | EELF Field Name (ecomp_logger) |
Logging Analytics Field Name |
|---|---|---|---|
| Timestamp | logTimeStamp | BeginTimeStamp or Timestamp |
LogTimeStamp |
| Log Type Name (optional) |
logTypeName | N/A | p_marker |
| Log Level | logLevel | Category Log Level | Level |
| Trace ID | traceId | RequestID | TransactionID |
| Status Code | statusCode | Status Code | Status Code |
| Principal ID | principalId | PartnerName | User |
| Service / Program Name | serviceName | ServiceName | ServiceName |
| Log Message | message | detailMessage | p_message |
- This list of fields is not meant to be exclusive. Logs may contain other metadata in addition to the above prescribed.
- EELF/Log Analytics Compliance with London Global Requirement (GR)
- If you have a container that adheres to either the EELF or Logging Analytics format, then the container is logging fields that are relevant for security logging (as indicated by the above table). So from a compliance standpoint to the Security Logging GR, you would be in compliance from that aspect.
- PREFERRED: It would be preferred if the property names were normalized to what is documented in the "property name" column above.
- Log Format
- This requirement does not specify a log format.
- FIRST PREFERENCE: It would be preferred to output into a JSON format. The CPS logback.xml file can be used for Java-based containers as an example.
- SECOND PREFERENCE: would be name, value pair, e.g., "propertyName:<propertyName>, "
- Such as, logTimeStamp:<logTimeStamp>, logTypeName:<logTypeName>, logLevel:<logLevel>, traceId:<traceId>, statusCode:<statusCode>, principalId:<principalId>, serviceName:<serviceName>, message:<message>
- Please note that some of the field values are stated enumerations. See the more info link below for specifics.
- LEAST PREFERED: would be position-based formats.
- This requirement does not specify where logs are to be outputted. However, there is an existing global requirement since Jakarta specifies logging to STDOUT and STDERR (SEE: https://jira.onap.org/browse/REQ-441).
- DOCUMENTATION
- This requirement strives to ease impact across projects. Recognizing that there is legacy logging code, flexibility is afforded for implementation. As a result, projects will need to provide documentation on docs.onap.org on what is the logging format the container is using. The logging architecture that will ingest these logs requires this information to be documented.
More Info:
https://wiki.onap.org/display/DW/Jakarta+Best+Practice+Proposal+for+Standardized+Logging+Fields **
Should be the Assignee - use @ notation): rheinemann , zwarico ,
Link to HLD/LLD (if any):
Dependency Relationships with Other Projects:
Project Impact (Test Only (TO), Code (C)): C **
Support Status for each Affected Project (Supported (S); Partially Supported (P); Not Supported (N)):
Note: for any affected projects labeled 'P' or 'N', please document the resulting gaps.
Integration Leads (use @ notation):
Company Engagement:
- is blocked by
-
REQ-1341 Standardized logging fields - Java London release
-
- To Do
-
-
-
- To Do
-
- relates to
-
CPS-869
Apply Standardized logging fields to adhere to ONAP Best practice REQ-1072
-
- Closed
-
-
REQ-441
LOGS MANAGEMENT - PHASE 1: COMMON PLACE FOR DATA
-
- To Do
-
- mentioned in
-
Page Loading...
-
-
-
-
-
-