Skip to main content

Logging

Note

When we certify an ECR we demand that the ECR is equipped with a good enough logging to make troubleshooting in the future easy and accessible

Why does logging require a page on its own?​

Logging is a crucial part of maintaining the performance and security of your ECR. Its helping you identify and troubleshoot issues effectively. This page will give you best practices and examples for implementing logging in your ECR.

We have been apart of way too many integrations where the logfile of the ECR is filled with shattered textfields, no timestamps, zero structure, etc. So we need to shine some light on this subject to help us, and you to troubleshoot issues in the future.

The structure of your logs​

A well-defined log format ensures consistency which then results in an easier time when parsing a log. Consider using a structured format like:

  • JSON
  • XML
  • CSV
  • YAML
  • MARKDOWN
  • or a standardized log message pattern.

They are all accepted and we are looking forward to seeing how you log your communication! :)

What should the logs look like?​

This example shows you a log that clearly defines where the message originated, what kind of message it is and its contents in an unaltered form:

Good looking log

```text Test ```

Here is an example of a practically unusable logfile

  • No identification of who sends and receives the data.
  • Not any clear and readable timestamps.
  • No IP/PORT of the ECR and Terminal.
  • Scrambled data-elements. The values doesn't correlate to the data-elements.
Worse looking log

Effort put into good logs is never wasted!