After installing the management pack which use this collector, all configuration files related to this collector is available at :<DCF-Install>/ Collecting/Smarts-Collector/<Management-Pack>/conf/

To use this collector, simply declare it in the collecting configuration file: <DCF-Install>/ Collecting/Collector-Manager/<Management-Pack>(smarts-metrics-collect)/conf/collecting.xml

For example:

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://www.watch4net.com/APG/Collecting" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.watch4net.com/APG/Collecting collecting.xsd ">
<connectors>
<connector enabled="true" name="File" type="File-Connector"   config="conf/file-connector.xml" />
<connector enabled="true" name="Kafka" type="Kafka-Connector"   config="Kafka-Connector/smarts-metrics-collect/conf/kafka-connector.xml" />
</connectors>

<collectors>
<collector enabled="true" name="smarts-INCHARGE-AM-PM-0-metrics" next="Kafka File" type="Smarts-Collector" config="Smarts-Collector/smarts-metrics-collect/conf/smarts-INCHARGE-AM-PM-0-metrics.xml" />
<collector enabled="true" name="smarts-INCHARGE-AM-PM-0-topo" next="Kafka File" type="Smarts-Collector" config="Smarts-Collector/smarts-metrics-collect/conf/smarts-INCHARGE-AM-PM-0-topo.xml" />
</collectors>
</config>

There are 2 components here. Collectors section deals with configuration of domain managers and the data which need to be pulled from these servers.

Connectors section deals with sending this collected data (JSON format) to Configured Kafka servers and/or to a file for debugging.

Configuration files Information

These configuration files deals with polling Smarts topology.

  1. smarts-INCHARGE-AM-PM-0-metrics.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE config SYSTEM "smarts.dtd">
    <config>
    <domain>INCHARGE-AM-PM</domain>
    <host>localhost:12345</host>
    <username>admin</username>
    <password>{38985215010FA2D2BCBDCCE151D4C261A68B1E0486B804084A615512D4BAB69C56EEFAA581451988199D8314585605ED}</password>
    <group>group</group>
    <period>240</period>
    <thread pool-size="3" />
    <dm-connection pool-size="3" keep-connection="false" creation-grace-time="100" />
    <indicators select="both">conf/pm-metrics.xml</indicators>
    <properties refresh="00:00/86400" send-on-refresh-only="false" />
    <smooth-factor>0.5</smooth-factor>
    </config>
    

    The polling configuration file (typical path : <DCF Install>/Collecting/Smarts-Collector/<Management-Pack>(smarts-metrics-collect)/conf/smarts-INCHARGE-AM-PM-0-metrics.xml) will have details regarding Smarts domain manager connection parameters and also points to the metric configuration file which have configurations regarding what details need to be fetched from configured Smarts domain manager. Here that file is pm-metrics.xml.

    The domain attribute let you specify Smarts Domain manager name.

    The host attribute is host name and port information of the Smarts server.

    The username and password tag are User Name and password used to login to Smarts server.

    The group tag value used by the collector to assign the string specified in the group element to generated metric.

    The period is the polling period.

    The thread pool-size attribute let you specify the number of concurrent polling threads which will share a customizable number of connections to Smarts InCharge domain (specified in dm-connection pool-size).

    Since the Collector is design to be very fast, it can disturb Smarts InCharge domain: that's why there are two other parameters which control the polling rate.

    The dm-connection creation-grace-time is the minimum delay between consecutive connections to the Smarts InCharge domain.

    The smooth-factor control the actual polling rate.

    For example, if polling period is 240 second and smooth factor is 0.5, the Collector will try to pool the domain in 0.5 * 240 = 120 seconds.

    The dm-connection keep-connection attribute control whether we should keep domain connections after the polling process or not. It is usually more reliable to set it to false ensuring that we always have proper connectivity to the domain manager.

    The dm-connection no-clobber attribute controls the connection creation process: if set to true, no new connection are created until the next polling cycle starts. This behavior may be useful in certain cases to avoid connection pile-ups on domain managers. Should be left to false, unless this problem actually occurs, as enabling it will lead to some domain managers not being polled when random connection timeout occurs. This attribute is optional (default value is false).

    Finally, the most important configuration element of a Smarts InCharge Collector is its domain descriptor file which defines what is interesting in a Smarts InCharge domain. You specify it in the indicators element and the syntax of this file is described in the following section.

    <indicators select="both">conf/pm-metrics.xml</indicators>

    The select attribute enables you to choose between 3 polling modes:

    properties polla only properties, not generating any actual performance metrics. This is useful for inventory purpose.

    values generatea only the performance values and not poll properties at all.

    both is the default polling mode, polling both properties and values.

    1. pm-metrics.xml (Domain descriptor file)

      This domain descriptor is an XML file which describes what will be retrieved from a specific Smarts InCharge domain.

      Example 1:

      <?xml version="1.0" encoding="UTF-8"?>
      <!DOCTYPE domain SYSTEM  "indicators.dtd">
      <domain>
      <script id="datagrp-tag">
      <![CDATA[
      ctx.create("datagrp", "SMARTS-PM-METRICS");
      ]]>
      </script>
      
      <data id="Device" class="UnitaryComputerSystem" start="true">
      <scripted-property script-id="datagrp-tag" />
      <property name="IPAddress Description Model Location SNMPAddress PrimaryOwnerContact Vendor"
      rename="ip devdesc model location ip contact vendor" />
      <property name="CreationClassName" rename="type" />
      <property name="IsManaged" rename="ismanaged" />
      <value name="IsUnresponsive" rename="Reachability" unit="%">
      <transformation match="false" replace="100.0" />
      <transformation match="true" replace="0.0" />
      </value>
      </data>
      

      The data element is equivalent to a class of Smarts Domain manager. You have to create data block for each interested class of Smarts domain manager.

      The nested value and property elements specify which numerical attributes and which object properties should be retrieved.

      Both value and property elements can have a rename attribute to rename the Smarts InCharge attribute. The value supports a special attribute called unit which enables you to specify the value unit.

      Note that the start attribute. It is VERY important not to forget it. It is used by the collector as an “entry point” into Smarts InCharge object repository. When the collector starts the polling process, it will retrieve all the instances of the classes whose start attribute is set to true.

      The above example:

      1. fetch instances of UnitaryComputerSystem.

      2. Each element properties as per property declaration. For ex: CreationClassName attribute will be renamed as type .. etc

      3. Datagrp is added as new property on the output as per script output.

      4. IsUnresponsive metric is renamed as Reachability and its values are mapped to 100.0% or 0% if it value is true or false respectively.

      Finally JSON object will be constructed and pushed to configured Kafka.

      Example 2:

      <data class="NetworkAdapter" containment="InstrumentedBy" start="true">
      <scripted-property script-id="datagrp-tag" />
      <property name="CreationClassName" rename="type" />
      <property name="IsManaged" rename="ismanaged" />
      </data>
      
      <data class="NetworkAdapter_Performance" instance-name-pattern="@PREVIOUS">
      <value name="ifInDiscardsRate ifOutDiscardsRate"
      rename="ifInDiscards ifOutDiscards" unit="Pkts/s" />
      <value name="ifInErrorsRate ifOutErrorsRate"
      rename="ifInErrors ifOutErrors" unit="Pkts/s" />
      <value name="ifInNUcastPktsRate ifOutNUcastPktsRate ifInUcastPktsRate ifOutUcastPktsRate"
      rename="ifInNUcastPkts ifOutNUcastPkts ifInUcastPkts ifOutUcastPkts"
      unit="Pkts/s" />
      <value name="CurrentUtilization ifInOctetsRate ifOutOctetsRate MaxSpeed" unit="float" />
      </data>
      

      The instance-name-pattern attribute allows you to construct a new instance identifier instead of default value. This helpa in case the object name is getting changed frequently in Smarts domain manager.

      Smarts InCharge stores the topology using many objects linked together through relations. The collector can use these relations to explore the topology. It enables you to collect properties and values from many linked objects from the instances of a given class. You can do this by specifying a space separated list of relation fields in the containment attribute of the data element. Relation fields can be either single reference or reference sets.

      In this above example:

      1. The collector explores the InstrumentedBy relation of the NetworkAdapter instances (i.e. declared in a data block without start attribute or with start="false").

      2. If the InstrumentedBy contains some NetworkAdapter Performance instances, the collector will retrieve the ifInDiscardsRate and other attributes declared under value from the Smarts InCharge object.

      3. Only related NetworkAdapter Performance instances of Interface class will be retrieved and not all instances will be retrieved.

      4. The generated value will keep any previously assigned properties like type.

  2. smarts-INCHARGE-AM-PM-0-topo.xml

    This topology configuration file and its descriptor file below are similar to other configuration files.

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE config SYSTEM "smarts.dtd">
    <config>
    <domain>INCHARGE-AM-PM</domain>
    <host>localhost:12345</host>
    <username>admin</username>
    <password>{38985215010FA2D2BCBDCCE151D4C261A68B1E0486B804084A615512D4BAB69C56EEFAA581451988199D8314585605ED}</password>
    <group>group</group>
    <period>3600</period>
    <thread pool-size="3" />
    <dm-connection pool-size="3" keep-connection="false" creation-grace-time="100" />
    <indicators select="both">conf/pm-topo.xml</indicators>
    <properties refresh="00:00/86400" send-on-refresh-only="false" />
    <smooth-factor>0.5</smooth-factor>
    </config>
    
    1. pm-topo.xml

      <?xml version="1.0" encoding="UTF-8"?>
      <!DOCTYPE domain SYSTEM  "indicators.dtd">
      <domain>
      <script id="datagrp-tag">
      <![CDATA[
      ctx.create("datagrp", "SMARTS-PM-TOPO");
      ]]>
      </script>
      <data id="Device" class="UnitaryComputerSystem" containment="ComposedOf PartOf" start="true">
      <scripted-property script-id="datagrp-tag" />
      <property name="IPAddress Description Model Location SNMPAddress PrimaryOwnerContact Vendor"
      rename="ip devdesc model location ip contact vendor" />
      <property name="CreationClassName" rename="type" />
      <property name="IsManaged" rename="ismanaged" />
      <value name="IsUnresponsive" rename="Reachability" unit="%">
      <transformation match="false" replace="100.0" />
      <transformation match="true" replace="0.0" />
      </value>
      </data>
      
      <data class="Memory" containment="PartOf" start="true">
      <scripted-property script-id="datagrp-tag" />
      <property name="CreationClassName" rename="type" />
      <property name="IsManaged" rename="ismanaged" />
      <value name="DeviceID" rename="id" unit="integer" />
      </data>
      
      <data class="FileSystem" containment="PartOf" start="true">
      <scripted-property script-id="datagrp-tag" />
      <property name="CreationClassName" rename="type" />
      <property name="IsManaged" rename="ismanaged" />
      <value name="DeviceID" rename="id" unit="integer" />
      </data>
      

      These configuration files will retrieve Smarts domain manager topology information based on the configured interval.

Configuration file properties

Below are the list of XML tags which can be used in configuration files for polling attributes from Smarts domain manager.

Scope

By default, polled properties are visible within their own data block and every other block we may reach from it. A data block can override a property and then shadow any previous value. When the collector exits a data block, it will normally discard the collected properties.

It is sometimes useful to retrieve properties from other instances using relationships, and tag local numerical attributes with them. That is why you can set the keep-properties attribute to true in order to extends the property lifetime to the previously explored data block.

<data class=”Interface” containment=”Underlying InstrumentedBy” start=”true”>
….
…..

<data class=”NetworkAdapter Performance”>
<value name=”ifInOctetsRate” rename=” ifInOctets ” unit=”Octets/s”/>
</data>

<data class="IP" keep-properties="true">
<scripted-property script-id="datagrp-tag" />
<property name="Address" rename="ifaceip" append-with="," />
<value name="RoundTripTime" rename="ResponseTime" unit="ms" />
</data>

In this example, we are exploring the Underlying relationship to get the interface IP address and tag ifInOctets values with.

Qualified relations: If the relation attributes contains the string no-values this will give a hint to the collector not to explore this relation when property polling is disabled. This is useful when some classes are explored only to gather properties.
<domain>
<!-- ... -->
<data class=”Interface” containment="Underlying(ip-no-values)">
<!-- ... -->
</data>
<!-- ... -->
</domain>
Restricted relation sets: A relation can be either a single reference, or a reference set. If we want to process a reference set as a single reference, we can restrict the collector to retrieve only the first instance. This is achieved by adding a [0] at the end of the relation attribute name.
<domain>
<!-- ... -->
<data class=”Host” containment="ComposedOf[0]" start=”true”>
<!-- ... -->
</data>
<!-- ... -->
</domain>

In the example, we would only retrieve the first component from each Host instance. Note that the [0] suffix is not part of a qualified relation name.

Special relations: Special relation which doesn't exist in Smarts manager. This relation is called self and enables you to re-explore a class instance within another context.
<domain>
<!-- ... -->
<data class=”Interface” containment="self(to-another-context)">
<!-- ... -->
</data>
<!-- ... -->
</domain>
Conditional Relationship Exploration: Sometimes you don't want to explore all the relations anytime, or don't want to get all the instances from a relation. That why the from attribute has been introduced to the data element. With this attribute, you can choose in what context you want to explore a class instance.
<domain>
<!-- ... -->
<data id="Device" class="Host" containment=”ComposedOf” start=”true”>
<!-- ... -->
</data>
<data id="Device" class=”Router” containment=”ComposedOf” start=”true”>
<!-- ... -->
</data>
<data class=”Processor” containment=”InstrumentedBy” from="Host">
<!-- ... -->
</data>
<data class=”Interface” containment=”InstrumentedBy” from="Device">
<!-- ... -->
</data>
<!-- ... -->
</domain>

The from attribute can contain a space separated list of data block class names or data block ids. In the previous example, we would explore Processor block from Hosts only while we would explore Interfaces for every Device. Please note that the class names specified in the from attribute WILL NOT HONOR CLASS HIERARCHY. It must be the exact name specified in the class attribute of the data block the collector comes from.

When several choices are involved, the following rules are applied:

1. The collector firsts locates matching data block (with or without from attribute).

2. If blocks with matching id are found, we explore them.

3. If there are no block with matching id but some with matching class names, we explore them.

4. If no matching blocks were found in 2 and 3, we explore default matches (without from attribute).

Contextual Relationship Exploration: The from attribute can contain even more specific references. The id or class name specified can be appended a qualified relation name (within brackets). The data block will be evaluated according the rules described in the previous section, but only if the collector is coming from the specified relation. This is particularly useful with the self relation to avoid infinite recursion.
<domain>
<!-- ... -->
<data class=”Interface” containment="self(special-context)">
<!-- ... -->
</data>
<data class=”Interface” from="Host[self(special-context)]">
<!-- ... -->
</data>
<!-- ... -->
</domain>

Property polling and processing

1. Basic Information: A transformation element nested into a property one performs a simple search and replace in the collected attribute. You have to specify two attributes match and replace which are respectively a regular expression and the new content to replace the match with. They are always all orderly evaluated and then a value can be transformed several times.

The property element also support a drop-empty attribute which default value is true, meaning that empty properties will be discarded.
domain>
<!-- ... -->
<data class=”Interface”>
<property name=”MaxSpeed” rename=”maxspeed” drop-empty="true">
<transformation match="^([0-9]{2,})[0-9]{6}$" replace="$1 Mbits"/>
<transformation match="^([0-9]{2,})[0-9]{3}$" replace="$1 Kbits"/>
</property>
</data>
<!-- ... -->
</domain>

Here, we collect the MaxSpeed attribute from Interface instances transforming it into a more human readable string. Any empty speed value will be discarded. If we specified the force tag in property declaration, any other value will result into an uninitialized value.

2. Multiple/Tabular properties handling: The default behavior of property polling is to always keep the first value for each distinct property name within a data block. However, if multiple values should be concatenated, you can specify the append- with attribute. Instead of being discarded, additional values will be appended to the previous one using the content of the append-with as a separator.

Note that this also applies with the keep-properties set to true, when already existing properties are retrieved from relation.
<domain>
<!-- ... -->
<data class=”HostSystem”>
<property name=”Vendor OperatingSystem OSLevel”
rename=”devdesc devdesc devdesc” append-with=" " />
</data>
<!-- ... -->
</domain>

In this example, we will append Vendor, OperatingSystem and OSLevel with a <space> character to generate a nice devdesc property.

Value polling and processing

1. Simple sanity checks: The value elements support two attributes min and max which provide simple sanity check. If a value is outside specified boundaries, it will be discarded (unless the force attribute has been specified).
<domain>
<!-- ... -->
<data class=”NetworkAdapter Performance”>
<value name=”ifInOctetsRate” unit=”Octets/s” min="0"/>
</data>
<!-- ... -->
</domain>

This example would drop negative (and obviously invalid) rates. Since we don't specify max attribute, any positive value will be accepted.

2. Inlined expressions: When specifying the source attribute for a value using the name attribute (e.g. name = "ifInOctet- sRate"), you can also write some simple expressions. Most arithmetic operators are supported (+, -, *, /). Note that you can not use <space> in an expression since it would be splitted in two values: you must quote it first.
<domain>
<!-- ... -->
<data class=”HostPhysicalDevice”>
<value name="'NoOfBlocks*BlockSize'" rename=”Capacity” unit=”Bytes”/>
</data>
<!-- ... -->
</domain>

Since the capacity in bytes in not available here, we multiply the number of available block by the block size to compute it.

Embedded scripts:Sometimes the previously described features are not flexible enough to poll a Smarts domain. Some models can be very complex, requiring some advanced processing. This processing can be achieved embedding processing scripts in a domain descriptor.

1. Script definition: Scripts are declared in separate script elements. For each script you have to declare its id, its parameters (in) and its output (out). The script body in declared in the script elements itself.
<domain>
<!-- ... -->
<script id="my-script" in="Param1 Param2" out="Output1">
<![CDATA[
<!-- script body -->
]]>
</script>
<!-- ... -->
</domain>

Scripting engine is based on Apache JEXL. The syntax is mostly Java based with some handy shortcuts but some restrictions. For more information on the exact syntax, please refer to http://jakarta.apache.org/commons/jexl/reference/syntax.html.

2. Script reference: A script can be referenced in a data block:

- to process values using a scripted-value element

- to process properties using a scripted-property element

- to filter instances using pre-filter-script element and/or post-filter-script element

Each of these elements must specify the script reference using the script-id attribute. They must also specify input using the in attribute (except for pre-filter-script) and output using the out attribute (for scripted-value and scripted-property only).

Input is a list of space separated Smarts InCharge attribute names while output is a list of DCF names. They are similar to the name and rename attributes in value and property elements. If they are not or partially specified, those declared in script definition will be used.
<domain>
<!-- ... -->
<data class=”... ”>
<!-- ... -->
<scripted-value script-id="my-script" in="MyInAttribute" out="MyVar"/>
<!-- ... -->
</data>
<!-- ... -->
</domain>

3. Script variables: Each script is evaluated in its own context. As in any programming language, variables can be referenced using identifiers. When a script is evaluated, each input parameter is defined as a read-only variable (in can be shadowed by a local variable however).

Input parameters are either Smarts InCharge repository objects directly gathered from domain using the Remote API (see reference for details) or constants (when enclosed by quotes in the input parameter list). A script will be exposed all attributes collected from the domain, not only those requested as input parameters.

A script can obviously use its own variables. Furthermore, it can access some special variables:

- ctx is the script context. Most functionality is based on this special variable. Depending on its purpose, a script ctx variable will expose different functionality.

- smInstance is the instance name from Smarts InCharge.

- apgInstance is the instance name from DCF (it may be equal to smInstance)

- pctx is the polling context. It enables a script to interract with poller internals. You should never use it unless you know what you are doing.

4. General script context: The script context offer some helper methods for scripts. In any script you can access the following methods from the ctx variable:

Methods

Description

Object value(value) Unpacks a Remote API object.
Object[] array(value) Unpacks a Remote API array.
String str(value) Creates a string from the specified object, the returned string is never null but can be empty.
String[] strarray(value) Creates a string array from the specified object, the returned string is never null but can contain empty strings.
String nstr(value) Creates a string from the specified object, the returned string can be null.
String[] nstrarray(value) Creates a string array from the specified object, the returned string can't be null but can contain null values.
Number num(value) Creates a number from the specified object, the returned number can't be null but can be NaN .
Number[] numarray(value) Creates a number array from the specified object, the returned number can't be null but can contain some NaN .
Number nnum(value) Creates a number from the specified object, the returned number can be null.
Number[] nnumarray(value) Creates a number array from the specified object, the returned number can't be null but can contain null values.
void id(instance, key, suffix) Creates a unique id from the specified names (instance and suffix can be null).
void store(pctx, id, value) Stores a value in the polling context using the specified unique id.
Object fetch(pctx, id) Retrieve a value from the polling context using the specified unique id.
Object timestored(pctx, id) Retrieves the timestamp when a value was stored from the polling context using the specified unique id.
Object looptime- stored(pctx, id) Retrieves the polling cycle timestamp when a value was stored from the polling context using the specified unique id.
void store(key, value) Stores a value in the current polling context using the specified key. Keys will use input parameter mappings.
Object fetch(key) Retrieves a value from the current polling context using the specified key.
Object timestored(key) Retrieves the timestamp when a value was stored from the current polling context using the specified key.
Object looptime- stored(key) Retrieves the polling cycle timestamp when a value was stored from the current polling context using the specified key.
void pstore(key, value) Stores a value in the previous polling context using the specified key. Keys will use input parameter mappings.
Object pfetch(key) Retrieves a value from the previous polling context using the specified key.
Object ptimestored(key) Retrieves the timestamp when a value was stored from the previous polling context using the specified key.
Object plooptime- stored(key) Retrieves the polling cycle timestamp when a value was stored from the previous polling context using the specified key.
void istore(key, value) Stores a value in the initial polling context (which is kept accross polling loops) using the specified key. Keys will use input parameter mappings.
Object ifetch(key) Retrieves a value from the initial polling context (which is kept accross polling loops) using the specified key.
Object itimestored(key) Retrieves the timestamp when a value was stored from the initial polling context (which is kept accross polling loops) using the specified key.
Object ilooptime- stored(key) Retrieves the polling cycle timestamp when a value was stored from the initial polling context (which is kept accross polling loops) using the specified key.
void out(value) Prints the value on standard output.
void err(value) Prints the value on error output
void log(value) Prints the value in logs
int time() Returns the current timestamp in seconds.
int looptime() Returns the current polling cycle timestamp in seconds
Scripted values are scripts which generate values. Values are generated with the create methods. Every created value will be automatically sent without any other operation unless discarded with the discard method. These scripts can access the following methods from ctx:
Methods Description
Value create(name) Creates an uninitialized value using the specified name. It is equivalent to create(name, NaN) .
Value create(name, value) Creates a value using the specified name. It is equivalent to create(name, value, null) .
Value create(name, value, unit) Creates a value using the specified name and unit. If script reference defines output mapping, the name will be transformed to the reference output name.
void discard(value) Discards a previously created value
<?xml version=”1.0” encoding=”UTF-8”?>
<!DOCTYPE domain SYSTEM ”indicators.dtd”>
<domain>
<!-- ... -->
<script id=”capacity-decode” in=”Capacity” out=”Capacity”>
<![CDATA[
v = ctx.str(Capacity);
if(v.matches(”([0-9n.]+)( GB)?”)) {
ctx.create(”Capacity”,
v.replaceAll(”([0-9n.]+)( GB)?”, ”$1”)*1024*1024*1024,
”Bytes”);
} else if(v.matches(”([0-9n.]+)( MB)?”)) {
ctx.create(”Capacity”,
v.replaceAll(”([0-9n.]+)( MB)?”, ”$1”)*1024*1024,
”Bytes”);
} else if(v.matches(”([0-9n.]+)( KB)?”)) {
ctx.create(”Capacity”,
v.replaceAll(”([0-9n.]+)( KB)?”, ”$1”)*1024,
”Bytes”);
} else if(v.matches(”([0-9n.]+) *”)) {
ctx.create(”Capacity”,
v.replaceAll(”([0-9n.]+) *”, ”$1”)*1,
”Bytes”);
}
]]>
</script>
<!-- ... -->
</domain>

This sample script convert a capacity string into a numeric value. The capacity string is expected to be a number followed by a unit. Please note the implicit string to number conversion in v.replaceAll("([0-9\.]+) *", "$1")*1.

The script may be applied with the following reference:
<scripted-value script-id=”capacity-decode” in=”TotalSize” out=”TotalSize” />

The Capacity parameter will be dynamically mapped to TotalSize attribute. The created value will be automatically renamed from "Capacity" to TotalSize. Note that the mappings doesn't prevent script from creating more value, however, they will not be automatically renamed.

Another usefull example is the delta script. It shows how you can store data across polling cycles to compute deltas.
<domain>
<!-- ... -->
<script id=”rate” in=”value unit ” out=”rate”>
<![CDATA[
previousValue = ctx.ifetch(rate);
previousTimestamp = ctx.itimestored(rate);
currentValue = ctx.num(value);
currentTimestamp = ctx.time();
if (previousValue != null) {
newRate = (currentValue-previousValue) / (currentTimestamp-previousTimestamp);
if (newRate >= 0) {
ctx.create(rate, newRate, unit);
}
}
ctx.istore(rate, currentValue);
]]>
</script>
<!-- ... -->
</domain>
Scripted properties: Scripted properties are scripts which generate properties. Properties are generated with the create methods. Every created property will be automatically sent along with values without any other operation unless discarded with the discard method. These scripts can access the following methods from ctx:
Methods Description
Value create(name, value) Creates a property using the specified name. It is equivalent to create(name, value, null).
Value create(name, value, appendWith) Creates a property using the specified name and append it using the specified separator. If script reference defines output mapping, the name will be transformed to the reference output name.
void discard(value) Discards a previously created property
A scripted-property element can have a make-variable attribute. It has exactly the same meaning as in property elements.
<domain>
<!-- ... -->
<script id=”non-empty” in=”a1 a2” out=”prop”>
<![CDATA[
if(ctx.str(a1).length() > 0) {
ctx.create(”prop”, a1);
} else if(ctx.str(a2).length() > 0) {
ctx.create(”prop”, a2);
}
]]>
</script>
<!-- ... -->
</domain>

The script may be applied with the following reference:

<scripted-property script-id=”non-empty” in=”DeviceID Description” out=”part” />

This will create the part property from the first non empty value of DeviceID or Description. If both are empty, the property will not be created.

Instance filter scripts: Filter scripts has no special functionality but must return true or false. The returned value is the value of the last script statement (there is no return keyword).

The main difference between a pre-filter-script and a post-filter-script is that a pre-filter script can't have any input because it is executed before instance attributes polling. The only contextual information it can access is the Smarts InCharge instance name (smInstance variable).

A post-filter script can override DCF instance name. This is simply done overwritting the apgInstancevariable (which normally contains the previously set DCF instance name).
<domain>
<!-- ... -->
<script id=”physical-device”>
<![CDATA[
smInstance.indexOf(”physical”) >= 0
]]>
</script>
<script id=”fast-eth-iface” in=”Type MaxSpeed”>
<![CDATA[
apgInstance = ”FAST-ETH-” + apgInstance;
ctx.num(MaxSpeed) >= 100000000
&& ctx.str(Type).equals(”ETHERNETCSMACD”)
]]>
</script>
<!-- ... -->
<data class=”Interface”>
<pre-filter-script script-id=”physical-device” />
<post-filter-script script-id=”fast-eth-iface” in=”Type MaxSpeed” />
<property name=”Name” rename=”part”/>
<value name=”Status” rename=” Availability ” unit=”%”>
<transformation match=”UP” replace=”100.0” />
<transformation match=”DOWN” replace=”0.0” />
</value>
</data>
<!-- ... -->
</domain>

This is a pretty complete example where we first filter interfaces which instance name contains the string physical and then which Type is ETHERNETCSMACD and MaxSpeed _ 100 Mbits.

Configuration hints

- Polling period: Check your polling settings to be consistent with collector settings. Indeed, the collector will retrieve data from Smarts InCharge every 4 minutes (this is the default settings, you can change it afterward) but if Smarts InCharge polling is set to an higher value, you will have some duplicated entries in the database. To change this setting, go to the Polling and Threshold panel and set every polling period according to your desired accuracy.