Known issues in 3.4.3
|
The following link http://jira.rivermuse.org/secure/IssueNavigator.jspa?mode=hide&requestId=10022 will take you to a real-time filter in Jira for all open tickets for 3.4.x.
The known issues documented below are tickets that RiverMuse wants to draw your attention to, or, have yet to be merged into the CORE system.
Desktop
Ticket No: CORE-8
Description: If an alert rule is defined that sets the owner of an alert, it correctly sets the owner, but leaves the status as unassigned. Currently there is no option available in the Rules Wizard to change the status to 'assigned' Therefore, the status should automatically be changed to 'assigned' as per the workflow ,or, the ability to change the status should be made available via the Rules Wizard. The preference would be to automatically set the status to force synchronization with the workflow.
Process Management GUI
Ticket No: CORE-9
Description: When applying a column sort in the process list for a host, the columns containing numbers are being sorted alphabetically, not numerically.
Description: As a pre-requisite to running the process manager agent on Windows, you need Java Runtime Environment 1.6 (JRE) on your system. If you have not previously installed the Java Runtime Environment 1.6 (JRE) download the application from http://www.java.com/getjava. Please be advised, the system relies on the 32 bit, NOT 64 bit, edition of the JRE.
Description: The Process Management GUI shows the current status of any managed system on starting, but, does not update the Process Management table to reflect any change in the states. You must manually refresh the system to update the process state.
|
|
yarpd
Ticket No: CORE-21
Description: When attempting to setup a time correlation to increase the severity of an alert after a period of time in rivermuse.conditions:
The condition did not return a TRUE value, so the associated action never executed.
Ticket No: CORE-4
Description: When you enable yarpd, the system performance degrades. When a system is receiving alerts, and yarpd is running, if the alert rate grows to above 20 per second then a backlog develops in the alert_MVC table. The backlog then grows at an increasing rate, whilst the receipt of alerts continues. The backlog can take a long period of time to clear.
Platform issue
When running Internet Explorer (IE)7, IE8, or, Firefox in a Windows XP environment, RiverMuse has recorded unusually high levels of memory usage. For example, over five hours on IE7, memory usage grew from 100MB to over 1GB.
The issue affects javascript engines running on certain platforms.
Currently, the issue is not present when running RiverMuse with IE8 on Windows Vista, and Google Chrome on the PC.
SNMP Traps
The discriminator field only allows 128 characters. Depending on the trap, and for the majority of traps, the whole discriminator cannot be displayed. This can cause issues with similar alerts becoming duplicates if they have slight differences, which have been truncated by the discriminator field. The varbinds have been included first in the discriminator, but sometimes varbinds can exceed 128 characters.
Currently unsupported
Description: The maximum length of an alert description is currently limited to 254 characters; this can be extended by running the following SQL:
ALTER TABLE `rivermuse`.`alerts` MODIFY COLUMN `description` TEXT DEFAULT NULL;
ALTER TABLE `rivermuse`.`events` MODIFY COLUMN `description` TEXT DEFAULT NULL;
You can provide a further extension by configuring rsyslog to allow large messages with the $MaxMessageSize directive. For further details go to the rsyslog website. If messages are received by UDP it is best not to go above 4k, otherwise up to 64k is valid.