All other elements of SNMP Dynamic Applications, such as presentation objects and alerts, behave in the same manner as other Dynamic Application types. For details on other parts of SNMP Dynamic Applications,
Use the following menu options to navigate the SL1 user interface:
- To view a pop-out list of menu options, click the menu icon (
).
- To view a page containing all of the menu options, click the Advanced menu icon (
).
Collection Objects
Like all Dynamic Application types, SNMP Dynamic Applications contain collection objects. Collection objects for SNMP Dynamic Applications share common characteristics with collection objects for other Dynamic Application types, such as naming, data typing, and grouping.
Unlike collection objects for other Dynamic Application types, collection objects for SNMP Dynamic Applications are based on SNMP OIDs. Because of this, Collection Objects for SNMP Dynamic Applications have the following unique field:
- SNMP OID. The Object Identifier associated with the object. SL1 will use the OID to perform an SNMP walk on the device aligned with the Dynamic Application.
You can find this field and other information about Collection Objects for an SNMP Dynamic Application by clicking the wrench icon () for a Dynamic Application, and then selecting the tab. A list of Collection Objects aligned with that Dynamic Application appears at the bottom of the window.
NOTE: You can also add collection objects to an SNMP Dynamic Application through the OID Browser page (System > Tools > OID Browser) or through the SNMP Walker tool (Device Administration panel > Toolbox > SNMP Walker). For details, see the section on Viewing MIBs and Using the SNMP Walker Tool.
Scalar OIDs represent a single object; tabular OIDs represent groups of objects in a MIB table. For improved efficiency, you can add a ".0" to the end of all scalar OIDs in an SNMP Dynamic Application. For example, for the singular object "sysDescr", you could enter ".1.3.6.1.2.1.1.1.0" in the SNMP OID field.
Extending the SNMP OID Field
SL1 allows you to use the SNMP OID field to perform more sophisticated OID evaluations and operations when defining the value of a collection object.
You can find the SNMP OID field by clicking the wrench icon () for a Dynamic Application, and then selecting the tab.
Using Multiple OIDs and/or Existing Collection Objects to Define a Single Collection Object
In the SNMP OID field, you can concatenate the values from one or more OIDs or one or more collections objects.
To concatenate the values from one or more OIDs in a single SNMP collection object, use the following syntax in the SNMP OID field:
OID number or partial OID number.collection object.integer
where:
- OID number or partial OID number. Enter the OID number or partial OID number. SL1 will retrieve the value of this OID.
- collection_object. You can specify one or more collection object names (in SL1, these name usually begin with "o_" ). SL1 will retrieve the value of the collection object and include it in the collection object.
- integer. You can specify an integer to append to include in the collection object.
For example, you could enter the following in the SNMP OID field:
- <partial oid>.<collection object>
.1.3.6.1.2.1.1.9.1.o_1
- <partial oid>.<collection object>.<integer>
.1.3.6.1.2.1.1.9.1.o_1.0
- <partial oid>.<collection object 1>.<collection object 2>.<integer>
.1.3.6.1.2.1.1.9.o_1.o_2.0
NOTE: If a collection object is dependent upon the value of another collection object, during polling SL1 polls the values in order of dependency. For example, if the definition of o_123 includes the value of o_456, SL1 polls o_456 before polling o_123.
Using Python Operators to Define a Collection Object
The SNMP OID field can include:
Arithmetic operators (+, -, *, /), comparison operators (>, <, !=, ==), and/or boolean operators ("and", "or", "not").
NOTE: The "==" operator is used to test equality. The single "=" assignment operator is not supported, except when used inside some ScienceLogic functions.
- For example, you could enter the following in the SNMP OID field:
o_16752 + o_16753
and the new collection object will be populated with the sum of the two collection objects.
- If you want to perform a calculation with multiple OIDs (notmultiple collection objects) in the SNMP OID field, use the em7snmp.collect function. For example, you could enter the following in the SNMP OID field:
em7snmp.collect (".1.3.6.1.2.1.1.1") + em7snmp.collect(".1.3.6.1.2.1.1.2")
and the new collection object will be populated with the sum of the values from the two OIDs.
Using Variables in the SNMP Field to Specify Component Devices
For details on configuring Dynamic Applications to discover component devices, see the
In the Dynamic Application that discovers component devices, SL1 will store the value of the collection object designated as the Component Identifier into variables as follows:
Component Identifier | Variable Name |
---|---|
Device Name | comp_name |
Distinguished Name | comp_dn |
Unique Identifier | comp_unique_id |
GUID | comp_guid |
Suppose you have created a discovery Dynamic Application and discovered three component devices. Suppose you want to create a Dynamic Application that will collect data about these new component devices. In the SNMP OID field for each collection object, you can append comp_name, .comp_dn , comp_unique_id, or .comp_guid to the OID. This ensures that the collected data for each component device is easy to identify in SL1 and can be aligned with the appropriate component device.
To specify that a value varies for each component device, use the following syntax:
OID number or partial OID number.component_identifier_variable
where:
- OID number or partial OID number. Enter the OID number or partial OID number. SL1 will retrieve the value of this OID.
- component_identifier_variable. You can specify a variable for a component identifier. SL1 will substitute the value for each component device into the variable.
For example:
Suppose we have will use a single SNMP Dynamic Application to collect data about two component devices:
Component Device Name | Component DN Value |
---|---|
Device 1 | 1 |
Device 2 | 2 |
Suppose our SNMP data looks like this:
OID | OID Value |
---|---|
.1.2.3.1 | number1_3 |
.1.2.3.2 | number2_3 |
.1.2.4.1 | number1_4 |
.1.2.4.2 | number2_4 |
Suppose we entered following in the SNMP OID field:
.1.2.3.comp_dn
- For device 1, SL1 will collect the value of "1.2.3.1". That value is "number1_3".
- For device 2, SL1 will collect the value of "1.2.3.2". That value is "number2_3".
Suppose we enter following in the SNMP OID field:
.1.2.4.comp_dn
- For device 1, SL1 will collect the value of "1.2.4.1". That value is "number1_4".
- For device 2, SL1 will collect the value of "1.2.4.2". That value is "number2_4".
Using Caching to Define a Collection Object
You can use SNMP objects to define a cache for use by one or more Dynamic Applications. For SNMP Dynamic Applications, caching is defined in the SNMP OID field in the Collection Objects page instead of for the entire Dynamic Application.
NOTE: The Caching field in the Dynamic Applications Properties Editor page does not affect caching for SNMP Dynamic Applications.
To define a cache for an SNMP collection object, you define the cache in the SNMP OID field in all Dynamic Applications that will use the cache, both those that will create the cache and those that will consume the cache. If the cache has timed out, the next request will re-populate the cache, making it available to all other Dynamic Applications. All Dynamic Applications can consume the cached value and refresh the cache.
To define a cache for an SNMP collection object, use the following syntax in the SNMP OID field:
em7snmp.collect ('collection_object_definition', enable_cache=true_or_false, time_to_expire=time_in_minutes, time_to_recollect=time_in_minutes)
where:
- collection_object_definition. The OID or extended OID for which you want SL1 to cache a value or retrieve a cached value.
- enable_cache=true_or_false. To either create a cache or use a cached value, specify true.
- time_to_expire=time_in_minutes. Number of minutes that the collected value will remain in the cache. This value cannot be less than the value in the time_to_recollect argument..
- time_to_recollect=time_in_minutes. Frequency, in minutes, at which SL1 will try to collect a value for the collection object. If collection succeeds, SL1 will populate the collection object with the new value and store the new value in the cache. If collection fails, SL1 will populate the collection object with the previously cached value.
For example:
em7snmp.collect('.1.3.6.1.2.1.25.2.3.1.3', enable_cache=True,time_to_expire=15, time_to_recollect=15)
- In this example, the collection object will be populated with the value of the OID '.1.3.6.1.2.1.25.2.3.1.3'.
- The collected value will be stored in the cache.
- The value will be re-collected every 15 minutes.
- If we use this collection object in another Dynamic Application, that collection object can both populate the cache and retrieve values from the cache.
Filtering Results to Define a Collection Object
In the SNMP OID field , you can use the function em7utils.filter to filter the results.
The em7utils.filter function also supports the following operators:
- eq (equals)
- gt (greater than)
- ge (greater than or equal to)
- lt (less than)
- le (less than or equal to)
Suppose the OID .1.3.6.1.2.1.1.9.1.4 is an SNMP table, and for device 1, the data looks like this:
OID | OID Value |
---|---|
.1.3.6.1.2.1.1.9.1.4.1 | 1 |
.1.3.6.1.2.1.1.9.1.4.2 | 3 |
.1.3.6.1.2.1.1.9.1.4.3 | 9 |
.1.3.6.1.2.1.1.9.1.4.4 | 2 |
.1.3.6.1.2.1.1.9.1.4.5 | 4 |
.1.3.6.1.2.1.1.9.1.4.6 | 8 |
.1.3.6.1.2.1.1.9.1.4.7 | 6 |
.1.3.6.1.2.1.1.9.1.4.8 | 10 |
.1.3.6.1.2.1.1.9.1.4.9 | 100 |
.1.3.6.1.2.1.1.9.1.4.10 | 1000 |
We could enter the following in the SNMP OID field :
em7utils.filter(em7snmp.collect(".1.3.6.1.2.1.1.9.1.4"), gt (10))
For device 1, the collection object would contain the array:
.9, 100
.10, 1000
For another example, suppose you want to collect information about interfaces, but you don't want any information about loopback interfaces. Loopback interfaces use the interface type "24". You could enter the following in the SNMP OID field:
em7utils.filter(em7snmp.collect(".1.3.6.1.2.1.2.2.1.3", lambda x:x!="24"))
The OID .1.3.6.1.2.1.2.2.1.3 maps to the interfacetype object in the interface table in the IF-MIB. The "lambda x " syntax creates a sub-function called "x". The logic then says "collect values where 'x' is not equal to '24'". Those values will be stored in the collection object. SL1 retrieves all the interface types that do not have a value of "24".
For details on the lambda syntax, consult the Python documentation https://docs.python.org/2/tutorial/controlflow.html?highlight=lambda#lambda-expressions
Defining "Fallback" Values for a Collection Object
In the SNMP OID field, you can use syntax that tells SL1:
- If the first OID is available, use the first OID
- If the first OID is not available, use the second OID
- If the second OID is not available, use the third OID
- and so on
To include multiple OIDs in the SNMP OID field, use this syntax:
em7snmp.collect (".1.3.6.1.2.1.1.1") or em7snmp.collect (".1.3.6.1.2.1.1.2") or em7snmp.collect (".1.3.6.1.2.1.1.3")
To include multiple collection objects in the SNMP OID field:
o_1234 or o_1234 or o_1236
To include a mixture of OIDs and collection objects in the SNMP OID field:
o_1234 or em7snmp.collect ('.1.3.6.1.2.1.1.2')
Using Index Values and Parsed Index Values to Define a Collection Object
If you are creating a collection object of type "Index", in the SMNP OID field, you can collect an entire index or parse an index.
- To collect an entire index, use the syntax:
em7snmp.full_index (object_name)
For example:
em7snmp.full_index (o_1234)
This example returns the full index for the collection object o_1234 and stores the index in a new collection object.
- To parse a multi-part index, you can enter the following in the SNMP OID field:
em7snmp.parse_index (collection_object,[index_format], index_element_number)
where:
- collection_object is the collection object for which you want to retrieve an index
- index_format describes the data type and order of the elements in the index. The index_format is surrounded by square brackets and each element is separated by a comma. The basic index types used in SNMP are described in detail in RFC 2578 Section 7.7, (https://tools.ietf.org/html/rfc2578#section-7). You can include the following elements:
INDEX_TYPE_INTEGER
INDEX_TYPE_IP
INDEX_TYPE_STRING
INDEX_TYPE_IMPLIEDSTRING
INDEX_TYPE_OID
INDEX_TYPE_IMPLIEDOID
- index_element_number is the position of the index_element that you want to collect. The first element in a multi-part index has the index_element_number of "0" (zero).
For example, suppose we have a collection object "o_224". Suppose the index for the OID in o_224 includes the following elements:
ipCidrRouteDest, ipCidrRouteMask, ipCidrRouteTos, ipCidrRouteNextHop
Here is the information about the example index:
OID Name | Data Type | Element Position in the Index |
---|---|---|
ipCidrRouteDest | INDEX_TYPE_IP | 0 |
ipCidrRouteMask | INDEX_TYPE_IP | 1 |
ipCidrRouteTos | INDEX_TYPE_INTEGER | 2 |
ipCidrRouteNextHop | INDEX_TYPE_IP | 3 |
To retrieve this index and assign only the value of ipCidrRouteNextHop to the new index collection object , we would enter the following in the SNMP OID field :
em7snmp.parse_index (o_224, [INDEX_TYPE_IP, INDEX_TYPE_IP, INDEX_TYPE_INTEGER, INDEX_TYPE_IP], 3)