1.22. Release Notes 1.0.5

NetSpyGlass v1.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 psu_cisco() and fan_cisco() in module nw2rules
    • 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 psu_arista() in module 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 fan_arista() in module nw2rules.
    • 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 psu_juniper() and 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 psu_state() and fan_state().
  • 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 nw2functions.alert(). Parameter 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_clear works 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 ( .1.3.6.1.4.1.2636.3.15.4.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 (.1.3.6.1.4.1.2636.3.15.4.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 nw2functions.aggregate()
  • 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