IBM Support

Debug settings for Netcool Impact 7.1

Technical Blog Post


Debug settings for Netcool Impact 7.1



To set debugging for Netcool Impact 7.1, there are 2 files in $IMPACT_HOME/etc:


Note:  There is also another similar file called, but that is not discussed here.

These log4j files control the logging levels and logging thresholds used by the impact servers, as well as certain parameters that control the number of backup log files that are maintained and the size of those files.

Here is an example of an file:






  log4j.appender.NETCOOL.layout.ConversionPattern=%d{DATE} %-5p [%c{1}] %m%n







  # This appender captures the messages emitted from Impact which are

  # at the ERROR priority or above. Due to a potential for quick rollover

  # of the main impactserver.log, certain error messages may be lost before

  # someone has a chance to view them. Since this appender will have less

  # information in it, the chances of that happening are greatly diminished.




  log4j.appender.NETCOOL-ERRORS.layout.ConversionPattern=%d{DATE} %-5p [%c{1}] %m%n







  # set the default priority to INFO for all micromuse/ibm loggers,NETCOOL,NETCOOL-ERRORS,NETCOOL,NETCOOL-ERRORS


  # override any specific loggers


The items in RED relate to logging levels and the items in BLUE relate to the number and size of the log files.  The remaining lines in BLACK should not normally need to be changed and won’t be discussed here.

Within the Impact product, there are various log messages which will either be output or suppressed depending on the logging threshold levels specified in the log4j files.  The full list of logging thresholds which can be used are as follows:

OFF:               Has the highest possible rank and is intended to turn off logging.

FATAL:             Designates very severe error events that will presumably lead the application to abort.

ERROR:         Designates error events that might still allow the application to continue running.

WARN:           Designates potentially harmful situations.

INFO:              Designates informational messages that highlight the progress of the application at coarse-grained level.

DEBUG:          Designates fine-grained informational events that are most useful to debug an application.

TRACE:          Designates finer-grained informational events than the DEBUG

ALL:                 Has the lowest possible rank and is intended to turn on all logging.

This list ranks from the minimum amount of logging at the top (OFF) to the maximum at the bottom (ALL), although for Impact we tend to only use ERROR, INFO, DEBUG and TRACE.

These two lines:



Control the threshold for log messages which are written to the log files impactserver.log and impactserver-errors.log (for the Impact server) and impactgui.log and impactgui-errors.log (for the ImpactUI server) respectively.  So, for example, with log4j.appender.NETCOOL.threshold set to INFO in, no log messages of type DEBUG or TRACE will be written to the log file impactserver.log, even if they are defined further down.

Further down in the file, you will see these two lines:,NETCOOL,NETCOOL-ERRORS,NETCOOL,NETCOOL-ERRORS

These set the default logging level for the classes and com.micromuse to INFO and  also sets the messages to be logged to the NETCOOL and  NETCOOL-ERRORS appenders (as defined higher up in the file).  Changing the INFO value to DEBUG or TRACE will change these defaults.

The values below this in the file can override the logging value for the specified classes or packages, for example:

These overrides can be up or down.  So, in this line:

The logger for will be overridden to be ERROR, if this line was not here, the default would be INFO, taken from the earlier line:,NETCOOL,NETCOOL-ERRORS.  This will reduce the level of logging you see from that package/class.  If you were to override and specify DEBUG, you would increase the logging level for that package/class.

The overriding can be set at different package/class levels, so for example, you can set:

And this will override the logging for the class GetHTTPFunction.  You can also specify it at a higher level, i.e.:

This will produce the same tracing for that class and others at that level.  You can keep going, specifying, for example:


And, in each case, you will get DEBUG logging for all classes at each of those levels and below.

I did some testing and found that you can also be clever and filter the tracing with the lines in the correct order, for example if you specify:


This will set DEBUG logging for all classes in but then override it back to INFO for the classes at the lower levels dblayer, event, sever, service and common.parser.  So if you set DEBUG logging on a package but get more than you want and the logs fill up too quickly, you can unset it for the bits you don’t want.



[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":""}]