[
https://issues.apache.org/jira/browse/IGNITE-17237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17237:
--------------------------------------
Description:
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
was:
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 are better fits this, 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
> 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
>
> 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.7#820007)
