Logging

Background

To make logging process consistent across Iroha applications logging process should be introduced and logging format should be defined.

Action items

1. Nikita Puzankov write RFC 
2. DevOps team - review it
3. Nikita Puzankov move RFC to ADR

Problem

Unstructured logs are hard to monitor, analyze and process automatically.

1. Logs should be printed to stdout and stderr.
2. Log-level (verbosity) should be changeable in runtime, example: system signal (e.g., SIGUSR1, SIGHUP) to reread configs(env variable)  and change the log-level.

Solution

Log macroses can log function arguments and result, using https://tools.ietf.org/html/rfc5424 or newer.  Nowadays de facto standard for log is JSON.

LEVEL DATE_TIME function_name[start]: arguments
LEVEL DATE_TIME function_name[end]: result

Example:

DEBUG - 2020-08-04 08:09:40:759899847 - request[start]: 
DEBUG - 2020-08-04 08:09:40:759961514 - self = Client { public_key: PublicKey { digest_function: "ed25519", payload: "[1E, 0, 33, 8A, D, 96, B, B4, 4D, 9E, 7F, 3A, C1, 3C, A, 5D, 89, BF,
  31, 8A, F8, 76, E2, FD, 15, 50, EE, 28, C5, EE, 9E, 63]" }, torii_url: "127.0.0.1:45371" },

Decisions

• Use https://github.com/rust-lang/log as logging facade
• Define own logger implementation
• use `#[log]` macro for public methods
• Provide Maintenance API for changing log-level

Alternatives

• Own implementation - are hard to maintain and time consuming in development with no guarantees about performance
• Tracing libraries - very complicated, no need in current state but may be considered for future use (with back compatible logging format extension)

Concerns

• Implementation of loggers could affect performance
• Async actions will be hard to discover in a log file

Assumptions

• We do not depend on any implementation, only on format

Risks

• Format will be inefficient for automatic monitoring `[1;8]`
• Logging will slow down performance `[4;7]`
• Log messages format will not help in issues discovery `[2;8]`

Additional Information