1.22. Release Notes 1.0.5¶
1.22.1. New features¶
- Discovery and monitoring of operational state of power supply units and fans has been added for Cisco, Arista and Juniper. Since these vendors provide different and incompatible OIDs that expose various metrics for power supplies and fans, NetSpyGlass converts values it collects using those to two standardized vendor-neutral monitoring variables psuState and fanState that have value “1” when component is operating normally or “0” when it fails. The original variables also appear in the Graphing Workbench and other parts of NetSpyGlass UI and can be used for calculations or alerts. For example, one of the variables we use to monitor the state of fans on Arista devices actually returns fan speed in rpm. By default NetSpyGlass only uses this to check if the fan is spinning, however you could use this variable to set up an alert that would activate when the fan is spinning too fast. Original variables provide more fine grained information about the component but have incompatible semantics, while unified variables psuState and fanState are more coarse since they reflect only two states, “normal” or “failure”, but work across all supported vendors.
- On Cisco we monitor OIDs CISCO-ENVMON-MIB:ciscoEnvMonSupplyState or CISCO-ENTITY-FRU-CONTROL-MIB:cefcFRUPowerStatusTable (whichever is supported by the device) for power supplies and CISCO-ENVMON-MIB:ciscoEnvMonFanState for fans. Unprocessed variable names are ciscoEnvMonSupplyState, cefcFRUPowerStatusTable and ciscoEnvMonFanState; their values are converted to psuState and fanState See functions
- On Arista NetSpyGlass uses OID that measures input PSU current as a proxy for the PSU state. The value is collected in the variable aristaPSUInputCurrentSensor and is converted to variable psuState by function
nw2rules(operating state is considered “normal” if input current is greater than 0). For the fans on Arista, NetSpyGlass monitors fan rpm sensor (variable aristaFanSensor ) and converts it to fanState by also comparing with zero - the fan is considered to be operating normally if the value is greater than 0. See function
- On Juniper NetSpyGlass uses OIDs JUNIPER-MIB:jnxOperatingState and tracks state of the power supplies in variable jnxPSUOperatingState and state of fans in jnxFanOperatingState. Their values are converted to psuState and fanState. See functions
fan_juniper()in the same module.
- you can find Python functions that perform the conversion in the default rules script. The copy of the script comes as part of the distribution rpm or deb package in the file /opt/netspyglass/current/python/nw2rules.py. Search the file for functions
- Added fields “user” and “reason” to the AlertSilence object. These fields can be set and accessed both via JSON API and script silence.py
- added arguments on_active and on_clear to the function
on_activate(if provided and if the value is not None) should be a string that consists of the full path and optionally command line arguments (separated by spaces) for an external script or a program that NetSpyGlass should call when alert goes from state ‘cleared’ to state ‘active’. Informtation is passed to this script via environment variables with names composed from alert_ and alert object field name, such as alert_name, alert_deviceName and so on. The set of fields and therefore set of environment variables is the same as the set of variables you can access via macros. Parameter
on_clearworks in a similar way, except the script is called when alert clears (goes from the state active to state clear). These “action” scripts can be used to various kinds of automations triggered by alerts.
- discovered JunOS bug that broke interface CoS queue configurations on some Juniper devices. On devices with this bug walking OID JUNIPER-COS-MI::jnxCosQstatTailDropPkts ( .188.8.131.52.4.1.26184.108.40.206.1.11 ) yields “No Such Instance currently exists at this OID” but walking the parent JUNIPER-COS-MI::jnxCosQstatTable or just JUNIPER-COS-MI::jnxCosQstatEntry (.220.127.116.11.4.1.2618.104.22.168.1) returns expected results. I have ran into this bug on EX4500 running JunOS 12.3R6.6. This release includes workaround that makes it possible to discover interface queue configuration on devices like that
- Added Python function
nw2functions.skip_nans()that can be used to filter out monitoring variable instances with value NaN before they are fed to
- Added ability to discover links between a switche and a server that runs LLDP but does not respond to SNMP queries. For this to work and make the server appear in maps it should be added to the configuration. Since the server does not respond to SNMP, the community string used in the config can be anything as long as it is not empty string.
1.22.2. Bugs fixed in this version¶
- NET-1064 : handling of the clock shift because of the leap second