[
https://issues.apache.org/jira/browse/IGNITE-7611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685091#comment-16685091
]
Stanislav Lukyanov edited comment on IGNITE-7611 at 12/4/18 10:56 AM:
----------------------------------------------------------------------
[~pgarg] The last thing we'd introduced is DEV_ONLY warnings - IGNITE-7284.
By default these warnings are just printed as usual. There are two ways to
control them:
1) Set property IGNITE_DEV_ONLY_LOGGING_DISABLED=false to disable all of them
2) If the underlying logging framework supports markers (like log4j2), one can
use the framework-specific way of configuring marked messages (for example see
docs for marker-based filtering in log4j2:
https://logging.apache.org/log4j/2.0/manual/filters.html#MarkerFilter)
In general, we need more docs for logging setup.
Currently we have a description of how to forward Ignite logging to different
logging frameworks - https://apacheignite.readme.io/docs/logging. This
description, while could be improved, seems to be sufficient.
What we don't have is:
1) Description of all logging configuration options independent from frameworks
These options are mostly system properties and Ignite configuration parameters
that control the output.
Here are some properties related to logging that I found after a quick look:
- IGNITE_LOG_INSTANCE_NAME
- IGNITE_UPDATE_NOTIFIER
- IGNITE_STARVATION_CHECK_INTERVAL
- IGNITE_QUIET
- IGNITE_TROUBLESHOOTING_LOGGER
- IGNITE_CONSOLE_APPENDER
- IGNITE_LOG_DIR
- IGNITE_GRID_CLIENT_LOG_ENABLED
- IGNITE_DEV_ONLY_LOGGING_DISABLED
- IGNITE_DUMP_THREADS_ON_FAILURE
- GridLogThrottle.throttleTimeout(int)
- IgniteConfiguration.metricsLogFrequency
- IgniteConfiguration.gridLogger
2) Best practices of logging configuration
Most users don't care about logging much (unfortunately) until something
breaks, so the best thing we can do is to describe how to setup logging:
- Enable verbose mode
- Capture standard output (stdout and stderr)
- Make sure you know where the log files are stored and that there is enough
space there
- Don't store log files in /tmp
- Archive old log files periodically
3) Adjusting log configuration dynamically
Most logger implementations support dynamic configuration changes:
- j.u.logging (JavaLogger) supports configuration changes via JMX
- log4j and log4j2 configuration files can be changed directly - the new
version of the file will be applied after some delay (seconds)
was (Author: slukyanov):
[~pgarg] The last thing we'd introduced is DEV_ONLY warnings - IGNITE-7284.
By default these warnings are just printed as usual. There are two ways to
control them:
1) Set property IGNITE_DEV_ONLY_LOGGING_DISABLED=false to disable all of them
2) If the underlying logging framework supports markers (like log4j2), one can
use the framework-specific way of configuring marked messages (for example see
docs for marker-based filtering in log4j2:
https://logging.apache.org/log4j/2.0/manual/filters.html#MarkerFilter)
In general, we need more docs for logging setup.
Currently we have a description of how to forward Ignite logging to different
logging frameworks - https://apacheignite.readme.io/docs/logging. This
description, while could be improved, seems to be sufficient.
What we don't have is:
1) Description of all logging configuration options independent from frameworks
These options are mostly system properties and Ignite configuration parameters
that control the output.
Here are some properties related to logging that I found after a quick look:
- IGNITE_LOG_INSTANCE_NAME
- IGNITE_UPDATE_NOTIFIER
- IGNITE_STARVATION_CHECK_INTERVAL
- IGNITE_QUIET
- IGNITE_TROUBLESHOOTING_LOGGER
- IGNITE_CONSOLE_APPENDER
- IGNITE_LOG_DIR
- IGNITE_GRID_CLIENT_LOG_ENABLED
- IGNITE_DEV_ONLY_LOGGING_DISABLED
- IGNITE_DUMP_THREADS_ON_FAILURE
- IGNITE_THROTTLE_LOG_THRESHOLD
- IgniteConfiguration.metricsLogFrequency
- IgniteConfiguration.gridLogger
2) Best practices of logging configuration
Most users don't care about logging much (unfortunately) until something
breaks, so the best thing we can do is to describe how to setup logging:
- Enable verbose mode
- Capture standard output (stdout and stderr)
- Make sure you know where the log files are stored and that there is enough
space there
- Don't store log files in /tmp
- Archive old log files periodically
3) Adjusting log configuration dynamically
Most logger implementations support dynamic configuration changes:
- j.u.logging (JavaLogger) supports configuration changes via JMX
- log4j and log4j2 configuration files can be changed directly - the new
version of the file will be applied after some delay (seconds)
> Document logger configuration options
> -------------------------------------
>
> Key: IGNITE-7611
> URL: https://issues.apache.org/jira/browse/IGNITE-7611
> Project: Ignite
> Issue Type: Bug
> Components: documentation
> Reporter: Stanislav Lukyanov
> Assignee: Artem Budnikov
> Priority: Major
> Fix For: 2.7
>
>
> Existing documentation on readme.io
> (https://apacheignite.readme.io/docs/logging) gives details on how to enable
> each of the supported logging frameworks, and some info on the default
> configuration (e.g. IGNITE_QUIET).
> The documentation should also cover some other features of Ignite logging,
> such as recently added features of automatic reconfiguration of log4j 1.x and
> 2.x (IGNITE-6946) and DEV_ONLY marker in logging messages (IGNITE-7284), as
> well as other features like automatic metrics logging (MetricsLogFrequency)
> and performance suggestions on start
> (IGNITE_PERFORMANCE_SUGGESTIONS_DISABLED).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
