.. snmp-traps:

SNMP Traps
----------

.. _22.1|VOSS-567:

When the managed system generates certain events, it will forward a SNMP trap. The reason for the event
trap is contained in the SNMP MIB string. 

.. important::

   It is strongly recommended that you monitor SNMP traps that can have a 
   **critical** severity level. Refer to the examples in this document.

For a list of notification messages, see: :ref:`notification-messages`.

Note that if the corresponding SNMP MIB is not loaded on the NMS,
a numerical representation of the SNMP entry is provided.

The list of monitored events is described in the SNMP Trap section below.
A detailed breakdown of each SNMP trap type is provided in the appendix.

..  .. note::

..   These SNMP traps are not raised when the system is in maintenance mode, but are resumed
..   once the system is exited from maintenance mode. 

The SNMP will send traps to the trap destination configured.
If the trap destination is incorrect or not configured, the NMS will not receive the traps.

SNMP configuration settings can be managed from the CLI. Refer to the CLI **notify** command:

::


 
    platform@development:~$ notify
    USAGE:
    ------
    notify add [info|warn|error]             - Add the email or snmp URI to a
       <email/snmp-uri> ...                      specified notification level.

   

The following system parameters are monitored by default

* Disk Space: warnings are issued if the file system breaches the following thresholds:

::

  disk  / 30% free
  disk  /opt/platform 30% free
  disk  /var/log 10% free
 
* System Load Monitoring: warnings are issued if the system load is excessive (the system load parameters can be defined during configuration)
* SNMP: standard SNMP System Events, for example, Cold Start
* Process state changes: Informative messages are sent to the NMS indicating that processes have been restarted.

In general, the originator of the SNMP traps is determined by originating hostname / IP address.
Many Network Management Systems provide trap management and escalation per system being managed,
including identification based on system name, location and contact details.

Those events monitored directly by |VOSS Automate| (e.g. disk space, system load and process warnings) include the system name
as part of the variable bindings to assist identification of the originating system.

The state of the |VOSS Automate| system can be monitored either on the NMS or via the command line interface using the **diag** command.



.. |VOSS Automate| replace:: VOSS Automate
.. |Unified CM| replace:: Unified CM