SONARPLEX Generation 5 Release
- Sebastian Koch
The SONARPLEX generation 5 software is the major release and a big step into the future. It offers a broad range of new features and many bug fixes and imporvements under the hood. Major changes were done to support future technologies, hardware platforms and to open ways for further virtualization support.
Upgrade
Check out the How-To Upgrade from SONARPLEX Generation 4 to 5 guide which leads you through all necessary steps.
Compatibility
Following matrix shows the compatibility of all azeti Products to the SONARPLEX Generation 5 release.
SONARPLEX Versions below the Generation 4 are already out of support and should be upgraded to the latest one. Updates are available as part of the azeti Live Update Service (LUS).
| Product | SONARPLEX Generation 5 (5.1.1a and above) Latest and recommended Release |
|---|---|
| azeti NG |  |
| azeti 600M | |
azeti 650M | |
| azeti 2300 | |
| azeti 2300 | |
| azeti 7300(M) | |
| azeti VAA | |
| azeti 3000 | Not supported because product is end-of-life |
| azeti SONARGATE | |
| azeti SMS Gateway | |
| azeti Windows Agent | |
| azeti Unix Agent | |
| azeti Mac OSX Agent | Not supported because product is end-of-life |
| azeti SONARMANAGER |
(SONARMANAGER Version 2.7.3.24 or higher required) |
On this page:
New Features and Improvements
E-Mail Daemon with Queue Administration - QMail
The Mail Transfer Agent of qmail operates independent and parallel to the monitoring. This minimizes the influence of email delivery to the monitoring performance. Furthermore qmail raises the stability and safety of the email transmission. A new page in the Administration GUI, "Email Queue", gives the possibility to maintain and observe the email message queue of outgoing notifications.
A fundamental distinction is the fact, that the appliance now holds a remote delivery queue. This means that if the receiving MTA could not be connected, the appliance will retry sending the mail.
Below an example of delivery times:
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.
Known Issues
- Socket error when performing check_modbus_write4
- Readme and Help should be revamped for check_snmp_itraffic
- Use pipes and separate plugin-daemons for time/load critical modbus plugins
- Module specific log level is not used, when global level is e.g. INFO
- Wrong write4 configuration leads to non-helpful error message
- Long boot time without ethernet connection
- Socket error when performing check_modbus_write4
- Reply timeouts in check_modbus_fast_read3
- Special character '°C' coding problem within DM
- Monitoring GUI "Processes", changes done there needs to be logged in "configchanges.log"
- Minor issues with backup versioning
- Video Harvester plugin creates wrong folder structure when '/' is not set as default destination path
- Multiple "All defined hosts" in distributed monitoring NOC setup
- Deleting a Service Dependency via Admin GUI can fail
- style