harden drives api and improve logging

[micbar]

Description

We improved the logging of several http services. If possible and present, we now log the X-Request-Id.

Logging Documentation

In ocis, we have the following log levels

FATAL

FATAL means that the application is about to stop a serious problem or corruption from happening. This level of logging shows that the application’s situation is catastrophic, such that an important function is not working. For example the application is unable to connect to the data store due to config errors or not able to parse the config

ERROR (default setting, OCIS_LOG_LEVEL=error)

This is the default log level, all errors on this level are important for admins because they need to fix them. This log level is used when a severe issue is stopping functions within the application from operating correctly. Ocis logs all kind of inter service communication errors on this level because these needs to be addressed.

WARN

The WARN log level is used when ocis detects an unexpected failure during an operation. It is also used if some operations might be incomplete. It does not mean that the application has been harmed, the code should continue to work as usual. Admins should eventually check these warnings just in case the problem reoccurs.

INFO

Messages on this level are documenting the normal behavior of applications. They state what happened. These entries are purely informative to confirm that the application is working as desired. The info log level also enables the ocis Proxy to write a full access log.

DEBUG

This log level provides diagnostic information in a detailed manner. It is verbose and has more information than you would need when using the application. This log level is used to understand problems in the application and during reproduction of problems. This log level could put a very high load on the output device and is not recommended in production environments. You should consider enabling this level only on a single service or very few services to pinpoint issues or bugs.

To do

• Drives API
• User API
• Groups API
• Thumbnails API
• Search API

Motivation and Context

Increase the debuggability of the stack

How Has This Been Tested?

• test environment:
• test case 1:
• test case 2:
• ...

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[micbar]

@michaelstingl FYI

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
7 Code Smells

8.8% Coverage
15.5% Duplication