Device Correlation Configuration

 
uimpga-ga
 
 
 
3
 
 
Warning!
Different versions of CA UIM use different database schema for the UIM database. This document assumes that you are using CA UIM 8.5.1 or later. If you are using a different version of CA UIM, the following items may not be valid as described in your CA UIM environment:
  • UIM database table and column names.
  • Example SQL queries to the UIM database.
Note: CA Technologies reserves the right to make schema changes in subsequent versions of CA UIM that render the content of this document invalid.
Overview
device_correlation_configuration
Device correlation is the process of associating the device properties from a probe with the correct device in the UIM database.
The latest version of the discovery_server probe improves the default device correlation logic and allows for a high degree of customization. Improvements to device correlation include:
  • Enhanced built-in correlation rules
    • Match on a combination of properties to provide a more accurate result.
    • Expanded name correlation.
    • Less reliance on origin for matching.
  • More customizability
    • Built-in rules have more configuration options.
    • Users can create their own rules.
    • The order of rules can be specified.
  • Flexibility to support different environments
    • Support for single and multi-tenant environments.
    • Matching on origin can be disabled where there is no overlap in names or IP addresses.
    • Multiple origins can be grouped and treated as equal for correlation purposes.
Terms
The following device correlation terms are used in subsequent sections.
 
Perspective Device
 
A probe perspective of a device. The perspective of a device consists of the properties the probe collects about a device.
These values are stored in the cm_device and cm_device_attribute database tables.
 
Source Device
 
The perspective device from a probe that is being correlated.
 
Target Device
 
 A perspective device that exists in the database that is a possible matching device during correlation.
 
Master Device
 
The merged representation of a device from one or more perspectives.
The values are stored in the cm_computer_system and cm_computer_system_attr database tables.
 
Device Correlation
 
The process of associating an incoming source device with an existing target device in the database.
 
Correlation Property
 
A property that is used to match a source device with a target device.
 
Decorrelation Property
 
A property that is used to prevent a source device from matching with a target device.
 
Correlation Rule
 
A rule defining the set of correlation properties that are used to match a source device with a target device.
How Correlation Works
You should understand of how correlation rules and properties function before you modify the device correlation configuration.
The device correlation rules run as shown in the following diagram. If a matching device is found, the remaining rules are not executed.  
Correlation Rule Logic
Correlation Rule Logic
  1. Correlation (match_on_all) properties are used to match a source device with a target device.
  2. If a possible match is found, the decorrelation (unmatch_on_any) properties are evaluated against all perspective devices of the target master device.  If both the source device and other target device include a specified decorrelation property and their values are different, then the target device is discarded.
  3. A matching device is found when all correlation properties for a rule match with a target device and is not discarded by any of the decorrelation properties.
How to Get Best Results from Correlation
The accuracy of device correlation is highly dependent on the extent of device information published by probes to the Discovery Server. You might not have control over the published device information with some probes, but here are examples where you can help:
  •  For simple probes like net_connect that only publish the information provided by the user, it is highly recommended that you set up device profiles with a hostname and IP address instead of only an IP address.  This will enable correlation by name and IP and be less reliant on origin for matching.
  • When using the Discovery Wizard to set up discovery agents, you will get the best results if you include SNMP, SSH, and/or WMI credentials to discover more complete device details.
  • When using the vmware probe, you should install the VMware tools for guests (guest tools) on virtual machines for the vmware probe to obtain the IP address and hostname of virtual machines.
The other area where you can help is to assign origins strategically in your UIM environment to aid correlation. Because an IP address or simple hostname (not FQDN) might not be unique in an environment, origin is used as a qualifier when correlating an IP address or simple hostname. If origins are not assigned carefully, it can prevent correlation from making a match.
The default origin is the name of the hub within the UIM environment from which device information originates. With multiple hubs, accepting this default can lead to problems if there is no reason for each hub to have a different origin. It would be less problematic to assign every hub the same origin and then override it at the hub or robot only if there is a specific reason to do so. For example, if there are overlapping IP addresses or names across locations, then a different origin should be assigned for each location.  For multiple tenants, a different origin should be assigned to each tenant to separate their data.
Configuring Device Correlation
The device correlation configuration is specified in the <device>/<correlation> section of the %UIMHOME%\probes\service\discovery_server\discovery_server.cfg file. Details are explained in the following sections.
Use Raw Configure in the discovery_server probe or a text editor to modify discovery_server.cfg. After making changes, restart the discovery_server probe to enable the changes.
Considerations Before Modifying the Default Configuration
  • In an existing UIM environment, we strongly advise experimenting with this feature in a test environment before applying it in your production environment.
  • In a complex network environment, fine-tuning device correlation rules can be a trial-and-error process. Modifying the correlation rules might produce unexpected results. A new configuration might result in duplicate devices (under-correlation) or different devices might appear as one (over-correlation). In either case, some cleanup might be needed to repair unexpected correlation results.
  • Before you start, identify what constitutes device uniqueness in your network. You should have a good understanding of the following aspects of your UIM environment:
    • UIM hub, robot, and probe layout
    • Network layout and IP addressing
    • Origin configuration
    • Multi-tenancy requirements
    • Device naming conventions
  • Correlation time is a major component of overall processing time for the Discovery Server. The Discovery Server performs correlation for each device it receives from the probeDiscovery hub queue, and how quickly the correlation engine processes the devices through the rules affects the speed at which the Discovery Server clears this queue. If rules are not configured carefully, you might experience a dramatic slowdown in hub queue processing.
  • See the Important note in the following table of rule parameters regarding match_on_all property specifications. Selecting a suitable first property can make a significant difference in discovery performance.
  • Existing records will not be reprocessed after changing the correlation configuration.
Correlation Rules
Correlation rules are defined as a subsection in the <device>/<correlation>/<rules> section of the discovery_server.cfg file. If the correlation configuration has been modified, you can refer to the default settings in the discovery_server.cfx file.
Notes about the default correlation rules:
  • The <name_mac_ip>, <name_mac>, <name_ip>, and <mac_ip> correlation rules match on a combination of properties to find the best match. By matching on a combination of properties, the likelihood of a mismatch is much lower and thus origin is not included as a match property.
  • RobotInstanceId is specified as a decorrelation property for all rules except CorrelationId to prevent two robot devices from correlating. This property is not needed in most environments but protects against environments where multiple robots are hosted on one system.
  • The <mac> correlation rule is not qualified by origin. The MAC addresses used for correlation are generally unique.
    • Because MAC addresses across vCenters in a vmware environment are not guaranteed to be unique, the VM VirtualID and the vCenter VirtualManagerId are used as decorrelation properties.  
    • The combination of CorrelationNames and IpAddresses is also used as a decorrelation property. If two devices have a MAC in common and each have known names and IP addresses but none in common, then it is strongly likely they are different devices and should not correlate.  This combination is used to protect against cases of non- unique MACs.
  • Concerning the <fqdn> and <name_origin> correlation rules:
    • The <fqdn> rule assumes that FQDNs are unique and so is not qualified by origin.  
    • The <name_origin> rule operates on names that are not fully qualified and thus need to be qualified by origin.
    • The <fqdn> and <name_origin> correlation rules include the combination of MacAddresses and IpAddresses as a decorrelation property. If two devices have a name in common and each have known MAC and IP addresses but none in common, then it is likely they are different devices and should not correlate. This combination is used to protect against duplicated names causing correlation.
  • The <ip_origin> correlation rule includes MacAddresses and CorrelationNames as independent decorrelation properties to prevent mismatches on IP where IP addresses have shifted between devices and some device records still have a stale IP address.  Name and MAC are considered strong correlators. If there was a match by name or MAC, a match should have already been found. If two devices match by IP but not name or MAC, they are likely different devices.
  • The <CorrelationId> correlation rule is needed by UIM4z probes (zevent, znetwork, zops, zstorage, and zvm). These probes collect information from IBM z/OS systems and do not include typical correlation properties, such as IP addresses, MAC addresses, and DNS names.  When the UIM4z probes target the same system, they publish the same CorrelationId to ensure that the device perspectives from each of the UIM4z probes correlate.  CorrelationId is not limited to the UIM4z probes: it can be used by other probes that target the same system to help ensure a consistent correlation result when other device information might be lacking.
The default rules are intended to cover the majority of cases, but existing rules can be modified and new rules can be added as needed.
Here are the parameters for each correlation rule:
enabled
(required key)
 
true
 to enable the rule,
 false
 to disable the rule.
position
(required key)
The correlation rule order is controlled by the position value. A position value is >= 1. All enabled rules must have a distinct position value. Rules are executed in ascending order.
The discovery server will fail to start if the same position value is used for more than one enabled rule.
Two-digit position values make it easier to insert new rules into the rule sequence.
match_on_all
(required key)
A comma-separated list of properties used for correlation. All match properties need to match (AND) and are evaluated in the order specified. At least one match property must be specified. The property names can be any property stored in the database.
For convenience, related properties can be defined as a set in the <defined_correlation_property> section. A defined correlation property should be prefixed with defined: in match_on_all to specify that it refers to a defined property in <defined_correlation_property> and not to an individual property name.
 For multi-value properties such as IP and MAC addresses, only one matching value is needed to satisfy as a match.
 
A distinctive device property like name, MAC, IP, or any other distinct identifier should be specified first in the match_on_all list. A general property like Origin that is common among many devices should not be specified first. The first property is used in the database query. Use a distinctive first property to help limit the number of results that are evaluated.
unmatch_on_any
(optional key)
 A comma-separated list of properties used for decorrelation. Two devices are considered different and do not correlate if both devices contain one of the unmatch_on_any properties but have different values for that property. Like match_on_all, the specified properties can refer to either individual property names or defined properties.
A combination of properties can be specified as a decorrelation property using ‘&&’. For example: defined:MacAddresses && defined:IpAddresses. When using a combination of properties, both devices must include all of the properties specified in the combination in order to be evaluated.  In the example of “defined:MacAddresses && defined:IpAddresses,” two devices are considered different if they both have MAC and IP addresses AND no MAC addresses are in common AND no IP addresses in common.
Correlation Names
A new CorrelationNames property has been added to aggregate the different name properties used in name correlation. The <device>/<correlation>/<correlation_names> section controls what names are included as CorrelationNames property values.
The properties are prefixed with a probe name in order to give fine-grained control regarding probe properties that are included or excluded.  ‘any’ means any probe.
The excluded_probe_properties key allows properties from specific probes to be excluded from name correlation. For example, if you want to exclude VMName from the vmware probe, set excluded_probe_properties as follows:
excluded_probe_properties = “vmware.VMName”
Excluded properties override included properties. If you have the same property specified in both included properties and excluded properties parameters, the property will be excluded.
Note that the label is only included for niscache devices. For non-niscache devices, it is assumed that the probe sets at least one of the name properties (for example: PrimaryDnsName, SysName, or ComputerName). The label is redundant with one of these properties.
Defined Correlation Properties
A defined correlation property is a pseudo property that specifies the set of aggregate properties.  A defined correlation property is defined in the <device>/<correlation>/<defined_correlation_property> section of the discovery_server.cfg file.   
Here are the parameters for each defined correlation property:
type
(required key)
One of the following:
  • Fqdn
  • IpAddress
  • Other
 
Fqdn
 limits the set of values to fully qualified domain names only.
 
IpAddress
 enables IP address subnets and IP address ranges to be specified in included_values and excluded_values, as described below.
 
Other
 should be used when a more specific type is not needed.
included_source_properties
(required key)
A comma-separated list of properties from a probe that are used for the source correlation values.  The format per property is 
{probe_name}.{property_name}
'any
' means any probe.
See the default settings above for examples.
excluded_source_properties
(optional key)
A comma-separated list of properties from a probe that are ignored as source correlation values. Properties follow the same format as in included_source_properties.
Excluded properties override included properties. If you have the same property specified in both included properties and excluded properties parameters, the property will be excluded.
included_target_properties
(required key)
A comma-separated list of properties in the database that are used for the target correlation values. Properties follow the same format as in included_source_properties.
excluded_target_properties
(optional key)
A comma-separated list of properties in the database that are ignored as target correlation values. Properties follow the same format as in included_source_properties.
Excluded properties override included properties. If you have the same property specified in both included properties and excluded properties parameters, the property will be excluded.
included_values
(optional section)
Limits the correlation rule to the specified list of values. If <included_values> is not present or empty, all values are included.
For all types other than IpAddress:
Values are specified using a separate key per value. Any key name can be used.  The value can either be a single discrete value or a wild-carded value. The wildcards can represent a 'starts with' pattern (foo*), a 'contains' pattern (*foo*) or an 'ends with' pattern (*bar).  
IpAddress:
Values are specified using a separate key per value.  Any key name can be used.  Values can be individual IP addresses, IP address subnets in CIDR notation (for example:: 1.2.3.0/24) or an IP address range (for example: 1.2.3.1-50).
excluded_values
(optional section)
Specifies values to be ignored when evaluating the rule. If <excluded_values> is not present or empty, no values are excluded. A value needs to satisfy both is included and not excluded conditions. If a value is covered by both included_values and excluded_values, it is excluded. 
The same types of values can be specified as with included_values.
treat_as_equal_values
(optional section)
User defined sections can be added inside <treat_as_equal_values> to specify the set of values that should be treated as equal. See the following sections on how to use <treat_as_equal_values>.
Origin Handling Using treat_as_equal_values
For correlation rules that are qualified by origin, a matching origin (either from the Origin or EnrichedOrigins properties) is needed for two devices to correlate.  This means that the hub and/or robot origins must be assigned strategically to facilitate correlation or that enriched origins must be set up to help bind the devices.  
Setting up a common origin for correlation can be difficult. Sometimes, more specific origins are needed for tracking purposes, so adding a common origin would be an unwanted added step. The <treat_as_equal_values> feature is a way to compensate for these difficulties.
A <treat_as_equal_values> section can be added to the <Origins> defined correlation property to define the set of origins that can be treated as equal for correlation purposes. A match will be made for two different origins if both are defined in a subsection of <treat_as_equal_values>.
Below are some examples using <treat_as_equal_values> inside <Origins>.
<treat_as_equal_values>
<CustomerA_origins>
origin = CustomerA*
</CustomerA_origins>
<CustomerB_origins>
origin1 = red
origin2 = green
origin3 = blue
</CustomerB_origins>
<ChicagoOffice_origins>
origin = "*Chicago*"
</ChicagoOffice_origins>
</treat_as_equal_values >
CustomerA_origins is an example that can work well when there is a consistent naming pattern for origins. For example, Device A with IP address 1.2.3.4 and origin CustomerAHub1 and device B with IP address 1.2.3.4 and origin CustomerAHub2 should correlate because both origins start with "CustomerA." 
CustomerB_origins is an example when there is no consistent naming pattern for origins, and discrete origins must be specified as part of a “treat as equals” set. For example, as defined by CustomerB_origins, Device A with IP address 1.2.3.4 and origin “red” and device B with IP address 1.2.3.4 and origin “blue” correlate.  
ChicagoOffice_origins is another example that can work well when there is a consistent naming pattern for origins. In this case, the matching pattern is in the middle of the origin string.
For each user-defined subsection in <treat_as_equal_values> (for example : CustomerB_origins), one or more values can be specified using a separate key per value.  Any key name can be used.  The value can either be a single discrete value or a wild-carded value. The wildcards can represent a 'starts with. pattern (foo*), a .contains. pattern (*foo*) or an 'ends with' pattern (*bar).   
Using treat_as_equal_values in General
The <treat_as_equal_values> feature is not limited to origins. It can be used with other defined correlation properties, such as IP addresses and names. For example, if a server with multiple names is being monitored by two different probes that return different names, the server will likely appear as different devices because of the difference in names. A <treat_as_equals> subsection can be added to AllCorrelationNames and FqdnCorrelationNames to specify the different names that should match.
Correlation Scenarios
IP Address Change
If the IP address of a device changes but the device includes a name or a MAC address, one of the <name_mac>, <mac>, <fqdn>, or <name_origin> correlation rules can find a match.
Name Change
If a device includes a MAC address and the name of a device changes, one of the <mac_ip> or <mac> correlation rules can find a match.  By default, two devices with the same IP address do not correlate if their names are different. The default handles environments in which IP addresses frequently change.  If the IP addresses are static, you can remove “defined:AllCorrelationNames” as a decorrelation property in the <ip_origin> rule.
MAC Address Change
If a device is replaced with new hardware and the former name and IP address are retained, one of the <name_ip>, <fqdn>, <name_origin>, or <ip_origin> correlation rules should find a match.
IP and MAC Address Change
If a device is replaced with new hardware and the former name is retained but both the IP and MAC address are different, by default, the new device will not correlate with the previous device because the devices are considered to be different devices.  See the next case for an example in which the combination of IP and MAC addresses is needed for decorrelation. You can modify the <fqdn> or <name_origin> correlation rules to handle this case, but the changes can impact the next case.
Duplicated Hostname Across VMs
When VMs are created from a template, they typically have different VM names but can have the same hostname until someone changes the hostname in the OS. If the vmware guest tools are installed on the VMs, the vmware probe might report multiple VMs with the same hostname. For example:
VM1:
  • VMName:  abc
  • ComputerName: abc (ComputerName is the property for hostname)
  • IP: 10.20.30.1
  • MAC: 11:22:33:00:00:01
  • VirtualID: 282a7ffa-2178-4e4d-b85d-66940ce8c7af
VM2:
  • VMName:  def
  • ComputerName: abc
  • IP: 10.20.30.2
  • MAC: 11:22:33:00:00:02
  • VirtualID: d8710ff4-b4f3-446a-be27-9c791069c986
VM3:
  • VMName:  ghi
  • ComputerName: abc
  • IP: 10.20.30.3
  • MAC: 11:22:33:00:00:03
  • VirtualID: 24945572-a358-4c68-a71c-85de1ca94130
Controller device:
  • RobotName: abc (the robot name defaults to the hostname)
  • IP: 10.20.30.1
  • MAC: 11:22:33:00:00:01
All of the devices have the name "abc" in common. The VMs do not correlate to each other because they have different VirtualIDs. Only VM1 should correlate to the controller based on name, IP, and MAC address. VM2 and VM3 should not correlate to the controller because they have different IP and MAC addresses.
Name Mismatch
If the vmware guest tools are not installed on a VM, the vmware probe can get the VM name but not the hostname or IP address of the VM.  In the past, the Vmware probe collected only the MAC addresses of the VM if guest tools were installed. Vmware v.6.72 and later collect the MAC address without requiring guest tools. In this scenario, the VM name does not match the hostname but should still correlate based on MAC addresses.
VM device:
  • VMName:  abcVM
  • MAC: 11:22:33:44:55:66
Controller device:
  • RobotName: abc (robot name defaults to hostname)
  • MAC: 11:22:33:44:55:66
These two different perspectives correlate on MAC address.
No Overlapping IP Addresses
If there are no overlapping IP addresses in the UIM environment, disable origin in IP address correlation to avoid mismatches by origin.
There are two alternatives for accomplishing this:
  1. Remove origin from the <ip_origin> rule.
  2. Create a new <ip> rule and disable the <ip_origin> rule
To remove origin from the <ip_origin> rule, remove “defined:Origins” from match_on_all, as highlighted below:
 ip_cod_block_Paint.jpg 
To create a new <ip> rule and disable the <ip_origin> rule:
<ip_origin>
enabled =
false
position = 90
match_on_all = "defined:IpAddresses, defined:Origins"
unmatch_on_any = "RobotInstanceId, SysName, VirtualID, VirtualManagerId, defined:AllCorrelationNames, defined:MacAddresses"
</ip_origin>
<ip>
enabled = true
position = 90
match_on_all = "
defined:IpAddresses
"
unmatch_on_any = "RobotInstanceId, SysName, VirtualID, VirtualManagerId, defined:AllCorrelationNames, defined:MacAddresses"
</ip>
No Overlapping Names
If there are no overlapping names in the UIM environment, disable origin in name correlation to avoid mismatches by origin using the same approach outlined for “No overlapping IP addresses”:
  1. Remove origin from the <name_origin> rule.
  2. Create a new <name> rule and disable the <name_origin> rule.
With both alternatives, you can disable the <fqdn> rule. The <name_origin> rule with origin removed or the new <name> rule will handle all names (FQDN and non-FQDN).
Custom Rule for Unique IP Addresses
If a subset of IP addresses is unique in the environment and the addresses do not need to be qualified by origin for correlation, you can create a custom rule to handle them. For example, if IP addresses in the subnet 10.20.32.0/20 are unique, you can create a UniqueIpAddresses correlation property to include the subnet and then create a new rule to use UniqueIpAddresses.
In the <defined_correlation_property> section, create UniqueIpAddresses by copying the IpAddresses property. Rename it to UniqueIpAddresses.  Add the subnet 10.20.32.0/20 to the included_values property. For example:
<UniqueIpAddresses>
type = IpAddress
included_source_properties = "any.PrimaryIPV4Address,discovery_agent.TargetIpAddresses"
excluded_source_properties =
included_target_properties = "any.PrimaryIPV4Address,any.OtherIPAddresses"
excluded_target_properties =
<included_values>
subnet1 =
10.20.32.0/20
</included_values>
</UniqueIpAddresses>
 Create a <unique_ip> correlation rule:
<unique_ip>
enabled = true
position = 71
match_on_all = "defined:UniqueIpAddresses"
unmatch_on_any = "RobotInstanceId, VirtualID, VirtualManagerId, defined:AllCorrelationNames, defined:MacAddresses"
</unique_ip>
Assign a position to the rule that is different from any of the existing rules.
 Multiple rules can have the same position value if only one of those rules is enabled.
Monitoring Devices for Multiple Customers from a Single Robot/Probe
Consider this scenario for a managed service provider (MSP) using a single polling robot to monitor devices for multiple customers:
  • Robot ABC / 1.2.3.4 with origin CustomerA running local CDM probe.
  • Multi-customer polling robot XYZ with origin MSP.
  • Polling robot XYZ monitors ABC / 1.2.3.4 with net_connect
Robot device ABC:
  • RobotName: ABC
  • IP: 1.2.3.4
  • Origin: CustomerA
Net_connect device configured with name:
  • Label: ABC
  • IP: 1.2.3.4
  • Origin: MSP
The devices should correlate by <name_ip> even though the origins do not match.
If net_connect is configured only with the target IP address, the devices won’t correlate by <ip_origin> because the origins are different.  There are two ways to resolve this condition:
  1. If the IP addresses of the customer robots targeted by net_connect are unique, follow the solution outlined in “Custom Rule for Unique IP Addresses.”
  2. You can add a <treat_as_equal_values> subsection to <Origins> to bind the origins CustomerA and MSP:
<defined_correlation_property>
<Origins>
Other required parameters are omitted in this example
<treat_as_equal_values>
<CustomerA_origins>
origin1 = CustomerA
origin2 = MSP
</CustomerA_origins>
</treat_as_equal_values >
</Origins>
</defined_correlation_property>
Review Correlation History
To view the results of correlation by device, query the CM_DEVICE_CORRELATION_HISTORY table in the UIM database. Columns represent the following topics.
  • source_dev_id: incoming device perspective dev_id
  • target_dev_id: existing device perspective dev_id if a match was found.  Otherwise: null.
  • cs_id: identifies the CM_COMPUTER_SYSTEM master device
  • time_processed: when the device was processed
  • reason:
    • 0 indicates a probe import
    • 1 indicates a re-import
    • 2 indicates a recorrelation.
  • match_type: if a match was found, the name of the rule that found the match is entered. Otherwise, it is set to “none.”
  • match_key [1-3] / match_value[1-3]: if a match was found, these columns contain the first three property names and values from the match_on_all list as defined by the rule.
The following are sample entries of the table.
source_dev_id
target_dev_id
cs_id
time_processed
reason
match_ type
match_key1
match_value1
match_key2
match_value2
match_key3
match_value3
De3a9a071ef9d604c77b20cb3472f014b
NULL
77476
25:48.3
0
none
NULL
NULL
NULL
NULL
NULL
NULL
Dff18e70a40a97603f432cff9cead607f
NULL
77478
25:48.8
0
none
NULL
NULL
NULL
NULL
NULL
NULL
D14be8e1fc25e1d5bed8fae9df8d74b24
NULL
77484
25:51.1
0
none
NULL
NULL
NULL
NULL
NULL
NULL
Df3a884f885e03129e8ff4e81e1b05bee
Dff18e70a40a97603f432cff9cead607f
 
77478
25:53.0
0
name_ip
defined:AllCorrelationNames
howeu01-u159980
defined:IpAddresses
172.19.255.19
NULL
NULL
D3adeafb5d2f00b69e9b43329a424c816
De3a9a071ef9d604c77b20cb3472f014b
77476
25:54.2
0
name_mac_ip
defined:AllCorrelationNames
wvaud1opt5
defined:MacAddresses
00-1a-e3-6c-84-40
defined:IpAddresses
172.19.255.76
Dcd1e6873020967dab879533d969f57b8
D14be8e1fc25e1d5bed8fae9df8d74b24
77484
25:58.4
0
name_origin
defined:AllCorrelationNames
netapp-sim-admin
defined:Origins
origin-b
NULL
NULL
Troubleshooting Correlation
If, having changed the correlation configuration, you see unexpected results, refer to the the correlation troubleshooting documentation.