cc/td/doc/product/natkit
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Facility Administration and Message Logging

Facility Administration and Message Logging

This chapter describes NATkit 2.0 facilities and explains how and where messages are logged. NATkit 2.0 log messages are written to the Syslog facility. NATkit 2.0 debugging messages are written to the /var/adm/CSCOpx/log/daemons.log file.

This chapter consists of the following sections:

Errors and Logs

NATkit 2.0 creates error reports and message logs for all the tasks carried out by NATkit 2.0. Each tool, SNMP Poller, Syslog, Device Availability, Configuration Collector, System Logs, Audits, WAN Switches, and Transient has a corresponding error report and message log.

The error reports list any problems encountered while trying to perform data collection. The message logs track various data collection events, depending on which tool's log you are viewing.

In addition to each tool, there is an error report and message log for NATkit's system processes that collects similar information.


Logging, Error Rotation, and Reporting Errors

Error Report and Message Log Format

Each error report and message log follows a similar, tabular format. Information for each recorded event includes:

Error Message Storage

NATkit 2.0 error messages are written to the /var/adm/CSCOpx/log/dmgtd.log file. Because messages are continuously added to this file, you might want to occasionally copy this file to a different name, compress it, and empty the dmgtd.log file.

Debugging messages from NATkit 2.0 back-end processes are written to the
/var/adm/CSCOpx/log/daemons.log file. Messages are continuously added to this file, up to the file's preset size limit. When this size limit is reached, the contents of daemons.log is removed and appended to the file daemonsbackup.log in the same directory.

See the "Troubleshooting" appendix for more information about debugging error messages.

Scheduling Scheme

NATkit 2.0 has a self-contained scheduling mechanism (except Software Management and scheduled backup, which use UNIX cron and at) that is configured automatically during installation.

Process Status

Any NATkit 2.0 user can view the status of any process by selecting Admin > System Admin > Process Status.

Table 5-1 shows possible back-end processes and their expected statuses.


Table 5-1: Back-End Process Status
Name Description State

AvIcmpPoller

Polls devices using ICMP1 and provides information about whether a device is accessible.

Running normally

AvInputGen

Retrieves polling information from the database and provides AvIcmpPoller and AvSnmpPoller with a list of devices to poll and the frequency with which to poll them.

Running normally

AvLoader

Moves data from AvIcmpPoller and AvSnmpPoller to the NATkit 2.0 database.

Running normally

AvSnmpPoller

Polls devices using SNMP2 and provides protocol distribution and reload information.

Running normally

AvTrimmer

A transient process that runs on a regular schedule to trim expired availability data from the NATkit 2.0 database.

Running normally

CasServer

A Change Audit program that provides back-end database services for applications that want to log network changes and for Change Audit reports.

Running normally

ChangeAudit

Consists of the following Java programs which provide the back-end functionality of Device Configuration:

  • CasServer

  • ConfigArchive

  • InvChangeProbe

  • Scheduler

Running normally

CMLogger

Used by Java back-end processes and clients to get error messages from NATkit 2.0 message catalogs.

Running but busy flag set

ConfigArchive

A Change Audit program that gets configuration files from devices and archives them.

Running normally

ConfigChangeDetector

Detects configuration changes in the network.

Running normally

ConfigPurge

Deletes expired configuration files from the archive.

Running normally

ConfigUpdate

Sweeps managed devices looking for configuration changes.

Running normally

DbServer

A system service: the database engine.

Running normally

DbService

Java database interface.

Running normally

DIServer

Imports and adds devices to the inventory.

Running normally

diskWatcher

Used only on UNIX systems. A system service that monitors file-system capacity for NATkit 2.0 critical file systems.

Running normally

EDS

A system service that distributes application and network events among NATkit 2.0 components.

Running normally

NATkit 2.0DbMonitor

A system service that monitors the accessibility of the NATkit 2.0 database engine, which helps to ensure that the system is not started until the database engine is ready. All database-dependent back-end processes depend on this process.

Running normally

NATkit 2.0OSG

Sybase's open server gateway that allows Java programs to connect to the NATkit 2.0 database.

Running normally

IcServer

Routinely collects inventory updates from managed devices. Inventory updates are acquired through SNMP queries on MIBs in the devices that maintain inventory information.

Running normally

InvChangeDetector

Detects inventory changes in the network and causes the device database to be updated.

Running normally

InvChangeProbe

A Change Audit program that sends notifications when new devices are managed by DIServer or when managed devices are deleted from inventory.

Running normally

JSSsched

Scheduling process.

Running normally

NetsysRpt

Provides configuration files to the NetSys application and acquires NetSys reports for NATkit 2.0 users.

Running normally

OSGpxDb

Open Server Gateway.

Running normally

RmeOrb

One of the system services that is the object request broker (ORB) part of CORBA.

Running normally

Scheduler

A Change Audit program that schedules repeating jobs for the Inventory and Device Configuration back-end processes.

Running normally

SyslogAnalyzer

Filters and forwards messages from routers and switches to the central NATkit 2.0 server.

Running normally

WebServer

The Apache web server used only on UNIX systems.

Running normally

1ICMP = Internet Control Message Protocol.
2SNMP = Simple Network Management Protocol.

Table 5-2 describes the possible process (or daemon) states.


Table 5-2: Process Status Defined
State Definition

Administrator has shut down this server

The administrator or another program has shut down the process.

Failed to run

The process has failed by exiting or sending a failed init message.

Never started

The process is not configured for autostart. The process must be started manually.

Program started - No mgt msgs received

The process has started but the status has not been reported to the Daemon Manager.

Running but busy flag set

The process has successfully started, but does not participate in process management messaging.

Running normally

The process has successfully started and is reporting status to the Daemon Manager.

Transient terminated

The process has completed its function and has terminated normally.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Wed Jul 12 18:12:41 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.