Discovering Your Network › Discovery and Polling

Discovery and Polling

Discovery is the process through which Data Aggregator discovers and models your IT infrastructure.

The discovery process does the following steps:

• Confirms what protocols devices respond to, depending upon what protocols you select when you create a discovery profile. For example, assuming that you select all protocols (SNMP and ICMP), the following steps occur. Data Aggregator determines if a device can respond to ICMP. Data Aggregator then determines if the device can respond to SNMP. If the device does not respond to ICMP, Data Aggregator will not confirm that the device responds to SNMP.
• Retrieves a minimum set of information for every discovered device that is sufficient to classify the device and add it to the appropriate device collection.

Inventory discovery is the process where Data Aggregator identifies the devices on your network. Devices are identified using the IP domain, IP addresses, IP ranges, and hostnames you specify in discovery profiles. Specifically, inventory discovery identifies if devices are manageable or not (pingable vs SNMP capable), and determines the classification (router, switch, and so on). Inventory discovery also determines the vendor (Cisco, Juniper, and so on) and determines the type (7700, 8200, and so on).

Devices that are discovered during this process are automatically added to out-of-the box device collections, depending on the rules that control each device collection membership. You can also create custom device collections in CA Performance Center that create corresponding custom device collections in Data Aggregator when synchronization occurs. During the first synchronization with CA Performance Center after devices are discovered, the devices are added to custom device collections per the rules that are defined on those device collections.

Note: For more information about creating custom device collections and synchronizing them with Data Aggregator, see the CA Performance Center Administrator Guide.

Component monitoring is a separate process. The monitoring process involves the collection and analysis of various operational data for specific device components, such as CPU, memory, and interfaces. All of the information that describes how the monitoring is done exists within monitoring profiles that you assign to device collections.

The relationship of monitoring profiles to device collections governs component monitoring. Component monitoring can be triggered in the following ways:

• A monitoring profile is assigned to a device collection which a given device is a member.
• A device is added to a device collection that already has a monitoring profile assigned to it.
• A monitoring profile, which is assigned to a device collection, is edited to include a new metric family to monitor. The components that are associated with the metric family are then monitored automatically for each device in the collection that the monitoring profile is attached to; if the component was not previously monitored for the device.
• A new vendor certification is added for an existing metric family that is polled in a monitoring profile.
• A monitoring profile specifies a change detection rate and has “Automatically Update Metric Families” checked.
• You click the “Update Metric Family” button on the Polled Metric Families tab of the Monitored Devices view.

A metric family defines the set of values to collect and report on for a given technology. These values are normalized so that reporting is uniform regardless of the data source. When included in a monitoring profile, metric families determine which values to collect for the devices that are associated with that monitoring profile.

Polling begins automatically after inventory discovery and component monitoring complete. Operational metrics and configuration data are polled on a discovered device and its monitored components. The operational metrics and configuration data that are polled depend on the metric families you specify in the monitoring profile. Operational metrics are collected and retained at regular intervals for reporting. Examples of operational metrics include error rate, daily baseline, hourly baseline, and port performance. Configuration data represents or identifies a component or the component configuration.

Examples of configuration data include:

ifNumber

A MIB variable that tells Data Aggregator how many ports a device has.

ifStackLastChange

A MIB variable that indicates whether a change occurs on an interface stack table.

Discovered devices and monitored components usually take up to 5 minutes to begin synchronizing with CA Performance Center. Devices and components that are discovered and monitored while a synchronization is in progress are synchronized after the current synchronization completes.

More information:

View Monitored Devices

How to Manage Change Detection