Probe SDK Terminology

Probe SDK Terminology
This article provides a description of terms you should understand as a probe developer. These terms are used in the Probe SDK Guide and the Probe SDK Cookbook.
CI Type ID (CI Type)
A CI type represents a group of related metric types. For example, the CI type for Disk might contain metrics for throughput, capacity, and free space. A numeric value represents a CI type. For example, the CI type for System.Disk is 1.1.
Note:CIs are also known as metric families where a group of metrics relates to multiple component types
Throughput, Capacity, and Free Space are the available measurements for a disk. Each of these measurements would have the representative CI type of System.Disk.
Components are usually part of a larger device and do not have an IP address. The subcomponents of a device are identified relative to an IP device.
 A component is modeled by an element. The infrastructure under management provides services where the solution is composed of many components. A component is often thought to be some physical part of a larger device, but running software can also be considered a component. The word element is frequently substituted for component.
Configuration Item (CI)
A CI represents an instance of a CI type with the associated metrics published by the probe.
A device is a high-level component identifiable through an IP address. Some examples of devices are computer systems such as servers and networking components.
Device ID
A device ID is an encoded identifier for a device that you use in post processing and database tables.
 A device is also associated with a human readable identifier. The Probe-SDK process automatically generates device IDs.
An element is an instance of an Element Type. Element objects model various kinds of components or devices to create a probe inventory. For example, computer systems, virtual machines, hard disks, and processes are all modeled as a topology of elements.
Element Type
The Probe-SDK facilitates the definition of various types of elements. These element types model various components and devices which creates the probe inventory. Element types are defined in the probe_schema.cfg file along with the QoS metric types. A Java class is generated for each Element Type defined in probe_schema.cfg. The probe developer uses the generated Java classes to represent the inventory the probe produces. The definition of new element types is facilitated by extending standardized base element types.
Metric Item (MI)
A MI represents an instance of a metric type which is a QoS measurement for a specific CI.
The Throughput measurement for the System.Disk CI contains the MIs Read Throughput, Write Throughput, and Total Throughput.
Quality of Service (QoS) measurements are captured by using metrics. Metrics and alarms must be defined for the probe monitoring target.
Metric ID
A metric ID is an encoded identifier for a metric measurement on an element or component instance. The Probe-SDK process automatically generates metric IDs.
If a probe is sending status QoS messages on a specific hard disk, the probe uses the same metric ID in the messages.
Metric Type ID (Metric Type)
A metric type specifies a measurement type that is available for a CI type. A metric type is a numeric string that represents a CI type and the associated MI type.
The string 1.1:29 is an example of an association between a CI type and a metric. The number 1.1 before the colon is the CI type for System.Disk, and 29 is associated with the metric type associated with the CI. For example, Read Throughput.
The System.Disk CI type Throughput measurement contains the MIs Read Throughput, Write Throughput, and Total Throughput. The metric types are:
  • 1.1:29 - System.Disk:Read Throughput
  • 1.1:30 - System.Disk:Write Throughput
  • 1.1:31 - System.Disk:Total Throughput
 Metric types are defined and managed in database tables with their associated CI type, description, and units. Element types are associated with metric types to model a component and provide the desired QoS data.
Monitors publish QoS data, process thresholds, and publish alarms. Monitors are configured through the probe UI or centralized services.
The most basic monitor enables the publishing of QoS data and is called a QoS monitor, or a QoS only monitor. A QoS monitor type is defined primarily by a metric type, QoS name, and an identifying key (in the probe_schema.cfg), and is associated with an element type. QoS monitor instances are configured to apply to element instances. QoS monitor configurations are generally saved in the <probe_name>.cfg file.
Various threshold and alarm monitors can be applied to a QoS measurement. The probe can provide these monitors, but the trend is to configure monitors through centralized services.
The origin is one of several properties set on a QoS message. The default origin is the hub, but you can change this property to any value through the robot.
 A QoS message has properties for the QoS measurement value and timestamp, origin, source, and target. A Device ID and a metric ID are also associated with a QoS message.
You use profiles to configure what inventory a probe monitors and at what frequency. A scheduler runs profiles at defined intervals. The intervals result in the collection and publishing of QoS and inventory data.
 A profile is sometimes called a resource on remote probe configurations.
QoS Definition Message
A QoS definition message provides additional overview information for each type of QoS message. A probe publishes a QoS definition message on the bus before publishing its associated QoS Message type. The Probe-SDK encapsulates these details away from the developer.
QoS Message
A published QoS message has a measured value, at a particular point in time, for a device or component. All QoS messages include origin, source, target, metric ID, device ID, and any other additional properties.
For example, a CPU Usage measured value of 95 percent, at the time 10:30 am, core #2 of CPU #4 in a server.
QoS Name
The QoS metric name that follows the format of QOS_<APPLICATION/PROBE_NAME>_<UNIQUE_IDENTIFIER>. The entire QoS name is capitalized with no spaces. For example, QOS_CLOUD1_MONITORNAME.
 A QosName and MetricType are associated with an element type. This association provides sufficient definition to publish QoS message measurements for an element instance.
The source is an IP addressable system or IP device.
The QoS message includes the source when a probe publishes a QoS message for a metric value on a component. If the source is an IP device, the source is the IP device or the parent IP device of the component.
The target is the element or component where the probe collects the metric measurement.