String

id

Technical id for the log record

This can be set by the client (if trusted to care for uniqueness) or be omitted and set by the client. The server allow the id to be reused (=update) for semantics like records of timespans (like, e.g., sessions). Proposed algorithm is UUID.

Header Fields, meta data of each record

String

recordType

Type of the record.

This is an unbounded enumeration, it’s free to select from the solution; anyway, it is recommended to use a known value (see subpage) to make recognition of the semantics of the record easier. Record types can be shared between solutions, e.g. session, activity and techInfo are record types that are used by applications. The record type is used for partitioning the CLJ data stores for the permission system, as well as a key in defining retention periods and archiving strategy.

String

recordSubType

Additional field to identify the event

Can be used as a type of the source log record. For example, if the recordType is 'serverLog', the recordSubType could be "tomcat" oder "weblogic".

String

tenant

Institute number

If needed, for organizations serving multiple iurisdictional tenant, this is the tenant code.

String

environment

Environment identifier

If needed, when the development, test, staging, production etc. environments are not separted by dedicated data store instances but merged in one, this identifier determines from which environment a log record originates.

DateTime-WithFractionSeconds

recordTimestamp

When the log record has been created

If the client does not provide this, or the given value cannot be parsed on server side, the processing engine will create a timestamp as next best guess.

Long

sequence

Determines order

Often the record timestamp is not sufficient to discriminate and order a set of logrecords. E.g. ElasticSearch does not care for finer granularity than miliseconds. In this case the sequence field could store micros or nanos. Another possibility to use this field is that a client can care for a gapless sequence to be sure that no records are lost during transmission, procession and retrieval. A logging front-end can use this field as sole default order attribute or as secondary order attribute after recordTimestamp.

String

logLevel

Level of importance, as provided by many low-level logging systems

This field is optional, it is also not normalized, meaning that whatever the client solution provides here will be taken as-is. A lot of logging libraries have their own mind on this topic.

User Info, information about the person or technical systems connected to the log record

String

user

Unique user id in its userType domain

This identifies the user or system uniquely within the domain given in "userType". This value gets more gain in the context of current data protection laws.

String

userType

Domain this user account belongs to

Needed if different user domains should be distinguished — like internet users (customers) and intranet users (employees). Or when user domains ob subsidiaries are not clearly separated by the user ids.

Source Info, which component wrote this log record

String

solutionCode

Unique identifier of a solution

Identifies the Solution as unit in the IT landscape.

String

solutionFunctionCode

Id of functional building block

If needed, more fine-grained organizational partitioning.

String

sourceApplication

Building block

More technical/architectural paritioning key.

String

sourceHostname

System name of the server initiating the logging call

e.g. DNS of physical or virtual system

String

sourceIp

Client IP, originator of the log

The value might differ in regard of the nature of the originator (e.g. a browser-based application, or a batch)

String

userAgent

Software that initiated the call

This field is used when the software and its version of the user/client is relevant. e.g. In web front-ends this identifies the Browser that has been used. The writing solution can give any information if it thinks that information about its caller makes a difference.

String

agentVersion

TODO

deprecated, might be removed in the future.

String

serverInstanceName

Identifies the server instance

e.g. the docker pod

Initiating solution

String

clientId

Code from initiating system

Inititiating systems are mostly user front-ends or batch processes.

Harvesting Info, where was the log record first persistet, might be different from the source solution

String

sourceType

Syntax of the incoming data

Syntax of the incoming data (into the messaging brick). 'generic' means using this data model in JSON, this is the default value. If the syntax is not 'generic' the central logging service might be able to to a proper transformation.

String

loggingHostname

Server Host Name

like sourceHostname

String

loggingHostIp

Server IP address

The system that provided the logging information, e.g. Apache host for access logs, or any other harvisting service running logstash, fume, rsyslog or a similar tool.

String

logFile

file name and path from which the log record has been harvested, if applicable

If logrecords are not sent directly to the messaging building block, but harvested from a logfile (by Logstash or a similar software) here this filename and path of the appropriate format (Windows, Unix, Mainframe, …) can be sent if needed.

Context

String

parentId

Hierarchical predecessor of this log record.

Could be of a functional or sequential order Here a key of a hierarchical higher-level record can be set. So a tree-like structure of log records can be created.

String

contextId1

Mapping context id field 1

Example: The id of a user session.

String

contextId2

Mapping context id field 2

Example: The (use case) id of a user’s activity.

String

contextId3

Mapping context id field 3

Example: The id of a explicit technical log record.

String

contextId4

Mapping context id field 4

DateTime-WithFractionSeconds

startDate

Start date of the record

For journalling records that have a time span, this field of the event signals the begin timestamp.

DateTime-WithFractionSeconds

endDate

End date of the session

For journalling records that have a time span, this field of the event signals the end timestamp.

String

correlationId

Correlation ID for a synchronous or quasi-synchronous call

Unique Id that is created as early as possible (ideally by the initiator) and then guided through the whole call hierarchy to create traces of calls.

Unstructured and semistructured data

String

message

Log Message

All the information that is not part of other fields

String

additionalInfo

semi-structured data

Business or other data. Technically this is a text field. It is recommended, though, to use JSON syntax, because the front-end can interpret it and display a tree structure. Special Case of additionalInfo: External Links. This can be rendered in the UI as Link with following Syntax: additionalInfo.extlink.ref : The URI for the external Link; additionalInfo.extlink.name : The DisplayName for the Link.

Result section

String

resultCode

Code if the record represents a task of any kind

HTTP record code, Exception, Error

String

errorMessage

Error Message

Any standardized code or message the sending solutions wants to log.

Boolean

businessError

Business Error

Sometimes business errors are stored as normal messages. It is up to the application to decide which message is a business error or a message. This value should be true for business errors

Status

normalizedStatus

Status field red/yellow/green

This field is for the user, giving a hint about whether this log record represents ok status, a warning or an error. enum Status { red yellow green }

Technical information

String

thread

Name of the server thread

String

logger

Software origin

Name of the class and method(optional) which logs this message

Long

durationMs

Duration of a call in milliseconds

String

logProcessingError

StackTrace of the log processing error.

This is not provided by the client solution but used if anything goes wrong in CLJ log record processing.