CI Resolution

The CI Resolver uses the following strategy to identify the CI that matches an event. The first match from this list of possible matches is used by the CI Resolver to identify the CI to which the event should be paired.

1. Event contains a CI reference. The CI is identified directly from this information and no resolution is necessary. Few events, except for some internal Operations Management events, include a direct reference to the matching CI.

2. CiInfo custom attribute of the event contains a valid RTSM ID, RTSM Global ID, SiteScope monitor ID, or an HPE Operations Agent ID which identifies the related CI. This match is common for events from OM SPIs.

   Note If CiInfo is set, the CI Resolver uses this attribute to identify the CI and then stops the resolution, even if CiInfo does not produce a match.

3. Event Service ID matches a service name that can be mapped by Topology Synchronization into a valid RTSM ID or RTSM Global ID. This match is common for events from OM SPIs.

   Topology Synchronization provides a mapping table that enables the CI Resolver to map Service IDs directly to RTSM IDs if the service was synchronized by Topology Synchronization.

4. Split Service ID into keywords and hostedOn information, and identify the best-fit CI.

5. Use application and object fields and host info and identify best-fit CI.

   In this context, Service ID is the OM message Service ID.

If OMi does not find any resolution hints in an event, it checks the application and object event properties in order to generate a related CI hint. These hints are used to resolve the related CI.

When node CI cannot be resolved from existing hints, OMi performs a retry every minute based on the hint information provided. By default, only events that are between 5 and 8 minutes old are affected. This means that the resolution on an event can be retried up to 3 times. The retry times are configured in the following infrastructure setting:

Administration > Setup and Maintenance > Infrastructure Settings

Alternatively, click Infrastructure Settings.

From the Applications drop-down list, select Operations Management and scroll to Operations Management- CI Resolver Settings.

Resolution Retry Time

Time in minutes after which the CI Resolver does a resolution retry for previously failed attempts. Default: 5

Retries are especially useful when incoming node hints are not sufficient to resolve a Node CI for the first time. Node hints can be modified in EPI in order to achieve successful node CI resolution during the next run.

CI hints can be provided in a number of forms.

The custom attribute is evaluated before the Service ID, ensuring that the Service IDs is overridden by the custom attribute values when available.

RTSM IDs

Format: UCMDB:<id>

Example: UCMDB:3bcbb67a6233cfdd0e400e7c1e637db5

RTSM Global IDs

Format: GUCMDB:<id>

Example: GUCMDB:4acdd67a5433cfaa0b600e7c1e667db9

If a UUID prefixed by the string UCMDB: or GUCMDB: is found, it is assumed to be a native RTSM ID or RTSM Global ID. If the CI Resolver can match the ID to a CI in the RTSM, the CI reference is set to this ID. This is the fastest and most accurate method.

SiteScope Monitor IDs

Format: SiteScope:<session_id>:<monitor_id>

SiteScope:12:2

If a SiteScope ID (SiteScope:<session_id>:<monitor_id>) is found, and if the CI Resolver can match the ID to a CI in the RTSM, the CI reference is set to the CI that is monitored by the SiteScope monitor.

HPE Operations Agent IDs

OmCoreId:<omagentid>

If an HPE Operations Agent Core ID is found, and if the CI Resolver can match the ID to a CI in the RTSM, the CI reference is set to the agent CI.

Service IDs

OSSPI:svc:fs:/dev/hda@@dbsystem.example.com

A traditional service name as used by OM Smart Plug-ins. If this service was synchronized by Topology Synchronization and a corresponding CI was created in the RTSM, the CI Resolver can use this information to directly map the event to the CI. If not, then the service ID is split into keywords.

Natural keys:

CiHint:oracle:database:CMDBDB@@dbsystem.example.com

or

oracle:database:CMDBDB@@dbsystem.example.com

If there is no exact knowledge about the target CI, a list of keywords (usually separated by colons in the message) is extracted from the message. The node name that contains the expected CI is specified after the @@ separator.

In our example, we are trying to find an Oracle Database instance called CMDBDB that is running on the node called dbsystem. The node information is important since there may be many occurrences of the Oracle Database instance called CMDBDB installed on different nodes. This information is used by the CI Resolver to find the best match by comparing these keys with the attribute information of the CIs in the RTSM.

As for a set of natural keys but for an unhosted CI:

mailservice:northamerica

For CIs that are not related to a node, like the email service provided for the northamerica region. To indicate that there is no hosted on information, the @@ separator must be omitted.

If the CI Resolver receives a hint with one or more keywords containing the separation character (default :), the keyword is not assessed as desired because it is divided into two or more incomplete keywords. The separation character is not considered part of the keyword.

IPv6 Hint Resolution

IP addresses can be included as hints. If you are specifying an IPv6 address, enclose it in quotation marks ("..."). For example:

• "<IPv6address>":NETIF@@<hostname>.example.com
• <hint1>:<hint2>@@"<IPv6address>"

RTSM ID Hint Resolution

Some data sources can provide the RTSM ID as a CI hint. However, when forwarding events to another OMi system, this ID might not be known to the second RTSM instance. For such cases, multiple CI hints, including the RTSM Global ID can be sent. If the first hint does not provide a match, the next hint is examined.

When an event is forwarded by Operations Management, the RTSM Global ID is added automatically as an additional hint.

Multiple CI hints are specified using the following format:

<CiHint1>|<CiHint2>|...

where <CiHintX> can be one of the following:

• UCMDB:<RTSM_ID>

• GUCMDB:<RTSM_Global_ID>

• SiteScope:<session_id>:<monitor_id>

• OmCoreId:<omagentid>

• CiHint:<hint1>:<hint2>:...@@<node>

Example:

GUCMDB:4acdd67a5433cfaa0b600e7c1e667db9|c@@dbsystem.example.com

The CI Resolver first checks whether there is a CI with the given RTSM Global ID. This ID usually provides a match as the Global ID should be synchronized across all RTSM instances. If the Global ID is not found, the natural hint (c@@dbsystem.example.com in the example above) is used.

ETI Hint Resolution

The ETI hint field is also used for the matching of a CI by CI resolution. If the ETI hint matches the ETI of a CI, this CI is given a higher match rating.

For example, if the CI hint matches a number of CPU CIs and Node CIs, and it has an ETI hint Memory Load:Critical, CIs with this ETI are given a higher match rating.

The host CI can usually be identified as long as the host information is available as a normal hint. Ideally, the @@node notation (an @@ separator with a specified node) is used to identify the node on which the CI is hosted. However, it can be difficult to uniquely match a dedicated CI if a hosted and a non-hosted CI have very similar attributes. If the @@node notation is not used, the first match found is accepted and this may not be the correct CI.

For example, only the hint CiHint:sendmail is received. If a sendmail service and a sendmail process exist, the CI Resolver is not able to differentiate between them because it does not differentiate between the hosted-on and not hosted CIs.

To differentiate between them, use:

CiHint:sendmail@@mailserver.example.com — to identify the sendmail process running on the mailserver.example.com node.

StrictCiHint:sendmail — to identify the sendmail service. To match, the sendmail CI must not have a hosted-on CI.

The hostedOn information is very important for correctly identifying a CI, and an attempt is made to resolve the node for each CI from the RTSM. The hostedOn information is derived by traversing all parent compositions of a CI until a node CI is found. The hostname of this node is used as the hostedOn information. When an event is received by Operations Management, the node info value of the CI is compared to the hostedOn information of a CI. If they match, the CI is used as a matching candidate.

The CI Resolver is used to update the node reference of an event.

The hints used to identify the related CI, node, source CI and ETI of an event are displayed in the Resolver Hints tab of the Event browser. See Resolver Hints for details.

The following hints are examined in this order to identify a related Node CI:

• HostInfo event attribute

  HostInfo is an attribute from the HPE Operations Agent to identify a target host. It usually contains the fully qualified domain name or the IP address of a host.

• CiInfo custom attribute

  CiInfo contains node information after the @@ separator in the event text.

• Service ID event attribute

  Service ID node information after the @@ separator in the event text.

  The node reference is retrieved from the RTSM as follows:

  1. Fully qualified domain name (primary_dnsname)

  2. IP address taken from the related ip_address in the RTSM:

     • ip_address.authoritative_dns_name attribute

     • ip_address.ip_address attribute

  3. OM core ID. A name attribute taken from the related hp_operationsagent CI in the RTSM.

The HostInfo is an attribute from the HPE Operations Agent to identify a target host. It usually contains the fully qualified domain name or the IP address of a host.

The Service ID event attribute and the CiInfo custom attribute contain node information after the @@ separator in the event text.

The node reference is resolved as follows:

1. Fully qualified domain name (primary_dnsname)

2. IP address taken from RTSM

   1. ip_address.authoritative_dns_name

   2. ip_address.ip_address

3. OM core ID taken from the RTSM entry hp.operationsagent.name.

Source CI resolution is used to identify the event source CI and uses the SourceHint attribute of an event. The format of the SourceHint must be the same as that of the normal CI resolution.

The CI Resolver extracts information about potential candidate CIs from the RTSM using a TQL query and maintains this information in a cache. You can either provide a custom TQL query or use the OMiAutoView feature to automatically generate a suitable TQL.

The OMiAutoView feature selects all CIs and all Service Level Agreements, and queries almost all attributes that are potentially useful for resolving CIs. The attributes that are not queried are excluded using the Cache Modification Configuration.

If you are using the TQL query generated by OMiAutoView, to maximize performance, it is also possible to restrict the total number of CIs held in the cache, and restrict the CI types to those most helpful for CI resolution. Configuring the restriction of CIs and CI types is achieved using the following CI Resolver Settings:

• CI Limit — used to limit the number of CIs loaded into the cache, if loaded by the TQL query generated by OMiAutoView.

• Cache Modification Configuration — used to specify which CI types and attribute types to exclude from the cache, and, if there are too many CIs being loaded into the cache, which CI types to use for CI resolution.

For detailed information, see the CI Resolver Settings.

There are two cache types, enabling you to decide whether the cache is kept on disk or in main memory:

• Database — HPE recommends to use the Database cache type. CI resolution maintains only the most often-used CIs in RAM. All other required CIs are maintained in a cache file. This option requires considerable extra disk space but results in a lower memory footprint. A small impact on CI resolution performance may be noticeable.

• In Memory — HPE recommends to select the In Memory cache type when maximizing event throughput is essential. CI resolution maintains all CIs in RAM. Only use this setting when there is sufficient RAM available.

Maintaining very large numbers of CIs in cache requires large amounts of RAM and also has an effect on performance. Controlling the maximum number of CIs held in cache reduces this load and is achieved by ignoring less relevant attributes and CI types normally selected using the OMiAutoView-generated TQL query. The CI types to be ignored are set in the Cache Modification Configuration setting. You can also specify which CI type should be permitted to be used for CI resolution and in which order they are to be evaluated.

The CI Resolver Cache Modification Configuration settings specify three types of information:

• <IgnoreCiType> — Contains a list of CI types to always be ignored.

If a CI type is specified to be ignored, it is always ignored by the CI Resolver. For example, if you know that you don't receive SAP events, but you have SAP CIs in your RTSM, then you can ignore the SAP CI types, reducing the size of the CI Resolver cache.

• <WhiteListCiType> — Contains a list of CI types that are always required.

If there are too many CI Types to be included in the available cache capacity, the CI types specified in the whitelist are included in the order that they are listed. As soon as it is no longer possible to include the CIs of the next CI type in the list, that CI type and all subsequent CI types in the whitelist are also ignored.

• <IgnoreAttribute> — Contains a list of attributes that are always ignored.

If an attribute is specified to be ignored, it is always ignored by the CI Resolver. You should ignore attributes that not suitable for identifying CIs.

The following is an example of the structure of the CI Resolver Cache Modification Configuration settings

<?xml version="1.0" encoding="UTF-8" ?>
<CiResolver>

  <IgnoreCiTypes>
    <IgnoreCiType>service_address</IgnoreCiType>
    <IgnoreCiType>installedsoftware</IgnoreCiType>
    ...
  </IgnoreCiTypes>

  <WhiteListTypes>
    <WhiteListCiType>node</WhiteListCiType>
    <WhiteListCiType>ip_address</WhiteListCiType>
    <WhiteListCiType>business_element</WhiteListCiType>
    ...
  </WhiteListTypes>

  <IgnoreAttributes>
    <IgnoreAttribute>ip_probename</IgnoreAttribute>
    <IgnoreAttribute>ip_isbroadcast</IgnoreAttribute>
    ...
  </IgnoreAttributes>

</CiResolver>


To configure CI resolution to minimize the type and number of CI and attributes held in the cache, see How to configure CI resolution cache usage.

If the OMiAutoView TQL does not meet your requirements, you can implement a custom TQL query, ensuring that it meets the following requirements:

• CIs that are contained within a node must have a direct or transitive Composition relationship to the node. For the IpAddress CI type, the relationship type must be Composition.

• In the TQL, the node must have one of the following attributes:

  • Primary Node DNS name

  • Association with one or more IP addresses (IpAddress with a Containment relationship)

• At least CI type, data name, and label of the CI must be visible.

• HPE Operations Agents must have Core ID value.

• SiteScope Monitors or performance measures must have a monitored_by relationship to the monitored CI. The monitor_id and session_id must be visible.

  

   

You can configure CI resolution enrichment rules to enrich the CI resolution cache with additional keywords for a specific CI. These keywords are provided by another CI in their neighborhood. To enrich a CI, you can use the tuneCache setting in the Settings Manager by adding an XML item <Enrichment> for an enrichment rule.

Rule Syntax

Enrichment is used to mark a CI with keywords that differentiates the CI from other CIs. This enables the use of the enriched keyword as a hint in an event.

An enrichment rule follows the syntax:

[<source ci type>].(from|to:<relationship type>.[<intermediate ci type>].)+[<target ci>].<attribute name>

The direction identifier before each reference indicates the direction of that reference (from = incoming or to = outgoing).

Supported Types and Operators

[Operators] and [Types] are combined to form a valid CI Resolution enrichment rule.

Examples of supported operators:

• containment

• composition

• monitored_by

• dependency

Supported relation directions:

• to

• from

Supported types:

• [<CITypeName>]

Supported types are any CI types contained in the RTSM, specified within squared brackets. The CI Type's name attribute is the value to put into the squared brackets, for example, [host] or [sitescope_monitor].

Keyword	Description	Example
from|to:<reference>	Follow the relationship of a CI to its neighbor CI by a given direction. from = incoming to = outgoing	from:monitored_by
[<Ci type name>]	Set the CI type.	[dbtable]
<CI type property name>	Property of the CI type.	[dbtable].name

Example Rule:

Assume that you have two Oracle databases, DB1 and DB2 on one system. Both databases have a dbtable CI with the name USER.

CI resolution cannot identify from which CI the event originated using the information available within the hint because the two dbtable CIs can only be differentiated by their parent CI relationship (DB1 and DB2). This information must be added by enrichment. Typically, a related CI hint would look like the following:

USER@@dbsystem.example.com

However, this does not work because the database name is not known.

However, if CI resolution is enriched with the database instance name using a CI resolution enrichment rule, it is possible to run a CI resolution successfully when the event also provides the DB instance name.

Enrichment rule:

To enrich a dbtable CI type with additional information about the CI type host name attribute, you can use the following rule.

[dbtable].from:composition.[oracle].name

A CI resolution enrichment rule can be specified to enrich the keywords cache to also include keywords from the parent CI. In this way, it is possible to resolve the correct dbtable CI if the event also provides the database instance name.

USER:DB1@@dbsystem.example.com

For information about CI resolution configurations, see the CI Resolver Settings.

This task shows you how to configure CI Resolution to minimize the type and number of CI and attributes held in the cache.

Maintaining very large numbers of CIs in cache requires large amounts of RAM and also has an effect on performance. Therefore, controlling the maximum number of CIs held in cache is recommended and this is achieved by ignoring less relevant attributes and CI types. The CI types to be ignored are set in the Cache Modification Configuration. You can also specify which CI type should be permitted to be used for CI resolution and in which order they are to be evaluated.

1. Open Infrastructure Settings:

   Administration > Setup and Maintenance > Infrastructure Settings

2. Select Applications and use the list to set the administration context to Operations Management.

3. Go to the CI Resolver Settings section.

4. Open the Cache Modification Configuration (click the associated Edit Setting button to open the Edit Setting dialog box).

   The Edit Setting dialog box displays the CI Resolver Cache Modification Configuration settings. This information uses XML syntax to specify three types of information:

   • <IgnoreCiType> — CI Types to always be ignored. If a CI type is specified to be ignored, it is always ignored by the CI Resolver.

   • <WhiteListCiType> — If there are too many CI Types to be included in the available cache capacity, the CI types specified in the whitelist are included in the order that they are listed. As soon as it is no longer possible to include the CIs of the next CI type in the list, that CI type and all subsequent CI types in the whitelist are also ignored.

   • <IgnoreAttribute> — Attributes to always be ignored. If an attribute is specified to be ignored, it is always ignored by the CI Resolver:

   The following is an example of the structure of the CI Resolver Cache Modification Configuration settings:

   <?xml version="1.0" encoding="UTF-8" ?>
<CiResolver>

  <IgnoreCiTypes>
    <IgnoreCiType>service_address</IgnoreCiType>
    <IgnoreCiType>installedsoftware</IgnoreCiType>
    ...
  </IgnoreCiTypes>

  <WhiteListTypes>
    <WhiteListCiType>node</WhiteListCiType>
    <WhiteListCiType>ip_address</WhiteListCiType>
    <WhiteListCiType>business_element</WhiteListCiType>
    ...
  </WhiteListTypes>

  <IgnoreAttributes>
    <IgnoreAttribute>ip_probename</IgnoreAttribute>
    <IgnoreAttribute>ip_isbroadcast</IgnoreAttribute>
    ...
  </IgnoreAttributes>

</CiResolver>

5. Specify the CI types and the attributes to always be excluded from CI resolution using the <IgnoreCiTypes> and the <IgnoreAttributes> sections.

6. Specify the CI types to be included if the available cache is not sufficient to load all available CIs. The order of the CI types in the list represent the order in which these CIs are included. As soon as the CIs belonging to a CI type cannot be accommodated in the cache, these CIs are excluded and no further CI Types are assessed.

7. Select Save.

Note Alternatively, you can replace the automatically generated TQL query with a TQL query customized for your environment.

This task shows you how to configure CI Resolution to limit the number of CI and attributes held in the cache.

1. Open Infrastructure Settings:

   Administration > Setup and Maintenance > Infrastructure Settings

2. Select Applications and use the list to set the administration context to Operations Management.

3. Go to the CI Resolver Settings section.

4. Open the CI Limit (click the associated Edit Setting button to open the Edit Setting dialog box).

   The Edit Setting dialog box displays the CI Limit value.

5. Specify a new CI limit.

   Note Maintaining very large numbers of CIs in cache requires large amounts of RAM and also has an effect on performance. Increasing the total number of CI loaded into cache, increase memory usage, which can result in an unstable system. If you must increase the number of CI permitted for CI resolution, make these increases using small increments and make sure that your installation remains stable.

6. Select Save.

OMi uses TQL queries to select CIs from the RTSM and maintains them in the CI Resolver Cache. The CI Resolver compares attributes of discovered CIs held in the CI Resolver Cache with event attributes and event resolver hints to relate each event that OMi receives to a CI in the RTSM.

The out-of-the-box query that OMi uses to query the RTSM is probably broader than you require. You can improve performance by narrowing the scope of the out-of-the-box query so that it loads into your CI Resolver Cache only the CIs that are relevant to your managed environment and to which you expect to map events. If you do not expect to match certain CI types, there is no need to include these CI type in the CI Resolver TQL. For example, if you are only managing Oracle databases, you should exclude databases of other types.

You modify TQL queries using the RTSM Modeling Studio, which provides a graphical representation of the query. You can add or remove information from the query so that it selects only those CIs from the RTSM that you decide are important for your managed environment.

Generally, the procedure for modifying a query is as follows:

1. Start the Modeling Studio: Administration > RTSM Administration > Modeling > Modeling Studio.

2. Select Queries from the drop-down list in the Resources pane.

3. Select the TQL query file:

   <OMi_HOME>/opr/examples/ciresolver/OprSample_CIResoluton_tql.xml

4. Click the Import button in the left View browsing pane.

5. Select Views from the drop-down list in the Resources pane.

6. Select the View file:

   <OMi_HOME>/opr/examples/ciresolver/OprSample_CIResoluton_view.xml

7. Click the Import button in the left View browsing pane.

8. Modify the query to select only the CIs that you need.

9. Use the count button, which shows the CIs and CI types per node, to evaluate if your changes reduce the number of CIs.