Skip to content

Use uniform style of logging

Problem description:

Currently there are using different formatting approaches in the logging:

  1. Sample with fmt library:
   OES_ERROR(oes::core::Format(fmt::format("Error: Cannot determine server port: {}\n", ec.message())));
  1. Sample with using only internal oes formatter:
   OES_WARNING(oes::core::Format("Not registered metric. Reason: %1\n") % e.what());

It would be good to make decision which is better and uniform this logging style.

Current usages

  • OES_%LEVEL%(oes::core::Format("")): 283 cases
  • OES_%LEVEL%(oes::core::Format(fmt::format(""))): 65 cases

Performance:

Currently time for logging a message is almost same for cases when it printed or filtered.
This may affect performance when formatting/preparing a log line, even logging level is high, "Info" or "Error".

Benchmark of format string with 5 arguments (release configuration):

  • fmt library: 1171 ns
  • oes internal formatter: 7584 ns

There fmt library is definitely better, but internal formatter also can be optimized.

Error handling

A good logger should not affect application due to formatting issues, should not throw exceptions. Current internal oes formatter has minimal exception safety, it doesn't throw an exception when missed argument. In comparison, missed argument in the fmt library leads to exception. This can be handled if wrap formatting into logging macro.

Proposal

Select one of the formatters, refactor and simplify the logging to one consistent style:

// format string will be related to selected formatter
OES_ERROR("Cannot determine server port: {}", ec.message());
  • Change the macro definitions to avoid explicitly calling the formatter fmt::format() or oes::core::Format().
  • Prevent throwing an exception on formatting issues.
  • Automatically add line break at the end of line ("\n" can be missed by mistake).
  • Remove redundant "Error:" prefix, if already logged with OES_ERROR() - 62 cases.
  • Try to reduce logging time for messages which are filtered by logging level.

Alternative: replace internal logger with one of existing open-source solutions.
Pros: Get a lot of useful features from the box (like logging to file).
Cons: Difficulties with customization/adding new features.