snmpa
DATA TYPES
oid() = [byte()] atl_type() = read | write | read_write notification_delivery_info() = #snmpa_notification_delivery_info{}
The oid() type is used to represent an ASN.1 OBJECT IDENTIFIER.
The record snmpa_notification_delivery_info contains the following fields:
- tag = term()
-
A user defined identity representing this notification send operation.
- mod = module()
-
A module implementing the snmpa_notification_delivery_info_receiver behaviour. The info functions of this module will be called at various stages of delivery.
- extra = term()
-
This is any extra info the user wants to have supplied when the functions in the callback module is called.
Types
Performs a GET operation on the agent. All loaded MIB objects are visible in this operation. The agent calls the corresponding instrumentation functions just as if it was a GET request coming from a manager.
Note that the request specific parameters (such as current_request_id) are not accessible for the instrumentation functions if this function is used.
Types
Performs a GET-NEXT operation on the agent. All loaded MIB objects are visible in this operation. The agent calls the corresponding instrumentation functions just as if it was a GET request coming from a manager.
Note that the request specific parameters (such as snmpa:current_request_id/0 are not accessible for the instrumentation functions if this function is used.
Types
Backup persistent/permanent data handled by the agent (such as local-db, mib-data and vacm).
Data stored by mnesia is not handled.
BackupDir cannot be identical to DbDir.
Simultaneous backup calls are not allowed. That is, two different processes cannot simultaneously successfully call this function. One of them will be first, and succeed. The second will fail with the error reason backup_in_progress.
Types
Types
Load Mibs into an agent. If the agent cannot load all MIBs (the default value of the Force argument is false), it will indicate where loading was aborted. The MibName is the name of the Mib, including the path to where the compiled mib is found. For example,
Dir = code:priv_dir(my_app) ++ "/mibs/", snmpa:load_mibs(snmp_master_agent, [Dir ++ "MY-MIB"]).
If Force = true then the agent will continue attempting to load each mib even after failing to load a previous mib. Use with care.
Types
Types
Get the request-id, context, community and address of the request currently being processed by the agent.
Note that these functions is intended to be called by the instrumentation functions and only if they are executed in the context of the agent process (e.g. it does not work if called from a spawned process).
Types
Converts the symbolic value Enum to the corresponding integer of the enumerated object or type Name in a MIB. The MIB must be loaded.
false is returned if the object or type is not defined in any loaded MIB, or if it does not define the symbolic value as enumerated.
Db is a reference to the symbolic store database (retrieved by a call to get_symbolic_store_db/0).
Types
Converts the integer Int to the corresponding symbolic value of the enumerated object or type Name in a MIB. The MIB must be loaded.
false is returned if the object or type is not defined in any loaded MIB, or if it does not define the symbolic value as enumerated.
Db is a reference to the symbolic store database (retrieved by a call to get_symbolic_store_db/0).
Types
Looks up the OBJECT IDENTIFIER of a MIB object, given the symbolic name. Note, the OBJECT IDENTIFIER is given for the object, not for an instance.
false is returned if the object is not defined in any loaded MIB.
Db is a reference to the symbolic store database (retrieved by a call to get_symbolic_store_db/0).
log_to_txt(LogDir, Mibs, OutFile, LogName, LogFile, Block | Start) -> ok | {ok, Cnt} | {error, Reason}
log_to_txt(LogDir, Mibs, OutFile, LogName, LogFile, Block, Start) -> ok | {ok, Cnt} | {error, Reason}
log_to_txt(LogDir, Mibs, OutFile, LogName, LogFile, Start, Stop) -> ok | {ok, Cnt} | {error, Reason}
log_to_txt(LogDir, Mibs, OutFile, LogName, LogFile, Block, Start, Stop) -> ok | {ok, Cnt} | {error, Reason}
OTP R16B03
Types
Converts an Audit Trail Log to a readable text file. OutFile defaults to "./snmpa_log.txt". LogName defaults to "snmpa_log". LogFile defaults to "snmpa.log".
The Block option indicates if the log should be blocked during conversion. This could be usefull when converting large logs (when otherwise the log could wrap during conversion). Defaults to true.
See snmp:log_to_txt for more info.
log_to_io(LogDir, Mibs, LogName, LogFile, Block | Start) -> ok | {ok, Cnt} | {error, Reason}
OTP R15B01
log_to_io(LogDir, Mibs, LogName, LogFile, Block, Start) -> ok | {ok, Cnt} | {error, Reason}
OTP R15B01
log_to_io(LogDir, Mibs, LogName, LogFile, Start, Stop) -> ok | {ok, Cnt} | {error, Reason}
OTP R15B01
log_to_io(LogDir, Mibs, LogName, LogFile, Block, Start, Stop) -> ok | {ok, Cnt} | {error, Reason}
OTP R16B03
Types
Converts an Audit Trail Log to a readable format and prints it on stdio. LogName defaults to "snmpa_log". LogFile defaults to "snmpa.log".
The Block option indicates if the log should be blocked during conversion. This could be usefull when converting large logs (when otherwise the log could wrap during conversion). Defaults to true.
See snmp:log_to_io for more info.
Types
Changes the log size of the Audit Trail Log. The application must be configured to use the audit trail log function. Please refer to disk_log(3) in Kernel Reference Manual for a description of how to change the log size.
The change is permanent, as long as the log is not deleted. That means, the log size is remembered across reboots.
Types
Types
Types
Types
Types
Registers a sub-agent under a sub-tree of another agent.
It is easy to make mistakes when registering sub-agents and this activity should be done carefully. For example, a strange behaviour would result from the following configuration:
snmp_agent:register_subagent(MAPid,[1,2,3,4],SA1), snmp_agent:register_subagent(SA1,[1,2,3], SA2).
SA2 will not get requests starting with object identifier [1,2,3] since SA1 does not.
Types
Send the notification Notification to the management targets defined for notify-name (name) in the snmpNotifyTable in SNMP-NOTIFICATION-MIB from the specified context.
If no name is specified (or if it is ""), the notification is sent to all management targets.
If no context is specified, the default context, "", is used.
The send option receiver specifies where information about delivery of Inform-Requests should be sent. The agent sends Inform-Requests and waits for acknowledgments from the management targets. The receiver can have three values:
-
no_receiver - No information is delivered.
-
notification_delivery_info() - The information is delivered via a function call according to this data. See the DATA TYPES section above for details.
-
{tag(), tag_receiver()} - The information is delivered either via messages or via a function call according to the value of tag_receiver().
Delivery is done differently depending on the value of tag_receiver():
-
pid() | registered_name() - The info will be delivered in the following messages:
-
{snmp_targets, tag(), Addresses}
This informs the user which target addresses the notification was sent to.
-
{snmp_notification, tag(), {got_response, Address}}
This informs the user that this target address acknowledged the notification.
-
{snmp_notification, tag(), {no_response, Address}}
This informs the user that this target address did not acknowledge the notification.
The notification is sent as an Inform-Request to each target address in Addresses and if there are no targets for which an Inform-Request is sent, Addresses is the empty list [].
The tag_receiver() will first be sent the snmp_targets message, and then for each address in Addresses list, one of the two snmp_notification messages.
-
-
{Mod, Func, Args} - The info will be delivered via the function call:
Mod:Func([Msg | Args])
where Msg has the same content and purpose as the messages descrived above.
-
The 'process oid' "tag" that can be provided with the variable name / oids is indended to be used for oid post processing. The value 'keep', which is the default, leaves the oid as is. The value 'truncate', will cause the oid to be "truncated". That is, any trailing ".0" will be removed.
There is a way to exclude a varbind from the notification. In the normal varbinds list, providing the special value '$ignore-oid' (instead of a normal value) will exclude this varbind from the notification.
A define for this has been added to the snmp_types.hrl include file, NOTIFICATION_IGNORE_VB_VALUE.
The extra info is not normally interpreted by the agent, instead it is passed through to the net-if process. It is up to the implementor of that process to make use of this data.
The version of net-if provided by this application makes no use of this data, with one exception: Any tuple containing the atom snmpa_default_notification_extra_info may be used by the agent and is therefor reserved.
See the net-if incomming messages for sending a trap and notification for more info.
send_notification(Agent, Notification, Receiver, NotifyName, ContextName, Varbinds, LocalEngineID) -> void()
OTP R14B
Types
Sends the notification Notification to the management targets defined for NotifyName in the snmpNotifyTable in SNMP-NOTIFICATION-MIB from the specified context.
If no NotifyName is specified (or if it is ""), the notification is sent to all management targets (Addresses below).
If no ContextName is specified, the default "" context is used.
The parameter Receiver specifies where information about delivery of Inform-Requests should be sent. The agent sends Inform-Requests and waits for acknowledgments from the managers. Receiver can have three values:
-
no_receiver - No information is delivered.
-
notification_delivery_info() - The information is delivered via a function call according to this data. See the DATA TYPES section above for details.
-
{Tag, Recv} - The information is delivered either via messages or via a function call according to the value of Recv.
If Receiver has the value {Tag, Recv}, the delivery is done according to Recv:
-
pid() | atom() - The info will be delivered in the following messages:
-
{snmp_targets, Tag, Addresses}
This inform the user which target addresses the notification was sent to.
-
{snmp_notification, Tag, {got_response, Address}}
This informs the user that this target address acknowledged the notification.
-
{snmp_notification, Tag, {no_response, Address}}
This informs the user that this target address did not acknowledge notification.
The notification is sent as an Inform-Request to each target address in Addresses and if there are no targets for which an Inform-Request is sent, Addresses is the empty list [].
The receiver will first be sent the snmp_targets message, and then for each address in Addresses list, one of the two snmp_notification messages.
-
-
{Mod, Func, Args} - The info will be delivered via the function call:
Mod:Func([Msg | Args])
where Msg has the same content and purpose as the messages descrived above.
Address is a management target address and Addresses is a list of management target addresses. They are defined as followes:
Addresses = [address()] Address = address() address() = v1_address() | v3_address() v1_address() = {TDomain, TAddress} v3_address() = {{TDomain, TAddress}, V3MsgData} TDomain = tdoamin() TAddress = taddress() tdomain() = The oid of snmpUDPDomain This is the only supported transport domain. taddress() = [A1, A2, A3, A4, P1, P3] The 4 first bytes makes up the IP-address and the last 2, the UDP-port number. V3MsgData = v3_msg_data() v3_msg_data() = term()
If Receiver is a notification_delivery_info() record, then the information about the notification delivery will be delivered to the receiver via the callback functions defined by the snmpa_notification_delivery_info_receiver behaviour according to the content of the notification_delivery_info() record.
The optional argument Varbinds defines values for the objects in the notification. If no value is given for an object, the Agent performs a get-operation to retrieve the value.
Varbinds is a list of Varbind, where each Varbind is one of:
- {Variable, Value}, where Variable is the symbolic name of a scalar variable referred to in the notification specification.
- {Column, RowIndex, Value}, where Column is the symbolic name of a column variable. RowIndex is a list of indices for the specified element. If this is the case, the OBJECT IDENTIFIER sent in the notification is the RowIndex appended to the OBJECT IDENTIFIER for the table column. This is the OBJECT IDENTIFIER which specifies the element.
- {OID, Value}, where OID is the OBJECT IDENTIFIER for an instance of an object, scalar variable, or column variable.
For example, to specify that sysLocation should have the value "upstairs" in the notification, we could use one of:
- {sysLocation, "upstairs"} or
- {[1,3,6,1,2,1,1,6,0], "upstairs"} or
- {?sysLocation_instance, "upstairs"} (provided that the generated .hrl file is included)
If a variable in the notification is a table element, the RowIndex for the element must be given in the Varbinds list. In this case, the OBJECT IDENTIFIER sent in the notification is the OBJECT IDENTIFIER that identifies this element. This OBJECT IDENTIFIER could be used in a get operation later.
This function is asynchronous, and does not return any information. If an error occurs, user_err/2 of the error report module is called and the notification is discarded.
Note that the use of the LocalEngineID argument is only intended for special cases, if the agent is to "emulate" multiple EngineIDs! By default, the agent uses the value of SnmpEngineID (see SNMP-FRAMEWORK-MIB).
ExtraInfo is not normally used in any way by the agent. It is intended to be passed along to the net-if process, which is a component that a user can implement themself. The users own net-if may then make use of ExtraInfo. The net-if provided with this application does not process ExtraInfo.
There is one exception. Any tuple containing the atom snmpa_default_notification_extra_info will, in this context, be considered belonging to this application, and may be processed by the agent.
discovery(TargetName, Notification, ContextName, Varbinds) -> {ok, ManagerEngineID} | {error, Reason}
discovery(TargetName, Notification, Varbinds, DiscoHandler) -> {ok, ManagerEngineID} | {error, Reason}
discovery(TargetName, Notification, ContextName, Varbinds, DiscoHandler) -> {ok, ManagerEngineID} | {error, Reason}
discovery(TargetName, Notification, ContextName, Varbinds, DiscoHandler, ExtraInfo) -> {ok, ManagerEngineID} | {error, Reason}
Types
Initiate the discovery process with the manager identified by TargetName using the notification Notification.
This function is synchronous, which means that it will return when the discovery process has been completed or failed.
The DiscoHandler module is used during the discovery process. See discovery handler for more info.
The ExtraInfo argument is passed on to the callback functions of the DiscoHandler.
If we are not at security-level noAuthNoPriv, this could be complicated, since the agent will then continue with stage 2, before which the usm-related updates must be done.
The default discovery handler will require additional actions by the caller and the discovery will not work if the security-level is higher then noAuthNoPriv.
Types
This off-line utility function can be used to convert the old snmp application config (pre snmp-4.0) to the new snmp agent config (as of snmp-4.0).
For information about the old config (OldConfig) see the OTP R9C documentation.
For information about the current agent config (AgentConfig), see the Configuring the application chapter of the SNMP user's guide.
Types
Sets verbosity for the designated process. For the lowest verbosity silence, nothing is printed. The higher the verbosity, the more is printed.
See Also
calendar(3), erlc(1)