Declaring Inventory, Metrics, and Bulk Configuration

Defining your inventory elements, metrics, and bulk configuration templates in probe_schema.xml is the first step of probe development.
uimpga-ga
Defining your inventory elements, metrics, and bulk configuration templates in probe_schema.xml is the first step of probe development.
Contents
Determining the CI Type and Metric ID for Inventory and Metrics
Understanding CI Types requires a brief introduction to the NIS2 data model.
The NIS2 (also sometimes called TNT2) data model was created with several goals in mind:
  • Create a central database containing descriptions of every metric that the probes collect.
  • Create a central inventory of devices being monitored.
  • Create a central inventory of components of the devices being monitored (such as disks and network interfaces).
  • Allow localization of metrics (descriptions and units).
The NIS2 data model consists of 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 that is associated with a CI. (For example, free space on a disk.)
Configuration Items and Metrics
Every alarm and QoS metric should be associated with a NIS2 CI and metric type ID so that CA Unified Service Manager can show it in the correct device view.
configuration item
(CI) represents the component being monitored. The component is intended to be a physical element (like a disk). Each CI must be associated with an IP-addressable system - this is one of the limitations of the NIS2 data model. The probe must set the following three values when a CI is created with the Nimsoft SDK:
  • A CI type identifier that specifies the type of component. This is a dotted-decimal representation (for example: 1.1) with an English text representation stored in the database (1.1 = "System"."Disk"). The dotted decimal representation is localized. The localized text is contained in properties files that are shipped with wasp, and can also be updated separately using the wasp_language_pack package. The CI type IDs are defined in the CM_CONFIGURATION_ITEM_DEFINITION table.
  • A CI name that represents the name of the component being monitored (for example, the name of a disk or ethernet interface: "eth0").
  • An IP address to associate with the CI. This may be the IP address of the local system being monitored, or the IP address of a remote device.
A
metric type ID
represents the kind of measurement being collected. This ID is a single integer but is typically referenced using its fully-qualified path including the CI type, where it is the number after the colon (for example, the full path of 1.1:12 contains the CI type ID of 1.1 plus the metric type ID of 12, where the combination defines a unique kind of metric that can be collected: "System"."Disk":"Disk Free"). The metric type ID includes the metric unit, for example: 1.1:12 = "System"."Disk"."Disk Free" reported in GB and 1.1:13 = "System"."Disk"."Disk Free" reported in MB. The metric type IDs are defined in the CM_CONFIGURATION_ITEM_METRIC_DEFINITION table and units are defined in the CM_METRIC_UNIT table.
There are many CIs defined by Nimsoft in the CM_CONFIGURATION_ITEM_DEFINITION table of the NIS2 DB (the Nimsoft database typically named NimsoftSLM). Custom probe writers should use one of the provided CI definitions if one is applicable. If no existing CI definition can be used, a CI starting with 9 ("Private") may be used without contacting Nimsoft, or a range within the "Enterprise" or "Vendor" address spaces can be allocated through Nimsoft support or engineering. Allocating a range within the "Enterprise" or "Vendor" address space is recommended to avoid collisions in the "Private" address space (this is applicable in the case where two NMS environments need to be brought together - for example, a company merger where both companies are using the NMS product). Any additions to the CM_CONFIGURATION_ITEM_DEFINITION table (other than within the "Private" space) that are not coordinated through Nimsoft support or engineering may be overwritten during a product upgrade.
How it all comes together in CA Unified Service Manager
The SDK creates files in the niscache directory (under the Nimsoft installation directory) that represent devices, configuration items, and metrics. The discovery server periodically looks for these files and creates database entries based on the file content from each robot. QoS messages and alarms contain (in the message header) two new properties: dev_id (a link to the device) and met_id (a link to the metric). CA Unified Service Manager associates the alarms and metrics with the appropriate device based on these properties.
Configuring Icons for Inventory Elements
When you define inventory elements in probe_schema.xml, you can indicate which icons display for different elements.
<element-type name="ExampleComputerSystemElement"> <base-element-type>ComputerSystemElement</base-element-type> <icon>server</icon> <properties/> <qos-metric-types> ... </qos-metric-types> </element-type>
List of Available Icons
Each probe GUI provides a list of available icons. View the list of icons to determine which ones you want to use in a probe's inventory elements. Then use the displayed icon name when you define inventory elements in probe_schema.xml.
Follow these steps:
  1. Log in to Admin Console.
  2. Select a robot to see a list of probes deployed to the robot.
  3. Open the configuration UI for any probe.
  4. Append
    &mock=true
    to the URL displayed in the browser. This switches the probe config UI to mock mode. In the left navigation tree a folder displays that contains the available icons.
    The &mock=true append command does not work for the Admin Console version introduced with CA UIM version 8.47.
    Icons.png
Creating a Probe to Support Bulk Configuration
When you create a new probe project using the supplied
com.nimsoft:remote-probe-pobc-archetype
Maven Archetype template, bulk configuration is turned on by default. The bulk configuration structure is configured in the TemplateDefinitionGneration java code section of probe_schema.xml to support bulk configuration. The Probe SDK package includes a sample bulk configuration probe_schema.xml file named mock_vm_host located in the examples directory.
Disabling Bulk Configuration
When you create a new probe project, use the
com.nimsoft:local-probe-archetype
or
com.nimsoft:remote-probe-archetype
Maven Archetype template to create a local or remote probe that does not support bulk configuration.
Bulk configuration is enabled when you create a probe using the
com.nimsoft:remote-probe-pobc-archetype
Maven Archetype template. If you select this template by mistake when you created a probe project, you can disable bulk configuration by modify the following files:
  • probe_schema.xml:
    Remove the contents of the template-definition element, but do not remove the element.
  • <probe_name>.cfx:
    Remove `pobc_enable = true` from setup section. (or set it to false).
  • <probe_name>.pkg:
    Remove the templateDefinitions section.
  • pom.xml:
    Remove the `template-definitions` execution section from the probe-sdk-maven-plugin section. Then remove the `templateDefinitions` property from the genzip-plugin configuration.
Create a Default Template
You can create a default monitoring template for a probe.
Follow these steps:
  1. Install the probe on a robot and use the Template Editor to create a template with the appropriate settings. For example:
    Example Template.png
  2. Create and save your template. The template file is now located in <Nimsoft>\probes\<category>\<probe name>\bulk_config\raw_templates.
    • Templates are typically named with a GUID, (for example: f7c5656f-8e98-4db9-b205-9b4014acb34a.gzip) 
    • The saved template is a g-zipped JSON file.
  3. Determine which template is the one you want. Either create and rename each template one at a time (so that there is only one possibility), or gunzip and open each template in an editor (search for your template title).
  4. Make a copy of the template in a temporary work area on your filesystem.
  5. Unzip the .gzip file.
  6. Rename the JSON file.
  7. Search the JSON file for the GUID, and replace the GUID with the template name you want to use.
    For example, the Template has the name f7c5656f-8e98-4db9-b205-9b4014acb34a and you want to use the template name UMP_Metrics. Replace f7c5656f-8e98-4db9-b205-9b4014acb34a with UMP_Metrics. The probe template GUID is the same as the template filename.
  8. (Optional) If you want end users to only copy and not change your template, add
    "readOnly":true
    to the ProbeTemplate JSON object inside the template file. Look for a string containing
    "ProbeTemplate"
    similar to the following example.
    {"ctdType":"ProbeTemplate","ctdType":"ProbeTemplate","customProperties":{"readOnly":true},"id":"VM_and_Host_Template","label":"VM and Host Template","probeName":"vmware","probeVersion":"6.41","typeName":"vmware6.41"}
  9. Gzip the JSON that represents the template.
  10. Copy the new template to the probe project folder where your cfx and pkg are located. For Probe-SDK probes this will be the src/main/resources folder. For example:
    example resources folder.png
  11. Add template file references to the <generic> <files> section in probe.pkg. For example:
    <generic>
       <files>
            …
            <UMP_Metrics.gzip>
             type = binary
             access = 0644
             dir = probes/application/probe-name-string/bulk_config/raw_templates
          </UMP_Metrics.gzip>
       </files>
    </generic>
  12. Do a build install and deploy the probe.
  13. Verify that the template is in the probe bulk_config\raw_templates folder, and that the template appears in Template Editor.