HP OpenView System Administration Handbook [Electronic resources] : Network Node Manager, Customer Views, Service Information Portal, HP OpenView Operations نسخه متنی

16.1 EMBEDDED PERFORMANCE AGENT (OVOA)

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

• Control Daemon (ovcd)

• Message Agent (opcmsga)

• Action Agent (opcacta)

• Logfile Encapsulator (opcle)

• Monitor Agent (opcmona)

• Message Interceptor (opcmsgi)

• Trap Interceptor (opctrapi)

The performance data collection and communication agents are

• Embedded Performance Component (coda)OVOA-EPC

• HTTPS-basedcommunication agent (ovbbccb)

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).

16.1.1 OVOA Installation

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 is shown here:

# 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

16.1.2 Performance Data Provided by OVOA

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

• FS (File System) metrics

16.1.3 OVOA versus OVPA

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.

• Single metric alarming.

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

16.1.4 OVOA Configuration

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.

16.1.4.1 Deploy the Embedded Performance Agent Template

Let's walk through an example of configuring and installing an OVOA template on HP-UX:

1. 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).

     Figure 16-2. A template condition shows the threshold for the GBL_CPU_UTIL metric data collection from the OVOA.

     
     

     [View full size image]

     

   • Assign and distribute the template to the managed node (see Figure 16-3).

     Figure 16-3. The OV monitor template distribution process is the same as that for other components.

     
     

     [View full size image]

     

   • Check the template distribution on the managed node using the

     opctempate (or

     ovpolicy ) command; refer to Figure 16-4.

     Figure 16-4. The OVO templates (policies) are shown in the output of the

     opctemplate (

     ovpolicy ) command.

     
     

     [View full size image]

     

   • Review the results in the active message browser as shown in Figure 16-5

     Figure 16-5. The OVO monitor template distribution status is shown in the message browser.

     
     

     [View full size image]

     

   Figure 16-1. Create a new OVOA monitor template.

   
   

   [View full size image]

   

16.1.4.2 The Hook Between opcmona and OVOA

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.

16.1.5 Interface with Other Programs

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.

16.1.6 Commands and Files

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.

16.1.6.1 Frequently Used Commands

• 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

16.1.6.2 File Locations

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

• ./tmp/coda_list
  Temporary file

16.1.6.3 Data 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.