| Status | IN PROGRESS |
|---|---|
| Stakeholders | |
| Outcome | |
| Due date | |
| Owner |
Background
To make logging process consistent across Iroha applications #[log] attribute macro is introduced.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.
Solution
Log macroses can log It logs function arguments and result, using https://tools.ietf.org/html/rfc3164 like format:
| Code Block |
|---|
LEVEL DATE_TIME function_name[start]: arguments LEVEL DATE_TIME function_name[end]: result |
Example:
| Code Block |
|---|
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
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]`