| Section | |||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
New Features and Improvements
...
Try ------- after ------- -- delay until next -
seconds dd hh mm ss seconds dd hh mm ss
#00 0 [00 00:00:00] 400 [00 00:06:40]
#01 400 [00 00:06:40] 1200 [00 00:20:00]
#02 1600 [00 00:26:40] 2000 [00 00:33:20]
#03 3600 [00 01:00:00] 2800 [00 00:46:40]
#04 6400 [00 01:46:40] 3600 [00 01:00:00]
#05 10000 [00 02:46:40] 4400 [00 01:13:20]
#06 14400 [00 04:00:00] 5200 [00 01:26:40]
#07 19600 [00 05:26:40] 6000 [00 01:40:00]
... |
|---|
Extended Logging Framework
In order to unify logging capabilities an new framework has been implemented covering following features:
- Time based rotation
- Six different log levels
- Single point of configuration
Default logging verbose level is OFF. For appliances equipped with a Harddisk it is usefull to set the log level to INFO.
Lightning fast status data - Live Status
Module is internally used very extensive in order to work with much more recent runtime data then old status file based approach.
Time zones
Change Autoupdate process
If a downgrade is necessary it has to be performed manually by downloading the corresponding image from the portal server and manually installing it onto the appliance. Possible issues regarding the downgrade and an existing configuration should be discussed with the azeti support before actually performing the downgrade.
Disabling RRDs on satellities
In order to limit the number of disk i/o access a new option for Distributed Monitoring has been introduced to disable the recording of monitoring data on the sattelite appliance:
Admin GUI::Configuration::System::Status Delivery Configuration for Distributed Monitoring::Do not store performance data locally
In this case local RRDs are not used to save performance data, but they can be collected at NOC appliances by checking option
Admin GUI::Configuration::System::Status Delivery Configuration for Distributed Monitoring::Deliver Performance Data
Admin GUI
- rename of page "Configuration::Network::Interface Configuration" to "Configuration::Network::Ethernet Configuration"
- add new page "Configuration::Network::Routing Configuration"
- move "SonarDNS support" configuration to page "Configuration::Network::DNS Configuration"
- move "Static Routes" and "IP forwarding" to page "Configuration::Network::Routing Configuration"
Colors, fonts, pictures
Web interface of Sonarplex 5 was changed due to deliver better user experience and ease of usage. Fonts and colours have been changed to improve usability and readability.
Naming convention change
Since SONARPLEX 5 azeti is changing convention for device naming. SONARPLEX devices are now called azeti devices, for instance SONARPLEX 7300 will be called azeti 7300.
Plugin and Addon Compatibility
Almost all plugins and addons needs to be updated to a new version to be compatible with SONARPLEX 5. This section describes the changes and specifically notes when manual intervention is required to upgrade the plugin or addon to work on a SONARPLEX 5.
To make it short: any *.tar.gz packaged plugin will require an update. Any *.azsp, *.azsps, *.azse and *.azses package needs to be updated as well. Most of the *.pl plugins will work (for exceptions refer to the list below).
However: should you have 3rd party plugins installed, they might work out of the box but there is a chance they won't if they use hard coded file system paths. Refer to Upgrading Plugins manually to SONARPLEX 5.x.x compatibility (Experts only)
MODBUS plugins and daemon
The MODBUS daemon version 1.3.x and later will only work on the SONARPLEX 5 architecture. Don't try to install it on a SONARPLEX 4, it won't work.
The daemon is now packaged into a single azse file. There is no need to install separate packages for each serial interface any more. However there now are two separate MODBUS daemon packages, one for the Intel platforms (azeti 600M, 650M, 4300M, 7300M) -- take the one with "INTEL" in the file name. And one for the new azeti NG platform, which contains an "ARM" in its file name. Should you try to install the wrong daemon to your SOANRPLEX, the installation process will refuse to install this package, so just take the other one.
The daemon is backward compatible to earlier installations as far as possible and supports more than just two serial interfaces now. However, instead of using the MS Windows naming of the interfaces (COM1, COM2), we recommend using the UNIX pendants ttyS0, ttyS1, ttyS2, … instead. On Intel based SONARPLEX 5 devices, COM1 corresponds to ttyS2 and COM2 to ttyS3. Previous installations will work unaltered but on new hardware the old "COM1" and "COM2" settings in the host's MyProperties might no longer work. At the very least: don't mix both -- the old and the new -- naming schemes.
On azeti NG devices, a different naming scheme was adapted: use modbus1 and modbus2 to name the integrated serial EIA485 devices named in the same way at the front panel. Use these device names to configure MODBUS devices in the SONARPLEX.
Since daemon version 1.6.0, some incompatibilities had to be introduced to improve dry contact and door access reaction times. The corresponding plugins will now use passive check results and a more direct approach to interact with the daemon. Therefore they have to be upgraded to the latest verions along with the daemon and the configuration needs to be altered for some services. Furthermore, since the previous write plugin was not able to successfully write to both T3 device and the M2M controller registers, this plugin was enhanced to support both at once now.
To enable you to perform the adaption of the configuration as easy as possible, we provided you a simple to use plugin for doing both required changes. This configuration migration plugin needs to be installed once only. It performs the migration during the installation and thus can safely be removed after that has completed.
The MODBUS actions are now using the check_modbus_fast_write plugin and therefore the write plugin must be installed too, when using write actions.
...