DC 5.5 - Logs

With Digizuite 5.5 a brand new log system has been introduced. The system utilizes a set of third party tools for logs.

  • Loki

  • Promtail

Loki is a log aggregation system which aggregates and indexes all incoming logs thereby making them searchable. Promtail is a log file reader, which reads the physical log files from disk and sends it to Loki.

On top of this there has been build a simple log UI in MediaManager, while more advanced features are available in Grafana.

This documentation explains the simple log UI in MediaManager. Grafana is out of the scope of this documentation.

Media Manager log ui

The Media Manager log ui is located under Settings/Logs. In order to see this, the user must have the role Can_view_logs.

The log UI looks like this:

There are basic filter functionality available in the left hand side and the table can be expanded with more information such as a developer stack trace.

Trace and span ids

The UI is intuitive enough to leave further exploration up to the reader. There are, however, two very important concepts to understand when using this UI

  • Span ID

  • Trace ID

These IDs are used to identity the request / span in which the potential errors are.

To best explain what a Trace and a Span is, we use Upload as an example.

Uploading assets is not just uploading the asset. This spawns many smaller things which has to be handled like uploading the security and the indexes etc.

The API for uploading the asset is called UploadAsset and if we are interested in only knowing what happened in the API call, but not all the other things which was spawned by the API call, we use the Span ID. If on the other hand we can see that Solr is not updating correctly for new uploads, we can grab the Trace ID from the UploadAsset API call and there by get the entire trace.

So the Span ID contains only the logs for the API call it self, where as the Trace ID contains the entire trace of things spawned by the API Call.

The Trace and Span IDs are always parsed in the response headers of the requests and these may be inspected in the developer console of any browser. Here is an example of how the Span and Trace ID looks in Chrome:

In the specific example we have the following Span and Trace Id

00-b8ca49b44206984d85f703a759da533b-147613c346cad34a-01

Where the first part: b8ca49b44206984d85f703a759da533b is the Trace ID and the latter part: 147613c346cad34a is the Span ID.

These Span and Trace IDs follows a standard from OpenTelemetry.

Changing the log level

Should more logging be required, then it is possible to increase and/or decrease the amount of information being written to disk. This follows the same pattern as always with the following posibilities:

  • Trace

  • Debug

  • Information

  • Warning

  • Error

  • Critical

  • None

With Trace writing the most information and None writing (as the word suggest) nothing at all.

Each service has it’s own log file. For the Digizuite core services (i.e. everything in the webs in the folder /DigizuiteCore), we refer to the following documentation.

For the old code (DAM Center) there is a file in each folder called AppSettings.logging.json where the log level can be changed.

Please note this must be done for the service in question. Often times that means you should do it for the file in the folder /dmm3bwsv3, rather than the one in the root.

You can always figure out which folder it is needed in by following the path of the request.

For example a request looking like this

https://../dmm3bwsv3/SearchService.js?searchName=..

goes to the dmm3bwsv3 service and for that reason you must change the appsettings.logging.json file in the folder /dmm3bwsv3.

where as a request looking like this

https://../DigizuiteCore/LegacyService/api/metadata/editor

goes out to the LegacyService and as such must be changed in the appsettings.json file in the folder /DigizuiteCore/LegacyService.