Searching the Help
To search for information in the Help, type a word or phrase in the Search box. When you enter a group of words, OR is inferred. You can use Boolean operators to refine your search.
Results returned are case insensitive. However, results ranking takes case into account and assigns higher scores to case matches. Therefore, a search for "cats" followed by a search for "Cats" would return the same number of Help topics, but the order in which the topics are listed would be different.
Search for | Example | Results |
---|---|---|
A single word | cat
|
Topics that contain the word "cat". You will also find its grammatical variations, such as "cats". |
A phrase. You can specify that the search results contain a specific phrase. |
"cat food" (quotation marks) |
Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase. |
Search for | Operator | Example |
---|---|---|
Two or more words in the same topic |
|
|
Either word in a topic |
|
|
Topics that do not contain a specific word or phrase |
|
|
Topics that contain one string and do not contain another | ^ (caret) |
cat ^ mouse
|
A combination of search types | ( ) parentheses |
|
Testing and Troubleshooting
To test and troubleshoot the topology synchronization process, you can validate the configuration files, create and view a synchronization data dump, configure the level of detail being logged in the synchronization process log files, and review the writing rules, limitations, and common issues to ensure a clean synchronization from the get-go.
Learn More
You can use the supplied XML schema definitions to validate the correctness of XML configuration files. You can also use the supplied XML schema definition files to make writing new configuration files easier when using a suitable XML editor. You can use Eclipse or another editor of your choice that is capable of validating an XML file against a schema.
XSD XML Schema Definition is a standard from World Wide Web Consortium (W3C) for describing and validating the contents of XML files. XSD files are provided for all XML configuration files.
For more information, see the XML Schema documentation by W3C available from the following website: http://www.w3.org/XML/Schema.
The XML schema definition that you can use to validate contextmapping.xml
is in the following file:
OM for Unix: /var/opt/OV/shared/server/conf/discovery/schemas/mapping.xsd
OM for Windows: %OvShareDir%\server\conf\discovery\schemas\mapping.xsd
The schema files are stored in the following directory:
<OMi_HOME>/conf/opr/topology-sync/schemas
The files are:
package.xsd
-
Validates the
package.xml
file in each synchronization package. containmentrelations.xsd
-
Validates the
containmentrelations.xml
file. datadump.xsd
-
Validates synchronization data files that are created through enabling data dumps or used as input for the enrichment simulator.
mapping.xsd
-
Validates the following mapping files contained in the synchronization packages:
-
Context mapping -
contextmapping.xml
-
Type mapping -
typemapping.xml
-
Attribute mapping -
attributemapping.xml
-
Relation mapping -
relationmapping.xml
-
nodetypes.xsd
-
Validates the node type mapping file
nodetypes.xml
file in each synchronization package.
With a modern XML editor, you can validate a file against a schema. Eclipse, for example, can validate an XML file against a schema, if the top level element of the document contains a reference to an XSD file. To enable validation, add the following attributes to the top level element of an XML file:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="<path or URL to schema file>"
Replace <path or URL to schema file> with the respective path or URL to the schema file against which you want to validate. contextmapping.xml
file, add the following:
<?xml version="1.0" encoding="UTF-8"?> <Mapping xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="<OMi_Home>/conf/opr/topology-sync/schemas/mapping.xsd"> ... </Mapping>
After you have added the reference, the Eclipse editor validates the file and suggests valid elements when pressing CTRL+SPACE during editing. See the following figure for an example.
Note You may have to reopen the XML file after you have added the XSD reference to the XML file before Eclipse starts to validate it and provides suggestions.
You can use a dump of the synchronization data to:
-
Troubleshoot mapping rules to discover incorrect mappings.
-
Compare the data sent to the data in the RTSM database, and the data changed and added during the mapping.
-
Create a dump file to check XPath expressions of rules.
A synchronization data dump contains the synchronized topology data in XML files
There are two separate dumps:
-
The first is recorded following CI data normalization.
-
The second is recorded following the processing of the mapping rules.
To activate the creation of synchronization data dumps:
-
Navigate to the OM Topology Synchronization settings in the Infrastructure Settings Manager:
Administration > Setup and Maintenance > Infrastructure Settings
Alternatively, click Infrastructure Settings.
Operations Management - HPOM Topology Synchronization Settings > Dump data
-
Change the value of Dump data to true.
-
Start the topology synchronization in OM with the following command:
-
OM for Windows. Start the synchronization of topology data:
-
In the console tree, select Tools > HP Operations Manager Tools.
-
Right-click Synchronize Topology and select All Tasks > Launch Tool....
The
startInitialSync.bat
tool is started and begins to send all the topology data to the target management servers.
-
-
OM for UNIX or Linux. Type the following command to start the synchronization of topology data:
/opt/OV/bin/OpC/startInitialSync.sh
-
Here is an example extract from a data dump after mapping has been performed:
<CI> <OMId>Root</OMId> <OMType /> <Caption>Root</Caption> <Node>false</Node> <Service>false</Service> <OMAttributes /> <CMDBId /> <CMDBAttributes /> <CMDBType /> <RootContainerId /> <Children> <RelationType>container_f</RelationType> <CI> <Context>operations-agent</Context> <OMId>03a2f7b2-ec88-7539-0532-c5b07da188dd</OMId> <OMType>agent</OMType> <Caption>Operations-agent on met</Caption> <Node>false</Node> <Service>false</Service> <OMAttributes> <AgentId>03a2f7b2-ec88-7539-0532-c5b07da188dd</AgentId> <Name>met.example.example.com</Name> </OMAttributes> <CMDBType>hp_operations_agent</CMDBType> <RootContainerId>{8BB8864B-CEC9-4B26-BD4C-41F2C97C108E}</RootContainerId> <Dependencies> <RelationType>hosted_on</RelationType> <CI> <Context>VISPI</Context> <Context>nodegroups</Context> <OMId>{8BB8864B-CEC9-4B26-BD4C-41F2C97C108E}</OMId> <OMType>node</OMType> <Caption>met</Caption> <Node>true</Node> <Service>false</Service> <NodeGroupList> <NodeGroupID>OpenView_Windows2000</NodeGroupID> <NodeGroupID>Root_Nodes</NodeGroupID> </NodeGroupList> <MACAddressList /> <OMAttributes> <AgentId>03a2f7b2-ec88-7539-0532-c5b07da188dd</AgentId> <CommType>HTTPS</CommType> <DiscoveryDomain>${DefaultDomain}</DiscoveryDomain> <Domain>example.example.com</Domain> <Name>met.example.example.com</Name> <OSType>Windows_32</OSType> <OSVersion>2000 (5.0)</OSVersion> <SystemType>x86/x64 Compatible</SystemType> <VirtualNodeType>0</VirtualNodeType> </OMAttributes> <CMDBId /> <CMDBType>nt</CMDBType> <RootContainerId /> </CI> </Dependencies> </CI> </Children> </CI>
To view synchronization data dumps, navigate to the directory:
<OMi_HOME>/opr/tmp/datadump
The directory contains the following subdirectories:
-
pre-enrichment
Contains the synchronization data after the CI data structure has been normalized. The data reflects what has been loaded from OM to the RTSM.
-
post-enrichment
Contains the synchronization data after the mapping rules have been executed on the normalized data.
-
ws-data
Contains raw data which was read from the OM web service. For each OM node, node group, and service, there is an XML file called
Caption_OMId.xml
.Only in the case where writing to the RTSM failed, the XML file is written to the
post-ucmbd
directory.
To validate mapping rules, complete the following steps:
-
Compare file differences.
Using a file comparison tool of your choice you can easily see what has been changed during enrichment.
-
Validate XPath expressions.
You can validate XPath Expressions that are used in mapping rules by loading the normalized synchronization data dumps into an XML editor that supports XPath queries.
Note An XML document must have a single root element (
<ci>
) in the data dumps. When running XPath queries in the mapping rules, this root element does not exist. For testing with dump files, when you create absolute expressions, prepend the expression/ci
to your test expression.
This section contains a set of guidelines for writing rules.
Simplifying Rule Development
You can ease the writing of rules by selecting an XML editor that can validate and suggest elements according to an XML schema. See Validate XML configuration files for more information.
Avoiding Complex XPath Queries
Avoid complex XPath queries, especially in general conditions, where such queries must be applied to every CI. If you cannot avoid a complex XPath query, try to narrow the condition using operators such as OMType
, combined using the And
operator. Make sure that the simpler, non-XPath conditions are checked first (hint: And
is an exclusive operator).
Matching Against Existing Attributes Only
Accessing attributes that do not exist for all CIs is very performance intensive in combination with a relative expression depending on the complexity of the
Avoiding Broad XPath Expressions
Certain complex XPath expressions can result in excessive processing loads. For example, XPath expressions that include the following characteristics:
-
Apply to multiple nodes, such as expressions that contain
//
ordescendants:*/
-
Do not match nodes or match only on nodes that are very distant from the current node
The same applies to the XPathResultList
operator that returns all matched values. The time required for such operations grows approximately quadratically with the size of a hierarchy. Avoid such expressions where possible.
When using the descendants operator, do not use the star symbol (*
) as node test, but specify the name of the node of interest. For example, do not use descendants:*/caption
but use descendants:ci/caption
.
If you cannot avoid such an XPath expression within a condition, try to limit its execution by using the exclusive And
operator and perform simple tests before the XPathResult
operand is being used. For example, you could first check for the CI type.
Topology synchronization logs details of the synchronization process in log files. You can change the level of detail for debugging purposes.
Service Discovery Server Log Level Configuration
The service discovery server supports the following log levels:
-
Log level 1 logs errors only.
-
Log level 3 logs errors and information (including raw data received from the agent).
-
Log level 10 logs tracing information for debugging purposes, for example method parameters.
To change the log level of the service discovery server:
-
In a command prompt, run the following command:
ovconfchg -ovrg server -edit
You can see the log in a Notepad window.
-
Edit the file by adding
LOG_LEVEL=10
to the[om.svcdiscsserver]
namespace.
The service discovery server generates the following log file:
%OvShareDir%\server\log\OvSvcDiscServer.log
/var/opt/OV/shared/server/log/OvSvcDiscServer.log
Mapping Log Level Configuration
To change the log level of the mapping engine, follow these steps:
-
Open the following file in a text editor:
<OMi_HOME>/conf/core/Tools/log4j/wde/opr-svcdiscserver.properties
-
Locate the line starting with
loglevel=
-
Set the log level to any of the following values (for example,
loglevel=INFO
):DEBUG
designates fine-grained informational events that are most useful to debug an application.INFO
designates informational messages that highlight the progress of the application at coarse-grained level.WARN
designates potentially harmful situations.ERROR
designates error events that might still allow the application to continue running.FATAL
designates very severe error events that will presumably lead the application to abort.
The mapping engine generates the following log file:
<OMi_HOME>/log/wde/opr-svcdiscserver.log
The log files specified under File locations are a good starting point for troubleshooting.
The most common issues are listed in the following table. The issues apply to topology synchronization generally, unless otherwise specified.
Symptom |
Cause |
Solution |
|
---|---|---|---|
Topology synchronization fails.
|
Required patches for OM for Windows were not installed. See the OMi Readme for details, including information about any required agent hotfixes or patches.
|
Operations Manager for Windows: Install Patches OMW_00138 or superseding and OMW_00123 for OM 8.1x for Windows. Install Patches OMW_00139 or superseding and OMW_00124 for OM 9.00 for Windows. See the OMi 9.10 Release Notes for details. |
|
Operations Manager for UNIX or Linux: Install Patch PHSS_42736 or superseding for OM 9.10 for HP-UX. Install Patch OML_00050 or superseding for OM 9.10 for Linux. Install Patch ITOSOL_00772 or superseding for OM 9.10 for Solaris. |
|||
Topology synchronization fails. |
Synchronization package was changed on disk, but not uploaded to the database. |
Run the |
|
Result of dynamic topology synchronization is incomplete or empty. | Discovery policies (DiscoverOMTypes and DiscoverOM ) are deployed prior to configuring the OMi instance as a target server in OM. |
On the OM management server, run the command ovagtrep –publish . This command resends all topology data to the OM or OMi instances. |
|
All of a sudden, no more |
The |
Check if the |
|
Warnings in the log file. |
Model-related issues. |
No immediate action required, however topology synchronization performance can be affected. |
|
You created your own synchronization package but you only get a cryptic |
Mapping-related issues. |
Enable the data dump option and check if the file in the |
This section describes some known limitations relating to topology synchronization.
Delta Detection Limitations
If an attribute of a service or node in OM changes, and that attribute or node is mapped to a key attribute in the RTSM, the delta detection does not delete and replace the old RTSM CI instance, but generates an additional new instance.
Here is an example to illustrate this. Consider a managed node in OM for Windows that has an agent ID of aaaaa-bbbb-cccc-dddd
. This node maps to a host CI in the RTSM and an agent CI with the key aaaaa-bbbb-cccc-dddd
.
In OM, a change is made to the agent ID, so that the agent ID is now aaaaa-bbbb-cccc-eeee
. A new agent CI with the key attribute aaaaa-bbbb-cccc-eeee
is created, but the old one is not deleted. So there are now two RTSM instances relating to the same (changed) managed node.
Workaround: To overcome this limitation, you must manually delete the old RTSM instance.
Topology Synchronization Limitation
Event changes from the OM discovery server are registered with the WMI Listener, and forwarded through the WMI to startInitialSync.bat
runs.
We welcome your comments!
To open the configured email client on this computer, open an email window.
Otherwise, copy the information below to a web mail client, and send this email to ovdoc-asm@hpe.com.
Help Topic ID:
Product:
Topic Title:
Feedback: