|
|
The Unified Communications Manager (UCM) is a web-based CGI program which aids in the centralized management and monitoring of Cisco's distributed uOne application. It utilizes various UNIX and web facilities such as remote shell (rsh) to access logs and system commands. It provides operational, status, and trending information to the administrator responsible for monitoring overall system functionality and reliability. It is a software component that assists in reporting, trending, and diagnosing the uOne system.
The Unified Communications Manager (UCM) application requires Sun Solaris SPARC release 2.6 operating on the SPARC hardware platform. This system should be outfitted with hard disk space capacity commensurate with the number of distributed host systems employed and the time period for which data and reports will be needed for trending purposes.
Careful consideration should be given to the location of the UCM system in the network. Each Gateserver in the domain could log up to 240 MB per day to the central server. Therefore, the central logging server should be located as close as possible to the remote Gateservers.
The Unified Communications Manager (UCM) application requires the following software to be installed and operational on the system that has been designated for use as a management station by the administrator prior to installation of the software package containing UCM.
Setup remote shell and remote copy permissions for spmaster on those hosts that you have configured UCM to know about via entries into the oam.ini file in the system section. This is accomplished through the judicial usage of the .rhosts file in the home directory of the spmaster login account on each Gateserver. For example, the file /home2/spmaster/.rhosts might look as follows:
UCMsystem.<yourdomain>.com spmaster
This entry allows the spmaster user on the UCM system (UCMsystem) to perform the needed remote shell (rsh) functions as needed on this system.
Step 1 Ensure sufficient disk space is available for reports based on how many hosts and how far back extract files will be kept for reports.
Step 2 The required OS is Sun Sparc Version 2.6.
Step 3 The required user setup is spmaster:spgrp (401:400).
Step 4 The required packages are perl5, dapinit, dapacb, dapwaenv, dapumcli, and dapsnmp.
Step 5 Install the UCM (UM Manager) package dapummgr.
Step 6 Copy $HOME/ADMIN/cgi-bin/Samples to $HOME/ADMIN/cgi-bin.
Step 7 Copy $HOME/ummgr/Scripts/Extractor/Samples to $HOME/ummgr/Scripts/Extractor.
Step 8 Configure $HOME/ADMIN/cgi-bin/oam.ini file for required settings including which Gateservers UCM will manage (you can select localhost) including which Gateservers Data Extract Director should create report files from and where to find the log files on the UCM machine (Central Logging).
Step 9 Copy the $HOME/ummgr/Scripts/etc/Samples/passwd file into the $HOME/ummgr/Scripts/etc/ directory
Step 10 Edit this file for user:password entries to change the default login:passwd from administrator:admin to something else, if necessary.
Step 11 Set up spmaster crontab entry for DataExtractDirector.pl "Type" to run at some defined interval.
Step 12 Set up anonymous ftp user.
Step 13 Set up remote shell permissions for spmaster for those hosts you have configured in the oam.ini file in the system section.
Step 14 Remote systems logging will have to be properly configured depending on the report desired. For the UM Application Summary Report, configure DAP logging for
DestBillResource for App (*APP*Res logs)
For Caller Application Usage, Caller Voice Message Received Details, Subscriber Application Usage, Subscriber Fax Message Sent Details, Subscriber Voice Message Sent Details, and UM Application Usage, configure DAP logging for
DestEvent for App (*APP*Eve logs) UM.ini required to set BillingLogging=On
Step 15 LogRemover—care must be used in order not to remove log files before the Data Extract Director component of UCM Manager can gather a full day of log extract files. LogRemover is the only method available for the systematic removal of excess and unneeded files created by the central logging server or UCM.
A rule is that UM Manager's HOW_MANY parameter must be configured less than the amount of days that the used logfiles get removed (LogRemover.ini). Otherwise reports will show 0's for the first half of the day.
Step 16 Time Sync—To ensure menu selections have consistent date pull-downs, it is advisable (though not required) that date and time is synced between the UC Manager server and the uOne hosts it manages. NTP is a network time protocol that should be used for this purpose since the UCM is now operating as part of the underlying DAP architecture.
The DAP and uOne software components must be properly configured so that required information will be logged and available for use. The logged information will, in turn, be available to the UCM for trending and reporting purposes.
The destination of log files, if activated via configuration parameters, can now be either to the local Gateserver system or to one specifically designated elsewhere in the network. Local logging continues to function as it did in previous releases and will write the various UM and DAP log files to $PARMLIB/logs/logfiles as always. Network logging allows the logs to be written across the network to a system configured to be a central logging server. The central logging subsystem LOGSUB, a component of the DAP, accomplishes central logging by allowing itself to be configured to operate as either a client, a server, or both. The LOGSUB program makes this determination as it initializes and obtains the value associated with the LogServer entry in the Attrib.Global file.
To instruct the DAP and UM software to activate resource and event logging and to properly configure the LOGSUB process for local or network logging, two configuration files must be edited as explained in the paragraphs below.
If you are configuring a Gateserver to function as a single node for all UC processing including UCM (perhaps for training or demo purposes), then you should add the following element to the $PARMLIB/parms/BASE/Attrib.Global configuration file:
If logging is to be done and kept on the local GateServer only, then make these configuration changes to the following elements to the $PARMLIB/parms/BASE/Attrib.Global configuration file:
DestBillResource LOCAL # Capture alloc/freeing SP resources details locally DestEvent LOCAL # Destination of customer event detail is local LogServer No # This system is not a server - perform local logging only
When coded as LOCAL, the associated log files are captured locally to the directory $PARMLIB/logs/logfiles.
The vast majority of deployments of Gateservers will require multiple systems to service the uOne user base. When this is the case, remote logging will need to be configured in order for the UCM software to be useful in the consolidated management and reporting of activity within the domain.
Remote/Central logging is a new feature / facility available with this release. The LOGSUB program is the central logging application for all UC software. It has been enhanced to allow LOGSUB processes operating across all the Gateserver hosts in a domain to work together to write Resource and Event log files and their contents in a near real-time manner to a designated "central" LOGSUB process operating on a designated Gateserver host in the network. It is on this server that the UCM software will reside. UCM reporting functionality depends upon access to Resource and Event logs created by all the systems in a Gateserver domain.
Since most Gateservers will be configured as LOGSUB clients, the administrator will have already determined which Gateserver(s) is/are designated as the LOGSUB server(s) of the domain. As such, to configure the client to know about which system is running the properly configured server, set the LogServer entry in the $PARMLIB/parms/BASE/Attrib.Global file to:
LogServer serverhostname # This GateServer's LOGSUB is a client logging to that server
Whether a Gateserver has its LOGSUB process configured as a client, server, or both, log files are kept locally in the $PARMLIB/logs/logfiles directory. If it is configured as a server, then it listens to a TCP/IP socket for other client LOGSUB processes wishing to pass their log files to it. When it receives a log message, it inserts it into either the active Network Resource (.NetRes) or Network Event (.NetEve) file under the $PARMLIB/logs/netlogs directory on the LOGSUB server. Log records from all Gateserver systems are co-mingled into these files.
On the LOGSUB client machine, a special file is placed in the $PARMLIB/logs/netlogs. This file is named LOG.Network.Data and it contains special controlling information for synchronization between the client and the server. In the event either the client, server, or both are down, this file and the LOG.Network.Data file and associated structure is used by LOGSUB to recover and continue logging without loss (or duplication) of log records. This file should never be deleted or manipulated manually in any way.
If logging is to be done and sent to a central logging server system, then make these configuration changes to the following elements to the $PARMLIB/parms/BASE/Attrib.Global configuration file:
DestBillResource LOCAL_NET # Capture alloc/freeing DAP Resources to Network Server DestEvent LOCAL_NET # Destination of customer event detail is Network Server LogServer UCMServer1 # This system logs to the Network Central Logging Server
When coded as LOCAL-NET, the associated log files are captured both locally and transmitted across the network to the designated central logging server system. Log files are always written locally even when network logging is activated. The logging server parameter designates the name of the system in the domain configured to be the central logging server.
The second file to be edited is the UM.ini file (or the ini file used to run the uOne process). This is the controlling file for the Unified Messaging Application and it must be coded to instruct the UM application to write billing related information into the log files as follows:
BillingLogging=On
The changes to the Attrib.Global and the UM.ini files will cause a Gateserver to write the resource and event log files to the local disk drive in the $PARMLIB/logs/logfiles directory and to the $PARMLIB/logs/netlogs directory on the central logging server as appropriate. If all the desired logging is local, then the oam.ini file can be modified to instruct the UCM software to find the log files in the local directory.
At least one Gateserver system in the domain will need to be designated for use as the UCM system. The UCM system can also be, if desired, a fully functional Gateserver system. Or, it may just have the minimal subset of Gateserver DAP components installed for more efficiency (i.e., it may or may not need to run the TNTOBJ and the UM application). Again, the LOGSUB program is instructed to be a client or server through the usage of the log server parameter in the $PARMLIB/parms/BASE/Attrib.Global file. If the parameter is set to
LogServer Yes # Make this system as server for all others that wish to log here
then this system will act as a server and LOGSUB will accept log files directed to it from other LOGSUB processes in the domain writing their log records into files within the directory $PARMLIB/logs/netlogs. It will, under this configuration, act as a client as well, supporting any logging activity required by other DAP components or application software running on the system.
Ideally, only one Gateserver system would be configured as a LOGSUB server per domain. However, any LOGSUB on any Gateserver can be configured to function as a server, even if others are already providing the server function. Determining how many UCM systems and central logging servers to configure will be influenced by the scale of the operation and is left to the discretion of the administrator or UC network designer.
Comma separated value (csv) files can be readily downloaded and imported into popular desktop software packages for analysis. The capability to download comma separated value (csv) files directly to the client (browser) system is provided by the UCM software. Where it is possible to download data files for further analysis by an administrator, a DOWNLOAD button is provided. These are found on selected UM Reports HTML pages.
The download functionality is provided via the usage of anonymous ftp. In order for anonymous ftp to function on a UNIX server, it must be provisioned. This involves the addition of information to key UNIX OS files. These additions are discussed below.
As root, add the following line to the end of the /etc/passwd file.
ftp:x:30000:30000:Anonymous FTP:/home2/spmaster/ADMIN/htdocs/download:/nosuchshell
As root, add the following line to the end of the /etc/shadow file.
ftp:NP:6445::::::
oam.ini file, be sure to utilize tabs instead of space for indentation and do not embed comments in the same line where variables are defined. If this is not done, then items will be ignored or will cause problems.
The oam.ini file is the location where variable, parameter, and other UCM control information are stored. This information governs the operation of the UCM software components. It also provides some freedom in terms of where the software expects to find its key components and allows the user to control the scope and actions of the UCM. There are 4 categories of sections (Environment, Systems, Reports and Operations) and currently six defined sections with these categories (websetup, system, hosts, UM_Application_Summary, Event_Log, and UM_Process_Activity).
The websetup section allows for the specification of fundamental path and environment variable setup.
[websetup]
## Environment variable setup for Unfied Communications Manager
## Note: No space before and after '=' sign
## No comments on the same line where variables are
## defined
## For ex: HOMEDIR=/home2/spmaster ## homedir
## is not allowed
## The webserver has to run as this user, otherwise permission
## problems will be there
HOMEDIR=/home2/spmaster
WEB_PATH=/home2/spmaster/ummgr/Web
WEB_SCRIPTS=/home2/spmaster/ummgr/Scripts
WEB_HTML=/home2/spmaster/ADMIN/htdocs/UMMgrWeb
WEB_CGI=/home2/spmaster/ADMIN/cgi-bin
WEB_LOGS=/home2/spmaster/ummgr/UMMgrLogs
WEB_REPORTS=/home2/spmaster/ummgr/CSVFiles
HOWMANY_DAYS=3
#date_min should be YYYYMMDD
DATE_MIN=19990101
A login timeout parameter setting TIME_OUT is configurable in the oam.ini file. The value expected should be expressed in decimal days. For example, 0.007 days = 10 minutes. 0.25 days = 6 hours. The default TIME_OUT value in the sample oam.ini file is 0.25.
#default value is 6 hours TIME_OUT=0.25 #login timeout in days ex: 0.007 days = 10 mins, 0.25 days = 6 hrs #default value is 10 mins TIME_OUT=0.25
Versioning has been added for Release 4.x. Log file contents can (and often do) change from release to release. When this happens, a report might not recognize the change, which would in turn cause inaccuracies in reporting. The purpose of versioning is to manage the usage of the UCM software with previous releases of various UC Messaging software components and their log files / records in order to be able to isolate the format of the log files from that version.
In order for DataExtractDirector.pl to execute, the version.ini file must exist in the $HOME/ummgr/Scripts/Extractor directory. The DataExtractDirector.pl reads in this version.ini file to get the software version installed on the various remote systems and then executes the appropriate script to process the logs. You must copy up from Samples on first time installation.
If there is no entry found in the version.ini file, then a default script of <reportname>_csv.pl is executed to create the extract file. If this script is not found, then the Data Extract Director will log this as an error and no extract file will be created.
For example, assume the following is an entry in the version.ini file:
Event_Log_csv_4107.pl:dapumapp:(sparc) 4.1.0,REV=7
Here, the Data Extract Director will look for Event_Log_csv_4107.pl to run if the log file was created on a Gateserver that was running the version dapumapp 4.1.0,REV=7. If Event_Log_csv_4107.pl is not found, the Data Extract Director will look for the default script of Event_Log_csv.pl. If that is not found, then the Data Extract Director will log this as an error and no extract file will be created.
If no entry is specified in the version.ini file for a given extract file, then the default script is used to create the file.
As a second example, the version.ini file below simply specifies that the default program UM_Application_Summary_csv.pl is to be executed whenever the log files were created on a Gateserver system by the software contained in the package dapumapp of version 4.1.0,REV=10. The New_UM_Application_Summary_csv.pl program will be used to create the .csv files when the same package on another Gateserver creates the log files from a later version (4.1.0,REV=11). Similiarly, the Event_Log_csv_41.pl program will be invoked to create the Event_Log.csv extract files if the sofware package on the Gateserver is either 4.1.0,REV=9 or 4.1.0,REV=10. For all others, the default of Event_Log_csv.pl will be used.
##
## File Name: version.ini
##
## @(#)version.ini 120.1.1.1
##
## Each section is identified by the report type
## Entries under each section will have three fields
## separated by ':'. The fields are:
## 1 - Script Name
## 2 - Parameter to pkginfo ex: pkginfo -x field2
## 3 - Output returned from pkginfo on the 2nd line 2nd word
## Note: Entries under each section must start with a 'tab'
## default scriptName would be "<reportName>_csv.pl"
[UMAPPSUM]
UM_Application_Summary_csv.pl:dapumapp:4.1.0,REV=10
New_UM_Application_Summary_csv.pl:dapumapp:4.1.0,REV=11
[APPEVE]
Event_Log_csv_41.pl:dapumapp:4.1.0,REV=9
Event_Log_csv_41.pl:dapumapp:4.1.0,REV=10
The below results are based on an Ultra 450, 256MG.
A worst case DataExtractDirector collection period for a 24 hour loaded system with no call-inactivity time will take approximately 45 MINUTES. The time doubles if two systems with the same criteria are "datacollected". The formula is approximately:
DataCollector Time to process 550MB logfiles is approximately 1 HOUR.
The factor in determining how long dataextractdirector will take is the total number of hosts to collect data for, the "how many" parameter, and the size of the logs to process.
WebDirector - A worst case single report for a 24 hour loaded system with no call-inactivity time will take approximately 45 SECONDS. This time is from the time the Generate Report or Download CSV is selected. If two hosts are selected with this criteria than it would take 90 SECONDS. The uOne Summary Report is the only report that will be instantaneous, because it is already processed.
## Filename: oam.ini
##
## Each sysfile name must be listed as '[sysfile]'
## Its contents must start with a 'tab'
[websetup]
## Environment variable setup for OAM website
## Note: No space before and after '=' sign
## No comments on the same line where variables are
## defined
## For ex: HOMEDIR=/home2/spmaster ## homedir
## is not allowed
## The webserver has to run as this user, otherwise permission
## problems will be there
HOMEDIR=/home2/spmaster
WEB_PATH=/home2/spmaster/ummgr/Web
WEB_SCRIPTS=/home2/spmaster/ummgr/Scripts
WEB_HTML=/home2/spmaster/ADMIN/htdocs/UMMgrWeb
WEB_CGI=/home2/spmaster/ADMIN/cgi-bin
WEB_LOGS=/home2/spmaster/ummgr/UMMgrLogs
WEB_REPORTS=/home2/spmaster/ummgr/CSVFiles
#date_min should be YYYYMMDD
DATE_MIN=19990101
#login timeout in days ex: 0.007 days = 10 mins, 0.25 days = 6 hrs
#default value is 6 hrs
TIME_OUT=0.25
#For DataExtractor,
HOWMANY_DAYS=8
[system]
## Host:Tag
net-oamfft1:HM
net-oamfft1:UNIX
net-oamfft1:APP
mbridges-u5:HM
mbridges-u5:UNIX
mbridges-u5:APP
## Note: The Host should be either ipaddress or system name
## in both [system] and [hosts] sections
[hosts]
net-oamfft1|APP|UMAPPSUM|/home2/spmaster/r410/logs/netlogs|*.NetRes
net-oamfft1|APP|APPEVE|/home2/spmaster/r410/logs/netlogs|*.NetEve
mbridges-u5|APP|APPEVE|/home2/spmaster/r410/logs/netlogs|*.NetEve
mbridges-u5|APP|UMAPPSUM|/home2/spmaster/r410/logs/netlogs|*.NetRes
## Reports
[UM_Application_Summary]
tag=APP
type=UMAPPSUM
[Event_Log]
tag=APP
type=APPEVE
pattern=Subscriber|SNR|PA|PAT|Caller|FaxPrint|AmisAOut
## Operations
## The following section lists 'host=attributes' for
## UM_Process_Activity.ini
# +[a|f|h|m|o|p|t|F|H|L|M|P]
# where:
# a = Application Launch Object
# h = http server for UMAWI/SAWI/UMSA
# m = MWI
# p = FaxPrint
# t = TNT Object
# P = MWI Plug-in
[UM_Process_Activity]
mbridges-u5=tah
net-oamfft1=ath
##
## File Name: version.ini
##
## @(#)version.ini 120.1.1.1
##
## Each section is identified by the report type
## Entries under each section will have three fields
## separated by ':'. The fields are:
## 1 - Script Name
## 2 - Parameter to pkginfo ex: pkginfo -x field2
## 3 - Output returned from pkginfo on the 2nd line 2nd word
## Note: Entries under each section must start with a 'tab'
## default scriptName would be "<reportName>_csv.awk"
[UMAPPSUM]
UM_Application_Summary_csv_417.pl:dapumapp:4.1.0,REV=7
UM_Application_Summary_csv.418.pl:dapumapp:4.1.0,REV=8
UM_Application_Summary_csv.419.pl:dapumapp:4.1.0,REV=9
UM_Application_Summary_csv.pl:dapumapp:4.1.0,REV=10
[APPEVE]
Event_Log_csv4109.pl:dapumapp:4.1.0,REV=9
Event_Log_csv.pl:dapumapp:4.1.0,REV=10
Posted: Mon Sep 25 19:21:50 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.