|
|
As the TrafficDirector administrator, you must ensure that everything continues to operate correctly after setting up the initial configuration parameters. This chapter describes system-level tasks and troubleshooting tips to help you maintain the TrafficDirector environment.
The following sections provide more information:
To help you keep track of your TrafficDirector processing environment, you can retain a series of event logs to give you an up-to-date picture of each software transaction. The event logging subsystem lets you customize the type of messages to be logged and the aging period for the logs you want to maintain. You can redefine the logging definitions at runtime for various TrafficDirector applications and SQL database daemons after you define the initial configuration parameters.
Event logging is different from the logging parameters you defined in properties files to be installed on agents. In properties files, the logging settings for each statistical group---Stats, Hosts, Conversations, and ART---define the type of data to be collected at the SwitchProbe device or Network Analysis Module, then logged to the SQL database for trend reporting.
Event messages are generated by both TrafficDirector applications and the SQL database daemons. By default, the information is stored in two separate types of log files in $NSHOME/log:
A default configuration file in $NSHOME/usr/log.cfg is shipped with the TrafficDirector software. This file includes values for determining:
The log.cfg file contains separate entries for application- and daemon-type messages. You can edit the defaults with a text editor as required. To implement any changes, edit the configuration file before starting a particular TrafficDirector application for which you now want to log messages.
The sample default file looks like the following example:
# Event Logging Configuration File applic - directory $NSHOME/log
applic - expire 5
applic - loglevel warning
daemon - directory $NSHOME/log
daemon - expire 5
daemon - loglevel warning
You can log the following types of messages; each type represents to what extent the messages are logged and their level of severity:
The log files required to store all informational messages might be much larger than the log files required to store only fatal messages. You should consider retaining daily log files for no longer than five days. Before using the error logging feature, be sure to delete any old log files created with previous releases.
All database daemon messages are also sent to the Alert Monitor application for display regardless of the settings you defined in the log.cfg file. See Chapter 10, "Using Alert Monitor," for more information about daemon messages in Alert Monitor.
Each message in the log file is accompanied by information about the processing environment when the event occurred. The information includes the date and time, application name, process ID (pid), thread ID (if applicable), the user's login name when the message occurred (for UNIX platforms only), related agent and protocol information, and the text of the message. The log message uses the following format:
102439:grhl:239:paulb:E:RMON:probeTR-10:connect failed in udp_open()
All application messages, regardless of the TrafficDirector application you are tracking, are stored in the same file; likewise, all daemon messages, regardless of the type of daemon, are stored in a single separate file.
To keep the SQL server database you have selected---either the embedded SQL server that comes bundled with the TrafficDirector software, or the Microsoft SQL Server package---fully operational, the following sections will help you more effectively manage your database:
If you need to log all hosts or all conversations for a domain to the SQL database, you must resize both the TrafficDirector configuration defaults and the agent configuration settings at the SwitchProbe device or Network Analysis Module.
To do so, follow these steps:
Step 1 Reconfigure the SwitchProbe device or Network Analysis Module so its internal table size is increased to store more hosts and conversations.
Step 2 Use the Remote Login application to access the device.
You can increase the table sizes as they pertain to either generic domains or protocol domains. (See Chapter 4, "Using Remote Login to Configure SwitchProbe Devices" for more information.)
Step 3 Reset the device for the changes to take effect.
Step 4 Reconfigure the sqldb.dvp file in the $NSHOME/usr directory.
Step 5 You can redefine TopNHosts and TopNConversations variables.
You can either increase their settings up to 50,000, or reset the value to 0. Resetting disables all TopN host or conversation logging and let you log all available hosts and conversations.
Step 6 Reconfigure the default.dvp file in the $NSHOME/usr directory.
Step 7 Edit the called max-hosts and max-convs variables.
By default, max-hosts is set to 5000, and max-convs is set to 10000. Reset the values to correspond to those you set at the device.
Step 8 Start the TrafficDirector Config Rollup application.
Step 9 You can change the Host Database and Conversation Database variables which represent the minimum utilization thresholds that individual hosts and conversations must exceed before meeting the criteria to be logged into the SQL database.
You can reset both to 0.0, disabling utilization, so all available hosts and conversations are logged, no matter how the thresholds are set.
Step 10 After changing any TrafficDirector variables, you must stop and restart the RMON Manager.
To do so, run the dbshutdn utility in the $NSHOME/bin directory to shut down all background daemons.
After logging is properly reconfigured with the new parameter settings, expect disk usage to increase. See Appendix D, "Determining Machine Class and Disk Usage" to estimate the requirements for SQL database disk space.
You should back up the SQL Server database that stores all logged data to support the Trend Reporter application.
For UNIX users, you can also make a backup copy of the NSTREND_DB database. The NSTREND_DB database is a collection of files in the $NSHOME/msqldb/NSTREND_DB directory.
To copy the database, follow these steps:
Step 1 Exit from the rmonmgr application GUI and any other TrafficDirector applications that are currently open.
Step 2 Open a UNIX window as the TrafficDirector installation owner.
Step 3 Change to the $NSHOME directory.
Step 4 Create a backup directory for $NSHOME to store backup files with the following command:
mkdir backup
Step 5 Change to the $NSHOME/bin directory.
Step 6 Use the dbshutdn command to ensure that all TrafficDirector database daemons are shut down and no further transactions are written to the database tables.
Step 7 Use the su command to switch to the root username.
The su command prompts for the root password.
Step 8 Enter the root password.
Step 9 Use the following command to change your directory to the NSTREND_DB database:
cd $NSHOME/msql/msqldb/NSTREND_DB
Step 10 After you have accessed NSTREND_DB directory as root, enter the following command to build one backup that contains all files in the NSTREND_DB directory:
tar cvf $NSHOME/backup/backup.tar *
Step 11 Use the tar command to create a file called backup.tar in the $NSHOME/backup/directory which contains all database files in NSTREND_DB.
You also use the tar command with other parameters to write the NSTREND_DB database files directly to tape. See your specific UNIX operating system manuals for further information.
The backup.tar file uses about the same amount of disk space as the original database files. You can compress the backup.tar file to reduce the amount of disk space it uses.
Step 12 Change directory to $NSHOME/backup.
Step 13 Enter the following command:
compress backup.tar
The resulting file is called backup.tar.Z. If the original backup.tar file was 100 megabytes, then the backup.tar.Z file would contain roughly 15 megabytes.
Step 14 Exit out of the root user.
The backup is complete.
Step 15 Restart the TrafficDirector application.
To restore the NSTREND_DB database from a previous backup for a UNIX platform, use the same technique that you used for creating the backup.tar.Z file.
Follow these steps:
Step 1 Exit from the rmonmgr application GUI and TrafficDirector that are open.
Step 2 Open a UNIX window as the TrafficDirector installation owner.
Step 3 Change to the $NSHOME/bin directory.
Step 4 Use the dbshutdn command to ensure that all TrafficDirector database daemons are shut down and no further transactions are written to the database tables.
Step 5 Use the su command to switch to the root username.
The su command prompts for the root password.
Step 6 Enter the root password.
Step 7 Enter the following command to change to the NSTREND_DB database directory:
cd $NSHOME/msql/msqldb/NSTREND_DB
Step 8 If the backup.tar file was previously compressed, issue the following command to uncompress the file:
cd $NSHOME/msql/msqldb/NSTREND_DB
Step 9 Enter the following command to remove the existing NSTREND_DB database and its associated files:
rm $NSHOME/msqldb/NSTREND_DB/*
Step 10 Rebuild the database with the contents from a previously built backup.tar file using the tar command. (You must still be logged in as the root user with the current directory as $NSHOME/msql/msqldb/NSTREND_DB.)
Enter the following command:
tar xvf $NSHOME/backup/backup.tar
Step 11 Exit out of the root user.
The restore process is complete.
Step 12 Restart the RMON Manager application.
RMON Manager Service is the master service control routine for all TrafficDirector daemons.
When rmonmgr.exe is run, it starts the RMON Manager Service (if it is not already running). When closed, it stops the service if you respond Yes to the shutdown daemon prompt.
If you reply No, no action is taken.The RMON Manager Service will indicate the state as Running in the Service Control Manager on the Control Panel. All daemon activity (msql, logging, and trapd) will remain undisturbed even if you log out.
After installing the TrafficDirector application, the RMON Manager Service is listed as a service under the Windows NT Control Panel as shown in Figure B-1 (Start> Settings> Control Panel> Services).
The following sections describe how to start and stop the RMON Manager Service:
The default startup parameter for the RMON Manager Service is automatic. That is, all daemons will start up after you boot the system, before you log in as a Windows NT user.
If you do not want the daemons to start automatically, change the startup parameter to manual or disabled:
To change the RMON Manager Service to manual or disabled, follow these steps:
Step 1 Select RMON Manager Service from the Windows NT Service window.
Step 2 Click Startup.
Step 3 The Service window opens (Figure B-2).
Step 4 Click the Manual radio button.
Step 5 Click OK.
The mode changes to Manual (Figure B-3).
Step 6 To change the startup mode to disable, use the same procedure in Step 4, except select disabled.
You can stop and start RMON Manager Services using the Windows NT Services Panel.
To stop the RMON Manager Service, follow these steps:
Step 1 Select RMON Manager Service from the Service window.
Step 2 Click Stop.
The following message is displayed:
Are you sure you want to stop the RMON Manager Service service?
Step 3 Click Yes to stop the RMON Manager Service.
The following message is displayed:
Attempting to Stop the RMON Manager Service service on <hostname>
You can confirm that RMON Manager Services has been stopped by viewing the Service window and checking that Started no longer appears in the Status column (Figure B-4):
To start RMON Manager Services, follow these steps:
Step 1 Select RMON Manager Service from the Service window.
Step 2 Click Start.
The following message is displayed:
Attempting to Start the RMON Manager Service service on <hostname>
Step 3 You can confirm RMON Manager Services has been started by viewing the Service window and checking that Started now appears in the Status column (Figure B-5).
You can start and stop the RMON Manager Service by using the Windows NT NET command from the command console.
To start RMON Manager Service, enter this command:
C:\> NET Start RMONMGR
To stop RMON Manager Service, enter this command:
C:\> NET Stop RMONMGR
You can review the current status of RMON Manager Service from the Command Console by using the RMONSC utility.
To run the RMONSC utility, enter this command:
C:\> %nshome%\bin\rmonsc query rmonmgr
Figure B-6 contains a sample of the output from running RMONSC:
Microsoft<R> Windows NT<TM> <C> Copyright 1985-1996 Microsoft Corp. C:\WINNT\Profiles\Administrator\Desktop>cd\ C:\>%nshome\bin\rmonsc query rmonmgr Service Type: 16 WIN32_OWN_PROCESS Current State: 4 RUNNING Controls Accepted: 7 STOPPABLE & PAUSABLE & ACCEPT_SHUTDOWN Win32 Exit Code: 0 Service Exit Code: 0 Check Point: 0 Wait Hint: 0 msecs. C:\>
Posted: Mon Feb 8 15:20:34 PST 1999
Copyright 1989-1999©Cisco Systems Inc.