Home > Storage > PowerScale (Isilon) > Product Documentation > Management and Migration > PowerScale OneFS: Advanced Alert Configurations > SNMP alerts
SNMP alerts provide a standardized interface to query network devices for information. This can include uptime, descriptions, locations, and device-specific information. For OneFS, the device specific information includes cluster and node data, disk health, and much more.
There are two parts to the OneFS implementation of SNMP as listed below:
This section will only cover SNMP TRAP. The SNMP monitoring will be discussed in section 2.
Note: At the time of writing, any value in the OneFS SNMP TRAP configuration cannot be customized.
As explained in the Alert architecture section, OneFS sends an SNMP TRAP when CELOG events occur, sending them through configured SNMP TRAP channels. Internally SNMP TRAPs are sent by process snmpinform or snmptrap with appropriate parameters to a third-party SNMP management console on the client side.
As shown in this figure, either ‘snmpinform’ or ‘snmptrap’ can send the SNMP TRAP notification. The difference is that snmptrap is used to send the unacknowledged SNMP TRAP, which means that this process does not know whether the remote subscriber has received the message. The snmpinform, on the other hand, can send an acknowledged SNMP TRAP, which is also known as SNMP INFORM. For the detailed configuration of snmpinform and snmptrap, see the section Configuration considerations.
OneFS uses a custom management information base (MIB) to define human-readable names for managed SNMP objects and specify their data types and other properties. You can download these PowerScale specific MIBs from aa PowerScale node under /usr/share/snmp/mib/. For detailed information about MIB, see the section SNMP monitoring architecture.
Prior to OneFS 8.2.0, PowerScale OneFS only supports SNMPv2c TRAP, which means there is no authentication or encryption feature for SNMP TRAP. For the detailed difference between SNMPv2c and SNMPv3, see the section SNMP monitoring architecture.
To create an SNMP channel using snmptrap to send unacknowledged SNMP TRAP, use the following CLI command:
isi event channels create channel_1 snmp –-use-snmp-trap true
To create an SNMP channel using snmpinform to send acknowledgeable SNMP INFORMs, use the following CLI command:
isi event channels create channel_2 snmp –-use-snmp-trap false
Note: The switch to use snmpinform or snmptrap is only available in the CLI or PAPI (Platform API).
From OneFS version 8.0 onwards, CELOG uses snmpinform by default to send acknowledgeable SNMP TRAPs and sometimes this may not be supported in all customer environments. In these cases, it is recommended to modify the alert channel back to snmptrap. For details, see the KB article Upgrade to 8.0.x changes default SNMP behavior from 'snmptraps' to 'snmpinform'.
When an event channel has been set up to enable the snmptrap settings, changing the channel by the WebUI will lose the value of the snmptrap settings and revert to snmpinform settings. This issue is fixed in OneFS 8.0.0.6 and for the detailed information, see the KB article CELOGv2: Modify SNMP channel via WebUI reset use-snmp-trap.
The general configuration for SNMP alerts requires the end user to provide the following information:
The following command is an example to create an SNMP channel using snmptrap to the public community on a host with IP address 10.xxx.xxx.xxx
isi event channels create snmpchannel snmp –-use-snmp-trap true –-community public –-host 10.xxx.xxx.xxx
After you have created the SNMP channel, create an alert to use this channel:
isi event alerts modify myalert --channel snmpchannel
It is recommended to test the SNMP alert settings before you configure the third-party SNMP management software. The following example uses snmptrapd to verify the configuration and test the SNMP alert on a remote server.
echo "authCommunity log public" > /tmp/traps.cfg
snmptrapd -Lf /tmp/snmptrapd_traps.log -C -c /tmp/traps.cfg -p /tmp/at_snmp.pid -m ALL
NET-SNMP version 5.7.2
2018-05-07 04:56:46 <UNKNOWN> [UDP: [10.yyy.yyy.yyy]:35488->[10.xxx.xxx.xxx]:162]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (873813181) 101 days, 3:15:31.81
SNMPv2-MIB::snmpTrapOID.0 = OID: ISILON-TRAP-MIB::testEventCrit
ISILON-TRAP-MIB::instanceIdentifier = STRING: "2221"
ISILON-MIB::clusterName = STRING: x41040g
ISILON-MIB::nodeName = STRING: x41040g-1
ISILON-MIB::nodeSerialNumber = STRING: SX410-301448-0070
ISILON-TRAP-MIB::eventKbUrl = STRING: "Unavailable."
ISILON-TRAP-MIB::eventKbUrl = STRING: "Unavailable."
Starting from OneFS 8.2.0, PowerScale supports SNMPv3 TRAP which provides more security options like authentication and encryption. The detailed security levels supported are listed below:
Protocol version | Security levels | Description |
SNMPv3 | AuthPriv | Both authentication and encryption are enabled |
AuthNoPriv | Authentication is enabled but encryption is disabled | |
noAuthNoPriv | Both authentication and encryption are disabled |
The security level can be configured through the parameter --snmp-security-level under isi event channel modify. Unlike SNMPv2c, which use SNMP community string to identify the subscriber, SNMPv3 use MD5 or SHA encrypted passphrase for this purpose. Based on this, the community string should be left empty when the SNMPv3 channel is created. To set the authentication algorithm, use the parameter --snmp-auth-protocol and at the same time set the passphrase by --snmp-auth-password.
The SNMPv3 channel can only be created or configured through OneFS CLI. The following is an example to walk through all the configurations for this purpose. In this example, we create an SNMPv3 user - traptest whose passphrase is mypassword for both authentication (SHA) and encryption (AES). This user will be used in this SNMPv3 channel for the remote SNMPv3 host 10.7.xxx.xxx to subscribe the SNMPv3 TRAP.
isi event channels create snmpchannel snmp
--host 10.7.xxx.xxx
--use-snmp-trap True
--snmp-use-v3 True
--snmp-auth-protocol SHA
--snmp-auth-password mypassword
--snmp-priv-protocol AES
--snmp-priv-password mypassword
--snmp-security-level authPriv
--snmp-security-name traptest
--snmp-engine-id 0x8000000001020304
isi event alerts modify myalert --channel snmpchannel
It is recommended to test the SNMP alert settings before you configure the third-party SNMP management software. The following example uses snmptrapd to verify the configuration and test the SNMP alert on a remote server.
echo "createUser -e 0x8000000001020304 traptest SHA mypassword AES mypassword
authuser log traptest" > /tmp/traps.cfg
snmptrapd -Lf /tmp/snmptrapd_traps.log -C -c /tmp/traps.cfg -p /tmp/at_snmp.pid -m ALL
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (6229647) 17:18:16.47 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.12124.250.24.6.3 SNMPv2-SMI::enterprises.12124.250.50.15 = STRING: "9"
SNMPv2-SMI::enterprises.12124.1.1.1 = STRING: "vshen-5coqidt"
SNMPv2-SMI::enterprises.12124.2.1.1 = STRING: "vshen-5coqidt-1" SNMPv2-SMI::enterprises.12124.2.1.5 = STRING: "SV200-004EIJ-5XA4" SNMPv2-SMI::enterprises.12124.250.50.19 = STRING: "400150007" SNMPv2-SMI::enterprises.12124.250.50.20 = STRING: "SW_UPGRADE_NODE_NON_RESPONSIVE" SNMPv2-SMI::enterprises.12124.250.50.18 = STRING: http://doc.isilon.com/onefs/8.2/help/en-us/#ifs_r_event_400150007.html
Clear SNMP TRAP is introduced in OneFS 8.2.0. When an issue happens and is detected by CELOG, an SNMP TRAP will be sent if the corresponding SNMP channel has been created before. After this issue is fixed and the event is marked resolved, a clear SNMP TRAP will automatically be sent to the SNMP subscriber. The overall workflow is shown in Figure 18.
In the example shown in this figure, an issue happens due to the missing mirror boot disk. This issue is detected by the CELOG, and an SNMP TRAP is delivered with OID: bootDiskMirrorReqMissingCrit to the SNMP subscriber. After this issue is fixed and the event group is marked as resolved, a clear SNMP TRAP is delivered automatically to notify to the subscriber. The OID, in this case, is bootDiskMirrorReqMissingCritClear.
Note: From OneFS 8.2.0, all SNMP TRAP should have clear versions.
From OneFS 8.2.0, All the CELOG eventgroups now have associated SNMP TRAP.