Version 6.3.0 Release Notes
Alerts
18405: Integrate with new EM alert notifier
Alert notifications in EMS Monitor have been enhanced to support easier
integration with EM. In order to support this, the previously supported
notifications properties are no longer being used. See the upgrade notes section
below if you have modified or overridden the values for any of the notification
properties.
The following properties are defined in rtvapm.properties for notifications:
sl.rtview.alert.notifierenabled - Set to true to enable alert notifications. This
defaults to true. To disable alert notifications, set this to false.
sl.rtview.alert.notifiercommandnew - Set this to the command to execute when a
new alert is generated. This defaults to executing the my_alert_actions.bat. To
execute my_alert_actions.sh, set the following:
sl.rtview.cmd_line=-sub:$scriptEnding:sh.
To execute a different script with the same arguments, set the following (where
my_script is the name of your script):
sl.rtview.cmd_line=-sub:$alertActionScript:my_script
sl.rtview.alert.notifiercommandsevincrease - Set this to the command to execute
the first time an alert changes severity. The default for this is the same as the
sl.rtview.alert.notifiercommandnew.
sl.rtview.alert.notifiercommandcleared - Set this to the command to execute the
when an alert is cleared. By default, no command is configured. To execute a
script, copy the notifiercommandnew line and replace $alertActionScript with the
name of the script you want to execute. To execute a custom java command, see the
example in common\conf\custom_handlers.properties.
sl.rtview.alert.notifiercommandchanged - Set this to the command to execute when
a column in the alert table changes. To execute a script, copy the
notifiercommandnew line and replace $alertActionScript with the name of the
script you want to execute. To execute a custom java command, see the example in
common\conf\custom_handlers.properties. This must be used in conjunction with the
sl.rtview.alert.notifiercolumns property
sl.rtview.notifiercolumns - Set this to the name of one or more columns to
execute the sl.rtview.alert.notifiercommandchanged notification when they change.
For multiple columns, use a semi-colon delimited list. Note that this should be
limited to the minimum number of necessary columns, preferably less than 5, as a
large number of columns increases the persistence load on the central alert
server.
You may alternatively execute a custom java command instead of a script for alert
notifications. An example of this is provided under
RTVAPM_HOME\emsmon\sample\custom. To use the sample custom code, you must build
it and add the custom package and jar to your application:
1. Run RTVAPM_HOME\emsmon\sample\custom\make_classes.bat. This will build the
custom handlers and output them in
RTVAPM_HOME\emsmon\sample\custom\lib\rtvapm_custom.jar.
2. Modify common\conf\custom_handlers.properties to uncomment the
sl.rtview.alert. notifiercommandnew line. Also, modify the sl.rtview.cp line to
%RTVAPM_HOME%/emsmon/sample/custom/lib/rtvapm_custom.jar. You can optionally
uncomment the sl.rtview.alert.notifiercommandsevincrease,
sl.rtview.alert.notifiercommandcleared, sl.rtview.alert.notifiercommandchanged
and sl.rtview.alert.notifiercolumns lines if you want those additional
notifications to execute your custom java command notification.
3. When you run the data server, add the following to the command line:
-properties:%RTVAPM_HOME%/common/conf/custom_handlers
Upgrade Information
The following properties from rtvapm\common\conf\rtvapm.properties have been
removed or replaced. If you have modified any of these properties in
rtvapm\common\conf\rtvapm.properties or overridden them in your properties file,
you will need to make the following modifications.
sl.rtview.alert.alertcommand - use sl.rtview.notifiercommandnew instead. Also set
the same value on the sl.rtview.notifiercommandfirstsevchange property if you
want to receive a notification the first time the severity changes on an alert.
If you do not want to receive notifications the first time the severity changes
on an alert, set sl.rtview.notifiercommandfirstsevchange to a blank value.
sl.rtview.alert.renotificationmode - This property is no longer supported.
sl.rtview.alert.renotifyonsevchangedmode - This property is no longer supported.
This property previously defaulted to 1. If you set it to 0, set the
sl.rtview.notifiercommandfirstsevchange to a blank value. If you set it to 1, set
the sl.rtview.alert.notifiercommandchanged to the same value as
sl.rtview.notifiercommandnew and set the sl.rtview.alert.notifiercolumns property
to Severity. With this configuration, you will get a notification each time the
Severity changes. If you only want to act on increases, add logic to support this
to your script or custom command code.
sl.rtview.alert.renotficationcommand - This property is no longer supported.
sl.rtview.alert.commentcommand - This property is no longer supported. To receive
notifications when the comment changes, set the
sl.rtview.alert.notifiercommandchanged to the value you previously used for the
commentcommand property. Set the sl.rtview.alert.notifiercolumns property to
Comments.
sl.rtview.alert.alertclearedcommand - This property is no longer supported. Use
the sl.rtview.alert.notifiercommandcleared property instead.
18527: New alerts for low producers/consumers of topics
Two new alerts for EMSMON have been added: EmsTopicsConsumerCountLow and
EmsTopicsProducerCountLow. These alerts are triggered when consumerCount and
subscriberCount metrics from topics reached a defined minimum threshold.
18528: New alerts for message idle time
Two new alerts EmsQueueProviderIdleTimeHigh and EmsTopicProviderIdleTimeHigh have
been added to alert on the provider idle time for queues/topics.
These alerts will be triggered when there is no change in the number of incoming
messages for each queue and topic for a specified period of time (in seconds).
18533: create alert for INACTIVE EMS Servers in EMSMON
A new alert, EmsServerNotStarted, has been added to EMSMON to inform about
servers not being properly started.
Data Model
18721: Fixed calculation of deltas for queues/topics
A bug that caused incorrect calculation of deltas of inboundTotalBytes,
inboundTotalMessages, outboundTotalBytes, and outboundTotalMessages for queues
and topics has been fixed.
General
18529: New display dedicated to bridges
The EMS display Connections has been divided into two displays, with Connections
on the first and Bridges, Ports, and Users on the second.
18531: Small column size defined for name in EMS_DURABLES table
Dbconfig schemae have been updated to increase the size of the string type to 255
characters. Since the change has been an increase in the size of strings, there
is no possible loss of data. To upgrade and keep previous history data available,
you should perform the following steps:
1. Rename tables to tableName_prev. E.g. EMS_DURABLES to EMS_DURABLES_prev
2. Load the new schemae
3. Copy all rows from tableName_prev to tableName. E.g. Copy all rows from
EMS_DURABLES_prev to EMS_DURABLES
18614: EMS_COMPDESTTOTALS cache disabled
The EmsCompdestTotals cache has been disabled by default. This cache is not
normally used in any displays.
The definition for the history table, EMS_COMPDESTTOTALS, has been
correspondingly removed from rtvapm\emsmon\dbconfig\*.sql
Users with existing databases can remove this table from their installations at
their convenience.
Monitor
18814: Password column removed from server table
The Password column in the Server Table section of EMS Single Server Tables
display has been removed.
Version 6.2.0 Release Notes
17891: Support for Queue and Topic browsing
The EMS Monitor has been enhanced to support queue and topic browsing. To browse
the contents of a queue, navigate to EMS Destinations->Single Queue Summary
(ems_queue_summary.rtv), select the queue you would like to browse and click the
Browse button. By default, the queue browser is limited to showing 100 messages.
To increase this limit, override the following properties in rtview.properties:
collector.sl.rtview.jms.maxQueueMsgCount=100
To browse the contents of a topic, navigate to EMS Destinations->Single Topic
Summary (ems_topic_summary.rtv), select the topic you would like to browse and
click the Browse button.
Users running EMS Monitor as a solution package in EM who are upgrading from a
previous release will need to uncomment this line in rtview.properties:
# Include the EMSMON solution package
rtvapm_package=emsmon
Alerts
18128: Add alert descriptions to alerts
Alert descriptions were added to EMS alerts.
18179: Support global alert notification definitions
Alert notification is now user-configurable via properties. The defaults are:
- The alert command is my_alert_script.bat.
- The alert command executes for new alerts and on the first severity change.
To configure notification, you no longer need to modify the .rtv files, just set
properties and customize the alert handler script to your needs.
- (Windows) To use my_alert_actions.bat, copy it from common\bin to your project
directory and modify the end of the script to do the appropriate action.
- (Linux) To use my_alert_actions.sh, copy it from common\bin to your project
directory and modify the end of the script to do the appropriate action. Add your
project directory to the start of your path environment variable, or add "./" to
your $alertActionScript in conf/rtvapm_oramon.properties as follows.
sl.rtview.cmd_line=-sub:$alertActionScript:./my_alert_actions
Also, add this to your properties file:
sl.rtview.cmd_line=-sub:$scriptEnding:sh
- To use a different script, add it your project directory and add the following
to your properties file:
sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where
"my_custom_script" is the name of your script. If it does not use the .bat
extension, also add the following to your properties file:
sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your
script.
- To use a different command, add the following property to your properties file:
sl.rtview.alertCommand=XX where XX is the command to execute. This can be any
RTView command string. See the documentation for the alertCommand property on any
of the alerts for more information on this.
There are also several properties that the user can now set that were not
previously documented. You can get more info on these from the alert
documentation on the Global Notifications app option tab. At the time this rn was
written, the global notifications hadn't been added to the docs yet, but the
concepts can be found in Alerts->Alert Types->Limits in the descriptions for
these properties: reNotificationMode, reNotificationTime,
reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand,
commentAddedCommand.
sl.rtview.alert.renotificationmode
sl.rtview.alert.renotificationtime
sl.rtview.alert.renotifyonsevchangedmode
sl.rtview.alert.renotficationcommand
sl.rtview.alert.commentcommand
sl.rtview.alert.alertclearedcommand
18252: Custom handler and custom alert command added to sample project
EMS Monitor has been enhanced with an optional custom package that lets you
define custom functions and commands. The custom package code is in
%RTVAPM_HOME%\emsmon\projects\sample\custom\src\com\sl\rtvapm\custom. To build
the custom package classes, run
%RTVAPM_HOME%\emsmon\projects\sample\custom\src\make_classes.bat. This will build
the classes and output them in
%RTVAPM_HOME%\emsmon\projects\sample\custom\lib\rtvapm_custom.jar.
You may modify the custom function handler, RtvApmFunctionHandler.java, to
implement custom functions for use in custom displays. The custom function
handler api is described in the RTView Classic documentation under
Customization->Custom Functions and Customization->Customization API.
You may modify the custom command handler, RtvApmCommandHandler.java, to
implement custom commands for use in custom displays or as alert notification
commands. The custom command handler api is described in the RTView Classic
documentation under Customization->Custom Commands and
Customization->Customization API.
To enable these classes, include
%RTVAPM_HOME%\common\conf\custom_handlers.properties in your command line:
-properties:%RTVAPM_HOME%/common/conf/custom_handlers
The RtvApmCommandHandler class contains a sample alert notification command named
my_alert_command. You can use this example as a starting place to implement your
own custom alert notification command. To use the my_alert_command custom command
for alert notifications, uncomment the sl.rtview.alert.alertcommand line in
%RTVAPM_HOME%\common\conf\custom_handlers.properties.
18330: Alerts fired for standby servers
FT standby servers on EMSMON don't trigger alerts now.
18369: EmsServerStaleData alert fixed
The EmsServerStaleData alert now works as intended; it fires for active servers
but does not trigger for fault-tolerant servers
Configuration
18129: Create scripts to manage multiple configurations of servers
RTView has been enhanced with the addition of commands to start, stop, and get
the status of multiple processes (servers and clients) that are managed together.
For any type of deployment there is a set of RTView processes to manage; we will
refer to this set of processes as a ?configuration?. Configurations are specified
in a simple text file in your project settings directory named rtvservers.dat.
(See note about project settings directories below.)
Here is an example file:
default . dataserver rundata
default . historian runhist -ds
default . displayserver rundisp -ds
default . database rundb
Each line has four fields:
? The configuration name (?default? in this case). This may be any name you
choose.
? The location of the project settings directory, relative to the location of the
rtvservers.dat file (?.?, or current directory, in this case)
? The property filter which identifies the server (specifically, the property
filter under which the server?s JMX port is defined). By default this is the
server name: dataserver, displayserver, historian, etc.
? The command line used to start the process. Typically you will use one of the
following commands:
Command Process started
rundata Data Server
runhist Historian
rundisp Display Server
rundb Database (HSQLDB)
runv Viewer
The command line may include additional arguments such as -properties and
?propfilter.
*NOTE: the commands listed above may also be used directly in a command prompt or
shell window. On Windows you may type the commands as shown; on Unix systems you
must add .sh to each command, e.g. rundata.sh, runv.sh, etc.
*NOTE: you may write the paths using forward-slash notation on both Windows and
Unix systems. For example if your project settings directory were located in a
sub-directory below the location of your rtvservers.dat file, you would write the
path as ./subdirectory on both Windows and Unix.
The above example is for a web application deployment. In the case of a desktop
deployment you would not start the Display Server, and you would start the Viewer
desktop application; in this case the rtvservers.dat file could look like this:
default . dataserver rundata
default . historian runhist -ds
default . viewer runv -ds
default . database rundb
Here are the three commands that, together with the rtvservers.dat file, enable
you to manage your configurations:
Command Description
start_rtv Starts servers and clients using the run command line
stop_rtv Stops servers and clients using their defined JMX ports
status_rtv Displays status of servers and clients using their defined JMX ports
*NOTE: On Windows you may type the commands as shown; on Unix systems you must
add .sh to each command, e.g. start_rtv.sh, stop_rtv.sh, etc.
Each command used without arguments will give a usage message and list the
available configurations:
> start_rtv
Usage: start_rtv config [server] or 'all'
Available configs:
default
As indicated, each command may take:
? the name of a configuration, in which case the action will apply to all the
servers or clients specified in the configuration
? the keyword all, in which case the action will apply to all configurations in
the file
? the name of a configuration followed by the name of a server, in which case the
action will apply only to that server (or client) as specified in the
configuration
In addition the start_rtv command may take:
? an optional argument ?console (or ?c). Normally the processes are started
without a command window (on Windows) or standard output to the console (Unix);
this argument changes this behavior and is useful for testing.
? Other optional arguments to be included in the run command line.
*NOTE: On Windows the HSQLDB server (if used) will always run with a command
window and cannot be stopped via the stop_rtv command. You may stop it by typing
ctrl-C in its command window.
Here are some examples using the default configuration.
*NOTE: since there is only one configuration in the default file, the following
commands could specify all as well as default for the configuration.
> start_rtv default
Start default:
dataserver: Executing rundata -bg
displayserver: Executing rundisp -ds -bg
historian: Executing runhist -ds -bg
database: Executing start/min rundb
> status_rtv default
Status default:
dataserver: Running PID 4696 Uptime 000:00:01:47 CPU 00:00:02 Heap 0.7% Clients 2
displayserver: Running PID 6340 Uptime 000:00:01:45 CPU 00:00:01 Heap 1.0%
Displays 0
historian: Running PID 6108 Uptime 000:00:01:42 CPU 00:00:01 Heap 1.3% Connected
true
database: Running PID 6848 Uptime 000:00:01:39 CPU 00:00:00 Heap 0.4%
Note the Data Server reports two clients: those are the Display Server and
Historian, both of which were started with the ?ds argument, telling them to
connect to the Data Server. Note also the Historian reports it is connected to
the database
> stop_rtv default dataserver
Stop default:
dataserver: Stopped PID 4696 via JMX port 3368
> status_rtv default
Status default:
dataserver: Running PID 6256 Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1
displayserver: Running PID 2216 Uptime 000:00:02:48 CPU 00:00:00 Heap 1.1%
Displays 0
historian: Stopped
database: Running PID 6848 Uptime 000:00:10:57 CPU 00:00:00 Heap 0.6%
Note that with the Historian stopped, the Data Server has only one client.
> start_rtv default
Start default:
historian: Executing runhist -ds -bg
Note the start_rtv command only tries to start processes it determines to be
stopped.
The status_rtv command will report if a configured port is in use but the process
using it does not appear to belong to RTView:
dataserver: Data port xxx in use by PID yyy
displayserver: JMX port xxx in use by PID yyy
If no JMX port is configured the stop_rtv command will just report :
dataserver: No JMX port configured; must kill PID xxx by system command.
If the port is in use but the PID is not available (HP-UX, some Linux systems)
then the stop_rtv and status_rtv command will report the PID as ?????, for
example:
dataserver: Running PID ??? Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1
dataserver: Stopped PID ??? via JMX port 3368
Finally, please note the following. If multiple configurations are specified in
the rtvservers.dat file with different locations for the project settings
directory, the all argument will cause them all to be processed. However if they
are specified with the same startup directory they are considered alternative
configurations and only the first one will be processed.
For example you might have two installed RTView monitors and want to start them
both:
emsmon ./emsmon dataserver rundata
emsmon ./emsmon historian runhist -ds
emsmon ./emsmon displayserver rundisp -ds
emsmon2 ./emsmon2 dataserver rundata
emsmon2 ./emsmon2 historian runhist -ds
emsmon2 ./emsmon2 displayserver rundisp ?ds
In this case the all argument would cause both configurations to be processed.
On the other hand you might want to have alternative configurations for one
RTView monitor, such as desktop deployment and browser deployment:
desktop ./emsmon dataserver rundata
desktop ./emsmon historian runhist -ds
desktop ./emsmon viewer runv -ds
browser ./emsmon dataserver rundata
browser ./emsmon historian runhist -ds
browser ./emsmon displayserver rundisp -ds
In this case the all argument would cause only the first configuration to be
processed. The second configuration could be processed by referring to it
explicitly, e.g. start_rtv browser.
Deployment
18472: Solaris Sparc support
The EM scripts use to start, stop, and run processes, would fail on Solaris 11
systems. This has been corrected.
On Solaris 10 systems the scripts are not compatible with "sh" (which is a strict
Bourne shell). As a workaround you can edit the scripts to specify a different
shell. The shell "bash" is recommended, but if it is not available "ksh" may be
used instead.
Edit the following files in $RTVAPM_HOME/common/bin and change the first line
from "#!/bin/sh" to "#!/bin/bash":
rtvapm_common.sh
rtvapm_ports.sh
start_rtv.sh
status_rtv.sh
stop_rtv.sh
unix_run_apm_builder.sh
unix_run_apm_database.sh
unix_run_apm_dataserver.sh
unix_run_apm_displayserver.sh
unix_run_apm_historian.sh
unix_run_apm_viewer.sh
Monitor
18096: Trend charts in EMSMON now configured for history
Trend graphs for the following dashboards have been improved to display
historical data:
1. ems_allroutes_forserver.rtv
2. ems_alldurables_forserver.rtv (needed:
3. ems_server_trends
4. ems_alltopics_forserver
5. ems_topic_summary
6. ems_server_summary
7. ems_queue_summary
8. ems_allconsumers_forserver
9. ems_allqueues_forserver
10. ems_server_trends
11. ems_allproducers_forserver
Servers
18303: Added alert for connection count on a server
A new server alert EmsServerConnectionCountHigh has been added to EMS Monitor.
This alert will be triggered when the number of connections to the server reaches
the specified thresholds.
18519: Alert levels incorrect on EMS Server Table
A bug in the All Servers Table has been fixed that prevented the Alert Level
lights from being updated with alert behavior.
Version 6.1.0 Release Notes
Deployment
17662: Support deployment of Windows services on 64 bit platforms
EMS Monitor can be installed as Windows Services on 32 and 64 bit platforms.
General
17958: All tabular views now have max rows
The display of tables in EMS Monitor has been improved as follows: the
display-side limit on the number of rows in a table has been increased to 100,000
so (in almost all cases) all rows of data will always be available.
17978: About display added
A new About display has been included under the RTView Servers subcategory. This
display contains information about version, build date, and data sources.
Monitor
17704: New alerts for low producers/consumers of queues
The following alert definitions have been added to EMS Monitor:
EmsQueuesConsumerCountLow
EmsQueuesProducerCountLow
These alerts by default have a warning threshold of 15 and an alarm threshold of
5.
17984: Changed topic and queue detail trend colors for consistency
The line colors of the trends in the Single Topic Summary and Single Queue
Summary trends have been changed to be consistent with related displays (e.g. All
Topics for Server).
Navigation
17360: Historical Time Range Navigation provided for all trend charts
All displays containing trend charts in the EMSMON package have been enhanced to
include button that will invoke a Time Range Navigation Dialog, permitting the
selection of a historical time range for data shown in the trend chart.
Selecting the "..." button to the right of the Time Range dropdown selector will
invoke the dialog.
Once invoked, select the desired end time for the trend using the Calendar
control, or enter it in the text field provided. Once entered, hit the Apply
button to activate this time range.
Hit the "Return to Now" button to restore the trend chart to the current time.
Limitation: On the All Durables For Server display, the Total Pending Msgs (top)
trace in the trend graph is not configured for historical data. Whenever you
bring up the display it will begin redrawing from the origin.
Platform Support
17602: Support iPad deployment
EMS is now supported on iPad safari browsers.
Servers
17501: Clicking on pending count in heatmap view should list servers
The All Servers Heatmap and All Servers Grid displays have been enhanced such
that clicking on the Pending value field will drill down to the All Servers Table
display
|
