OpenView Operations version 7.0 introduced the embedded performance component. The OVOA is specifically designed to help you get more out-of-the-box performance information. The OVOA is supported on HP-UX, Solaris, Linux, AIX, Tru64, and Windows/NT platforms. While the OVOA collects a fixed set of performance metrics, you can set up threshold monitors through regular templates that only trigger events/messages for a subset of metric threshold violations. The typical installation of the agent software includes
The performance data collection and communication agents are
The OVOA facilitates metric data collection and reporting. Along with the performance agent, there is also a dedicated communication program referred to as the HTTPS-based agent. The startup and shutdown of the embedded performance agent and the HTTPS-based agent is the responsibility of the control daemon (ovcd).
OVOA installs automatically with the other OVO agents. When performing a manual installation (by copying the agent components) from the server to the node via ssh, ftp, or installing the agent software from a local CD-ROM, the OVOA component (perf_pkg.Z) and the HTTPS-based agent (comm._pkg.Z) are included in the list of selected OVOA components. After the installation, you can check the agent process status with the
ovc command to confirm that the embedded performance component and the communications component are running.
The performance agent is a registered subagent. This means it can also be stopped and started with the subagent option on the
ovc command (such as ovc stop coda). The HTTPS-based agent is not a subagent of the controldaemon, although the control daemon handles startup and shutdown. The output from the agent status command
# ovc -status ovcd Control Daemon CORE (1713) Running ovbbccb HP OpenView BBC Communications Broker CORE (1446) Running ovconfd HP OpenView Config and Deploy CORE (1714) Running ovcs HP OpenView Certificate Server SERVER (1715) Running opcmsga OVO Message Agent AGENT,EA (1733) Running opcacta OVO Action Agent AGENT,EA Aborted opcmsgi OVO Message Interceptor AGENT,EA (1725) Running opcle OVO Logfile Encapsulator AGENT,EA (1727) Running opcmona OVO Monitor Agent AGENT,EA (1729) Running opctrapi OVO SNMP Trap Interceptor AGENT,EA (1731) Running opceca OVO Event Correlation AGENT,EA Stopped opcecaas ECS Annotate Server AGENT,EA Stopped coda HP OpenView Performance Core (1734) Running
There are over 1000 possible performance metrics available for data collection if you have the right data collection tools. OVOA collects ~120 metrics depending on the vendor platform. ~30 metrics that are common (global) to almost every platform are available via OVOAs data collection environment. Consult the OVOA Metrics Help Text© for details and descriptions of the metrics. Refer to the document Appendix C, "Resources," for additional information on performance metrics.
The classes of metrics available are listed here for reference:
GLOBAL metrics include cpu, disk, network interface, operations, swap, file system, system calls, and table metrics
CPU (Processor) metrics
DISK metrics
NETIF (Network Interface) metrics
The OVO performance component collects a set of ~30 common system metrics referred to as the "Golden Metrics." A list of the most frequently collected system metrics is provided in Section 16.1.6, "Commands and Files." Use CODA for the data collection of the most common metrics. If it is necessary within your environment to collect additional metrics, consider adding the OpenView Performance Agent.
The embedded performance agent and OpenView Performance Agent can co-exist on the same managed node. With that said, you might wonder why would you need both. On the other hand, how can you decide which one is right for your environment? Let's compare the features of the two performance agents to determine which one best accomplishes the job of monitoring your environment.
Features of the OVOA:
Included as part of OVO (free!).
Collects configuration, cpu, swap, disk, memory and network metrics.
No
Application Response Measurement (ARM) Support.
Data is viewable using OpenView Performance Manager (for more information on this product visit http://openview.hp.com/products/ovperf/indexl).
Runs one performance daemon.
Alarms set via the OVO threshold template.
No export, extract or customization. Requires OV Reporter for data extraction.
The OVOA database is not configurable.
Data is available to some external OV programs such as OV Reporter and OV Performance Manager but cannot be exported for use in "arbitrary" programs. Features of the OVPA:
Can be purchased as a separate product or in GlancePlus Pak.
Collects OS, global, application, process-level metrics, network, and user-defined data sources via a data source integration (DSI) and application program interface (API).
Supports ARM 2.0 extended.
Data is viewable by PerfView NT and PerfView UX, OVPM UX, and OVPM NT.
Runs several performance daemons.
Alarms set in alarmdef file.
User-defined alarms can be based on any logical combination of metrics.
Provides extract export, customizable data base, alarming, historical and current data storage.
Database configuration is provided.
Data is available to external programs such as OV Reporter and OV Performance Manager and can be exported in various formats so it can be used with almost any other program.
Multiple metrics can be combined to generate alarms
Uses DSI metrics from external applications or SPIs can be used to generate alarms
Configuring the managed node for extracting data from the embedded performance component is as easy as configuring a monitor template. In fact, that is the primary method used to extract data from OVOA. The monitor agent periodically collects the metric data, defined within a monitor template. The monitor agent collects the data from the embedded performance subagent through a query interface. The message is then sent to the management server via the message agent if the value of the collected metric violates the defined threshold.
Let's walk through an example of configuring and installing an OVOA template on HP-UX:
Create a new monitor template (see Figure 16-1) and add the special syntax for the embedded performance agent. The trigger for the data collection is found in the string inside the Monitor Program or MIB field on the template OVPERF\\CODA\\GLOBAL\GBL_CPU\UTIL; each section of the key is described here:
OVPERF keyword for CODA (OVOA)
CODA name of the data source
GLOBAL object class (others include: CPU, NETIF, FS, DISK)
GBL_CPU_UTIL metric
Figure 16-1 is an example of the syntax to collect one of the performance metrics. The template data collection syntax for a Window node would look like the following: NTPerfMon\\FTP Server\\Current Connections\\_Total
Create a template condition for the threshold. (See Figure 16.2).
Assign and distribute the template to the managed node (see Figure 16-3).
Check the template distribution on the managed node using the
opctempate (or
ovpolicy ) command; refer to Figure 16-4.
opctemplate (
ovpolicy ) command.
Review the results in the active message browser as shown in Figure 16-5
Recall that there is another process, called the HTTPS-based agent, introduced with OVO 7.x. The agent is used as the mechanism for storing the metrics in the database files and provides communication between OVOA and opcmona. As an example, when the monitor agent starts it reads the configuration file for monitors. Using the information from the template, opcmona requests the data specified from OVOA. It communicates to the OVOA via the BBC. The frequency of requests for data (the interval you program in the template) may vary, but the updates to the data files from OVOA are fixed at five-minute intervals. Therefore, the recommendation is to set the monitor template interval at no less than 5 minutes.
OVOA allows other OpenView programs access to the metrics, such as
OV
Performance Manager (OVPM), SPIs, and
OV
Service Reporter (OVSR). Refer to the OV Performance Agent product documentation (web links are provided in Appendix C) for details on how to integrate these applications with OVOA. Creating and distributing templates that will utilize external programs such as the opcmon (API) is another powerful options which lends itself to more flexibility in that you can parse the output from standard UNIX commands (such as vmstat) to produce a metric value that is returned to the opcmona for evaluation. Refer to Section 16.4 for an example of creating a template for use with the command opcmon.
OVOA has a command set, files and directories. You can now perform the same task with more than one command. For example, to start and stop the OVOA/CODA process, you could use
opcagt (OVO 7.x),
ovc (OVO 8.x) or
codautil (OVO 7.x and 8.x). Always stop and start the process with the same command.
ovc status Display the status of the OV agents.
opcsubagt disable coda Disable coda data collection.
opcsubagt enable coda Enable coda data collection.
codautil start Start coda subagent.
codautil stop Stop coda subagent.
codautil obj List data sources (new with OVO 7.12 agent patch).
codautil dumpds Dump the data source (new with OVO 7.12 agent patch).
codautil status Check coda status.
codautil support Test the coda data collector.
The output from the
codautil support command will print to standard out and display the CODA version, metrics available, and the current collection of metric values. An example of the output from the command
codautil support is shown here:
=== 04/29/03 00:50:00 Instance: 0 GBL_COLLECTOR: Coda A.07.10.05 GBL_INTERVAL: 300.00 GBL_OSNAME: HP-UX GBL_OSVERSION: U GBL_OSRELEASE: B.11.11 GBL_MACHINE: 9000/800 GBL_NUM_CPU: 1 GBL_MEM_PHYS: 786432 GBL_NUM_DISK: 2 GBL_NUM_NETWORK: 1 GBL_MACHINE_MODEL: 9000/800/A400-44 GBL_STATTIME: 04/29/03 00:55:00 GBL_ACTIVE_CPU: 1 GBL_RUN_QUEUE: 0.19 GBL_CPU_SYS_MODE_UTIL: 0.09 GBL_CPU_USER_MODE_UTIL: 0.37 GBL_CPU_TOTAL_UTIL: 0.46 GBL_DISK_PHYS_IO_RATE: 2.42 GBL_INTERRUPT_RATE: 310.90 GBL_SWAP_SPACE_AVAIL: 2092.09 GBL_SWAP_SPACE_UTIL: 40.50 GBL_MEM_PAGEIN_RATE: 0.03 GBL_MEM_PAGEOUT_RATE: 0.00 GBL_MEM_UTIL: 97.69 GBL_NET_IN_PACKET_RATE: 3.57 GBL_NET_OUT_PACKET_RATE: 1.56 GBL_NET_ERROR_RATE: 0.00 GBL_FS_SPACE_UTIL_PEAK: 77.73
The locations and brief descriptions of the OVOA files for HP-UX, Solaris and LINUX platforms are shown here for reference.
/var/opt/OV/log/OpC/coda.txt Coda readme file
/var/opt/OV/log/coda.log Logs, OVOA start, stop, open, create, delete, log file rollover, and status messages
/var/opt/OV/bin/OpC/monitor /ddfcomp_coda, ddflog_coda,ddfcomp_codaAA, ddflog_codaAA used to create objects inside the coda database
/var/opt/OV/databases/coda.db Coda database file and up to five numbered coda database files
The data for the embedded performance component database log files is extracted every five minutes. It is estimated that 25MB of disk space is required. This estimate is based on the following formula: 1 metric instance = 8 bytes, multiplied by the number of instances and the number of times per day. For example, if you have 3 metrics collected every 5 minutes for one day (288 collection intervals) for 10 disks, multiplied by 8 bytes, the daily collections for the 10 disks would require ~69,120 bytes. Continue this calculation rule for the other objects on the system (such as CPUs, disks, file systems, and so on). So, estimating 25MB (5MB/data file) is really a minimum requirement for the disk capacity to store the data in the embedded performance agent (coda) logs. The log files are created once per week for five weeks. At the end of the fifth week, the sixth log file is created and the first log file is deleted. This is by design and cannot be altered. This process called "rollover" happens every Sunday at 12 a.m.