Status | ACCEPTED |
---|---|
Stakeholders | |
Outcome |
|
Due date | |
Owner |
Background
To make logging process consistent across Iroha applications logging process should be introduced and logging format should be defined.
Action items
- Nikita Puzankov write RFC
- DevOps team - review it
- Nikita Puzankov move RFC to ADR
Problem
Unstructured logs are hard to monitor, analyze and process automatically.
- Logs should be printed to stdout and stderr.
- 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]`