1.52. Release Notes 0.93

1.52.1. New features and improvements in this release

  • Improved stability in the monitor: smaller memory footprint.
  • discovery and monitoring of chassis alarms for Cisco and Juniper

Monitoring variables minorChassisAlarm and majorChassisAlarm poll values of chassis alarms. On Cisco, these correspond to OIDs chassisMinorAlarm and chassisMajorAlarm from the CISCO-STACK-MIB. The value of the variable is “0” when there are no active alarms and “1” when corresponding OID returns value of “on”, indicating that the chassis has raised an alarm. Monitoring variables minorChassisAlarm and majorChassisAlarm are “gauges”, that is, they track values of the corresponding OIDs and return back to “0” when alarms are cleared.

On Juniper, these variables track values returned by OIDs jnxYellowAlarmCount and jnxRedAlarmCount from JUNIPER-ALARM-MIB. The value of these monitoring variables is, therefore, equal to the number of active alarms at any moment. Monitoring variable minorChassisAlarm corresponds to the yellow alarm and majorChassisAlarm corresponds to the red alarm.

There is always only one instance of minorChassisAlarm and one instance of majorChassisAlarm per device that supports it. There are no instances of these variables for the devices that do not offer SNMP support for chassis alarms.

Chassis alarm variables appear in the tab “Chassis Alarms” in the device details page.

  • Graphs
Implemented support for the embedded device graph. Clicking link “Permanent link to this graph” on the device details page opens a small pop-up panel where user can enter the size of the graph and get a url that can be copied and pasted into thrid party dashboards. The link opens embeddable panel with the graph and graph legend that update itself every 30 sec.
  • Size of the icons representing devices on maps can be controlled by ‘display.map.nodeRadius’ configuration parameter. Supported values are: ‘fixed’, ‘auto’ or a number that represents icon radius in pixels.

1.52.2. Known issues

Data processing functions should be applied to the time series data in correct order. Some of the functions operate on the time series and return new time series, while others operate only on the last data point and return single data point. For example, rate() operates on the time series and returns new time series that is one data point shorter. smm() takes time series as an input and returns new time seties as well. Functions mul() and div() operate only on the last value and return single data point. This means, sequence

mul(smm(rate( ... )))

will compute rate, smooth it and then multiple the last value, which leads to the correct result. However,:

smm(mul(rate( ... )))

does not, because mul() returns only single data point so smm() does not have enough time series data to smooth.

This is going to be fixed in one of the subsequent releases.