| Table of Contents |
|---|
About This Document
...
| Pipe Order | Name | Type | Group | Description | Applicable (per log file) | Marker Associations | Moved MDC to standard attribute | Removed (was in older spec) | Required? Y/N/C (C= context dependent) N = not required L=Library provided | Derived | Historical | Acumos ref | Use Cases | Code References |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | LogTimestamp | log system | use %d field - see %d{"yyyy-MM-dd'T'HH:mm:ss.SSSXXX",UTC} | L | ||||||||||
| 2 | EntryTimestamp | MDC | if part of an ENTRY marker log | C | ||||||||||
| 3 | InvokeTimestamp | MDC | if part of an INVOKE marker log | C | ||||||||||
| 4 | MDC | UUID to track the processing of each client request across all the ONAP components involved in its processing | Y | In general | ||||||||||
| 5 | InvocationID | MDC | UUID correlates log entries relating to a single invocation of a single component | Y | ||||||||||
| 6 | InstanceUUIDInstanceID | MDC | UUID to differentiate between multiple instances of the same (named) log writing service/application | Y | was InstanceUUID | |||||||||
| 7 | ServiceInstanceID | MDC | C | |||||||||||
| 8 | thread | log system | use %thread field | L | ||||||||||
| 9 | ServiceName | The service inside the partner doing the call - includes API name | Y | |||||||||||
| 10 | PartnerName | unauthenticated = The part of the URI specifying the agent that the caller used to make the call to the component that is logging the message. authenticated = userid | Y | user | ||||||||||
| 11 | StatusCode | This field indicates the high level status of the request - one of (COMPLETE, ERROR, INPROGRESS) | Y | 20180807: expand from 2 fields to add "INPROGRESS" addresses Chris Lott question on https://wiki.acumos.org/display/OAM/Log+Standards | ||||||||||
| 12 | ResponseCode | This field contains application-specific error codes. | Y | |||||||||||
| 13 | ResponseDesc | This field contains a human readable description of the ResponseCode | Y | |||||||||||
| 14 | level | %level | L | |||||||||||
| 15 | Severity | Logging level by default aligned with the reported log level - one of INFO/TRACE/DEBUG/WARN/ERROR/FATAL | Y | level (but numbers) | ||||||||||
| 16 | ServerIPAddress | C | ||||||||||||
| 17 | ElapsedTime | C | ||||||||||||
| 18 | ServerFQDN | The VM FQDN if the server is virtualized. Otherwise the host name of the logging component. | Y | |||||||||||
| 19 | ClientIPAddress | This field contains the requesting remote client application’s IP address if known. Otherwise empty. | Y | |||||||||||
| 20 | VirtualServerName | C | ||||||||||||
| 21 | ContextName | C | ||||||||||||
| 22 | TargetEntity | The name of the ONAP component or sub-component, or external entity, at which the operation activities captured in this metrics log record is invoked. | C | |||||||||||
| 23 | TargetServiceName | The name of the API or operation activities invoked (name on the remote/target application) at the TargetEntity. | C | |||||||||||
| 24 | TargetElement | VNF/PNF context dependent - on CRUD operations of VNF/PNFs The IDs that need to be covered with the above Attributes are - VNF_ID OR VNFC_ID : (Unique identifier for a VNF asset that is being instantiated or that would generate an alarms) - VSERVER_ID OR VM_ID (or vmid): (Unique identified for a virtual server or virtual machine on which a Control Loop action is usually taken on, or that is installed as part of instantiation flow) - PNF : (What is the Unique identifier used within ONAP) | C | |||||||||||
| 25 | User | MDC | User - used for %X{user} | C | ||||||||||
| 26 | p_logger | log 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 | L | ||||||||||
| 27 | p_mdc | log system | allows forward compatability with ELK indexers that read all MDCs in a single field - while maintaining separate MDCs above. The key/value pairs all in one pipe field (will have some duplications currently with MDC’s that are in their own pipe – but allows us to expand the MDC list – replaces customvalue1-3 older fields - this field is %mdc | L | ||||||||||
| 28 | p_message | log system | The marker labels INVOKE, ENTRY, EXIT – and later will also include DEBUG, AUDIT, METRICS, ERROR when we go to 1 log file - this field is %marker | L | ||||||||||
| 29 | p_marker | log system | The marker labels INVOKE, ENTRY, EXIT – and later will also include DEBUG, AUDIT, METRICS, ERROR when we go to 1 log file - this field is %marker | L |
...
- It's only a few calls.
- It can be largely abstracted in the case of EELF logging.
MDC - InstanceID
(formerly InstanceUUID)
If known, this field contains a universally unique identifier used to differentiate between multiple instances of the same (named) log writing service/application. Its value is set at instance creation time (and read by it, e.g., at start/initialization time from the environment). This value should be picked up by the component instance from its configuration file and subsequently used to enable differentiation of log records created by multiple, locally load balanced ONAP component or subcomponent instances that are otherwise identically configured.
...
- There is considerable duplication:
- BeginTimestamp, EndTimestamp, ElapsedTime. These are all captured elsewhere (and ElapsedTime is even redundant within that triplet).
- Server, ServerIPAddress, ServerFQDN, VirtualServiceName. Overkill. Should be one, plus optionally ClientIPAddress (or some variant thereof).
- TargetEntity, TargetServiceName, not obviously different to similar attributes.
- There is junk:
- Severity? Nagios codes?
- ProcessKey?
- All the stuff that's already grayed out in the table above.
- People may defend these individually, maybe vigorously, but they're domain-specific:
- That absolutely doesn't mean they can't be used.
- Beats configuration allows ad hoc contexts to be indexed.
- But perhaps they don't belong in this kind of spec.
- Redundant attributes *do* matter, because:
- Populating and propagating everything prescribed by the guide approaches being prohibitive. People won't do it, and people *don't* do it.
- If something might be in one of several attributes then that's worse than it being in just one.
- That means:
- We're left with only two MANDATORY attributes, necessary to build invocations graphs:
- RequestID - top-level transactions.
- InvocationID - inter-component invocations.
- And a minimal number of OPTIONAL descriptive attributes: ServiceInstanceID, InstanceUUIDInstanceID, Server, StatusCode, ResponseCode, ResponseDescription.
- Those are the ones we need to document clearly, support in APIs, etc.
- That's <=10, a manageable number.
- And again, that matters because if the number isn't manageable, people won't (and don't) comply.
...
Note there are 3 tabs (see p_mak in logback.xml) delimiting the MARKERS (ENTRY and EXIT) at the end of each line
<property name="p_mak" value="%replace(%replace(%marker){'\t', '\\\\t'}){'\n','\\\\n'}"/>| Code Block | ||||
|---|---|---|---|---|
| ||||
2018-07-05T20:21:34.794Z http-nio-8080-exec-2 INFO org.onap.demo.logging.ApplicationService InstanceUUIDInstanceID=ede7dd52-91e8-45ce-9406-fbafd17a7d4c, RequestID=f9d8bb0f-4b4b-4700-9853-d3b79d861c5b, ServiceName=/logging-demo/rest/health/health, InvocationID=8f4c1f1d-5b32-4981-b658-e5992f28e6c8, InvokeTimestamp=2018-07-05T20:21:26.617Z, PartnerName=, ClientIPAddress=0:0:0:0:0:0:0:1, ServerFQDN=localhost ENTRY 2018-07-05T20:22:09.268Z http-nio-8080-exec-2 INFO org.onap.demo.logging.ApplicationService ResponseCode=, InstanceUUIDInstanceID=ede7dd52-91e8-45ce-9406-fbafd17a7d4c, RequestID=f9d8bb0f-4b4b-4700-9853-d3b79d861c5b, ServiceName=/logging-demo/rest/health/health, ResponseDescription=, InvocationID=8f4c1f1d-5b32-4981-b658-e5992f28e6c8, Severity=, InvokeTimestamp=2018-07-05T20:21:26.617Z, PartnerName=, ClientIPAddress=0:0:0:0:0:0:0:1, ServerFQDN=localhost, StatusCode= EXIT |
...