Many challenges lie ahead for communication service providers. While NNM addresses many of these challenges, it is difficult, if not impossible, for one product to satisfy all of them. Add-on products such as Customer Views (CV) and Service Information Portal (SIP) extend the functionality of NNM by allowing customization of the physical enterprise to reflect the logical enterprise. Service providers may require additional functionality to adequately manage extra resources, such as applications. In today's always-on infrastructure, there's a higher demand to keep all components of the enterprise up and running.
OpenView Operations (OVO) focuses on managing applications that run in the enterprise. OVO provides centrally configured intelligent agents that monitor specific applications. The OVO agent is supported on multiple platforms, including Windows and many versions of UNIX. This chapter introduces the three types of users, including the OVO Operator, Administrator, and the Template Administrator.
In the simplest form of monitoring devices, a management application can determine whether the device is up or down. NNM does an excellent job of discovering an enterprise and providing up/down status of the managed environment. In addition, NNM provides the ability to capture SNMP traps that are unsolicited messages indicating something on the device has a problem. Taken a step further, monitoring a system's running processes, services, or applications provides a more robust monitoring solution. OVO is designed to help administrators detect, solve, and prevent problems from occurring in the enterprise.
OVO runs in conjunction with the NNM processes in order to extend the management functionality to monitor processes, services, and applications. For example, some of the standard OVO offerings include monitoring syslog (UNIX), rclog (UNIX), and iisadmin service (Windows). The monitored environment can be configured to generate messages when certain errors appear in the syslog and rclog files. Messages can be generated when iisadmin service stops running.
The OVO agent has the ability to capture information from various message sources. These message sources are captured by one of the following interceptors: logfile encapsulator, SNMP trap interceptor, MPE Console, or OVO message interface,[1] as shown in Figure 12-1. The messages are assigned default attributes and presented in the OVO message browser. The message conditions are applied to the message to determine whether to suppress, prioritize, group, reformulate and correlate messages. The logfile encapsulator searches for specific patterns in a logfile. The trap interceptor captures SNMP traps that are sent to the management station and determines how to act on them. The MPE Console output can be monitored with OVO. The message interface is designed for template developers to customize templates that cannot be monitored with the previously mentioned methods.
Figure 12-1. OVO message sources are intercepted by logfile encapsulators, trap interceptors, MPE console, and the OVO message interface. The messages are assigned default attributes and presented in the OVO message browser.
Add-on components are also available to monitor specific applications and databases, such as Oracle®, Microsoft® Exchange Server, and PeopleSoft®. These add-on components are referred to as Smart Plug-Ins (SPIs). SPIs are very sophisticated and typically offer hundreds of monitoring options. SPIs frequently include commands and actions capable of restarting specific processes. SPIs also may incorporate application performance monitoring. For a list of available SPIs, refer to http://ovweb.external.hp.com/lpe/doc_serv.
OVO consists of a client/server solution that allows the configuration to be centrally managed and monitored. The monitoring process is distributed to the managed nodes. Problem resolution can also be distributed to the managed node by including automatic actions associated with the message source template that capture the problem. The messages or events appear in the message browser as shown in the diagram in Figure 12-2.
Figure 12-2. OVO consists of a client/server model that provides central configuration and distributed monitoring. Configuration is performed on the management server and the agents monitor the managed nodes.
The following list describes OVO terminology that will be used throughout the remainder of this book:
Management Server—. The OVO management server is the central location from which all configurations are performed. The management server consists of an Oracle database containing messages generated by the OVO agents.[2] Supported management servers include HP-UX and Solaris. Refer to the Installation Guide for the Management Server for a complete list of supported operating system versions for the management server and the agent available from http://ovweb.external.hp.com/lpe/doc_serv.
Agent—. OVO provides an intelligent agent that must be distributed to all nodes to be managed by OVO. The monitoring process occurs on the managed node. The agent is capable of performing local actions on the node. For example, you might want to monitor a process and restart the process if it stops running. The agent combined with the appropriate template provides this capability. Some of the currently supported OVO agent platforms include HP-UX, Solaris, Windows 2000, Windows XP, Linux, AIX, and Tru64.
Templates—. A template defines the applications to be monitored by the OVO agent. Select templates are assigned and distributed to a managed node based on the applications to be monitored. OVO ships with default templates that provide monitoring for common operating system logfiles and processes. Templates can be developed by administrators to monitor most applications. SPIs extend the functionality of OVO by providing specific application and database templates for applications such as Oracle®, SAP®, and Microsoft Exchange Server®.
Message browser—. The message browser is the focal point of OVO. Messages are events generated by an OVO agent indicating that something has happened on the managed node. Messages that appear in the browser are stored in an Oracle database on the management server.
Managed node—. OVO managed nodes have an OVO agent installed. The agent monitors applications on the node based on the templates assigned to the node.
Events—. An event is something that happens on a managed node. Events of interest might consist of a stopped process or service, an error message in a log file, or an application that is not functioning as it should. Events are detected by the OVO agent and templates assigned to the managed node.
Actions—. The agent is capable of performing local actions on a managed node. For example, you may want to monitor a process and restart the process if it stops running. The agent combined with the appropriate template provides the ability to detect that the process has stopped running and automatically restart the process.
OVO was formerly named Vantage Point Operations (VPO). OVO was also formerly named IT/Operations (ITO) and Operations Center (OPC). The renaming of the product came about with major product releases. However, the original commands and processes have not changed since the original commands used for OPC. Much of the OVO product documentation still contains OPC, ITO and VPO references.
OVO is invoked by typing opc from the command line. The opc command does not require backgrounding (opc&). Backgrounding is handled by the command itself. When you start OVO, you should see the login window shown in Figure 12-3.
Figure 12-3. Start OVO by typing opc from the command line. The default operator login is opc_op and the password is OpC_op. Usernames and passwords are case sensitive.
The default OVO logins include an operator (opc_op) and an administrator (opc_adm) user account. The default passwords are OpC_op for the opc_op account and OpC_adm for the opc_adm. The passwords are case sensitive. Note that these accounts are not affiliated with a Unix login. They are strictly used to login to the OVO application. The operator and administrator logins are described briefly in the following sections of this chapter.
The OVO operator is the user responsible for monitoring the environment. The message browser provides the operator with a view of messages and is the focal point of an operator account. The messages in the message browser indicate to the operator that an event has occurred. An event typically indicates that something in the managed enterprise has gone wrong.
The message browser contains ten columns, as shown in Figure 12-4. Each column provides indicators to the operator. At a glance, the operator can determine where the event originated, the severity of the event, and the type of event that occurred.
Figure 12-4. The message browser is the focal point of OVO. The message browser contains events that indicate to the operator that something has happened. At a glance, an operator can determine the severity of the event, the event message, and node on which the event occurred.
The operator login provides a toolset enabling the operator to perform a job. The job entails attempting to resolve problems listed by the events in the message browser. The operator login consists of five windows, described briefly in the following list:
Root—. The root window is a submap containing the hierarchy of all discovered devices in the enterprise.
Managed Nodes—. The Managed Nodes window contains the managed nodes assigned to the operator. An operator may be responsible for a subset of nodes in an enterprise. Operators are assigned nodes based on the monitored applications and the operator skill set.
Message Groups—. The Message Groups window consists of message groups assigned to the operator. Message groups contain events generated by OVO agents based on monitored attributes such as database, operating system type, or application name.
Application Desktop—. The Application Desktop contains applications and application groups assigned to the operator. Applications can be executed by the operator on a managed node without actually having to log into the system.
Message browser—. The message browser contains messages, message attributes, and status information sent by the managed nodes for which the operator is responsible.
OVO provides a Java-based GUI similar to that shown in Figure 12-5. The java client can be installed on Windows and Unix systems and configured to access the OVO server. The necessary components of OVO are available from the Java-based GUI for an operator to monitor messages and perform routine tasks.
Figure 12-5. The left pane of the Java-based GUI consists of an Explorer-like tree view of managed nodes, node groups, message groups, and applications. The right pane consists of the message browser.
The operator has the ability to limit the messages in the view by setting the filter as shown in Figure 12-5. An additional feature available with the Java-based GUI is the ability to click on a column to sort messages. By default, messages are sorted according to the timestamp. If you were to click the [Node] button at the top of the Node column, the messages would be sorted alphabetically by node name.
OVO makes no assumptions about a managed enterprise. Because of this, the OVO managed enterprise must be configured. The default administrator account is opc_adm and the password is OpC_adm. The administrator account provides the capability to configure the managed environment. The OVO administrator tasks of OVO include:
Adding managed nodes—. Devices connected to the network are discovered by underlying NNM processes (see Chapter 3, “Create a Deployment Plan”). However, devices are not automatically managed by OVO. The administrator must define the devices that to be monitored.
Creating node groups—. Node groups provide a logical means of managing systems. Nodes can be grouped based on attributes such as platform, application or customer. Node groups can be used to assign templates. Node groups are assigned to an operator based on the operator's skill set.
Creating message groups—. Message groups provide a logical means of grouping events that arrive in the message browser. Message groups are assigned to an operator.
Creating and customizing templates—. Templates are assigned and distributed to the managed node to determine what the OVO agent will monitor.
Creating template groups—. Template groups provide a logical means of organizing template. Template groups are assigned and distributed to the managed node to determine what the OVO agent will monitor.
Creating operators—. The default OVO operator account is opc_op. A typical environment will have a separate operator account for each OVO user.
Configuring operators—. The configuration of an operator includes defining managed nodes, applications, message groups. Each OVO operator may have a specific set of managed nodes and message group in which to monitor.
Distribution of agents and templates to managed nodes—. When the managed environment has been defined, the administrator must assign and distribute templates and the OVO agent to the managed node. This installs a process with a small footprint (less than 2% of the CPU) on the managed node. The agent process performs application monitoring and the templates define which applications to monitor.
OVO has one main administrator account, opc_adm that provides the ability to perform all necessary configuration. An OVO implementation may require additional users to assist with template development and customization. For example, specific applications require custom templates and may require a special set of skills and knowledge. Some examples of special skills include knowledge of applications and operating systems such as Oracle, Solaris, HP-UX, and SAP. Because these skill sets are diverse, many different administrators may be required to develop and maintain OVO templates for the corresponding applications.
The template administrator account provides the ability to create and maintain templates and template groups. The template administrator cannot assign or distribute templates. Templates contain parameters for monitoring including the name and location of a file to be monitored, a polling interval, and a set of conditions that capture or suppress messages. Templates also determine what to do with the message source after it has been intercepted. A template dictates whether to suppress, prioritize, group, reformulate and correlate messages.
Note
There is a command-line interface that allows you to maintain nodes, node groups, and template assignments. You must have root privileges to execute this command. For example, if you want to assign and distribute the existing template named OBAgent to the node ob001, execute the following two commands: opcnode -assign_templ templ_name="OBAgent" templ_type=EC_TEMPLATE node_name=ob001 net_type=NETWORK_IP opcragt -distrib -templates -force ob001
OVO focuses on application monitoring. OVO provides centrally configured intelligent agents that monitor specific applications. OVO allows you to monitor processes, services, and applications by distributing agent to the managed nodes. The OVO agent runs on multiple platforms, including Windows and many versions of UNIX. OVO can be accessed from a Motif-based GUI and from a Java-based GUI.
OVO provides three different user types: an administrator to configure the environment, an operator to monitor the environment, and a template administrator to configure and develop the templates needed to monitor the applications. The focal point of the OVO operator is the message browser. A message in the browser indicates to the operator that something has gone wrong. It is the responsibility of the operator to attempt to resolve the problem and return the system or application back to a normal state. Good luck.
[1] The OVO message interface is the opcmsg command. This command may be used in a script or in a compiled program. opcmsg provide the ability for a template developer to adequately monitor an application.
[2] A management server running OVO also runs the underlying NNM processes. When OVO is installed, NNM is also installed. NNM performs the discovery of the nodes. OVO is responsible for monitoring applications running on the nodes.