لطفا منتظر باشید ...
21.2 OVO DOCUMENTATION
OVO administrators should consider documentation that includes network layout, nodes, node groups, templates, applications, operator configuration, and SPIs. Both OVO and NNM can be used to gather documentation. Much of the documentation gathering can be automated using OVO commands. Additional documentation may include screen captures of the user interface.
OVO operators can also provide documentation via the Message Browser. If an operator determines a solution to a recurring problem, he or she can add an annotation to the message. This annotation might describe a fix that can be automated in OVO. The administrator can then modify the associated message source template to execute an automatic action that would resolve the recurring problem alleviating user intervention.
21.2.1 Documenting the Network Layout
The network layout can play a critical role in determining outages. For example, assume that a distributed application consists of components located in different geographical regions. OVO may be reporting a problem that appears to be an application that is down, when in reality a network outage has prevented the application from communicating with a database server located in a different geographical region. Another similar scenario is a client that is trying to access an application located in a different geographical region. Both examples appear to be an application outage, but may also be caused by a network outage.
The ovw GUI can be used to capture the network layout. Document important submaps that contain mission critical devices such as database and application servers. You may also want to document the network submaps that include the client systems that require access to the applications. Use a screen-capturing tool such as Paint Shop Pro® for capturing screen shots of network maps for documentation.
21.2.2 Documenting Nodes, Node Groups, and Templates
The OVO command
opcnode [6] can be executed from the command line to list Node Groups, Message Groups, Template Groups, and so on, for accurate documentation. Refer to the manpage on
opcnode . This utility helps immensely when documenting OVO customizations. Listed here are some examples of the
[6] The opcnode command requires root access.
The following command lists all nodes in the OVO node bank. This command also displays the symbol label, IP address, network type, machine type, and communication type:
opcnode list_nodes
List of all Nodes in the ITO database:
===========================================================
Name = xback1.hp.com
Label = xback1
IP-Address = 20.32.122.15
Network Type = MACH_S400, NETWORK_IP, CONSOLE_TEMPLATE, COMM_NCS
Machine Type = MACH_OTHER, NETWORK_NO_NODE, UNKNOWN_TEMPLATE,
COMM_UNSPEC_COMM
Comm Type = MACH_S400, NETWORK_IP, CONSOLE_TEMPLATE, COMM_NCS
=============================================================
Name = xnaodws.atl.hp.com
Label = xnaodws1
IP-Address = 20.32.12.15
Network Type = MACH_S400, NETWORK_IP, CONSOLE_TEMPLATE, COMM_NCS
Machine Type = MACH_WINNT
Comm Type = MACH_S700, OPCMSG_TEMPLATE, COMM_DCE_TCP
=============================================================
Name = xshell.hp.com
Label = xshell
IP-Address = 12.32.122.15
Network Type = MACH_S400, NETWORK_IP, CONSOLE_TEMPLATE, COMM_NCS
Machine Type = MACH_HP11_PA_RISC
Comm Type = MACH_S800, COMM_DCE_UDP
=============================================================
Operation successfully completed.
The next
opcnode command lists all node groups defined in OVO:
opcnode list_groups
Sample output:
List of all Node Groups in the ITO database:
===========================================================
Name = Agent_Check_NT
Label = Agent_Check_NT
Description = Custom Agent check for Windows NT Systems
===========================================================
Name = Agent_Check_UX
Label = Agent_Check_UX
Description = Custom Agent check for HP-UX Systems
===========================================================
Name = hp-ux
Label = hp-ux
Description = HP-UX Systems
===========================================================
Name = VirtualVault
Label = VirtualVault
Description = node group for VirtualVault systems
===========================================================
Name = net_devices
Label = net_devices
Description = Network Devices
Operation successfully completed.
This
opcnode command allows you to display all nodes in the node group listeded from the previous command.[7] The following lists all nodes assigned to the
[7] OVO allows you to group nodes together by including common nodes in a node group. Templates can be assigned to a group of nodes as well as individual nodes.
opcnode list_ass_nodes group_name=hp-ux
Sample output of the above command:
List of Nodes assigned to 'HP-ux':
===========================================================
Name = xback1.hp.com
Label = xback1
===========================================================
Name = xaodws.hp.com
Label = xaodws
===========================================================
Name = x3107nt.hp.com
Label = x3107nt1
===========================================================
Name = xsdrpt1.hp.com
Label = xsdrpt1
===========================================================
Name = xaodfs1.hp.com
Label = xaodfs1
===========================================================
Name = xaod001.hp.com
Label = xaod001
===========================================================
Name = xodsext.hp.com
Label = xodsext
===========================================================
Operation successfully completed.
The following opcnode command displays the templates assigned to the node named jasmine. If the template administrator is descriptive with template naming, this list is self-documenting. Otherwise, you may want to include additional information about the template and template conditions with your documentation.
opcnode list_ass_templs node_name=jasmine net_type=NETWORK_IP
Sample output:
List of Templates and Template Groups assigned to 'jasmine':
===========================================================
|MSG| mwa_4.3_UX
|SCH| housekeep_1.1_SCHED_UX11
|GRP| Agent Up Check
|GRP| HP WAN Monitoring
|GRP| Health Check
|GRP| MB:HP-UX 11
|GRP| MC/SG physical Management Server
|GRP| OPC: Core Infrastructure
|GRP| OS:HP-UX 11.x
|GRP| System Monitoring
===========================================================
Operation successfully completed.
The output of
opcnode can be saved to a file.[8] When you are comfortable using the
opcnode command, you can develop scripts to automate the documentation of your OVO environment. SPIs typically consist of a group of templates, applications, commands, and actions. The commands may be scripts or binary executables. Your documentation should include nodes, node groups, and templates.
[8] The
opcnode command is not limited to displaying information. It can be used to modify the OVO environment.
opcnode allows you to assign and de-assign templates as well as add and remove nodes to and from node groups.
21.2.3 Documenting Applications and Operator Configuration
Each operator is assigned a group of applications designed to assist him or her in returning the managed node back to a normal state. It is important that the OVO administrator assign the applications to an operator based on the operator's responsibilities. For example, an HP-UX operator should have access HP-UX applications that would allow problem resolution for HP-UX systems. An Oracle® operator should have access to the appropriate database applications.
Operators must be configured with a set of responsibilities in order to see messages in the browser. An operator is configured by assigning node groups and/or message groups to the operator. Configuration of the operators should be documented to verify that an operator is actually receiving messages. A screen capture of the operator configuration from the administrator GUI is good way to document operator configuration.
Operator configuration also includes applications and application groups assigned to an operator. A screen capture of an operator's application desktop such as the one shown in Figure 21-2 is a good way to document assigned applications.
Figure 21-2. Documenting the operator's application desktop ensures that each operator has access to the necessary tools.
height="293" SRC="/image/library/english/10090_21fig02.jpg" >
21.2.4 Documenting SPIs
SPIs typically consist of a group of templates, applications, commands, and actions. The commands may be scripts or binary executables. SPIs can be documented similarly to templates and applications. In addition to documenting the templates and applications, you should provide a directory listing of scripts and executables defined by the SPIs implemented in OVO.
21.2.5 Operator Documentation
While operators do not have access to modify the message source templates, they have the ability to add annotations (notes) to a message in the message browser. For example, an operator determines how to resolve an issue by logging into the system and executing a command. If this is a recurring problem, the operator can include details of the solution by adding an annotation to the message.
When the OVO administrator reviews the annotation provided by the operator, he or she might do one of several things. If the solution is simple and requires the execution of a command and executing this command always resolves the problem, this command can be added as an automatic (or operator-initiated) action to the message source template.
Another way the administrator may handle a problem is to create an application that would perform the task that resolves the problem. In this case, the operator is forced to execute the applicationthe action is not automatic.
In addition, the administrator could add procedures to the Instructions field of the message source template condition. In this example, the documentation has come full circle from the administrator to the operator back to the administrator. The documentation cycle should continue throughout the lifecycle of OVO.
