Sometimes we will need to get a log file to determine what is going on with Trap Manager. Since this is a windows application, we will need to modify a windows environment variable in order to activate the debugging process. To learn how to create environment variables, please see the “How To” post for environment variables or http://support.microsoft.com/kb/310519

1. Create the following environment variables

In the Environment variables section, create the following SYSTEM variables with the following values:

  BS_DEBUG=ON

  BS_DEBUG_MODULES=1

Remember with Trap Manager you must create SYSTEM variables, not USER because the Trap Manager process runs as a windows service and assumes the system role.

2. Restart the Computer

Remember with Trap Manager that you must restart the computer, so when the service restarts it will be able to come up in debug mode. Only then does it take effect. Now, make the problem happen. At this point, a log should have been created in the OidView main directory, named trapmanager.debug.log.

3. Turn off debugging

To turn off debugging, simply remove the variables that you created or set the values to OFF and 0, respectively.

  BS_DEBUG=OFF

  BS_DEBUG_MODULES=0

How To, OidView, Trap Manager debugging, logging, OidView, Trap Manager

Sometimes we will need to get a log file to determine what is going on with OiDView. Since this is a windows application, we will need to modify a windows environment variable in order to activate the debugging process. To learn how to create environment variables, please see the “How To” post for environment variables or http://support.microsoft.com/kb/310519

1. Create the BS_DEBUG environment variable

In the Environment variables section, create a USER variable BS_DEBUG with the following value:ON

  BS_DEBUG=ON

2. Restart the OidView application

Remember that you must restart the application. Only then does it take effect. Now, make the problem happen. At this point, a log should have been created in the OidView main directory, named OidView.debug.log.

3. Turn off debugging

To turn off debugging, simply remove the BS_DEBUG USER variable that you created or set the value to OFF

  BS_DEBUG=OFF

 

 

 

How To, OidView debugging, logging, OidView

Sometimes we will need to get a log file to determine what is going on in the monitoring engine. The main log file is in the main monitor engine directory, and is named monitorengine.log. There are a couple of different ways to turn on logging as well as different levels and components. Our logging system is based on the log4j logging componenet. More information about log4j can be found here: http://logging.apache.org/log4j/

The easiest way to turn on debugging is to simply issue the following command:

xmlApiClient -o system.logging.priority -v DEBUG

Here are some guidelines to use with debug logging….

1. LOG LEVEL PRIORITY

There are several different priority levels of logging. The default log level the engine ships with is “INFO”. This logs all informational messages to the log and the database.

Levels include ERROR, WARNING, INFO, DEBUG. ERROR will give the least amount of logging, while DEBUG will give the most. When we are debugging the product, you will need to enable the DEBUG priority.

There are two ways to change the priority. On a running engine, you may issue the command:

system.logging.priority -v <LEVEL>

In this case, to turn on debugging, you would issue:

system.logging.priority -v DEBUG

Another way would be to modify the monitorengine/log4j.xml file directly. In the last section of the file, you will see:

  <root>
    <priority value =”info” />
    <appender-ref ref=”Rolling”/>
  </root>

Change the line:

    <priority value =”info” />

to:

    <priority value =”debug” />

and save the file. The monitor engine will have to be restarted for it to take effect.

2. MONITOR DEBUG LEVEL

 This affects the amount of DEBUGGING information ONLY. The level of 1 will log the least amount of information and the level of 10 will log the most amount of ingformation. 5 is a good amount.

To adjust this value on the fly, issue the command:

   system.logging.level -v <LEVEL>

To adjust this to a value of 6, issue the command:

   system.logging.level -v 6

The other way to modify this value is to edit the engineconfig.properities file.

The following value (monitor_debug_level) must be modified. For example, to set it to 5, make sure the line reads:

   monitor_debug_level=5

3. LOG COMPONENT

You can control which component that the engine performs debug logging for. It is controlled by the following command: system.logging.component

The valid values for components are:

    ALL = ALL
    MRM = Monitor Results Manager
    PE = Poller Engine
    DE = Discover Engine
    OE = Output Engine
    NE = Notifier Engine
    RAE = Results Analysis Engine
    SP = Symbol Processor
    PM = Ping Monitor
    PB_SNMP = Poller Blade (SNMP)

To turn on debugging for the only the Discover Engine, for example, first enable debugging, and then specify the DE component:

xmlApiClient -o system.logging.priority -v DEBUG

xmlApiClient -o system.logging.component -v DE

To enable debugging for more than one component, use the comma separator. For example to debug the poller and the symbol processor, specify:

xmlApiClient -o system.logging.component -v PE,SP

 

 

 

 

 

 

How To, JaguarSX debugging, JaguarSX, logging

Sometimes when debugging issues it will be necessary to determine which queries are being sent to the database from the Web UI. Since the Jaguar web UI is completely written in PHP, you will have to modify a PHP text file located in the web directory. Here are some simple steps you can use to turn on logging.

1. Delete the www/bytesphere/logs/queries.log.

Deleting this file will allow us to focus on any newly logged queries and will remove the old ones.

2. Edit the www/bytesphere/includes/dbFunctions.php file

Inside this file is a function called mysql_query_wrapper. In there you must change the debug_on flag to 1.

Change the line:

 $debug_on = 0;

to the following:

 $debug_on = 1;

3. Save dbFunctions.php

Make sure after you save the file it has truly been updated. Especially double-check this on unix systems, as the file may be read-only.

4. Reproduce the issue!

Now that we have logging enabled, you can go ahead and reproduce the issue, so the queries will be logged into the queries.log file.

5. Retrieve the www/bytesphere/logs/queries.log file

Once you have sufficiently reproduced the problem, ZIP up the log file and email it to support.

How To, JaguarSX debugging, JaguarSX, logging