This section provides some examples of clients that could be using the LogObject. The first example is a possible standard diagnostic Client, the second example is of a possible analytic engine.
The diagnostic Client may monitor the general health of a system through status summary information that is outside of the scope of a LogObject. This might be HealthStatus information defined in the DI specification, or diagnostic information define in the UAFX specifications.
When a maintenance worker or engineer discover some problem, they can access a diagnostic Client to trouble shoot the issue. The diagnostic Client can call GetRecords from the Server(s) that are reporting an issue. The records should provide detailed information allowing the maintenance worker / engineer to diagnose and correct the issue. Typically, this C lient would filter and/or sort the information provided by the GetRecords Calls. It might also combine information from multiple Servers. The Client might allow the maintenance worker / engineer to search for specific information.
The Client would only connect to a Server when there is something to troubleshoot.
Figure B.1 - Diagnostic Client Illustration
If a system contains very small devices (with minimum storage), the diagnostic Client might periodically connect the small devices and collect the LogRecords. As an alternative the small device might just generate Events for the LogRecords and let some larger device or the diagnostic Client collect them. The diagnostic Client could store the collected records for a longer period, allowing the maintenance worker / engineer to review a longer history.
Note: Time Syncing functionality is required in OPC UA products, but end user might not enable it, in which case any dianostic Client or analytical engine should check the time on devices to which they are communicating and validate the time on that device.
An analytic engine would periodically collect all LogRecords and store them for analytics.
The diagnostic information may be collected in a cloud environment, where it can be analysed. This may be for predictive maintenance or for process optimization. The LogRecord Structure provides fields that can help an analytics engine, by providing correlation information between various Servers (TraceContext), and also the support for the grouping of information inside of a Server (TraceContext).
Figure B.2 - Analytics client illustration
OpenTelemetry Mapping (Normative)
OpenTelemetry is described as “a vendor-neutral open source observability framework for instrumenting, generating, collecting, and exporting telemetry data such as traces, metrics, and logs.” This modern system includes an infrastructure for collecting trace / metrics / log data, but this infrastructure may be too resource intensive for constrained devices. In these cases, it would be useful to be able to collect log / trace information and import it into the OpenTelemetry system.
In OpenTelemetry, a client triggered action can be assigned a globally unique Trace_Id. This Trace_Id is maintained for all actions related to the client request. In addition, actions are grouped using a unique Span_Id. This Span_Id might be promoted to a Parent_Id, when a tree of related trace / log message needs to be generated. This process is illustrated in Figure C.1. The Span_Id in OPC UA is an UInt64, and it should be unique inside of a TraceId inside of an application. An easy manner of achieving this is to just increment an UInt64 and persist the last value across the application.
Figure C.1 - OpenTelemetry Mapping to OPC UA
Figure C.1 also illustrates how an OpenTelemetry system could collect LogRecords from an LogObject C.2 describes part of the mapping an import tool would have to perform to convert LogObject LogRecords to OpenTelemetry records.
If an OpenTelemetry system is ingesting LogObject LogRecord, the collector will need to pull information from the TraceContext field. This structure contains the Trace_ID and SpanId, It might also contain ParentSpanId( if one was provided). The SpanId field is used to group LogRecords together. If the SpanId field is null, then for each unique entry in the GroupingId field, the import tool shall generate a unique SpanId.
Bibliography
https://datatracker.ietf.org/doc/html/rfc5424
OpenTelemetry – Open Telemetry Overview
https://opentelemetry.io/docs/https://opentelemetry.io/docs/
__________