Design Considerations

This article describes how the decisions made while developing a probe can affect the probe web user interface (UI) usability and behavior.
uimpga-ga
This article describes how the decisions made while developing a probe can affect the probe web user interface (UI) usability and behavior.
CI Modeling
When designing your metrics you should carefully choose your CI Types. The CI Types dictate how the metrics appear in the probe UI. The following figure shows an example of CIs that can contain one or many metrics.
Configuration Items and QoS Metrics
Configuration Items and QoS Metrics
Management Types
In general, the structure of the CIs you create must match the structure of the target you want to monitor. Consider one or more of the following concepts to organize your metrics.
 
IP Devices
 - Elements that exist within a network.
 
Hardware Components
 - Elements that exist within a device.
 
Software Components
 – Elements that exist within a software application.
 
Logical Containers
 – Represent groups of related elements.
 
Folders
 – Generic container for elements that do not fall within any of the other management types.
CI Model with No Organization
The following figure shows an example of a CI model with no components to organize the QoS measurements.
Computer System with Robot
Computer System with Robot
In this example, the probe configuration UI displays a device node and a list of all metrics. This model is efficient only if there are a few metrics collecting device data.
CI Model with Device Components
If you want to collect individual QoS metrics on multiple components within the target device, define multiple CI elements for the probe. The following figure shows an example of a CI model with organizational components for the QoS measurements.
CI Model with Device Components
CI Model with Device Components
In this example, the probe configuration UI displays a node for the device and child nodes for CPU, disk, and memory for the associated metrics. By adding this organization, the probe administrator can quickly locate the appropriate metrics by the CI type. This example shows the hierarchy of hardware components within a device. Alternately you can use this hierarchical organization to organize metrics for IP devices and software components.
CI Model with Logical Containers
The following figure shows an example of a CI model with organizational components representing logical containers for the QoS measurements in addition to device components.
CI Model with Logic Containers
CI Model with Logic Containers
In this example, the probe configuration UI displays a node for a data center and a nested set of child nodes for the associated clusters, resource pools, and computer systems. Each of the computer system nodes contain the metrics for CPU, disk, and memory. This example only contains metrics for individual computer systems, but more metrics could be added to monitor elements throughout the hierarchy. For example, you could add a metric to monitor the load on a resource pool.
Display of Probe Inventory
In Admin Console, the probe configuration UI shows the probe inventory in the left pane and the configuration settings for the selected element in the right pane. See the Admin Console Probe GUI article on the CA UIM Probes wiki for more details.
Local Probe Inventory
Local probes monitor components on the computer system where the probe runs with a controlling robot. The inventory in a local probe's GUI shows the local computer system between the probe and its profiles. Inventory is organized relative to an IP device which is identifiable and accessible through the Internet. The local computer system for local probes is the target IP device from which the inventory is discovered. The inventory is shown in the tree view to highlight this architecture.
Remote Probe Inventory
Remote probes typically use some form of internet communication to the external devices to collect the desired inventory and metrics. The profiles for remote probes specify a remote IP target device with credentials in its configuration parameters.
Inventory Modeling
Inventory devices and components are modeled as Java elements with associated QoS metrics. You select elements from a range of Java base elements which have associated attributes. Attributes are fixed properties describing an element and metrics are changing properties made available as QoS monitors. You use relationships to relate element instances in a hierarchical manner, but cyclical graphs are possible.
When you model a probe, your first challenge is to select the base element which best represents the device or component type. Standardized base elements representing the most common devices and components are in the 
java com.nimsoft.probe.framework.devkit.inventory
 package. Components use derivations from element, and devices use derivations from IPDeviceElement. These base elements are associated with standardized attributes.
 These standardized base element types with attributes are useful for the overall CA UIM topological modeling of the infrastructure. Related instances of base elements are used to model the topological graph for infrastructure. These standardized base types have standardized attributes. Metrics are not considered a part of the topology.  This means base elements do not have predefined metrics.
A new element definition (ElementDef) is created for each new component or device type. Each Element instance has an ElementDef reference. This instance provides the flexibility of runtime definition and extension. The base element types encapsulate this instance for convenience, and custom component and device classes are often generated which extend the base elements.
: When you design your probe_schema.xml, do not directly connect an IPDeviceElement or ComputerSystemElement as a child of another IPDeviceElement or ComputerSystemElement. Instead, place a Folder or other element between the two IPDeviceElement or ComputerSystemElement nodes in the inventory graph.
QoS Metric Type Selection
You must select the appropriate QoS metric type to associate with the device or component type. All metric types are predefined and registered in a database using the TNT2 data model. This data model provides a centralized repository with localized descriptions of all metrics and units that you use when developing a probe with the Probe-SDK.
TNT2 Data Model
The TNT2 data model is a centralized repository that contains metric descriptions, an inventory of devices and device components, and localizable metric descriptions and units. The TNT2 Data Model is sometimes given the name NIS2.
The TNT2 data model contains three basic types:
  • A device is an IP addressable system. A device entry is implicitly created when a configuration item is created.
  • A configuration item (CI) is a component of an IP addressable system. (A disk, for example.)
  • A metric is data that the probe collects with an associated CI. For example, the amount of free space on a disk.
CIs and Metrics
Every alarm and QoS metric should be associated with a CI and metric type ID so that CA Unified Service Manager can show the metric in the correct device view.
Metric Type Creation
Each metric type is associated with the element definition using a key name and a QoS name. The probe_sdk_local_dirscan and probe_sdk_mock_vm_host examples demonstrate this process.
For example, 1.1:10 is a metric type. The 1.1 indicates that this metric type is for the CI System.Disk and the 10 specifies the measurement for disk space used in MB. The CI type specifies a group of metrics. The 10 specifies the metric which has a localizable description and units. When associated with an element definition, this metric type might use UsageInMB as the key and QOS_STORAGE_DISK_USAGE_MB.
 The original concept for the CI type was that metric type grouping was based on component types. In current probe development, the CI is considered a group or family of metrics applicable to a type of component or a type of measurement.
Predefined Metric Types
A spreadsheet in the docs directory with the name MetricTypesWithUnits.SpreadSheetOfMostCommonTypesForReuse.TNT2.xlsx provides a quick reference to some of the metric types for general reuse.
Metric Type Registration
Metric type definitions are registered in the CM_CONFIGURATION_ITEM_METRIC_DEFINITION, CM_CONFIGURATION_ITEM_DEFINITION, and CM_METRIC_UNIT tables. These entries are required for proper consumption and correlation by CA UIM services for reporting and configuration.
All TNT2 entries that are intended for public use have gone through an approval process. Probes that are developed by CA or MarketPlace partners are both examples of public use. The TNT2 database has several thousand entries. Many entries are meant to be generic, and some probe entries are very specific. Use existing entries as much as possible.
Identifiers
Instances of elements must be uniquely and consistently identified for monitoring. Use GUIDs whenever they are available. However, GUIDs are often not available. You can use IP device elements because they are identifiable through their IP addressing information. Subcomponents of IP device elements which do not have independently unique identifiers are identified relative to their IP device elements.
IP device elements are used for correlation by the Discovery Server for the presentation of the infrastructure under management.
Elements often have attributes for serial numbers, MAC addresses, or other hardware identifiers. When available, set these attributes to help with overall correlation of QoS data. Attributes are especially useful when two probes are monitoring the same component, but might have different specifications for the primary identifier.