feat(log): Don't write time if logging to journald

[Bravo555]

Proposed changes

Journald already records the timestamp of each log and allows the user to easily customise the format using journalctl's --output flag, and to filter the logs using --since/--until. So only format time if not logging to journald.

Before:

After:

In this PR, while we use tracing-journald to detect if we're logging to journald and change our formatting based on that, we aren't yet fully using its functionality to send structured logs containing log levels and fields, because the default formatting of the journald's MESSAGE field (i.e. the log message shown by journalctl after the timestamp and identifier) does not format attached fields and the target to be present in the message.

Given an event like this:

info!(field = 42, "event happened");

our current logging to stderr gives us this:

Apr 30 08:27:10 32df1eef46c8 tedge-mapper[399038]:   INFO tedge_config::system_toml::log_level: event happened field=42

Logging with journald gives us this:

Apr 30 08:30:26 32df1eef46c8 tedge-mapper[406816]: **event happened**

Though field are accessible when selecting a more verbose output level:

{
        "_HOSTNAME" : "32df1eef46c8",
        "_SYSTEMD_INVOCATION_ID" : "192c32fe9c8f4fdf9dd20a9667569419",
        "_CMDLINE" : "/workspace/target/debug/tedge-mapper c8y",
        ...
        "CODE_FILE" : "crates/common/tedge_config/src/system_toml/log.rs",
        "__MONOTONIC_TIMESTAMP" : "196768238204",
        "MESSAGE" : "event happened",
        "CODE_LINE" : "66",
        "F_FIELD" : "42",
        "_PID" : "406816",
        "SYSLOG_IDENTIFIER" : "tedge-mapper",
        "_GID" : "995",
}

Given that this is a change from the current behaviour where in some cases we assume that the field should appear next to the message where it's relevant, which could be surprising to the users, we will still log to stderr and only switch once we can put embed relevant fields into the message.

There are some proposed solutions (tokio-rs/tracing#3474), but they haven't been merged yet.

Still, one nice thing about logging to journald is that information relevant to debugging, like CODE_FILE and CODE_LINE are attached to the logs by default and can be shown with --output json-pretty/verbose and at the same time they don't have to shown to users by default. With these and other fields it can make our debugging easier while not making logs too noisy for the users.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s. You can activate automatic signing by running just prepare-dev once)
• I ran just format as mentioned in CODING_GUIDELINES
• I used just check as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[codecov]

Codecov Report

❌ Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...s/common/tedge_config/src/system_toml/log_level.rs	77.77%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.