3 Instrumentation Functions
A user-defined instrumentation function for each object attaches the managed objects to real resources. This function is called by the agent on a
getorsetoperation. The function could read some hardware register, perform a calculation, or whatever is necessary to implement the semantics associated with the conceptual variable. These functions must be written both for scalar variables and for tables. They are specified in the association file, which is a text file. In this file, theOBJECT IDENTIFIER, or symbolic name for each managed object, is associated with an Erlang tuple{Module,Function,ListOfExtraArguments}.When a managed object is referenced in an SNMP operation, the associated
{Module, Function, ListOfExtraArguments}is called. The function is applied to some standard arguments (for example, the operation type) and the extra arguments supplied by the user.Instrumentation functions must be written for
getandsetfor scalar variables and tables, and forget-nextfor tables only. Theget-bulkoperation is translated into a series of calles toget-next.3.1 Instrumentation Functions
The following sections describe how the instrumentation functions should be defined in Erlang for the different operations. In the following,
RowIndexis a list of key values for the table, andColumnis a column number.These functions are described in detail in Definition of Instrumentation Functions.
3.1.1 New / Delete Operations
For scalar variables:
variable_access(new [, ExtraArg1, ...]) variable_access(delete [, ExtraArg1, ...])For tables:
table_access(new [, ExtraArg1, ...]) table_access(delete [, ExtraArg1, ...])These functions are called for each object in an MIB when the MIB is unloaded or loaded, respectively.
3.1.2 Get Operation
For scalar variables:
variable_access(get [, ExtraArg1, ...])For tables:
table_access(get,RowIndex,Cols [,ExtraArg1, ...])
Colsis a list ofColumn. The agent will sort incoming variables so that all operations on one row (same index) will be supplied at the same time. The reason for this is that a database normally retrieves information row by row.These functions must return the current values of the associated variables.
3.1.3 Set Operation
For scalar variables:
variable_access(set, NewValue [, ExtraArg1, ...])For tables:
table_access(set, RowIndex, Cols [, ExtraArg1,..])
Colsis a list of tuples{Column, NewValue}.These functions returns
noErrorif the assignment was successful, otherwise an error code.3.1.4 Is-set-ok Operation
As a complement to the
setoperation, it is possible to specify a test function. This function has the same syntax as the set operation above, except that the first argument isis_set_okinstead ofset. This function is called before the variable is set. Its purpose is to ensure that it is permissible to set the variable to the new value.variable_access(is_set_ok, NewValue [, ExtraArg1, ...])For tables:
table_access(set, RowIndex, Cols [, ExtraArg1,..])
Colsis a list of tuples{Column, NewValue}.3.1.5 Undo Operation
A function which has been called with
is_set_okwill be called again, either withsetif there was no error, or withundo, if an error occurred. In this way, resources can be reserved in theis_set_okoperation, released in theundooperation, or made permanent in thesetoperation.variable_access(undo, NewValue [, ExtraArg1, ...])For tables:
table_access(set, RowIndex, Cols [, ExtraArg1,..])
Colsis a list of tuples{Column, NewValue}.3.1.6 GetNext Operation
The GetNext Operation operation should only be defined for tables since the agent can find the next instance of plain variables in the MIB and call the instrumentation with the
getoperation.table_access(get_next, RowIndex, Cols [, ExtraArg1, ...])
Colsis a list of integers, all greater than or equal to zero. This indicates that the instrumentation should find the next accessible instance. This function returns the tuple{NextOid, NextValue}, orendOfTable.NextOidshould be the lexicographically next accessible instance of a managed object in the table. It should be a list of integers, where the first integer is the column, and the rest of the list is the indices for the next row. IfendOfTableis returned, the agent continues to search for the next instance among the other variables and tables.
RowIndexmay be an empty list, an incompletely specified row index, or the index for an unspecified row.This operation is best described with an example.
3.1.6.1 GetNext Example
A table called
myTablehas five columns. The first two are keys (not accessible), and the table has three rows. The instrumentation function for this table is calledmy_table.
Contents of my_table
N/A means not accessible.
The manager issues the following
getNextrequest:getNext{ myTable.myTableEntry.3.1.1, myTable.myTableEntry.5.1.1 }Since both operations involve the 1.1 index, this is transformed into one call to
my_table:my_table(get_next, [1, 1], [3, 5])In this call,
[1, 1]is theRowIndex, where key 1 has value 1, and key 2 has value 1, and[3, 5]is the list of requested columns. The function should now return the lexicographically next elements:[{[3, 1, 2], d}, {[5, 1, 2], f}]This is illustrated in the following table:
GetNext from [3,1,1] and [5,1,1].The manager now issues the following
getNextrequest:getNext{ myTable.myTableEntry.3.2.1, myTable.myTableEntry.5.2.1 }This is transformed into one call to
my_table:my_table(get_next, [2, 1], [3, 5])The function should now return:
[{[4, 1, 1], b}, endOfTable]This is illustrated in the following table:
GetNext from [3,2,1] and [5,2,1].The manager now issues the following
getNextrequest:getNext{ myTable.myTableEntry.3.1.2, myTable.myTableEntry.4.1.2 }This will be transform into one call to
my_table:my_table(get_next, [1, 2], [3, 4])The function should now return:
[{[3, 2, 1], g}, {[5, 1, 1], c}]This is illustrated in the following table:
GetNext from [3,1,2] and [4,1,2].The manager now issues the following
getNextrequest:getNext{ myTable.myTableEntry, myTable.myTableEntry.1.3.2 }This will be transform into two calls to
my_table:my_table(get_next, [], [0]) and my_table(get_next, [3, 2], [1])The function should now return:
[{[3, 1, 1], a}] and [{[3, 1, 1], a}]In both cases, the first accessible element in the table should be returned. As the key columns are not accessible, this means that the third column is the first row.
Normally, the functions described above behave exactly as shown, but they are free to perform other actions. For example, a get-request may have side effects such as setting some other variable, perhaps a global
lastAccessedvariable.3.2 Using the ExtraArgument
The
ListOfExtraArgumentscan be used to write generic functions. This list is appended to the standard arguments for each function. Consider two read-only variables for a device,ipAdrandnamewith object identifiers 1.1.23.4 and 1.1.7 respectively. To access these variables, one could implement the two Erlang functionsip_accessandname_access, which will be in the MIB. The functions could be specified in a text file as follows:
{ipAdr, {my_module, ip_access, []}}. % Or using the oid syntax for 'name' {[1,1,7], {my_module, name_access, []}}.The
ExtraArgumentparameter is the empty list. For example, when the agent receives a get-request for theipAdrvariable, a call will be made toip_access(get). The value returned by this function is the answer to the get-request.If
ip_accessandname_accessare implemented similarly, we could write ageneric_accessfunction using theListOfExtraArguments:{ipAdr, {my_module, generic_access, ['IPADR']}}. % The mnemonic 'name' is more convenient than 1.1.7 {name, {my_module, generic_access, ['NAME']}}.When the agent receives the same get-request as above, a call will be made to
generic_access(get,'IPADR').Yet another possibility, closer to the hardware, could be:
{ipAdr, {my_module, generic_access, [16#2543]}}. {name, {my_module, generic_access, [16#A2B3]}}.3.3 Default Instrumentation
When the MIB definition work is finished, there are two major issues left.
- Implementing the MIB
- Implementing a Manager Application.
Implementing an MIB can be a tedious task. Most probably, there is a need to test the agent before all tables and variables are implemented. In this case, the default instrumentation functions are useful. The toolkit can generate default instrumentation functions for variables as well as for tables. Consequently, a running prototype agent, which can handle
set,get,get-nextand table operations, is generated without any programming.The agent stores the values in an internal volatile database, which is based on the standard module
ets. However, it is possible to let the MIB compiler generate functions which use an internal, persistent database, or the Mnesia DBMS. Refer to the Mnesia User Guide and the Reference Manual, section SNMP, modulesnmp_genericfor more information.When parts of the MIB are implemented, you recompile it and continue on by using default functions. With this approach, the SNMP agent can be developed incrementally.
The default instrumentation allows the application on the manager side to be developed and tested simultaneously with the agent. As soon as the ASN.1 file is completed, let the MIB compiler generate a default implementation and develop the management application from this.
3.3.1 Table Operations
The generation of default functions for tables works for tables which use the
RowStatustextual convention from SNMPv2, defined in STANDARD-MIB and SNMPv2-TC.
We strongly encourage the use of the
RowStatusconvention for every table that can be modified from the manager, even for newly designed SNMPv1 MIBs. In SNMPv1, everybody has invented their own scheme for emulating table operations, which has led to numerous inconsistencies. The convention in SNMPv2 is flexible and powerful and has been tested successfully. If the table is read only, no RowStatus column should be used.3.4 Atomic Set
In SNMP, the
setoperation is atomic. Either all variables which are specified in asetoperation are changed, or none are changed. Therefore, thesetoperation is divided into two phases. In the first phase, the new value of each variable is checked against the definition of the variable in the MIB. The following definitions are checked:
- the type
- the length
- the range
- the variable is writable and within the MIB view.
At the end of phase one, the user defined
is_set_okfunctions are called for each scalar variable, and for each group of table operations.If no error occurs, the second phase is performed. This phase calls the user defined
setfunction for all variables.If an error occurs, either in the
is_set_okphase, or in thesetphase, all functions which were called withis_set_okbut notset, are called withundo.There are limitations with this transaction mechanism. If complex dependencies exist between variables, for example between
monthandday, another mechanism is needed. Setting the date to 'Feb 31' can be avoided by a somewhat more generic transaction mechanism. You can continue and find more and more complex situations and construct an N-phase set-mechanism. This toolkit only contains a trivial mechanism.The most common application of transaction mechanisms is to keep row operations together. Since our agent sorts row operations, the mechanism implemented in combination with the RowStatus (particularly 'createAndWait' value) solve most problems elegantly.