[
https://issues.apache.org/jira/browse/IGNITE-17237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov resolved IGNITE-17237.
---------------------------------------
Fix Version/s: 3.0.0-beta1
Resolution: Fixed
> Implement a logging subsystem
> -----------------------------
>
> Key: IGNITE-17237
> URL: https://issues.apache.org/jira/browse/IGNITE-17237
> Project: Ignite
> Issue Type: Epic
> Components: general
> Reporter: Konstantin Orlov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> h2. Motivation
> One of the most important parts of any running application is its logs. The
> operations team uses them to make sure the application runs smoothly.
> Developers use the log for troubleshooting. So we need to provide a uniform
> way to log any important event related to the system.
> h2. Requirements
> * Implementation should not rely on any particular 3rd-party logging
> framework
> * Implementation should support 5 base logging severities: TRACE, DEBUG,
> INFO, WARN, ERROR
> * Implementation should provide a uniform API for server-side use as well as
> for clients
> * For clients there should be an ability to specify logger programmatically
> through the client builder
> * Implementation should provide seamless integration with majority of
> popular logging frameworks
> * Implementation should support parameters' substitution to avoid wrapping
> with {{ifEnabled}} for very simple cases
> h2. Proposed solution
> We could take an advantage of {{System.Logger}} frameworks. This implies a
> two level architecture with uniform frontend which should be used throughout
> our system, and interchangeable backends. Besides, {{System.Logger}}
> framework have already integrated with such 3rd-party frameworks as {{SLF4j}}
> and {{Log4j}}.
> h2. Proposed guidelines
> h3. Message layout
> Nowadays so many deployments have an automated logging preprocessing, that
> it's important not only make the logs human readable, but make them machine
> friendly. With that said, we need to get sure that all arguments are easy to
> locate and parse. To achieve this, the proposed log format is follow:
> {code:java}
> <Log message> [argKey1=argVal1, argKey2=argVal2]
> {code}
> For example:
> {code:java}
> Table has been created [id=0xaabbccdd, tName=my_table, sName=my_schema]
> {code}
> Perhaps, the structured logs fits better, but this is currently out of scope.
> h3. Arguments inlining
> We need to avoid string concatenation to inline arguments into the message
> because logging subsystem should provide arguments' substitution
> h3. On choosing the level
> We must come from an understanding that both levels WARN and ERROR requires
> an attention of an operation team, so those levels should be used only when
> the cluster is in (or about to move to) invalids state.
> INFO is a normal level that is used to log regular _unfrequent_ events. Avoid
> to use this level for frequent events like TABLE INSERT
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
