You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafodion.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/04/20 05:11:04 UTC

[jira] [Commented] (TRAFODION-2596) Improve the log4j and log4cxx infrastructure in Trafodion

    [ https://issues.apache.org/jira/browse/TRAFODION-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976090#comment-15976090 ] 

ASF GitHub Bot commented on TRAFODION-2596:
-------------------------------------------

GitHub user selvaganesang opened a pull request:

    https://github.com/apache/incubator-trafodion/pull/1070

    [TRAFODION-2596] Improve the log4j and log4cxx infrastructure in Traf…

    …odion
    
    The following changes are made in the way Trafodion logs the messages:
    
    Writes to a log file based on a component or set of components.
    
    C++ part of the code base:
    
    Component	   Default log file            Configuration File
    TM		                tm_<nid>.log                    log4cxx.trafodion.tm.config
    SSCP                       sscp_<nid>.log                   log4cxx.trafodion.sscp.config
    SSMP                      ssmp_<nid>.log                 log4cxx.trafodion.ssmp.config
    All SQL processes   trafodion.sql_<nid>.log     log4cxx.trafodion.sql.config
      mxosrvr
      sqlci
      tdm_arkesp
      tdm_arkcmp
      tdm_udrserv
    
    Java part of the code base
    TM                 trafodion.dtm.log          log4j.dtm.config
    SQL                trafodion.sql.java.log     log4j.sql.config
    
    By default, the log level is set to INFO for most of the cases. When a message
    dominates the log file and if doesn't add value in the current level, it will be
    changed to  the higher level in the hierarchy. This should help to improve the
    usefulness of the log file at the default INFO level.
    
    The existence of an environment variable TRAF_MULTIPLE_SQL_LOG_FILE will revert back
    to the old way of logging into multiple files. Then, the configuration file
    log4cxx.trafodion.masterexe.config will be used.
    
    Currently, RollingFileAppender appender is used for both modes. Different config files
    are used to change this appender when the need arises.
    
    log4cxx.trafodion.udr.config and log4cxx.trafodion.lob.config are removed.
    log4j.hdfs.config used as the config file for SQL is renamed to log4j.sql.config
    
    Foundation components logging will be revamped later.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/selvaganesang/incubator-trafodion trafodion-2596_3

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/incubator-trafodion/pull/1070.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1070
    
----
commit ed4c93f5d26fbd018f8c3ad54165ad1fbb2477c1
Author: selvaganesang <se...@esgyn.com>
Date:   2017-04-20T00:50:56Z

    [TRAFODION-2596] Improve the log4j and log4cxx infrastructure in Trafodion
    
    The following changes are made in the way Trafodion logs the messages:
    
    Writes to a log file based on a component or set of components.
    
    C++ part of the code base:
    
    Component	   Default log file            Configuration File
    TM		   tm_<nid>.log                log4cxx.trafodion.tm.config
    SSCP               sscp_<nid>.log              log4cxx.trafodion.sscp.config
    SSMP               ssmp_<nid>.log              log4cxx.trafodion.ssmp.config
    All SQL processes  trafodion.sql_<nid>.log     log4cxx.trafodion.sql.config
      mxosrvr
      sqlci
      tdm_arkesp
      tdm_arkcmp
      tdm_udrserv
    
    Java part of the code base
    TM                 trafodion.dtm.log          log4j.dtm.config
    SQL                trafodion.sql.java.log     log4j.sql.config
    
    By default, the log level is set to INFO for most of the cases. When a message
    dominates the log file and if doesn't add value in the current level, it will be
    changed to  the higher level in the hierarchy. This should help to improve the
    usefulness of the log file at the default INFO level.
    
    The existence of an environment variable TRAF_MULTIPLE_SQL_LOG_FILE will revert back
    to the old way of logging into multiple files. Then, the configuration file
    log4cxx.trafodion.masterexe.config will be used.
    
    Currently, RollingFileAppender appender is used for both modes. Different config files
    are used to change this appender when the need arises.
    
    log4cxx.trafodion.udr.config and log4cxx.trafodion.lob.config are removed.
    log4j.hdfs.config used as the config file for SQL is renamed to log4j.sql.config
    
    Foundation components logging will be revamped later.

----


> Improve the log4j and log4cxx infrastructure in Trafodion
> ---------------------------------------------------------
>
>                 Key: TRAFODION-2596
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-2596
>             Project: Apache Trafodion
>          Issue Type: Improvement
>            Reporter: Selvaganesan Govindarajan
>            Assignee: Selvaganesan Govindarajan
>
> Currently SQL logs messages in different files identified by the master node and pid in its name. This creates many log files in $TRAF_HOME/log directory and makes it unmanageable.
> SQL primarily use log4cxx infrastructure for logging error messages and error events. I believe error messages are written only when the master process reads the diagnostics area and it is not written when the error originates.  But the error events(SQLMXLogging) might be written by any process.
> In addition, all other logs on the java side uses a single log file even when it is written from multiple processes in our environment.  Eg trafodion.hdfs.log trafodion.dtm.log. Even the C++ logging writes from multiple processes. The amount of log entries written by SQL from C++ side is way less than the any other logging within our environment. Definitely, they pale in comparison with hbase, hive and other Hadoop processes.
> So, I think it will be neat solution to log the entries from all SQL processes into one log file per node



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)