Version 4.2.0 Release Notes
Configuration
22451: Solution Package for TIBCO ActiveMatrix added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for TIBCO ActiveMatrix.
22826: Solution Package for Amazon Web Services added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for Amazon Web Services.
22828: Solution Package for IBM DB2 added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for IBM DB2.
22829: Solution Package for Docker added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for Docker.
22830: Solution Package for RTView Host Agent added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for RTView Host Agent.
22832: Solution Package for MongoDB added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for MongoDB.
22834: Solution Package for Node.js added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for Node.js
.
22835: Solution Package for Oracle Database added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for Oracle Database.
22838: Solution Package for Oracle Web Logic added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for Oracle Web Logic.
22839: Solution Package for IBM WebSphere added to Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for IBM WebSphere.
23135: Fixed bug with removing vpn from Solace connection
In the previous release, it was not possible to remove all Solace vpn's from the
connections dialog. This has been fixed.
23140: New Connection icon no longer disappears from Configuration Application after toggling tabs on SYSLOG connections.
The Solace Add Syslog Connection ('+') button now always appears as expected.
23187: IE 11 Compatibility mode is now recognized as not supported
IE 11 Compatibility mode is now flagged as being unsupported for the
Configuration Application.
JBoss
22976: Wildfly documented in sample.properties and added to Configuration Application
The connection properties for WildFly have been added to the sample.properties
and included in the Configuration Application.
Data Server
23210: Improved error reporting for start_rtv.bat/sh scripts
The start_rtv scripts have been enhanced to report possible port conflicts before
trying to start a server, and to report if a server is not actually started due
to some other cause (e.g. expired license key).
if a server's data and/or JMX port is already in use by another process,
start_rtv will report e.g.:
dataserver: JMX port xxx in use by PID yyy
dataserver: Data port xxx in use by PID yyy
If the server fails to start for some other reason, start_rtv will report e.g.:
dataserver: Executing rundata -propfilter:receiver
dataserver: ... was not started, check log file.
Distribution
23077: RTView DataServer for Kafka port prefix and server name default updated
The following changes have been made to the default project in the RTView
DataServer for Kafka deliverable:
- Default port prefix is now 32
- Short-form server name has been changed from KAFKAMON to DataServerKafka
- Long-form server name has been changed from Apache Kafka Monitor to RTView
DataServer for Kafka
- project directory name has been changed from projects\sample-server to
projects\rtview-server
23198: Sample project directory renamed to rtview-server
Two naming changes have been made to the RTViewDataServer family of deliverables:
The sample-server project for the RTViewDataServer* deliverables and the
sample-collector project of the RTViewDataCollector deliverable have been renamed
to "rtview-server".
The RTViewDataCollector_x.zip deliverable has been renamed to
RTViewDataServerSP_x.zip, to reflect that it contains all solution packages.
23223: RTView DataServer for TIBCO - new deliverable
A new RTView(R) DataServer variant has been added to the RTView monitoring
lineup. It is intended for use by those who wish to monitor TIBCO's middleware
products.
Files:
RTViewDataServerTIBCO_x.zip
RTViewDataCollectorTIBCO_x.zip
RTView(R) DataServer for TIBCO includes Solution Packages for:
- TIBCO BusinessWorks 5
- TIBCO BusinessWorks 6
- TIBCO Enterprise Message Service
- TIBCO Adapters
- TIBCO ActiveSpaces (2.x)
- TIBCO Hawk
- TIBCO FTL
- TIBCO ActiveMatrix
- RTView Management
23228: RTView DataServer for Solace - new deliverable
A new RTView(R) DataServer variant has been added to the RTView monitoring
lineup. It is intended for use by those who wish to monitor Solace appliances.
Files:
RTViewDataServerSolace_x.zip
RTViewDataCollectorSolace_x.zip
RTView(R) DataServer for Solace includes Solution Packages for:
- Solace
- Syslog
General
22859: Spurious file no longer appears in cache subdirectory
Previously, under certain circumstances a spurious file was generated in the
cache subdirectory when using the datacache mechanism. This is no longer the
case.
23064: Configuration Application now displaying proper warning after failing to write property.
An alert dialog has been added to display any warning msgs that follow a
successful save.
23168: Extend With SQL previously not working for trends in some displays
RTView trend displays will automatically retrieve data from a database if
available and if required by the time range requested in the display.
This feature was not working correctly for a number of displays. This has been
corrected.
RTView Core Functionality
Data Historian
22195: RTView Historian now uses PreparedStatements
The Historian now uses PreparedStatements for repeated SQL Queries against the
historian database
- For raw data insert
- For data compaction
- For retention deletion
Previously the historian used literal SQL queries with unique timestamps.
Data Server
23211: Message now shown in dataserver console when Java is not available.
The scripts which start servers have been improved to give a clear indication if
the java command is not available.
If java(.exe) is not found on the PATH but JAVA_HOME is defined, the scripts will
add JAVA_HOME/bin to the PATH and try again.
If JAVA_HOME is not defined or java(.exe) cannot be found in JAVA_HOME, the
scripts will fail with the error "java not found on PATH and JAVA_HOME not
defined or not valid." On Windows this will be followed by a pause and "Press any
key to continue".
Scripts
23032: New validate_install.bat/sh script
A new script has been added to the RTView distributions to validate the RTView
installation. It will verify the environment and directory structure and on Unix
it will also fix file permissions and file formats as required.
The script is validate_install.bat/sh. It is used in a command prompt or terminal
window by changing to the toplevel/rtvapm directory and typing
"validate_install(.sh)".
On Unix, if file permissions or formats are fixed, the script will print a count
of the files fixed. Additionally, if invoked with the argument "-v" (verbose) it
will list the names of the files fixed.
Examples:
Validating installation in /opt/rtview/RTViewSolaceMonitor
... Java installation correct.
... rtvapm installation correct.
... file permissions correct.
... file formats correct.
Validating installation in C:\rtview\RTViewDataServerKafka
... Java installation correct.
... rtvapm installation correct.
23219: hsqldb updated to 1.8.1
The version of hsqldb included has been updated to 1.8.1.
Previously when the hsqldb database was shut down with stop_rtv.bat/sh, its
console window would show multiple messages of the form
Exception in thread "HSQLDB Connection @5757c327" java.lang.NullPointerException
This has been corrected.
Note that on Windows, when shutting down the database you may see messages of the
form "database alias=alertdefs does not exist" in the hsqldb console window.
These messages may be ignored.
Solution Package
Apache Kafka
23184: Custom Kafka DS incorrectly parses some command output
The Solution Package for Kafka makes use of the output from the
kafka-consumer-groups.sh command. In the case where a consumer is not assigned
any partitions it will appear in the command output with dashes for the
partition-related fields, e.g.
TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
- - - - consumer5-67bd6d45-0f4c-450e-a969-c16e565808b4 /192.168.200.226 consumer5
Lines of this form were not correctly handled by the dataserver, resulting in
error messages like:
[rtview] getLagTable: java.lang.NumberFormatException: For input string: "-"
This has been corrected.
IBM DB2 Database
21571: Minor typo on display for IBM DB2 Database display
A typo in the IBM DB2 Database displays has been fixed.
IBM Websphere Application Server
22991: WSM data server no longer crashes if classpath not set
In previous releases, the Solution Package for IBM WebSphere crashed if the
classpath did not contain the WebSphere jars. This has been fixed.
23182: Cache configuration parameters now available in Config UI
All caches from the RTView IBM WebSphere Monitor have been enhanced to support
parametrizion of condensing and cache size attributes.
This enhancement will be taken into account for the RTView Configuration Admin
Tool to allow customers to make changes in these cache attributes.
TIBCO BusinessWorks
22503: SQL statements for BW tables optimized
The schemas for the BW historian tables listed below (found under
rtvapm/bwmon/dbconfig) have been optimized to reflect common customer scenarios:
BW_ENGINES
BW_PROCESSES
BW_PROCESS_TOTALS
BW_ACTIVITIES
BW_ACTIVITY_TOTALS
1. "MicroAgentName" VARCHAR(100) increased to "MicroAgentName" VARCHAR(160) since
the engine name often exceeds 100 chars. NOTE: This change does not apply to
Sybase, due to Sybase not supporting >100 characters for an index column.
2. "MicroAgentInstance" VARCHAR(255) decreased to "MicroAgentInstance"
VARCHAR(10) because this column refers to the instance # which rarely exceeds
1000. This will save some space in the database.
Users with existing tables do not need to update their tables.
23167: BwProcessCreatedRateLow now alerts corrected
The BwProcessCreatedRateLow alert was incorrectly configured so that it acted
like a "High" rather than a "Low" alert. In other words, the alert would trigger
if the Created Rate value was greater than the threshold rather than less than.
This has been corrected.
Version 4.1.0 Release Notes
Configuration
22559: Run all sample projects as receivers
The solution package data servers for all sample projects are now run as
receivers. This means that all data servers open an RtvAgent port to listen for
collector/sender data.
22574: Added sender target to all sample projects
Enterprise RTView has been enhanced to include sender targets in the
configuration for all sample solution package projects. The sender target is only
used when the solution package data server is run as a sender.
22583: Solution Package for Apache Kafka added to configuration application
The RTView Configuration Application has been enhanced to include the Solution
Package for Apache Kafka.
22606: Improved user notification
When one or more solution packages are added to a data server connection, and the
project type is a configclient, a message will be displayed instructing the user
to update the data server connections list with the new solution package(s).
22747: Solution Package for Solace added to the Configuration Application
The RTView Configuration Application has been enhanced to include the Solution
Package for Solace Message Router.
22831: Solution Package for Redhat JBoss added to configuration application
The RTView Configuration Application has been enhanced to include the Solution
Package for Redhat JBoss.
22833: Solution Package for IBM MQ added to configuration application
The RTView Configuration Application has been enhanced to include the Solution
Package for IBM Websphere MQ.
22847: Enable Checkbox should be enabled for default diagram generator and metric explorer DB
The enabled checkbox should always appear ungrayed for Diagram Generator and
Metric Explorer DB connections
22891: Configuration Application now uses basic authentication instead of digest
In the previous release, the Configuration Application used Digest authentication
which cause occasional problems with the login dialog coming up repeatedly when
single sign on was not enabled in the app server. It has been modified to use
BASIC authentication instead which does not require single sign on.
Basic authentication sends the username and password as a base64-encoded string.
This a public encoding scheme and is therefore not secure unless https is used.
If you are concerned about keeping the login credentials of the Configuration
Application secure, you should deploy it using https which will secure all data
including the login credentials.
22892: New Restart Data Server option added to configuration application
The RTView Configuration Application has been enhanced with a button to restart a
Solution Package data server. This button is available whenever there are
unapplied changes. To restart a solution package data server:
1. Make some configuration changes and click SAVE to save them.
2. A Restart button will appear in the top right corner of the page. When you
click the Restart button, you will be taken back to the top level page. The data
server for the solution package project will exit, then start back up with the
changes applied. The button is also available on the top level page if you want
to restart your data server later.
There is a delay of 10 seconds between the shutdown of the server and the restart
in order to allow system resources to be released by the exising process. It may
take several more seconds before Configuration Application and other clients
reconnect to the data server.
Note that this process only restarts the data server. Settings for the display
server or historian processes will not be applied until those processes are
restarted using the scripts. They cannot be restarted from the Configuration
Application.
Deployment
22056: Added https support to the servlet container
The html server feature of RTView Enterprise Monitor has been enhanced to support
https. This is configured in the Configuration Application Data Server page in
the HTML Server section. There are 4 fields for configuring https:
- Use Https - Set to true to use https
- Keystore File - Set to the key store file name (including path) that contains
the certificate for your domain. This is required to use https.
- Keystore Password - Set to the password for the keystore. This field is
optional.
- Key Manager Password - Set to the password for the key manager. This field is
optional.
22173: New cache viewer added to servlet container
RTView Enteprise Monitor html server feature has been enhanced to include a cache
viewer. This is useful for verifying cache contents without the need for setting
up the thin client. For any data server that has the html server enabled,
navigate to the following url to bring up the cache viewer:
http://localhost:3270/common
Replacing the 32 with the port prefix used by your data server. Select a cache
from the top table to show the cache contents in the lower table.
Distribution
22850: RTViewDataServer available on Red Hat OpenShift Container Platform
The RTView DataServer deliverable has been made available on Red Hat's OpenShift
Container Platform, starting with version 4.0.0.
The URL for the image is:
registry.connect.redhat.com/slcorp/rtview-dataserver
More information is available on RedHat's site at:
https://access.redhat.com/containers/?tab=overview#/registry.connect.redhat.com/slcorp/rtview-dataserver
RTView Core Functionality
Data Sources
22840: Automatically detect when JSON configured standby EMS Servers become active
The EMS Admin data adapter had an issue with fault-tolerant server pairs
configured via JSON, such that the data adapter would not detect when the
inactive server became active. This has been corrected.
Distribution
22853: rtvpost servlet added to Jetty
RTView Enteprise Monitor html server feature has been enhanced to include the
%RTV_HOME%\servlets\rtvpost\rtvpost.war servlet in Jetty.
Scripts
22888: Start script no longer fails on Solaris
On Solaris 10/11 using RTViewEnterpriseMonitor, starting the central database
might give the error "expr: string too long". This has been corrected.
Solution Package
Apache Kafka
22731: Add summary data to kafka caches.
The column "ZK Disconnect Rate" has been added to the All Brokers table. This is
the mean rate of Zookeeper disconnects per broker, in seconds.
Two caches have been added:
KafkaServerZookeeper contains per-broker counts of zookeeper disconnects and
expirations
KafkaCluster contains server and client counts and specific metrics summarized at
the cluster level.
22808: Added missing database definitions
Two tables have been added to the SQL schemas under kafkamon\dbconfig. These
caches were added in the previous release as task 22094:
KAFKA_TOPIC_PARTITION
KAFKA_TOPIC_TOTALS_SERVER
22852: Simplified connection properties
The instructions for kafkamon connections included the following section, which
is now obsolete and should be disregarded:
## The aggregator dataserver (if it is not also a collector) will not include any
of the above
## Kafka configuration, but it must include a topic property (without a
bootstrap-server) for
## the cluster, e.g.
##
## receiver.sl.rtview.cache.config=kafka_topic_partition_cache_source.rtv
$kafkaClusterName:prodCluster
Solace
22721: Support Solace Cloud Edition
Support for Solace Cloud Edition has been added. Connections can be defined using
the RTView Configuration Application.
22787: Wrong metric name in renaming function will generate a wrong zero value
A typo on the name of the spool message size in MB metric for topic endpoints was
preventing the correct value to be collected. This typo has been fixed and now
the spool message size in MB for topic endpoints is collected properly.
Also, several typos on client bridge received bytes metrics have been removed
which prevented the correct values to be stored in the SolBridges cache. Now the
client received total, data, persistent, non persistent, and direct bytes are
stored properly into the cache.
22789: Collect SEMP version automatically to avoid configuration problems
As of Solace VMR version 8.7+ and Solace Appliance version 8.3+, it is no longer
required to include a SEMP version string in connection properties. See
https://docs.solace.com/SEMP/Using-Legacy-SEMP.htm.
For earlier versions of Solace VMR and Solace Appliance, the SEMP version string
should be entered in connection properties. Not using the proper SEMP version
string would impair the collection of monitoring metrics. See RTView Solace
Solution Package documentation for a description to determine the SEMP version
string in your Solace Message Router and to enter this value in your connection
properties.
TIBCO ActiveMatrix
22707: New AmxNodeNotRunning alert
The following alert has been added to amxmon: AmxNodeNotRunning.
It triggers if the runtime state of the node is not RUNNING.
TIBCO BusinessWorks
22695: BWAgentPlugin can now get max heap size from java.extended.properties if found
The Hawk microagent BWAgentPlugin reads the BW engine deployment files to
determine the Java max heap allocation. Usually this is given by the property
"java.heap.max" in the engine's .tra file, but it can also be given by the
property "java.extended.properties." The microagent has been enhanced to look for
the second property if the first is not found.
22884: bw6mon application table appnode counts and timestamps corrected
In a situation where there a number of applications with no process execution in
any appnode, bw6mon would report incorrectly the number of appnodes per
application, and would report the timestamp as zero (blank). These issues have
been corrected.
22885: Alert LED indicators now navigate to a page with detailed alert information
The summary pages have been enhanced with new alert displays. The Application,
AppNode, and Container summary pages have alert indicators whose color indicates
whether there are current alerts for the displayed item, in the categories
relevant to it.
Clicking an indicator will now bring up a table listing the alerts in each
category. To close this table and restore the previous display, click the Close
button.
Clicking a row of the alert table will bring up a detail window for the selected
alert.
22886: bw6mon appnode summary page heatmap tooltip correction
The bw appnode summary page has a heatmap of the processes of the appnode. The
heatmap cell's tooltip showed an incorrect set of columns. This has been fixed.
22889: bw6mon now correctly displays appnodes if containers are displayed first
In the BW monitor displays, if a container display was selected followed by an
appnode display, the appnode display would not show data correctly. This has been
fixed.
22898: BW6 Application Heatmap and AppNode Heatmap bug fixes
In the case of no processes execution in the lifetime of an application, the
application heatmap would not display the application correctly. This has been
corrected.
The appnode heatmap was not correctly connected to memory usage as indicated.
This has been corrected.
Version 4.0.0 Release Notes
22415: New RTViewDataCollector deliverable
A new deliverable called RTViewDataCollector has been added to the RTView lineup.
It is a reduced-size subset of functionality contained in the larger RTView
Enterprise Monitor deliverables - meant to be a convenient way to configure
remote sender DataServers. It supports all current Solution Packages.
It contains a single sample project that can be configured and duplicated as
needed, and configured using the new browser-based Config UI.
By default the RTViewDataServerSP is configured to be used as a sender,
forwarding data to a receiver DataServer.
Instructions for installation and use of the RTViewDataCollector are included in
a README file in the RTViewDataCollector deliverable.
22416: New RTViewDataServerSP deliverable
A new deliverable called RTViewDataServerSP has been added to the RTView lineup.
It is a reduced-size subset of the functionality contained in the larger RTView
Enterprise Monitor deliverables - meant to be a convenient way to configure
remote DataServers when the central EM installation location is not the optimal
location for Solution Package data collection. It supports all current Solution
Packages.
It can also be used to collect real-time data to be used by RTView Cloud
displays.
It contains a single sample project that can be configured and duplicated as
needed, and configured using the new browser-based Config UI.
By default the RTViewDataServerSP is configured to be used as a receiver,
listening for additional data being forwarded by sender DataServers. Users who
wish to configure sender DataServer's can refer to the new RTViewDataCollector
deliverable.
Instructions for installation and use of the RTViewDataServerSP are included in a
README file in the RTViewDataServerSP deliverable.
22417: New RTViewDataServer deliverable
A new deliverable called RTViewDataServer has been added to the RTView lineup. It
is intended primarily for sending real-time data to RTView Cloud displays.
Users who wish to leverage existing RTVIew Enterprise Monitor Solution Packages
should use the RTViewDataServerSP deliverable.
Instructions for installation and use of the RTViewDataServer are included in a
README file in the RTViewDataServer deliverable.
Configuration
22192: Replace emcommon with project-common
The emsample\conf\emcommon.properties file has been replaced with
project-common.properties which is editable by the configuration ui.
Users upgrading from previous releases can continue to use their existing
emcommon.properties file by copying it into the emsample\conf directory. It will
still be read by all emsample servers.
22264: New Configuration application added
RTView EM and its specialized Monitors have been enhanced to support a
configuration application. See the documentation for more information.
22284: add rtvadmin to make_war and update_war scripts
The new rtvadmin war file, which runs the Config UI, has been added to the
make_war and update_war scripts
22288: Removed projects\sample and webapps subdirectories from rtvapm\sp directories
In previous releases, each solution package directory under RTVAPM_HOME had
projects, ALERTDEFS, HISTORY and webapps subdirectories. Those subdirectories
have been removed. The RTVAPM_HOME\projects\emsample\servers directory has sample
project directories for all solution packages that can be used instead.
22290: remove server level properties from sp\conf\rtvapm.sp.properties files
In previous releases, each solution package defined its own ports, sender target
and server identification properties. These properties have been removed from the
solution package properties and should be defined in the project properties
instead. The sample projects included in EM have been updated to include these
properties which have been set to the same values that they inherited from the
solution package properties in previous releases.
New projects that do not define these properties will use the following defaults:
# data server ports and process identifiers
dataserver.sl.rtview.dataserver.port=3278
dataserver.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3268
dataserver.sl.rtview.cmd_line=-proctag:RTVAPM.RtvDataServer
sl.rtview.alert.persistAlertEngineName=RTVAPM
sl.rtview.sub=$domainName:SL-RTVAPM-1
# data client
dataclient.sl.rtview.dataserver=//localhost:3278
# display server ports and process identifier
displayserver.sl.rtview.displayserver.port=3279
displayserver.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3269
displayserver.sl.rtview.cmd_line=-proctag:RTVAPM.RtvDisplayServer
# historian port and identifier
historian.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3267
historian.sl.rtview.cmd_line=-proctag:RTVAPM.RtvHistorian
# database port
database.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3261
# sender ports,target and identifier
sender.sl.rtview.dataserver.port=3276
sender.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3266
sender.sl.rtview.sub=$rtvAgentName:MyMachineName
# receiver port
receiver.sl.rtview.rtvagent.port=3272
# http port
collector.sl.rtview.rtvhttp.port=3275
Upward compatibility support is included for projects created previous to EM 4.0.
In EM 4.0, the rtview.properties files in all sample projects were replaced with
project.properties files. Any project with an rtview.properties file is
recognized as a project created with a previous release. In that case, RTView
will automatically read in the old ports, sender target and server identification
properties for all solution packages in the rtview.properties file. Therefore,
projects created with previous of EM will continue to run with no modifications.
It is recommended, but not required that existing custom solution packages make
the following changes. These changes are needed in order to be compatibe with the
new Configuration Application. Custom solution packages will continue to work as
before without these changes, but data servers containing custom solution
packages without these changes should not be configured via the Configuration
Application:
1. Move the following server level properties from conf\rtvapm.sp.properties to
conf\rtvapm.sp.compat.properties:
- all ports
- all proctag properties
- sender.sl.rtview.sub=$rtvAgentName
- sl.rtview.alert.persistAlertEngineName
- sl.rtview.sub=$domainName
2. Put the custom solution package directory under RTVAPM_HOME or
RTVAPM_USER_HOME as follows:
- if under RTVAPM_HOME, the solution package name must end in "mon" for the
Configuration Application to detect it
This will add the custom solution package to the list of available solution
packages in the Configuration Application.
3. add rtvadmin\sp.meta.json under lib with the following - the Configuration
Application will use this as the display name for your solution package:
{
"displayname": "The Display Name for your SP"
}
4. copy src\rtfiles\rtvconfig.sp.xml to lib\rtvadmin so the Configuration
Application can read its CI Types.
22298: New portprefix command line option
The RTView launcher has been enhanced with options for changing all the port
numbers used by a package. Port numbers are assigned to a package using a package
prefix and a two-digit suffix specific to the port. A complete list of suffixes
is appended. This enhancement allows you to change the port number prefix for the
server being launched. The change will apply only to that launch unless you also
specify -saveportprefix, in which case the new prefix and port numbers will be
saved to project.properties.json and project.properties.
-portprefix:X Change all relevant ports to use prefix X by appending arguments to
the command line that will be used to launch the server.
-saveportprefix Used with -portprefix, save project.properties and
project.properties.json. If the project does not contain those files, create them
and add project.properties to the end of the command line. If the project does
contain those files modify and save them.
Note if you start a server with -portprefix, you may use the status_rtv and
stop_rtv commands with it only if you repeat the -portprefix option with those
commmands.
22474: PROPDB and RTVCONFIG databases disabled
The following database connections are now disabled by default in emsample:
PROPDB
RTVCONFIG
These databases are not used in the standard emsample project. Customer with
existing emsample projects that do use those databases should continue to defined
them in their central.properties file as before.
22531: Added button to displays to access the config ui
The EM Config UI may be accessed via a "gear" icon which will appear at the right
end of the title bar. It is visible only in the thin client when the role is
admin.
22579: KAFKAMON server requires rtvmgr package
The emsample project configuration for kafkamon has been modified to include the
rtvmgr package, which is required for kafkamon operation.
TIBCO ActiveMatrix
21862: BW6 displays and caches are now enabled by default
The bwmon and bw6mon packages are now both enabled by default within emsample,
with the possibility that only one package is actually active.
The amxmon package, which uses some bw caches, is still disabled by default.
Instructions for enabling it can be found under rtvapm/amxmon/README.txt
Deployment
22125: New html server available for Data Servers
RTView Enterprise Monitor has been enhanced to embed Eclipse Jetty to support
running an html server in any data server process. This html server is configured
to host the following servlets:
- %RTV_HOME%\servlets\rtvadmin\rtvadmin.war
- %RTV_HOME%\servlets\rtvquery\rtvquery.war
- %RTV_HOME%\servlets\rtvdata\rtvdata.war
- %RTV_HOME%\servlets\rtvadmin\rtvadmin.war
The html server is disabled by default in all deliverables except the
RTViewDataServer and RTViewDataCollector deliverables. To enable it, add the
following property to the properties file for your data server:
dataserver.sl.rtvapm.sc.enabled=true
The servlets hosted in a data server are automatically configured at startup with
the correct port for connecting to the data server. The servlets can be accessed
at http://localhost:3270/servletname. To change the port, add the following
property to the properties file for your data server:
dataserver.sl.rtvapm.sc.port=3370
When running with the html server enabled in a data server, you must always shut
down the server using the stop_rtv script. This is because the html server writes
temporary files to the directory listed in the java.io.tmpdir System property.
When the data server is shutdown properly using stop_rtv, the temporary files are
deleted. If the data server is shut down using a kill command, the temporary
files are not cleared.
Eclipse Jetty is dual licensed under Apache License 2.0 and Eclipse Public
License 1.0.
22302: Improvements to HA for all directories under emsample\servers
High Availabllility has been fixed and/or incorporated to all dataservers that
are available under EM.
Distribution
22120: Jackson libraries - move into shared location
External jackson and netty libraries previously provided as part of the Kafka
monitoring solution package have been moved out of that solution package into the
common platform library directory.
22177: New RTViewEnterpriseMonitor bundle that has all solution packages
RTView Enterprise Monitor is now available as one download containing all
available solution packages.
This new deliverable, RTViewEnterpriseMonitor_VERSION.zip, contains the following
directories:
RTViewEnterpriseMonitor\
apache-tomcat-7.0.72\
bin\
emsample\
rtvapm\
make_all.sh
make_all.bat
apache-tomcat-7.0.72 - Apache Tomcat 7.0 configured for jmx remote monitoring and
pre-populated with RTView Enterprise Monitor servlets
bin - scripts for launching apache tomcat and all enabled RTView EM solution
packages
emsample - example EM project
rtvapm - the RTView Enterprise Monitor application directory
Refer to the RTVIew EM UserGuide for more information on how to configure and use
RTView EM.
22419: Bundled tomcat updated to v8.5.24
The Apache Tomcat bundled with RTView EM has been updated to version 8.5.24
General
22099: Applied properties view sometimes shows wrong property hierarchy
In previous releases, the order of Applied Properties was sometime incorrect.
This has been fixed.
22315: Removed custom sp example from deliverable
The custom solution package example has been removed from EM. Contact SL
technical support for information on creating custom solution packages.
Existing custom solution packages will continue to work as they did before. See
the release note for TN22290 for information on how to optionally upgrade your
custom solution package to be compatible with the new Configuration Application.
A simple mechanism has been added for configuring custom handlers for use in
custom displays. An example of the custom handler classes is available under the
following directories:
RTViewEnterpriseMonitor: emsample\custom
TIBCOEnterpriseMonitor: em-tibco\custom
All standalone deliverables: projects\sample\custom
Use the following properties to instance the custom handlers in your server:
# Add the jar containing the custom classes to the classpath. Adjust this path if
necessary
# to point to the location of your jar.
sl.rtview.cp=<path to custom jar>/lib/rtvapm_custom.jar
# the custom function handler
sl.rtvapm.customfunctionhandler=functionHandlerClassName
# the custom command handler
sl.rtvapm.customcommandhandler=commandHandlerClassName
# the custom rtview manager
sl.rtvapm.customrtvmanager=rtviewManager
# the custom app manager
sl.rtvapm.customappmanager=rtvAppManager
The steps for using the sample java alert notification example has changed as
follows:
1. Enable alert notifications in the Configuration Application
2. Add the following properties on the CUSTOM PROPERTIES tab:
# Add the jar containing the custom classes to the classpath. Adjust this path if
necessary
# to point to the location of your jar.
sl.rtview.cp=<path to custom jar>/lib/rtvapm_custom.jar
# instance the custom command handler:
sl.rtvapm.customcommandhandler=com.sl.rtvapm.custom.RtvApmCommandHandler
# new alert notification:
sl.rtview.alert.notifiercommandnew=system cust
'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol'
$alertNotifyTable
# cleared alert notification:
sl.rtview.alert.notifiercommandcleared=system cust
'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol'
$alertNotifyTable
# alert column changed notification. change the notifiercolumns property to
notify on other columns:
sl.rtview.alert.notifiercolumns=Acknowledged;Owner;Comments
sl.rtview.alert.notifiercommandchanged=system cust
'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol'
$alertNotifyTable
# first severity change notification
sl.rtview.alert.notifiercommandfirstsevchange=system cust
'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol'
$alertNotifyTable
# timer renotifications for all open/unacknowledged alerts
sl.rtview.alert.notifierrenottime=300
sl.rtview.alert.notifiercommandrenot=system cust
'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol'
$alertNotifyTable
RTVMGR
21741: Monitoring Tomcat 8.0 or 8.5 no longer produces cache function errors
A bug that caused errors in the dataserver.log file for data server's monitoring
Tomcat 8.x servers has been fixed. The errors had the following syntax:
ERROR: function <tomcatWebModuleStats04DeltaRate>, Table structure has changed;
cannot save data., type:DELTARATEROWS, file:tomcat_cache.rtv
ERROR: function <tomcatManagerStats77DeltaRate>, Table structure has changed;
cannot save data., type:DELTARATEROWS, file:tomcat_cache.rtv
RTView Core Functionality
22551: Mouseover text no longer mispositioned on scrolled thin client displays
A problem has been fixed in the thin client that caused the mouseover (tooltip)
text to be mispositioned for objects that needed to be scrolled into view.
Data Server
22462: Float column values no longer garbled in rtvquery response
In the previous release, values for cache columns with type = float were garbled
in query responses from the rtvquery (REST) servlet, so the response could not be
parsed. This is fixed.
Data Sources
22482: GmsRtViewHawkCustomSSLHandler now called for HAWK 5.x ems connections by the TIBCO Hawk Data Source
Previously the GmsRtViewHawkCustomSSLHandler "MyHawkSSLHandler" was not called
for TIBCO Hawk 5.x ems connections. This is no longer the case.
Use of the GmsRtViewHawkCustomSSLHandler "MyHawkSSLHandler" to set Hawk SSL
parameters is described in the "TIBCO Hawk SSL Parameters" Section of the TIBCO
Hawk Data Source documentation.
Display Server
22117: Tomcat no longer throws an error if image path contains a backslash
A bug has been fixed in the thin client which would cause Tomcat 8.5+ to throw an
IllegalArgumentException if the path to an image contained a backslash.
The full exception is as follows:
java.lang.IllegalArgumentException: Invalid character found in the request
target. The valid characters are defined in RFC 7230 and RFC 3986
Object Library
19863: Added support for HTML pie charts
BASICS:
The thin client now supports a web pie chart.
The web pie chart is a pure HTML implementation of an RTView pie chart object. In
the RTView thin client, the web pie chart provides an interactive, high
performance chart without requiring the Flash player or other browser plugin.
There is no web pie chart in the Builder palette. Instead, a new property named
webChartFlag has been added to the flex (obj_fxpie) and swing (obj_pie) pie
charts. To enable the web pie chart the user simply sets the webChartFlag
property to true (checked) on a flex or swing pie chart instance. Then, when the
display is opened in the thin client in a web compatible browser, the web pie
chart will appear in place of the flex or swing pie chart.
This feature is similar to the webChartFlag property that has been available on
the flex and swing trend graph and bar graph objects in several prior releases.
PROPERTIES:
The web pie chart supports all of the major properties available in the flex and
swing pie charts. However several minor properties are not supported or have
limited support in the web pie chart. These properties are listed at the end of
this note.
BEHAVIOR:
In addition to the properties listed below, there are some behavioral differences
between the web pie chart and the flex/swing pie chart as follows.
1) Stretching: Unlike the swing pie chart obj_pie, the web pie chart does not
stretch to an oval shape to fill the available space. Instead the web pie chart
remains round, with its diameter determined by the smaller dimension. (The flex
pie chart is always round too).
2) Slice order: In the swing and flex pie charts the bottom edge of the first
wedge/slice, corresponding to the first row in the valueTable, is drawn at 0
degrees (that is, its bottom edge is horizontal). The slices for subsequent rows
follow in counter-clockwise order. In the web pie chart, the first slice is drawn
at 90 degrees, so its left edge is vertical. The slices for subsequent rows
follow in clockwise order.
3) Tooltip: The tooltip on the web pie chart shows the label and value for a
wedge, but does not show its computed %
4) Wedge labels (on obj_fxpie only): On obj_fxpie, wedge labels are visible
unless wedgeLabelPosition = None(0), as expected. However, the label shows only
the wedge's label, not its value or %. Also the wedgeLabelPosition values of
"Inside with Callout(3)" and "Outside(4)" give the same result as "Callout(1)" on
the html5 chart. If wedgeLabelPosition = Inside(2), some wedge labels may spill
outside of their wedge, depending on the size of the label and wedge.
ENABLING / DISABLING:
The web pie chart can be enabled for all obj_fxpie (flex) instances by adding the
following rule to an rtview stylesheet (.rts) file loaded by the display server:
obj_fxpie {
webChartFlag : 1
}
Similarly, the web pie chart can be enabled for all obj_pie (Swing) instances by
the following rule:
obj_pie {
webChartFlag : 1
}
See the documentation for more information on using RTView stylesheets.
If a stylesheet is used note that the webChartFlag value can still be overridden
and set to zero (false) on individual instances.
UNSUPPORTED/IGNORED PROPERTIES:
As mentioned earlier, some chart properties are hidden in the builder if
webChartFlag is checked.
These properties of obj_fxpie are hidden if webChartFlag is checked:
bg3dFlag
bgGradientFlag
labelColumnFormat
rowLabelVisFlag
rowNameVisFlag
legendBgGradientFlag
legendWidthPercent
legendValueVisFlag
legendPercentVisFlag
entranceDuration
entranceTrigger
entranceType
exitDuration
exitTrigger
exitType
wedgeExplodeRadiusPercent
wedgeLabelTextColor
wedgeLabelTextFont
These properties of obj_pie are hidden if webChartFlag is checked:
bgEdgeWidth
bgGradientMode
bgGradientColor2
bgRaisedFlag
bgShadowFlag
bgStyle
borderPixels
labelColumnFormat
rowLabelVisFlag
rowNameVisFlag
labelMinTabWidth
legendBgGradientMode
legendBgGradientColor2
legendWidthPercent
legendValueVisFlag
legendPercentVisFlag
outlineColor
transparencyPercent
22114: webChartFlag can now be set in styles sheet for bar and trend graphs
In prior releases, the webChartFlag property could not be set on obj_bargraph and
obj_trendgraph02 objects via an rtview stylesheet (.rts) file. This has been
fixed, so the following stylesheet entries will now set webChartFlag on all such
objects:
obj_trendgraph02 {
webChartFlag: 1;
}
obj_bargraph {
webChartFlag: 1;
}
22398: Fx Graphs now supported in 64 bit java on Windows
The Fx Graph objects are now supported in the Builder & Viewer in 64 bit versions
of Java on Windows. Previously only 32 bit java was supported.
This enhancement does not affect Linux or MacOS rtview installations. The Fx
Graph objects are still not supported in the Builder/Viewer on those platforms.
Reporting
22541: Export to PDF in thin client no longer triggers server log error message
Previously, under certain circumstances, exporting a PDF, using the "Export to
PDF" option would trigger a java.lang.IllegalStateException error message in the
(display)server log (e.g. logs\displayserver.log). This is no longer the case.
22558: Ability to suppress headers and footers in generated PDF reports added
A capability to suppress headers and footers in generated PDF reports has been
added to the report generator.
This is achieved by means of adding new attributes to the report tag in the
report config xml file
The new attributes are:
no_header
no_footer
which take a boolean value, and are false by default.
Not adding the attributes will have the same behavior as previously.
e.g.
for a generated report with a header and footer
<report name = "plant_status">
for a generated report with no header (but with a footer)
<report name = "plant_status_no_header" no_header="true" >
for a generated report with no footer (but with a header)
<report name = "plant_status_no_footer" no_footer="true" >
for a generated report with no header and no footer
<report name = "plant_status_no_header_footer" no_header="true" no_footer="true">
Scripts
22296: rtvpost added to make_war and update_war scripts
The rtvpost war file is now included in the make_ and update_wars scripts.
22542: Split start/stop_servers scripts in bundles into central vs data servers
The RTViewEnterpriseMonitor and RTViewTIBCOMonitor deliverables have been
enhanced with scripts to start and stop only the central servers, and to start
and stop only the data servers. They are:
start_central_servers.bat/sh
stop_central_servers.bat/sh
start_data_servers.bat/sh
stop_data_servers.bat/sh
--------------------------------------
The start_rtv, stop_rtv, and status_rtv scripts have been enhanced as follows:
(1) The first argument to the scripts, the config, may now be a list of configs
separated by "+". For example, "start_rtv bwmon+emsmon" will start all
(uncommented) servers in the bwmon and emsmon sections.
(2) A new argument has been added to exclude a list of configs. For example,
"start_rtv all -exclude:bwmon+emsmon" will start all (uncommented) servers except
those in the bwmon and emsmon sections.
Solution Package
22171: New Data Cache package
A new Data Cache package has been added to RTView Enterprise Monitor. It is used
to post data to RTView via http from a javascript application such as NodeJs.
Rest Endpoints (urls) are provided to allow the posting of data to caches, and
the creation, deletion and replacement of caches.
Refer to rtvapm\datacache\README.txt for more information
22310: Solution package README.txt files deprecated
The solution package README.txt files have been deprecated.
Information relevant to essential configuration has been migrated into the
conf\sample.properties comments, to continue to support users who prefer to set
properties manually in the properties files, rather than use the new Config UI.
Apache Kafka
22134: New consumer lag metrics alerts
The following alerts have been added to Kafka Monitor:
KafkaConsumerLagIncreasing
This alert is triggered for any topic if the consumer lag rate of change is
greater than zero for the specified duration. This implies the lag is steadily
increasing.
KafkaConsumerSlow = current-delta positive and lag-delta nonnegative
This alert is triggered for any topic if the consumer lag delta is nonnegative
and the current offset delta is positive for the specified duration. This implies
the consumer is slow in reading messages and should be considered a warning.
KafkaConsumerPartitionStalled
This alert is triggered for any partition of any topic if the consumer lag delta
is nonnegative and the current offset delta is zero for the specified duration.
This implies new messages are being added to the partition but the consumer is
not reading them.
22473: Collect and display consumer lag metrics
The information Kafka Monitor presents about consumer lag has been significantly
enhanced.
Lag metrics are now collected on a per-partition basis for the cluster and
summarized across brokers and consumers. The new calculated value is now used in
the Consumer displays instead of the old "record-max-lag" value reported by the
brokers, and new displays have been added as follows.
1. The Cluster All Topics Chart now has a bar graph with lag values summed across
brokers and consumers
2. The Topic Summary has a new Partitions tab with
- Bargraph of lag per topic:broker
- Table of partitions for topic
3. The Broker Summary has a new Topic Lag tab with
- Bargraph of lag per topic
- Table of topics for broker
4. The Consumer Summary has a new Consumer Lag tab with
- Bargraph of lag per topic
- Table of topics for consumer
Host Infrastructure
22261: rtvHostAgent no longer pre-extracted
To reduce the size of the product download, the rtvHostAgent .zip file will no
longer be pre-extracted under hostmon/agents.
The README.txt from within the rtvHostAgent_x.zip is, however, now available as
hostmon/agents/README_rtvHostAgent.txt
Oracle Weblogic
22158: HOST CPU Usage % no longer zero for non JRockit JVMs
The System CPU % has been enhanced to use the SystemCpuLoad attribute from the
JMX OperatingSystem MBean when the running version of Java is 1.7 or higher.
This fixes an issue whereby the HOST CPU Usage % was zero for non JRockit JVMs.
22159: The JVM CPU % now represents multiple cores and is not capped at 100%
The JVM CPU % now shows percentages above 100%, which comes from the number of
cores.
22370: function error in data server logs cleaned up
Previously a WLM dataserver running on Linux, monitoring v12.2.x, would print the
following spurious error:
2017-11-28 15:01:42,928 INFO GmsTimer-DataServer - [rtview] ERROR: function
<wlsWorkManagerStats2>, Table structure has changed; cannot save data.,
type:DELTARATEROWS, file:wls_workmgr_cache.rtv
This error has been addressed
TIBCO ActiveSpaces
22162: New Tasmon Query Metrics displays
New Tasmon Query Metrics displays (All Queries Table, Query Summary) have been
added.
These show metrics on queries including query duration.
The All Queries Table display shows metrics for current and recent queries,
filterable by selected Domain, Metaspace and space.
Information on a specific query can be shown by drilling down on a row in the
Queries table. This will drill down to, and populate, the Query Summary display
for the selected query.
The Query Summary display shows Space, Member and Query information for the
selected query.
In the case where the query is run across multiple members, information is shown
for related queries. Queries are related when they share the same parent request
id as the selected query.
Related queries can be drilled down to in the Related Queries Table, to become
the selected query in the query summary display.
Additional Member information is available by drilling down on the Member Info ..
area, which will drill down to the Member Summary display for the given member.
Note: The metrics for the above displays are only available for ActiveSpaces
2.3(+) Systems when query statistics monitoring has been configured.
Query statistics monitoring is configured by populating the TasQueryStats cache
using a named connection to ActiveSpaces 2.3+ Metaspace as described in the
sample.properties file.
# Configure the following cache definition to populate the TasQueryStats cache
for version 2.3+ ActiveSpaces Systems
# - one for each configured connection using the $tasConnName subs
#
#collector.sl.rtview.cache.config=tas_querystats_cache_source.rtv
$tasDomain:<domain-name> $tasConnName:<connection>
#
22163: New Tasmon Alert TasQueryDurationHigh
A new Tasmon Alert TasQueryDurationHigh has been added.
This alert will trigger when a query duration (in seconds) is above the defined
thresholds (in seconds).
This alert has a per space override available.
Note: The metrics for the above alert are only available for ActiveSpaces 2.3(+)
Systems when query statistics monitoring has been configured.
Query statistics monitoring is configured by populating the TasQueryStats cache
using a named connection to ActiveSpaces 2.3+ Metaspace as described in the
sample.properties file.
# Configure the following cache definition to populate the TasQueryStats cache
for version 2.3+ ActiveSpaces Systems
# - one for each configured connection using the $tasConnName subs
#
#collector.sl.rtview.cache.config=tas_querystats_cache_source.rtv
$tasDomain:<domain-name> $tasConnName:<connection>
#
22164: New TASMON connection parameters (securityToken and identityPassword)
New connection parameters, securityToken and identityPassword, have been added to
the tasmonds connection string property.
The securityToken value is the value of the path to the security token file. By
copying the security property file to current project directory, the path can be
eliminated and just the name of the security token file used.
When the securityToken parameter is used, the discovery parameter should not be
used, since discovery values are defined in the securityToken file.
The identityPassword value is the value of the password used to created the safe
identity password required with the security token file
Examples of connection strings that use these parameters are given in
sample.properties
# NOTE: When securityToken is used discovery and listen values should NOT be
specified
#collector.sl.rtview.tasmonds.conn=__name=<connection> memberName=RTViewEM
metaspaceName=<metaspace> discovery=<discoveryURL> listen=<listenURL>
# remote discovery
# collector.sl.rtview.tasmonds.conn=__name=ms1 memberName=RTViewEM
metaspaceName=ms1 discovery=tcp://localhost:6001?remote|true listen=-
# With secureToken
#collector.sl.rtview.tasmonds.conn=__name=ms memberName=RTViewEM metaspaceName=ms
securityToken=mytoken.txt
# with secureToken and identityPassword
#collector.sl.rtview.tasmonds.conn=__name=ms memberName=RTViewEM metaspaceName=ms
securityToken=mytoken.txt identityPassword=password
22504: Tasmon now supports encrypted identityPassword's in connection definition properties
Tasmon now supports encrypted identityPassword's in connection definition
properties, for use with securityToken files.
TIBCO Adapter
22078: Set the webChartFlag to true in the EM stylesheet for the Java trend graphs
The webChartEnabledFlag has been set to true for obj_trendgraph02 objects in EM
so that they will use the html5 version of the graph in the thin client.
TIBCO BusinessWorks
22157: Show BW6 deployment as appspace or container
The Application and Appnode tables have a new column Deployment with values
Appspace and Container, and there are checkboxes on the Table and Heatmap
displays to control which are displayed.
22187: Removed "Error Count" from BW6 AppNodes Heatmap metrics dropdown
The BW All AppNodes Heatmap display had an erroneous entry "Error Count" in the
Metrics dropdown menu. This has been removed.
22188: Fixed "Current Executions" on the BW6 AppNode summary display
On the BW AppNode summary display the field "Current Executions" was not
correctly attached to data and showed zero. This has been corrected.
22399: Time Since Last Update now formatted as duration
In the BW All Activities table in BusinessWorks 5 Monitor, the column Time Since
Last Update is now formatted as a duration, e.g. 0d 00:50 is 50 minutes.
22425: Support for standalone containers in BW6/BWCE
In this release, if you choose not to supply values for the properties
sl.rtview.bw.domain
sl.rtview.bw.appspace
sl.rtview.bw.appnode
then unique names will be created for appspace and appnode, and each container
will appear as a standalone application with a single appnode.
If you supply specific names then your containers will appear in the displays as
if they were appnodes in an appspace, and if they are instances of the same
application, their metrics will be summed for the application, as if it were
deployed to the appspace.
In summary, you may configure your containers to run as if they were appnodes in
an appspace; or else they will run such that each is a unique appnode and
application.
22442: Rename BW6 to BW in displays and navtree
The naming of BW displays across versions 5 and 6 has been made more uniform. The
displays such as BW6 Applications, BW6 AppNodes etc. will now be labeled simply
BW Applications etc.
In the navigation tree their section will be labeled TIBCO BusinessWorks and the
section formerly labeled TIBCO BusinessWorks will be labeled TIBCO BusinessWorks
5
22564: bw6mon and amxmon assigned unique port prefixes
The RTView EM packages TIBCO ActiveMatrix Monitor (amxmon) and TIBCO
BusinessWorks Monitor (bw6mon) have been given new default port assignments. This
will be reflected in the "port prefix" in the Configuration UI as well as the
"update_wars" scripts in the emsample project.
For BusinessWorks Monitor the new port prefix is 45. This results in the
following default port assignments:
dataserver data port 4578
dataserver JMX port 4568
datserver SC port 4570
dataserver rtvhttp port 4575
dataserver rtvagent port 4572
dataserver sender data port 4576
dataserver sender JMX port 4566
displayserver data port 4579
displayserver JMX port 4569
historian JMX port 4567
database (hsqldb) JMX port 4561
For ActiveMatrix Monitor the new port prefix is 44. This results in the following
default port assignments:
dataserver data port 4478
dataserver JMX port 4468
datserver SC port 4470
dataserver rtvhttp port 4475
dataserver rtvagent port 4472
dataserver sender data port 4476
dataserver sender JMX port 4466
displayserver data port 4479
displayserver JMX port 4469
historian JMX port 4467
database (hsqldb) JMX port 4461
For compatibility purposes the old port assignments are available in the
rtvapm.<package>.compat.properties files in RTVAPM_HOME/<package>/conf. Note that
these files will be automatically loaded if the file rtview.properties (which is
now obsolete) is found in the project directory.
22700: Support for specifying BW Engine name prefix on data server command line
The BW Monitor data server has been enhanced with a new command-line argument
-engineprefix:<string> where <string> will be used to identify BW Engine
microagents in the Hawk agent, and will be removed from BW Engine names in the
displays. This string is normally COM.TIBCO.ADAPTER.bwengine.
If you set the prefix e.g. -engineprefix:COM.TIBCO.ADAPTER.bwxxx you will see a
log message such as
... setting BW Engine prefix to COM.TIBCO.ADAPTER.bwxxx
TIBCO EMS
21717: servers.xml removed from emsmon project
The Monitor for TIBCO Enterprise Message Service has been enhanced to use
properties to define connections to EMS Servers. Previously this was done in an
xml file named servers.xml. Projects using servers.xml files to define their
connections will continue to work. New projects should define their server
connections as follows, replacing <URL> <USER>, <PASSWORD> with the appropriate
values for the connection:
collector.sl.rtview.jmsadm.jmsadm_server=url=<URL> user=<USER>
password=<PASSWORD>
Note that the user and password aguments are optional. Some examples:
collector.sl.rtview.jmsadm.jmsadm_server=url=tcp://host1:7222
collector.sl.rtview.jmsadm.jmsadm_server=url=tcp://host2:7222 user=user1
password=pass1
collector.sl.rtview.jmsadm.jmsadm_server=url=tcp://host3:7222,tcp://host3:7222
user=user1 password=pass1
Passwords can be encoded before entering them in your properties file using the
encode_string command line utility.
21718: Removed unneeded cp properties from EMSMON sample.properties
The following properties are no longer needed by the Monitor for TIBCO Enterprise
Message Service. They have been removed from the sample properties.
collector.sl.rtview.cp=%TIBJMS_ROOT%/lib/jms.jar
collector.sl.rtview.cp=%TIBJMS_ROOT%/lib/jms-2.0.jar
collector.sl.rtview.cp=%TIBJMS_ROOT%/lib/tibjms.jar
collector.sl.rtview.cp=%TIBJMS_ROOT%/lib/tibjmsadmin.jar
TIBCO FTL
22030: New Solution Package for TIBCO FTL
The Solution Package for TIBCO FTL (TFTLMON) has been added to RTView Enterprise
Monitor. This Solution Package monitors all the components of a FTL Realm,
including Satellite Servers, CSPF Neighbors, VPNs, Bridges, Clients, and
Endpoints.
See the RTView Enterprise Monitor User Guide for configuring the TFTLMON Solution
Package.
TIBCO Hawk
22170: Default hawk connection disabled
In previous releases, using stop_rtv.sh on Unix platforms to stop a Data Server
running the HAWKMON package failed due to a spurious rvd process caused by the
creation of an unecessary connection made by the HAWKMON data source. This has
been fixed.
UX Monitor
22260: UXRobot zip no longer pre-extracted
To reduce the size of the product download, the UXRobot.zip file will no longer
be pre-extracted under uxmon/agents.
The README.txt from within the UXRobot_x.zip is, however, now available as
hostmon/agents/README_UXRobot.txt
VMWare vSphere
22178: Re-implemented support for standalone ESXi hosts
In the previous release, support for standalone VMWare ESXi hosts (as opposed to
vCenter servers) was broken due to added support for clusters.
There is now a separate VMWmon cache source file or connections to standalone
VVWare hosts. For standalone hosts use
collector.sl.rtview.cache.config=vmw_host_cache_source.rtv
$vmw_conn:<connection-name>
and for vCenter servers use
collector.sl.rtview.cache.config=vmw_cache_source.rtv $vmw_conn:<connection-name>
Version 3.8.1 Release Notes
Solution Package
Apache Kafka
22094: Enhanced Topic Summary with multiple averages
The Kafka Single Topic Summary and the Single Broker Summary Topic Trends
displays have been enhanced with the addition of a drop-down list to select
different averaging for the trend values, including mean, 1, 5, and 15 minutes.
22095: Sort options added to topics charts
The displays Kafka Cluster Activity for Topic and Kafka Cluster Activity for all
Topics have been enhanced with sort controls so you may choose the column by
which data is sorted, and in which direction.
22149: Added support for Kafka version 9 zookeepers
Kafka Zookeepers running under Kafka version 0.9 will now appear in the monitor
displays, in the cluster assigned in the startup properties.
Limitations:
- v0.9 Zookeepers will not have a "cluster id" field
- KafkaClusterSplitBrain alert will not work correctly for v0.9 Zookeepers
22150: Four KafkaCluster alerts added
Four alerts for Kafka Clusters have been added to the Alert Administration table.
Their names and descriptions are as follows:
KafkaClusterNoActiveController
There is more one active controller per cluster (could indicate split-brain)
KafkaClusterSplitBrain
One or more Zookeepers or Brokers are not acting as part of the main cluster
KafkaClusterPartitionsUnbalancedHigh
Partitions supported by the cluster are not evenly distributed across the
available brokers
KafkaClusterLeadersUnbalancedHigh
Partition leaders for the cluster are not evenly distributed across the available
brokers.
These may be made available in EM 3.8.0 by adding the following line to your
sample.properties file:
collector.sl.rtview.alert.config=kafka_cluster_alertdefs.rtv
22151: Support for multiple-digit zookeeper IDs
Previously the Kafka Monitor would fail to display metrics for a Zookeeper whose
ID was more than one digit. This has been corrected.
TIBCO BusinessWorks
22139: The column CPU % in BwEngines cache should never have NaN
Under some circumstances stopped engines would report a CPU% of NaN.
They will now report a value of zero.
22147: Active applications no longer incorrectly appear as EXPIRED
In the previous release, applications in the table could be missing a value in
the Timestamp column, which would cause the application to be marked expired, and
thus trigger the AppExpired alert if enabled.
This has been fixed.
Version 3.8.0 Release Notes
Configuration
22053: EM property handling has been enhanced
In previous releases, sender properties could be overriden by project properties
unintentionally. In order to address this, the EM property handling has been
enhanced to give precedence to the properties that use the sender property filter
for processes that are run with the sender property filter.
22069: Port inconsistencies fixed in multiple solution packages
The following solution packages were set to use an incorrect port in rtvagent.war
to communicate with the dataserver:
acwmon
mqmon
mysqlmon
ocmon
syslog
These have been corrected.
Deployment
21919: $rtvTimeZoneOffset substitution has been removed from emcommon and emreference
The $rtvTimeZoneOffset substitution has been removed from
emsample\conf\emcommon.properties. This substitution is not used in any standard
EM displays. Customers who have created custom displays for use with EM, should
check to see if they have used that substitution and if so, add it to their
project properties.
Distribution
21983: Fixed an issue with .war file creation
Previously some solution packages could not be built from scratch in a
deliverable using the make_wars_package.bat script, due to a file missing from
the package library. This has been fixed.
The effected solution packages are:
Solution Package for Amazon Cloudwatch (acwmon)
Solution Package for VMWare (vmwmon)
Solution Package for TIBCO ActiveSpaces (tasmon)
RTView Core Functionality
Data Historian
21921: Microsoft SQL Server 2014 and 2016 now supported
Microsoft SQL Server 2014 and 2016 are now supported as databases for use with
the Data Historian, provided that the latest JDBC driver is used (sqljdbc41.jar
with Java 1.7, sqljdbc42.jar with Java 1.8).
Data Sources
22083: Jmx commands no longer fail silently when RTView isn't connected
In previous releases, if a jmx command failed because RTView wasn't connected, it
failed silently. This has been fixed and the error is reported.
Display Server
21909: Tomcat logs no longer produce gratuitous rtvCleanup errors
In previous releases the following error message appeared in the Tomcat log at
shutdown, for each deployed copy of the rtvdisplay servlet:
"SEVERE: The web application [/rtvdisplay] appears to have started a thread named
[rtvCleanup] but has failed to stop it. This is very likely to create a memory
leak."
Starting with this release, the error message should be seen less often in the
log file, although it may still appear occasionally. In any case, there is no
danger of a memory leak when tomcat is shutdown.
21990: Fixed a vulnerability in the thin client
An XSS (cross-site scripting) vulnerability in the thin client login.jsp file has
been fixed.
21996: Fixed an issue with thin client resizing
In previous releases, after a display is resized by the thin client to fit the
browser window, the black border around the default button (if any) was drawn in
the button's original position, rather than the button's new position. This is
fixed.
Object Library
21045: Misconfigured table objects no longer cause javascript exceptions in the thin client
A bug in the thin client has been fixed which could cause a javascript exception
if the columnFormat on a table object was misconfigured to specify a format for a
string column, and a backslash character appeared in the column.
Scripts
22049: EM enhanced to automatically read local project.property files
EM applications have been enhanced to automatically read project.properties if it
exists in the directory where they were started. If project.properties does not
exist, no error is printed.
Upgrade Notes: If you are upgrading from a previous version and your project
contains a project.properties file, be aware that this file will be used even if
it is not specified on the command line. To avoid this, rename or remove your
project.properties file.
Solution Package
Apache Kafka
22029: New Solution Package for Apache Kafka
The Solution Package for Apache Kafka (KAFKAMON) has been added to RTView
Enterprise Monitor. This Solution Package monitors all the components of a Kafka
Cluster, including Zookeepers, Brokers, Producers, Consumers, and Topics.
See the RTView Enterprise Monitor User Guide for configuring the KAFKAMON
Solution Package.
General
21856: Several solution packages have had their ports standardized
The default port numbers for sender and receiver ports in several solution
packages were modified to follow the convention of using the same first 2 digits
for all ports within a solution package. The modified properties are listed
below.
db2mon, jbossmon, oramon, tasmon, tbemon, vmwmon: Changed the following
properties from port 5665 to 3272:
sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3272 packages=all
receiver.sl.rtview.rtvagent.port=3272
dockermon, mongomon, mssqlmon, nodemon: Changed first 2 port digits from 41 to 32
for the following properties:
sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3272 packages=all
receiver.sl.rtview.rtvagent.port=3272
sender.sl.rtview.dataserver.port=3276
sender.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3266
hawkmon: Changed first 2 port digits from 39 to 33 for the following properties:
sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3372 packages=all
receiver.sl.rtview.rtvagent.port=3372
sender.sl.rtview.dataserver.port=3376
sender.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3366
hostbase: Changed first 2 port digits from 39 to 32 for the following properties:
sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3272 packages=all
sender.sl.rtview.dataserver.port=3276
sender.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3266
receiver.sl.rtview.rtvagent.port=3272
Host Infrastructure
21903: Fixed an issue with HostProcessCountLow alert
The indexes and the driving metric of the HostProcessCountLow alert have been
fixed. In addition, the Alert Text now reads as a Low Alert instead of a High
Alert.
IBM Websphere Application Server
21776: Linux custom_setup script enhanced in WSM
The custom_setup script for Linux has been enhanced to exclusively define
WAS_HOME and JAVA_HOME environment variables. And similarly to the configuration
under Windows, the definition of the location of the API jars required to connect
to the WebSphere Admin has been moved to the sample.properties file.
MySQL
21861: MySQLMON enhanced to collect MYSQL 5.7.6+ data by default
The RTView MYSQLMON Solution Package no longer requires the
"show_compatibility_mode=ON" setting to allow collection of MySQL 5.7.10+.
22097: MYSQLMON sql schema files now complete
The database table schemas under rtvapm\mysqlmon\dbconfig have been updated to
include missing optional table schemas.
The name of the existing tables were also updated to remove the extraneous
"_TABLE" from the end of them, to match the table names as configured in the
MYSQLMON historian.
Users of v3.7 may need to update their three existing database table names to the
new names. Users who used Historian auto-creation will already have the new table
names.
Example syntax is available below.
Oracle
alter table MYSQL_BYTES_TABLE rename to MYSQL_BYTES;
alter table MYSQL_CRUD_TABLE rename to MYSQL_CRUD;
alter table MYSQL_QUERIES_TABLE rename to MYSQL_QUERIES;
DB2
RENAME TABLE MYSQL_BYTES_TABLE TO MYSQL_BYTES;
RENAME TABLE MYSQL_CRUD_TABLE TO MYSQL_CRUD;
RENAME TABLE MYSQL_QUERIES_TABLE TO MYSQL_QUERIES;
MySQL
RENAME TABLE MYSQL_BYTES_TABLE TO MYSQL_BYTES;
RENAME TABLE MYSQL_CRUD_TABLE TO MYSQL_CRUD;
RENAME TABLE MYSQL_QUERIES_TABLE TO MYSQL_QUERIES;
SQL Server
(replace "database_name" with the name of your database)
use database_name
go
exec sp_rename '[MYSQL_BYTES_TABLE]', '[MYSQL_BYTES]'
exec sp_rename '[MYSQL_CRUD_TABLE]', '[MYSQL_CRUD]'
exec sp_rename '[MYSQL_QUERIES_TABLE]', '[MYSQL_QUERIES]'
go
Sybase
sp_rename 'MYSQL_BYTES_TABLE', 'MYSQL_BYTES';
sp_rename 'MYSQL_CRUD_TABLE', 'MYSQL_CRUD';
sp_rename 'MYSQL_QUERIES_TABLE', 'MYSQL_QUERIES';
Solace
21815: Message Router drop down enhanced to show availability of message routers
The Message Router drop down has been enhanced to indicate the availability of
the Message Router. When the Message Router is disconnected, the connection name
contains the string [?] appended to indicate the quality state: "No Data". When
the Message Router has expired, the connection name contains the string [X]
appended to indicate the quality state: "Lost Data". No string is appended to the
connection name if the Message Router has no monitoring issues.
21886: Removed unnecessary link in Message Routers navigation tab
The link to the CSPF Neighbors has been removed from the Message Routers
navigation tab.
21997: Multiple improvements made to some SOLMON displays
To avoid having the SOLMON Client displays blank when there is an error in the
SEMP request that populates the SolClients cache, an improvement in our displays
has been introduced to show the data available mainly from the SolClientStats
cache and leave the SolClients cache as a secondary source of data.
As a result, the All Clients Table can show the data coming from the available
SolClientStats cache. The missing columns that are primarily static strings will
be blank in this display.
In regard the Clients Summary, a quality measurement of the available data is
being performed so the display shows the existing data and hides the graphical
elements for which we don't have available current data. If the data is Expired,
the background of this display is shown grey with the string "[X]" appended to
the Client name in the drop down. Finally, the background of the display will be
shown as light red and the Alert State grayed out if there is no client
available.
22036: Properties related to SOLMON history tables moved to conf directory
The properties that enable/disable the SOLMON history tables have been moved from
the sample.properties file to the rtvapm.solmon.properties file located in the
conf directory. To change the default settings, follow the instructions provided
in the second file.
TIBCO ActiveSpaces
21860: Handling of ActiveSpaces environment variables has been improved
The custom_setup.sh script in tasmon would overwrite the existing value of
LD_LIBRARY_PATH rather than append to it. This has been corrected.
Also, both the .bat and .sh version will now check to see if a location for AS
libraries is defined, and if not will use a default location and warn the user.
You may define your correct location by editing the script.
For Windows the default location is:
AS_PATH=%RTVAPM_HOME%\..\ext\tibco\as\2.1.6
For Unix it is:
AS_HOME=/opt/tibco/as/2.1
Note the scripts no longer issue a warning that the script "has not been edited."
22059: New System Resource Metrics available for metaspace members
New System Resource Metrics are available for metaspace members, for metaspace
members that have system monitoring enabled, in the the All Members Table Display
(and in the TasMembers cache)
Enabling system monitoring is described in the Tibco Active spaces documentation.
System monitoring can be enabled at Tibco process (e.g. as-agent) launch time by
using the command line argument -monitor_system true.
System monitoring can also be dynamically enabled or disabled for metaspace
members using as-admin CLI commands.
Individual metaspace members can have system monitoring enabled / disabled using
the as-admin command
execute on member "<name>" monitor system true|false
e.g.
execute on member "retail_put" monitor system true
Multiple / all metaspace members can have system monitoring enabled / disabled
using the as-admin command
execute on [peer | remote] members <admin_command>
e.g.
execute on peer members monitor system true
The System Resource Metrics are obtained from the $sys_stats space.
These are are the values used in the as-admin CLI command
show | describe system stats
The (new) column names in the the All Members Table Display (and the TasMembers
cache) are the same as the $sys_stats space tuple field names for traceabilty
The (new) column names and description from the Tibco show | describe system
stats documentation are given below
String sys_name
Indicates the operating system that is running.
String cmd_name
Indicates the command used to start as-admin; for example, as-admin
-monitor_system true .
String proc_id
Indicates the process ID for the process that is monitored.
String user_name
Indicates the user name of the user running the process.
Long thread_count
Indicates the number of threads running for the process.
Long res_mem_size
Indicates the amount of physical memory currently allocated to the member or
agent process. (Resident Memory(MB))
Float mem_load
Indicates the % Memory used.
Long peak_res_mem_size
Indicates the peak size of the system resident memory allocated by the system.
Long page_size
Indicates the current size of the system pagefiles (resident memory) allocated by
the system. Page File Size (MB)
Long peak_page_size
Indicates the peak size of the system pagefiles allocated by the system.
Float process_cpu_load
Indicates the load on the CPU. (CPU %)
Integer cpu_count
Indicates the number of CPUs running on the system.
JVM Heap Metrics - only available for Java Metaspace member processes
Indicates the following information for the JVM heap:
Long jvm_comm_heap_size
Committed MB - The committed heap usage.
Long jvm_max_heap_size
Max MB - The maximum heap usage.
Long jvm_used_heap_size
Peak (MB) - Indicates the peak usage in MB.
JVM Nonheap - only available for Java Metaspace member processes
Indicates the following information for the JVM non-heap memory:
Long jvm_comm_nonheap_size
Committed MB - The committed nonheap usage.
Long jvm_max_nonheap_size
Max MB - The maximum nonheap usage.
Long jvm_used_nonheap_size
Peak (MB) - Indicates the peak nonheap usage in MB.
Long jvm_finalizing_count
The amount of memory freed by the finalize operation on the JVM.
String as_version
Indicates the ActiveSpaces version that is running.
Additionally, there is the calculated value JvmMemoryUsedPercent ,
where JvmMemoryUsedPercent is %age JVM Heap Used ( Used JVM Heap / Max Jvm Heap)
= (jvm_used_heap_size/jvm_max_heap_size) * 100.0
22060: New displays added to display member system resource usage
Two new displays (Member Summary - Process, Member Summary - JVM) have been added
to the TIBCO Active Spaces solution pack to display member system resource usage.
The Member Summary - Process display, displays current and historical process
resource usage for a given metaspace member.
Note: The metrics for the above display are only available for members where
system monitoring has been enabled.
Enabling system monitoring for a member is described in the TIBCO documentation.
The Member Summary - JVM display, displays current and historical JVM resource
usage for a given metaspace member.
Note: The metrics for the above display are only available for Java members where
system monitoring has been enabled.
Enabling system monitoring for a java member is described in the TIBCO
documentation.
22061: Additional resource metrics have been added to the history of the TasMembers cache
Additional selected member resource metrics have been added to the history of the
TasMembers cache.
The individual columns / metrics are described in The release note for 22059.
The subset of additional columns used for history are listed in the "ALTER TABLE"
commands, below.
Users will need to update the table structure of the TAS_MEMBER historian table
by executing the following alter table SQL sentences in your selected database
administrative tool:
DB2:
ALTER TABLE "TAS_MEMBER" ADD "thread_count" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "res_mem_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "mem_load" FLOAT;
ALTER TABLE "TAS_MEMBER" ADD "peak_res_mem_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "page_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "peak_page_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "process_cpu_load" FLOAT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_comm_heap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_max_heap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_used_heap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_comm_nonheap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_max_nonheap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_used_nonheap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_finalizing_count" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "JvmMemoryUsedPercent" DOUBLE ;
SQL Server:
ALTER TABLE [TAS_MEMBER] ADD [thread_count] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [res_mem_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [mem_load] FLOAT;
ALTER TABLE [TAS_MEMBER] ADD [peak_res_mem_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [page_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [peak_page_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [process_cpu_load] FLOAT;
ALTER TABLE [TAS_MEMBER] ADD [jvm_comm_heap_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [jvm_max_heap_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [jvm_used_heap_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [jvm_comm_nonheap_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [jvm_max_nonheap_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [jvm_used_nonheap_size] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [jvm_finalizing_count] BIGINT;
ALTER TABLE [TAS_MEMBER] ADD [JvmMemoryUsedPercent] FLOAT;
MySQL:
ALTER TABLE "TAS_MEMBER" ADD "thread_count" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "res_mem_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "mem_load" FLOAT;
ALTER TABLE "TAS_MEMBER" ADD "peak_res_mem_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "page_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "peak_page_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "process_cpu_load" FLOAT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_comm_heap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_max_heap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_used_heap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_comm_nonheap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_max_nonheap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_used_nonheap_size" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "jvm_finalizing_count" BIGINT;
ALTER TABLE "TAS_MEMBER" ADD "JvmMemoryUsedPercent" DOUBLE;
Oracle:
ALTER TABLE "TAS_MEMBER" ADD ("thread_count" NUMBER, "res_mem_size" NUMBER,
"mem_load" FLOAT, "peak_res_mem_size" NUMBER, "page_size" NUMBER,
"peak_page_size" NUMBER, "process_cpu_load" FLOAT, "jvm_comm_heap_size" NUMBER,
"jvm_max_heap_size" NUMBER, "jvm_used_heap_size" NUMBER, "jvm_comm_nonheap_size"
NUMBER, "jvm_max_nonheap_size" NUMBER, "jvm_used_nonheap_size" NUMBER,
"jvm_finalizing_count" NUMBER, "JvmMemoryUsedPercent" REAL);
SyBase:
ALTER TABLE "TAS_MEMBER" ADD "thread_count" BIGINT NULL, "res_mem_size" BIGINT
NULL, "mem_load" FLOAT NULL, "peak_res_mem_size" BIGINT NULL, "page_size" BIGINT
NULL, "peak_page_size" BIGINT NULL, "process_cpu_load" FLOAT NULL,
"jvm_comm_heap_size" BIGINT NULL, "jvm_max_heap_size" BIGINT NULL,
"jvm_used_heap_size" BIGINT NULL, "jvm_comm_nonheap_size" BIGINT NULL,
"jvm_max_nonheap_size" BIGINT NULL, "jvm_used_nonheap_size" BIGINT NULL,
"jvm_finalizing_count" BIGINT NULL, "JvmMemoryUsedPercent" FLOAT NULL;
22062: TASMON enhanced with three new alerts
The new Alerts TasMemberCpuHigh, TasMemberMemoryUsedHigh,
TasMemberJvmMemoryUsedHigh have been added.
A new alert - TasMemberCpuHigh has been added. This alert will trigger when the
Member CPU Used % goes above the specified threshold for the specified duration.
This alert has a per member override available.
A new alert - TasMemberMemoryUsedHigh has been added. This alert will trigger
when the Member Memory Used % goes above the specified threshold for the
specified duration. This alert has a per member override available.
A new alert - TasMemberJvmMemoryUsedHigh has been added. This alert will trigger
when the Member JVM Memory Used % goes above the specified threshold for the
specified duration. This alert has a per member override available.
Note: The metrics for the above alerts are only available for members where
system monitoring has been enabled.
Enabling System monitoring for a member is described in the TIBCO documentation.
Also note, the metric for Jvm Memory Used %, is only available for java members
where system monitoring has been enabled. Enabling System monitoring for a java
member is described in the TIBCO documentation.
22063: New system resource metrics are available in the All Members Heatmap Display
New CPU %, Memory % and JVM Memory % system resource metrics are available in the
All Members Heatmap Display.
These Metrics are available to select from the Metric drop-down selector, and are
visible in the cell mouse-over pop-up.
Note: Note that these values are only present for members that have system
monitoring enabled. For members without system monitoring enabled, the value for
the metric is NaN (Not a number) and displayed appropriately.
See the TIBCO documentation for how to enable system monitoring for metaspace
members.
22113: "Misses" and "ToPersist" Metrics now display correctly in Summary displays.
Previously, under some circumstances, the "Misses" and "ToPersist" labelled
metrics would not display the correct values, in Summary displays. This is no
longer the case. Summary Displays consist of Metaspace Summary, Space Summary,
Member Summary, and Member by Space Summary.
TIBCO Adapter
21899: New TIBCO Adapter Monitor Solution package
The TIBCO Adapter Solution Package TADMON has been included in RTView EM. This
Solution Package allows monitoring of TIBCO Adapters, which connect to multiple
technologies. These adapters are arranged in several categories depending on the
type of the technology they integrate with TIBCO products. There are Technical
Adapters (Eg. TIBCO ActiveMatrix Adapter for Database), Functional Adapters (Eg.
TIBCO Adapter for Remedy), and custom (implemented by the TIBCO Adapter SDK).
See the RTView EM User Guide for configuring the TADMON Solution Package.
TIBCO BusinessWorks
21965: Improved notification of stopped/expired BW6 appnodes and applications
In BW6 Monitor an appnode is marked as expired in the displays after a period of
time has elapsed with no change in its data. This enhancement adds a new alert,
Bw6AppNodeExpired, that you can enable for all or specific appnodes, to be raised
at that time.
If an application is stopped (e.g. by admin interface) its state will become
"Stopped" in the application table. This enhancement adds a new alert,
Bw6ApplicationStopped, that you can enable for all or specific applications, to
be raised at that time.
Note that whereas expired AppNodes may be removed from the displays after a
specified time, Applications do not expire. If an application is undeployed and
not redeployed, it will only be removed from the displays when the RTView
dataserver is restarted.
21992: BWMON enhanced with a new and improved readme file
The README file for the RTView OSGi Plugin for BusinessWorks Monitor has been
expanded and reorganized for greater clarity.
22014: New alert BwEngineUnreachable
BW Monitor has improved the way it detects and presents the status of BW Engines.
1. If an Engine is stopped normally its status will become STOPPED as before. Now
this status will also be shown by highlighting the Engine's row in the All
Engines table using a light pink color. This highlighting will also be used on
the BW Processes and Activities associated with the stopped Engine. In addition
the alert BwEngineStopped will be triggered if it is enabled.
2. If an Engine stops abnormally, e.g. crashes, the Hawk agent will report it as
"unreachable", and BW Monitor now makes use of this information: the Engine
status becomes UNREACHABLE and the Engine and its processes and activities become
highlighted in their respective tables using the standard gray color. In addition
a new alert BwEngineUnreachable will be triggered if it is enabled.
Note that, as before, if the Hawk agent itself becomes unreachable, it will be
marked Expired, along with all its engines and their associated processes and
activities, and the BwServerExpired alert will be triggered if it is enabled.
22015: appnode status of "Expired" split into "Stopped" vs "Unreachable"
Previously an appnode would be marked Expired if data was not received from it
for any reason.
Now it will be marked either Stopped if it was stopped normally, e.g. by an admin
comand, or Unreachable if it stops abnormally, e.g. the process crashes. In
either case the appnode will be removed from the displays after 24 hours with no
data.
The Bw6AppNodeExpired alert has been replaced with two new alerts,
Bw6AppNodeStopped and Bw6AppNodeUnreachable.
22017: New alert Bw6AppExpired
BW6 Monitor has been enhanced with Application expiration, defined as follows: an
application expires when none of its processes has shown activity for longer than
the expiration period, 10 minutes by default. Thus if an application is
distributed across multiple AppNodes in an AppSpace, it will not expire as long
as any one of its AppNodes is still running.
An expired application will be highlighted in gray the All Applications table,
and a new alert Bw6AppExpired will be triggered if it is enabled.
22035: BWMON enhanced with option to limit collection of activity and process data
If you want to reduce the amount of data collected by BW Monitor and you do not
require BW Activity data, you may disable the collection of this data with the
following property:
collector.sl.rtview.sub=$bwActivitiesDisabled:1
Likewise, you may disable the collection of BW Process data with the following
property:
collector.sl.rtview.sub=$bwProcessesDisabled:1
22067: BW6MON enhanced with new alert
BW6 Monitor has been enhanced with a new alert Bw6AppErrorState which indicates
that an application has encountered an error and thus is in some state other than
Running or Stopped. The specific state (e.g. StartFailed) will be reported in the
alert text.
e.g. BW6 App is in error state "StartFailed".
22116: BW6MON AppNode table enhanced with new State column
The column State has been added to the BW6 AppNode table, with the values ACTIVE,
STOPPED, UNREACHABLE. A corresponding text field has been added to the AppNode
Summary display.
In addition, the AppNode, AppSlice, Process, and Activity tables will display row
highlighting for any AppNode in the Stopped or Unreachable states. Unreachable
rows will be displayed in grey and Stopped rows in pink.
TIBCO EMS
21878: EMSMON enhanced with user-friendly headers
All EMSMON tabular displays have been enhanced with user-friendly headers. The
displays are in the following menu options:
All EMS Servers->All Servers Table
Single EMS Server->Single Server Tables
EMS Topics->All EMS Topics Table
EMS Queues->All EMS Queues Table
EMS Clients->Routes
EMS Clients->Connections
EMS Clients->Producers
EMS Clients->Durables
EMS Clients->Bridges, Users, Ports
21969: Background colors in EMSMON All Servers grid have been updated
The All Servers Grid display has been fixed to mimic the color indicators for
Inactive Servers when EMS Servers were working correctly and went down. This will
be indicated with the Expired flag set to true, which has been included in the
composite object comprising the elements of the object grid. This addition will
help to find EMS Servers that were working fine, but went down unexpectedly.
For aesthetic consistency across all the displays under the All EMS Servers menu,
the All Servers Table display has been enhanced to reflect the background color
of Expired EMS Servers as Inactive. Also, in this same display, the font color
from Inactive and FT Standby EMS Servers has been changed to be readable.
VMWare vSphere
21830: VMWMON enhanced to monitor hardware of esxi hosts
RTView VMWare Monitor has been enhanced to monitor the hardware components of the
esxi hosts.
The host hardware components are shown in the new Host Health table, and the
System Vendor and Model are shown in new columns in the All Hosts table.
The Host Health table has multiple components per host and sensors per component.
It has a dropdown selector to filter the table by sensor type.
Version 3.7.0 Release Notes
Distribution
21836: MySQL now provided via Docker Hub
For the convenience of users who utilize Docker, the slcorp repo on Docker Hub
now includes an image of MySQL Database configured to work with RTView.
This container only works with Docker 1.10 and later.
See rtvapm/containers/docker/mysql-rtview/README.txt for more information.
Drill Down
21887: Fixed an issue with navtrees
In previous releases, when drilling down from within a display to another display
in the navtree, the tree selection sometimes failed to update correctly. This
happened in the case where there were multiple navtree items for the same display
with different subs and the user drilled down to that display from within another
display. This has been fixed.
RTView Core Functionality
Alerts
21924: Fixed an issue with disabling event alerts
In previous releases, disabling event alerts was sometimes ignored due to a bug
that was introduced in RTView Classic 6.7.0, RTView EM 3.2.0. This has been
fixed.
Builder
21672: Builder enhanced to remember dialog window sizes and positions
The Display Builder has been enhanced to automatically save and restore the size
and location of the following dialogs:
- Open (File->Open)
- Save (File->Save/Save-As)
- Function Results (Function Dialog->Result Button)
The Tools->Reset Window Layout menu option and the -resetlayout command line
option restore the size and location of these windows in addition to the other
windows that were previously reset.
Builder - Property Dialogs
15582: Japanese label for "Update Mode" property now shown on certain dialogs
Previously, the Japanese label for "Update Mode" property was not shown on
certain polled ds attach to data dialogs when running on a Japanese OS. The
English label was used instead. This is no longer the case.
Affected dialogs include the custom polledds and polledds2 example data sources,
and the http rest data source
Data Server
21898: Fixed an issue with rtvquery returning errors on valid query strings
In previous releases, the rtvquery servlet would sometimes return an error of "No
data received before timeout, query may be invalid" for a specific, valid cache
query string, on every attempt. The servlet needed to be restarted to clear the
error. This has been fixed.
Data Sources
21689: Fixed an issue with the "Extend with SQL" cache feature
In prior releases, the "Extend with SQL" feature of the cache data source could
cause thread growth if the history database connection was undefined or
unavailable. This is now fixed.
Display Server
21906: Thin client enhanced to check user role access on each request
In prior releases, after a user had logged into the thin client, the user could
manually enter a specific URL in the same browser instance and possibly view data
from rtview displays to which the user's role should have denied access. This is
fixed.
21908: Enhanced display server with option to limit access to specific panel files
The display server now supports a "permitpanel" option to specify the panel
layout files that the server will read.
A panel layout for the thin client is requested from the display server with a
URL parameter as follows:
panels.jsp?file=X
where X is the name of the panel layout file that the server should read. By
default, the display server will attempt to read any filename on the server that
is specified by the URL parameter. If the file is a valid panel layout file, the
thin client will use it. But if the file does not exist, a "no such file" error
is displayed in the browser, and if the file exists but does not contain the
expected layout information, a "no panels found" error is displayed in the
browser.
The permitpanel option allows you to specify the file(s) which the display server
will read in response to a panels.jsp request. Requests from panels.jsp for any
other files are rejected with a "Permission denied" error shown in the browser,
regardless of whether the file exists or not, and the server will not attempt to
read such files.
The option may be specified multiple times to allow access to multiple panel
files.
Command-line example:
run_displayserver -permitpanel:PANELS.ini -permitpanel:layout.xml
DISPLAYSERVER.ini example:
permitpanel PANELS.ini
permitpanel layout.xml
In addition, the display server supports another new option to prevent attempts
to load remote files, as follows:
-permitfile:LOCAL_ONLY
If that option is specified any rtv or image files that are referenced by URL
will not be read and the server will log a message similar to the following:
non-local file read permission denied: http://host/somefile
21912: Fixed phishing vulnerabilities in thin client
In prior releases, it was possible to create phishing URLs which appeared to be
directed at the rtview thin client but would redirect the user to another site,
or download and possibly execute a file. These vulnerabilities have been fixed.
Platform Support
21871: RTView upgraded to Java 1.7
RTView is now built with Java 1.7.
Java 1.6 is no longer supported.
Solution Package
Docker
21913: Docker Engine and Container heatmaps now indicate expiration
Previously Docker Engine and Container heatmaps did not indicate expiration of
their respective entities.
This is no longer the case. Entities in the heatmap change color to indicate
expiry.
MySQL
21791: New MySQL Monitoring Solution Package
The Solution Package for MySQL has been added to the list of monitoring Databases
under RTView EM. The monitoring data for this Solution Package is collected under
the servers/miscmon dataserver. Please refer to the RTView EM documentation for
information about configuration and troubleshooting.
21968: Alert names have been optimized
To follow the RTView standard naming convention of limits alerts with high
thresholds, the following alerts have been renamed: MysqlSlowQueries,
MysqlLocksWaited, MysqlQcacheLowMemPrunes, MysqlSlowThreads, and
MysqlDelayedWrites. These alerts are now named: MysqlSlowQueriesHigh,
MysqlLocksWaitedHigh, MysqlQcacheLowMemPrunesHigh, MysqlSlowThreadsHigh, and
MysqlDelayedWritesHigh, respectively.
Oracle Coherence
21644: Added new configuration option to display invocation only clusters
Invocation only clusters (those with no storage nodes or caches) require
additional configuration to be monitored.
This requires that one invocation only cluster be monitored at a time by a
suitably configured data server.
Configuration for use with an invocation cluster takes the form of a properties
file that must be edited by the user before use. The properties file is called
invocationonly.properties and can be found in the sample project directory.
You will need to edit the invocationonly.properties file, to set the
ACTUAL_CONN_NAME placeholder to the value of the sl.rtview.jmx.jmxconn property
used to connect to the invocation only cluster.
e.g. consider using the named connection "MyInvocationCluster"
Then you would have the property
sl.rtvapm.ocmon.jmxconn=MyInvocationCluster
and you would need to to edit the property line in invocationonly.properties
from
maincollector.sl.rtview.cache.config=oc_connection_dummy_cache_store.rtv
$conn:ACTUAL_CONN_NAME $cache:OcStorageDataRaw $file:ocmon_ts_constants.xml
$table:DummyOcStorageDataRaw
to
maincollector.sl.rtview.cache.config=oc_connection_dummy_cache_store.rtv
$conn:MyInvocationCluster $cache:OcStorageDataRaw $file:ocmon_ts_constants.xml
$table:DummyOcStorageDataRaw
When the invocationonly.properties has been edited this way, it can be used to
configure the monitoring dataserver by using the command line argument
-properties:invocationonly
either on the command line when launching the dataserver, or adding it in the
rtvservers.dat entry used to launch the monitoring dataserver.
21763: New Cluster MBean Servers display has been added
A new Cluster MBean Servers display has been added that lists information on
currently detected remote JMX management enabled MBean Servers within the
cluster. The new Cluster Bean Server display is accessible from the OC Metrics
Administration display, by clicking on the "Cluster MBean Servers" Button. This
will bring up the Cluster MBean Servers display.
The Cluster MBean Servers display lists the currently detected remote JMX
management enabled Mbean Servers, in the currently selected cluster. Information
displayed includes the hostname and IP address of the cluster node, and the port
used for remote JMX management.
21764: New displays for federated cache information have been added
Coherence now allows you to federate caches across clusters. New displays allow
you to monitor federation performance and throughput. The new displays are under
the Federated Clusters tab in the nav tree. Detail and Summary displays are
available for performance statistics derived from the cluster Destination and
Origin MBeans.
The Detail displays show the current information for all participating nodes for
a selected cluster. This information may be restricted to a single host if
desired. You can drill down on an individual node in the Detail display to
display Summary information for that node. Summary displays show current
information, and trended historical rate information.
Destination information shows how efficiently each node in the local cluster
participant is sending data to each destination cluster participant. Origin
information shows how efficiently each node in the local cluster participant is
receiving data from destination cluster participants.
21765: New Cache Size Alerts
New alerts are available to monitor cache sizes and alert if thresholds are
exceeded.
A new alert - OCCacheSizeHigh has been added. This alert will trigger when the
cache size goes above the specified threshold for the specified duration.
This alert has per cluster, per (cache) service, per cache and per (cache) tier
overrides. This alert appears in the "Other" Category when triggered.
Given that cache sizes vary, if you are only interested if the size of specific
caches exceeds specific thresholds, it may be preferable to use the Per Cache, or
Per Storage Class Override settings, allowing you set specific thresholds for
specific caches.
e.g. If the size of the "DistributedCacheForMessages" caches exceeds a
specific size.
A new alert - OcCacheOCCacheSizeLow has been added. This alert will trigger when
the rate of cache gets goes above the specified threshold for the specified
duration.
This alert has per cluster, per (cache) service, per cache and per (cache) tier
overrides. This alert appears in the "Other" Category when triggered.
Given that cache sizes vary, if you are only interested if the size of specific
caches goes below specific thresholds, it may be preferable to use the Per Cache,
or Per Storage Class Override settings, allowing you to set specific thresholds
for specific caches.
e.g. If the size of the "DistributedCacheForMessages" cache goes below a
specific size.
These alerts are disabled by default as appropriate threshold values and
overrides will vary by installation and will need to be set accordingly.
Oracle Weblogic
21835: Fixed a few typos in alert descriptions
Fixed typos in the alert description of the following two alerts:
WlsServerStaleData and WlsPendingRequestCurrentHigh.
TIBCO ActiveSpaces
21738: Fixed an issue with gaps in trend chart data
A bug that prevented the Response Time trend from the Metaspace Summary display
to show gaps when the data server was disconnected for more than 5 min has been
fixed.
TIBCO BusinessEvents
21863: TIBCO BE Monitor enhanced to connect to TIBCO APIX solutions
TIBCO APIX is a solution with TIBCO BE engines defined with certain rules and
events. Customers can now configure TBEMON to monitor TIBCO APIX BE engines.
To monitor an APIX BE engine you will include two new files via cache.config
properties:
tbe_cache_source_be5.1_asg_cacheagent.rtv
tbe_cache_source_be5.1_asg_inferenceagent.rtv
Note you will need separate connections for cache and inference to a single
engine process
Include properties like the following in your runtime properties file.
asgCacheConn, asgInferConn are arbitrary but distinct names, e.g "asgcache_4456,
asginter_4456"
#collector.sl.rtview.jmx.jmxconn=<asgCacheConn> <hostname> <port> URL:- - -
'false'
#collector.sl.rtview.jmx.jmxconn=<asgInferConn> <hostname> <port> URL:- - -
'false'
#collector.sl.rtview.cache.config= tbe_cache_source_be5.1_asg_cacheagent.rtv
$tbe_conn:<asgCacheConn> $tbe_cluster:<clusterName>
#collector.sl.rtview.cache.config=tbe_cache_source_be5.1_asg_inferenceagent.rtv
$tbe_conn:<asgInferConn> $tbe_cluster:<clusterName>
21872: Enhanced sorting on the TBEMON All Agents table
The All Inference Agents table is now sorted by agentId by default
TIBCO EMS
21911: Aggregation of queue/topic caches now using sum instead of average
The compactionGroupBy attribute from the EMS Queue and Topic Extended Caches has
been changed from sum to average.
VMWare vSphere
21805: VMWare Monitor enhanced with Datastore information
VMWare Monitor has been enhanced with the addition of information about
Datastores. The navtree has a new section, Datastores, containing three tables
and a summary display. The Datastores Table lists all the datastores on a server
with their type, capacity, utilization, free space, etc. The Hosts by Datastore
Table and VMs by Datastore Table show which datastores are in use by which hosts
and VMs. The Datastore summary shows information about a single datastore,
including its utilization and free space over time.
21824: VMWare Monitor enhanced with hardware information
VMWare Monitor has been enhanced with the addition of information about hardware
components. The Hosts section of the navtree has a new entry: Host Health. Here
you will find information on each component such as the sensor type, current
reading, and state of the component.
21825: Enhanced VMWare Monitor with cluster information
VMWare Monitor has been enhanced with the addition of information about Clusters.
The navtree has a new section, Clusters, containing the All Clusters Table, which
lists all the clusters on a server with their overall status, HA configuration,
etc. The Hosts table also has a new column showing the cluster to which the host
belongs.
21828: VMWare Monitor enhanced with Host NICs information
VMWare Monitor has been enhanced with the addition of information about Host
NICs. The Hosts section of the navtree has a new entry, Host NICs, which displays
two tables, Physical NICs and Virtual NICs. Here you will find information such
as the link speed of a physical NIC or the IP address of a Virtual NIC.
21831: VMWare Monitor enhanced with vSphere information
VMWare Monitor has been enhanced with the addition of information about vSphere
Events and Alarms. The navtree has a new section, Events/Alarms, containing the
All Events Table and the All Alarms Table. Information about Events includes the
class, type, and message text. Information about Alarms includes the alarm name
and description and the acknowledgement status.
Version 3.6.0 Release Notes
Data Model
21354: EM enhanced to support same service name across multiple groups and environments
Enterprise Monitor has been enhnaced to support using the same service name in
multiple Groups and in multiple Environments. The CMDB Administration display has
been enhanced to support this as well. With the new changes, all entries must
have an Environment. Previously saved cmdb entries that do not have an
Environment can no longer be edited or viewed in the CMDB Administration display
although they are still visible in the Service Summary displays.
Upgrade Notes:
In order to support using the same service name in multiple Environments, the
schema for the RTVCMDB database has been changed to add the Environment column to
the table index. Existing projects from previous releases will continue to work
against an RTVCMDB database without this index. However, if you have an existing
project and you want to take advantage of this new feature, you will need to add
the Environment column to the table index and fill in an Environment for any
entries where it is blank.
Deployment
21748: Fixed an issue where Unix data servers sometimes failed to shut down
In previous releases, using stop_rtv on Unix platforms to stop a TIBCO solution
package data server process sometimes failed due to a spurious rvd process. This
has been fixed.
Distribution
21846: New RTView Monitor for Solace - AMI option
RTView Monitor for Solace is now available pre-installed on an Amazon EC2 Amazon
Machine Image (AMI) running Amazon Linux. It comes pre-installed with a 30-day
license, and is configured to start all RTView processes and supporting services
on restart.
The AMI includes the following application stack for convenience of quick
deployment. Please refer to /home/ec2-user/amibase/MANIFEST.txt for the full
version info:
Oracle Java 8
Node
Docker
MySQL 5.7 (via Docker) for storage of historical data
rtvHostAgent (via Docker) for providing host metrics to RTVMGR
cadvisor-rtview (via Docker) for providing docker metrics to RTVMGR
The scripts used to create the docker containers are included in named
subdirectories under /home/ec2-user/amibase, to be used as templates if you wish
to recreate the containers with your preferred configuration.
The MySQL database data is stored external to the docker container at
/home/ec2-user/amibase/mysql/DATA.
Initial Setup:
You may gain access to the community rtvsolmon-VERSION-YYYYMMDD-community AMI via
sl.com, at http://sl.com/solace-ami-free-trial/.
We recommend starting with an instance from the t2 family, sized according to the
number of Solace appliances you are monitoring. Depending on how much archival
data you wish to store in the database, you may wish to increase your disk size
past the default 8 GB of the AMI.
After creating an instance from the rtvsolmon-VERSION-YYYYMMDD-community AMI, you
will need to SSH to your instance to add the connection properties for your
Solace appliance(s) to
/home/ec2-user/RTViewSolaceMonitor/em-solmon/servers/solmon/sample.properties.
Please see the User Guide for full details.
General
21205: Thin client table objects are now rendered as HTML5
The table objects in the EM thin client have been enhanced to provide improved
filtering, sorting, and other interactive features. See the release note for
20185 for a detailed description of the new table features.
21813: Fixed an issue with group objects and wrapped diagrams
In the previous release, if the first object in a wrapped diagram was defined to
be included in a group, it was not included in the group object. This has been
fixed.
RTVMGR
21739: Enhanced the All JVMs Heatmap display with a Source drop down
A drop down for Source has been added to the All JVMs heatmap display.
21740: Enhanced the All JVMs Table display with a Source drop down
A drop down for Source has been added to the All JVMs Table display.
21754: Fixed an issue preventing JVM Runtime data collection
A bug that prevented collection of JVM Runtime data from several versions of Java
(6, 7 and 8 versions) has been fixed.
21792: Enhanced the All JVMs Table display with more columns
PID, Host Name, Current Heap, and Used Heap have been added to the All JVMs Table
display.
21793: Enhanced the All JVMs Heatmap display
The All JVMs Heatmap display from RTVMGR Solution Package has been enhanced to
include PID, Current Heap, and Used Heap. The last two metrics are also included
in the Metric drop down.
21838: Enhanced RTVMGR in SOLMON Bundle
The RTVMGR configuration has been enhanced in RTView Monitor for Solace. It now
includes monitoring for a MySQL Database, as well as Host and Docker metrics.
For users of the RTView Monitor for Solace AMI version, all connection properties
populate these displays have been pre-configured in the standard
sample.properties file and do not require further configuration.
Users of the On Premise version will not see data in the Host or MySQL displays
unless they choose to configure these.
RTView Core Functionality
21668: Enhanced caches with new initialization option
BACKGROUND:
If a cache's schemaTable property is not specified, then the cache's schema
(column names and types) is copied from the first data table applied to the cache
that contains at least one data row. Data tables that contain columns but no rows
are ignored. In some configurations that can delay cache initialization and cause
undesired behavior in functions and displays attached to the cache.
ENHANCEMENT:
An option has been added to the cache data source to initialize a cache's schema
from the first data table applied to the cache, even if the table contains zero
data rows.
The new option can be specified on the command-line as follows:
-cacheds:storeempty
Or in CACHEOPTIONS.ini as follows:
storeempty true
Or in an rtview properties file as follows:
sl.rtview.cache.storeempty=true
The new option is disabled by default. If the new option is not specified, the
cache's schema is initialized by the first data table containing at least one
data row that is applied to the cache, as in all prior releases. If a cache's
schemaTable property is specified then the cache's schema is always initialized
from that table, as in prior releases, regardless of the new property setting.
Alerts
21677: Enhanced Alert data source
The Alert data source has been enhanced to support a new table named Alert
Definitions. This table contains a row for each alert with the following columns:
Alert Name - the name of the alert
File Name - the name of the file containing the alert definition
Substitutions - the substitutions specified when the alert definition file was
loaded.
21795: Fixed an issue where the Cleared Reason for an alert was incorrect
In prevous releases, the Cleared Reason was sometimes incorrect after an alert
was disabled and re-enabled. This has been fixed.
Data Historian
21699: Enhanced Historian compaction to avoid long delays
The Historian smooth compaction code no longer performs a row count. This
prevents long delays during smoothing by avoiding Select Count(*) calls.
Data Sources
21522: Added new HTTP Data Adapter
The RTView HTTP Data Adapter embeds a HTTP server in RTView to handle data sent
as HTTP Requests. When enabled, the embedded HTTP server is opened on a specified
port, and delegates requests to handlers on given URLs.
The RTView HTTP Data Adapter comes with two default handlers that allow data to
be sent to RTView applications by means of JSON data in a specific format as HTTP
POST requests. This JSON data is mapped to GmsTabularData and can be used to
update RTView function chains or write to RTView caches directly.
RTView can be updated by clients that can send HTTP POST requests, containing
JSON data. Handlers receive the data, map the data to GmsTabularData, and then
perform actions with that data.
The default handlers are contained in the gsmjhttpds.jar. They expect JSON data
in the same format as output by the rtvquery servlet when fmt=json. If no
metadata is present, all columns are defined as string type.
The rtvquery JSON response format is defined as:
{
"metadata":[
{"name":"column 1 name","type":DataType},
... metadata for other columns ...
],
"data":[
{"column 1 name":"row1, column1 value", ... data for other columns in row 1},
... data for other rows ...
]
}
The expected format is a JSON object that can be mapped to GmsTabularData.
The JSON object has two named members: "metadata" describing the metadata (column
names and types for the following data), and "data" containing the data values.
The "metadata" member is a name:value pair where the value is a JSON array of
JSON objects, one per column. The column metadata objects have two members:
"name" and "type". The "name" member is a name:value pair with the column name as
its value. The "type" member is a name:value pair with the column type as its
value. Valid column types are GmsTabularData column types: "string", "long",
"int", "double", "float", "date", "boolean".
The metadata is used to define the column types for the mapped GmsTabularData. If
the metadata member is not present, the mapped GmsTabularData will use "string"
for all columns.
The "data" member is a name:value pair where the value is a JSON array of JSON
objects, one per row of data in the mapped GmsTabularData. Each row is a JSON
object, with member name:value pairs, one per column. Each column member is a
name:value pair, where the name is the name of the column, and the value is the
value of that column for that row.
When the RTView HTTP Data Adapter is enabled (using the default
RTVHTTPOPTIONS.INI file, contained in custom\rtvhttp), it has the following
options set:
Enabled: true
Port: 9099
Root Url: /rtview
Use HTTPS: false
And sets the following RTVHttp Handlers
DEFAULT_CACHE_WRITER
Handler Name:DEFAULT_CACHE_WRITER
Java Class: com.sl.gmsjhttpds.DefaultJsonCacheWriter
Handler URL: /write/cache/
DEFAULT_JSON_HANDLER
Handler Name:DEFAULT_JSON_HANDLER
Java Class: com.sl.gmsjhttpds.DefaultJsonHandler
Handler URL: /json/data/
DEFAULT_JSON_HANDLER is the Default Handler.
The default handlers are contained in the gsmjhttpds.jar. They expect JSON data
in the same format as output by the rtvquery servlet. If no metadata is present,
all columns are defined as string type.
HTTP POST requests to /rtview/json/data/<table_name> will be handled by the
DEFAULT_JSON_HANDLER, which will make the data available via rtvhttp data
attachments using the supplied <table_name>.
Data sent to /rtview/json/data/<table_name> will be output by RTView HTTP data
attachments,
where the "Handler Name:" is set to DEFAULT_JSON_HANDLER, and the "Table Name:"
is specified as the <table name> in the URL.
For Example:
Data sent to /rtview/json/data/MyData1 would be output by RTView HTTP data
attachments, where the "Handler Name:" is set to "DEFAULT_JSON_HANDLER", and the
"Table Name:" is "MyData1".
Likewise, data sent to /rtview/json/data/MyData2 would be output by RTView HTTP
data attachments, where the "Handler Name:" is set to "DEFAULT_JSON_HANDLER", and
the "Table Name:" is "MyData2".
Different data can be input to different function chains by being sent to
different URLs in this way.
HTTP POST requests to /rtview/write/cache/<cache_name> will be handled by the
DEFAULT_CACHE_WRITER, which will write the data to the current table of the named
cache, <cache_name>.
Since the data is written to the cache directly by the handler using the cache
name in the URL,
no data attachments need be configured in this case.
For Example:
Data sent to /rtview/write/cache/CACHE1 would be written to the current table in
cache "CACHE1".
Likewise, data sent to /rtview/write/cache/CACHE2 would be written to the current
table in cache "CACHE2".
Different data can be written to different caches by being sent to different URLs
in this way.
21669: Enhanced caches with new trim option
An option has been added to the cache data source to remove rows periodically
from a cache's history table according to its historyTimeSpan property. By
default, that operation is performed only when new data is applied to the cache.
The new option is useful in rare cases where new data may be applied to the cache
at time intervals (e.g. 1 hour) that are longer than the cache's historyTimeSpan
(e.g. 30 minutes).
The new option can be specified on the command-line as follows:
-cacheds:trimhist
Or in CACHEOPTIONS.ini as follows:
trimhist true
Or in an rtview properties file as follows:
sl.rtview.cache.trimhist=true
If the new option is specified, the historyTimeSpan limit is checked on all
caches every 30 seconds, approximately. The new option is disabled by default. If
the new option is not specified, then the historyTimeSpan limit is only checked
when new data is applied to the cache as in all prior releases.
21851: An issue with the handling of the onTermination event has been fixed
In a previous version, in task 21299, a bug was introduced to the onTermination()
error handling. In some cases, it would cause all data from the microagent that
sent the error to stop coming into RTView. This has been fixed.
Display Server
21772: Extra-bold font in Firefox fixed
In the previous release, objects using font index 7 (sans-serif bold) would
appear extra bold in some versions of Firefox if the display server was
configured to use the extended font feature with arimob.ttf assigned to font 7.
This has been fixed.
21853: Fixed an issue with small numbers not updating to zero in the thin client
In previous releases, the value displayed in an obj_rect_ilv object would not
change if the previous value was greater than zero and less than one, and a value
of zero was applied. This problem occurred only in the thin client and is now
fixed.
Object Library
21675: Enhanced charts with properties for legend text
Properties named legendTextFont and legendTextSize have been added to
obj_trendgraph02, obj_bargraph, and obj_pie to allow the user to choose the font
and size for legend text. Previously the legends on those objects always used
SansSerif at 9 pixels (trend) or 10 pixels (bar and pie) . Those are now the
default values for the new properties.
Scripts
21714: Added Unix scripts to create .war files for a given solution package
The script make_package_wars.sh has been added to the rtvapm distribution. Like
make_package_wars.bat, it is used to create an initial set of war files for a
given solution package. The war files are created in the <package>/webapps
directory. After they are created, update_wars.bat/sh should be run to update
them with the correct port numbers.
The scripts should be run from the <package>/webapps directory. They take the
package name as argument, e.g. "make_package_wars.sh bwmon".
21771: Fixed an issue where ports were misidentified
The rtvapm start/stop/status scripts, when testing the ports of a given server,
would incorrectly identify a port as "taken" whose number contained the server's
number with a leading or trailing digit. (For example finding 33675 in use and
saying 3675 is taken.) This has been corrected.
Service Model
20803: Enhanced EM to support removal of CI's no longer in data server
EM has been enhanced to support removing CI's that are no longer in the backend
data server. In previous releases, CI's were never removed from central EM even
if they were no longer in the backend data server that hosted the data for that
CI. With this change, the CI is removed from central EM when it is deleted from
the data server that is hosting it.
Solution Package
21847: EM enhanced with Sender/Receiver Mode
EM has been enhanced to support a sender/receiver deployment option for all
solution packages. The sender/receiver mode is an EM deployment model where the
sp data that is collected in one data server (the sender) is sent to another data
server (the receiver). The sender directly connects to sp data, populates its
local sp caches then sends that cache data to the receiver. The receiver may or
may not be configured to collect data as well. The sender does not generate
alerts or store history - those are done in the receiver. This is useful in cases
where you need to run a data server to collect sp data on a system that is not
accessible from the system where you are running the ui and/or EM central
servers.
To configure your project for the sender/receiver deployment:
1. Confirm that both the sender and receiver data servers are running the same
version of EM. This is a requirement for the sender/receiver deployment.
2. By default, the receiver will open an rtvagent port to receive cache data from
the sender. Lookup the port number under rtvapm\pck\conf\rtvapm.pck.properties
(where pck is the name of the solution package in your receiver) in this
property:
receiver.sl.rtview.rtvagent.port=1234 (where 1234 is the port number)
3. If that port is already in use, override it in the properties file for your
receiver to set another port:
receiver.sl.rtview.rtvagent.port=5678
4. If your sender will be unable to directly connect to the rtvagent port, deploy
the RTVAgent Servlet and note the url of the servlet.
5. Run the receiver with the receiver property filter command line option:
-propfilter:receiver
6. By default, the sender will send to the port you looked up in step 2 on the
local system. To send to a different port, different system or to the rtvagent
url, override the dataxfr.target property in the properties file for your sender:
sender.sl.rtvapm.dataxfr.target=id=default url=<your url goes here> packages=all
Some examples:
sender.sl.rtvapm.dataxfr.target=id=default
url=http://localhost:8068/miscmon_rtvagent packages=all
sender.sl.rtvapm.dataxfr.target=id=default url=receiverhost:1234 packages=all
Note that the target id is default. This will override the default value.
7. If you want your sender to send data to multiple receivers, add a dataxfr line
for each receiver. Each line must have a unique id. You can optionally list the
packages for which you want to send data (if you want to send different package
data to different receivers) or specify all to send caches for all packages for
which the sender is configured. For example:
sender.sl.rtvapm.dataxfr.target=id=emsmon_target
url=http://localhost:8068/emsmon_rtvagent packages=emsmon
sender.sl.rtvapm.dataxfr.target=id=rtvmgr_target
url=http://localhost:8068/emsmon_rtvagent packages=rtvmgr
sender.sl.rtvapm.dataxfr.target=id=bwmon_target
url=http://localhost:8068/bwmon_rtvagent packages=bwmon;hawkmon;hostbase
Note that each target above has a unique id. You can optionally disable the
default target as follows:
sender.sl.rtvapm.dataxfr.target=id=default packages=__none
8. Run the sender with the sender property filter command line option:
propfilter:sender
UPGRADE NOTES
In previous releases, some of the solution packages supported a sender/receiver
deployment. This task has modified the previous implementation and made it
available to all solution packages. Customers with existing projects from a
previous release that were using the sender/receiver deployment will need to
modify their properties files after upgrading in some cases:
1. If the project properties files overwrite the
sender.sl.rtview.sub=$rtvAgentTarget property, they will need to change it to use
the new sender.sl.rtvapm.dataxfr.target property using the url they had specified
for the $rtvAgentTarget. For example,
sender.sl.rtview.sub=$rtvAgentTarget:'localhost:3172' would be changed to
sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3172 packages=all
2. If the project properties files adds additional targets using the
sender.sl.rtview.cache.config property, they will need to change it to use the
new sender.sl.rtvapm.dataxfr.target property using the url they had specified for
the $rtvAgentTarget and a new unique id. For example,
sender.sl.rtview.cache.config=pck_rtvagent_sender.rtv
$rtvAgentTarget:'otherhost:3172'
sender.sl.rtvapm.dataxfr.target=id=target2 url=otherhost:3172 packages=all
3. If the project properties file did not overwrite either of the above, it just
used the default sender/receiver properties, no changes are needed.
General
21659: Sender/Receiver servlet removed from Custom Solution Package
The rtvagent war is not included in the custom solution project because the
sender-receiver capability is not implemented at this time.
21688: Downgraded bundled Tomcat to version 7.0 due to log errors
The Apache Tomcat server that was included with RTView Monitor for Solace and the
RTView Enterprise Monitor for TIBCO has been changed from version 8 to version 7.
This enabled more monitoring metrics, and addressed the following errors in the
/servers/solmon/logs/dataserver.log file:
ERROR: function <tomcatWebModuleStats04DeltaRate>, Table structure has changed;
cannot save data., type:DELTARATEROWS, file:tomcat_cache.rtv
ERROR: function <tomcatManagerStats77DeltaRate>, Table structure has changed;
cannot save data., type:DELTARATEROWS, file:tomcat_cache.rtv
Solace
21697: Fixed an issue preventing Tomcat from stopping cleanly
A bug that prevented Tomcat from stopping cleanly on UNIX and Linux systems has
been fixed. The CATALINA_PID variable is now defined in the Tomcat setenv.sh
script for these systems.
Also, the start_tomcat.sh script requirement of JAVA_HOME being set in the
environment has been changed to require Java available in the PATH. This change
will allow starting RTView processes at startup before the user environment has
been set.
21786: All Endpoints Table display enhanced with two new check boxes
Two new check boxes to filter by Expired and Down have been added to the All
Endpoints Table display.
21787: All VPNs Table display enhanced with two new check boxes
Two new check boxes to filter by Expired and Disabled have been added to the All
VPNs Table display.
21788: All Clients Table display enhanced with two new check boxes
The All Clients Table display has been enhanced by adding two check boxes to
filter by Expired and Internal. By default, Expired and Disabled check boxes are
unchecked, meaning that only non-expired of the Primary Type Clients are shown.
When checked, all Clients, expired and non-expired as well as Primary and
Internal will be respectively shown.
21789: All CSPF Neighbors Table display enhanced with two new check boxes
Two new check boxes for State Ok and Expired have been added to the All CSPF
Neighbors Table display. By default both check boxes are unchecked, meaning that
all non-expired CSPF Neighbors are shown. When Ok is checked, only CSPF Neighbors
with State=Ok are shown. When Expired is checked all CSPF Neighbors, expired and
non-expired are shown in the table.
21790: All Bridges Table display enhanced with two new check boxes
Two new check boxes for "Disabled" and "Expired" have been added to the All
Bridges Table display. By default the "Expired" check box is unchecked, meaning
that only non-expired Bridges are shown, and the "Disabled" check box is checked,
which shows all Bridges regardless of their Admin State. When "Disabled" is
unchecked, only enabled Bridges with Admin State=Enabled are shown. When
"Expired" is checked, all expired Bridges are shown in the table, in addition to
the non-expired Bridges.
21799: CSPF cache enhanced with Ingress/Egress metrics
Ingress and Egress metrics for CSPF Neighbor Msg Routers have been added.
21800: New CSPF Ingress/Egress metrics are now available
Ingress/Egress metrics for CSPF Neighbor Msg Routers have been stored in history
from the CSPH Neighbor cache.
The table creation SQL statement for supported platforms is located in
solmon/dbconfig directory. The name of the table is SOL_CSPF_NEIGHBOR.
By default, data is being stored in history for this table. To disable storage of
historical data, edit the sample.properties file and uncomment the following
property:
collector.sl.rtview.sub=$SOL_CSPF_NEIGHBOR_TABLE:''
21801: SolAppliances cache enhanced with two new metrics
Two new metrics have been included in the SolAppliances cache. Host Address and
Connected. The later keeps track of the connection state of the Msg Router.
21803: Message Router Summary display enhanced with Host Address
The Host Address has been added to the header of the Msg Router Summary display.
21804: EM enhanced with a new alert
A new alert,SolMsgRouterNotConnected, has been added. This alert will be executed
when the Msg Router is not ready for collecting monitoring data.
21807: SOLMON tables functionality enhanced
All tabular displays now select a row by single clicking and drill down to the
corresponding summary by double clicking. The enhanced displays are the
following:
- Message Routers->All Message Routers Table
- Neighbors-> CSPH Neigbors Table
- VPNs->All VPNs Table
- Clients->All Clients Table
- Bridges-> All Bridges Table
- Endpoints-> All Endpoints Table
- Capacity Analysis-> All Msg Routers Capacity
21808: All Msg Routers Heatmap display has been enhanced
Two check boxes, "Connected" and "Expired", have been added to the All Msg
Routers Heatmap display.
21809: Enhanced some displays to correctly align their contents
The Msg Router and the Capacity displays for the corresponding menu tags have
been enhanced to correctly align their contents.
21810: Enhanced EM with a new page for CSPF Neighbors
The CSPF Neighbor Msg Router displays have been organised under a new menu tab
named Neighbors.
21812: Msg Router VPN Activity display has been enhanced
The Msg Router VPN Activity display has been enhanced to show the most active
VPNs sorted by Client Connections, Ingress/Egress bytes / sec and Pending Msgs.
The number of VPNs shown is adjusted to the height of the window.
21814: EM enhanced with new metrics
In Msgs /sec and Out Msgs / sec have been added to the SOLMON-MSGROUTER CI Type
as Key Metrics.
21817: Trend Value precision is now one decimal value in Client Summary display
The precision of the trend values has been changed to one decimal value in the
Client Summary display.
21827: Enhanced EM by standardizing colors across multiple displays
The following displays have been improved to follow RTView EM standards on color
trends:
- Message Router Capacity Summary
- Message Router Capacity Trends
- Single Message Router Summary
- Single Bridge Summary
- Single Client Summary
- Single Endpoint Summary
- Single VPN Summary
TIBCO BusinessEvents
20670: About and Version Info displays added to TBEMON
Two new displays have been added to TBEMON: an About display that shows general
information about the running application, and a Version Info display that
provides detailed information about the libraries used for each of the TBEMON
applications.
TIBCO BusinessWorks
21723: Fixed a bug on the All Engines table where engines misreported their statuses
When you drilled down to an engine from the All Engines table and returned to the
table, the Active Processes column would display NaN or Not Available for every
engine other than the one to which you drilled down. This has been fixed.
Note: the Active Processes column will display NaN or Not Available for any
engine whose status is STOPPED.
21781: Solution packages using Hawk enhanced with custom setup scripts for Unix
The solution packages that use the Hawk data adapter include bwmon, bw6mon,
amxmon, and hawkmon. On Unix systems they require that Tibco RV be included in
the environment variable LD_LIBRARY_PATH. Specifically, RV_ROOT must be defined
and LD_LIBRARY_PATH must contain $RV_ROOT/lib.
These packages now include custom_setup.sh files, which are automatically
executed when rtview programs start up. These files will modify LD_LIBRARY_PATH
correctly, whether it was previously defined or not.
21796: The monitor has been enhanced to support OSGi
RTView monitor for Tibco BusinessWorks has been enhanced with the ability to
monitor BW applications deployed in BW6 AppSpaces using the new RTView OSGi
Plugin for TIBCO BusinessWorks. An application using the OSGi plugin does not
require the use of Hawk for monitoring purposed.
For information on enabling and configuring the OSGi Plugin please refer to the
documentation and/or the online README file.
21797: RTView enhanced to monitor BW inside a Docker container
RTView monitor for Tibco BusinessWorks has been enhanced with the ability to
monitor BW applications deployed in Docker containers, using the new RTView OSGi
Plugin for TIBCO BusinessWorks. For information on enabling and configuring the
OSGi Plugin please refer to the documentation and/or the online README file.
21843: Data Types on the Monitor Process table have been optimized
In the BW6 Monitor Process table the columns Average Execution Time and Average
Elapsed Time were displayed as type Long, where they should be Double. This has
been corrected.
21844: RTView enhanced to monitor BW in PCF
RTView monitor for Tibco BusinessWorks has been enhanced with the ability to
monitor BW applications deployed in Pivotal Cloud Foundry containers, using the
new RTView OSGi Plugin for TIBCO BusinessWorks. For information on enabling and
configuring the OSGi Plugin please refer to the documentation and/or the online
README file.
21867: Fixed a column formatting issue in BW6
The BW6 AppNode table "Up Since" column actually represents the "uptime", or time
the appnode has been running, but it was not formatted as a duration. This has
been corrected.
21868: Fixed the default sort order for all BW6 tables
The display tables in the BW6 monitor are now sorted by default according to
their index columns.
21893: History tables BW6_APPS and BW6_APPSLICES no longer created
The Bw6App and Bw6AppSlice caches were incorrectly creating database tables.
These caches do not store their own history; their history metrics come from
aggregations of the Bw6Process cache history.
The BW6_APPS and BW6_APPSLICES tables have been removed from configuration files
and database schemas.
TIBCO EMS
21755: Added new filter for EMS connections by User
A new filter by User Name has been added to the EMS Connections for Server
display.
21848: EM enhanced with a new alternate alert for when EMS Consumers are stuck
An alternate alert to detect when EMS Consumers are stuck has been developed. The
reason for that is the current emsConsumerStalled alert is based on the
difference between:
totalMsgSentCount > totalMsgAckCount AND elapsedSinceLastAck > the alert
threshold.
However, this may not be an accurate measure of consumer stalled for some
customers in which all processed messages might not be acknowledged. In these
scenarios, the following condition is more appropriate:
currMsgSentCount > 0 AND elapsedSinceLastAck > the alert threshold
The new alert is called emsConsumerStuck.
Version 3.5.0 Release Notes
Alerts
21663: New MQ alert for channel status has been added
A new alert, MqChannelInactive, has been created. This alert will be executed
when non-system channels have the Status metric set to a value different than
RUNNING.
General
21640: New Diagram Generator has been added
RTView Enterprise Monitor has been enhanced with a new Diagram Generator package.
The Diagram Generator allows you to store node, link, and layout information in a
database and generate diagrams based on this information. The CUSTOM tab in the
emsample project has been enhanced to include the Diagram Generator
administration displays for creating your own diagrams as well as a sample
diagram.
Navigation
20951: Navtree now correctly follows user
Although the All Hawk Agents Table drills down to the Host Summary display for
that agent, the Host Summary did not become highlighted in the navtree. This has
been fixed.
RTVMGR
21554: Fixed an issue with JVM Summary display
A bug that prevented Start Time and Up Time to be available in the JVM Summary
display when multiple versions of Java were used has been fixed.
These two fields will be missing from the display when the process is executed
with Java 1.6. To fix the solution, upgrade to a higher version.
RTView Core Functionality
Data Historian
21683: Fixed a retention / compaction issue
When a mixture of simple retention and retention via advanced compaction was
used, only the first table using simple retention was processed for retention.
This has been corrected.
Data Server
21648: Enhanced rtvquery servlet to handle +/- infinity and NaN
In prior releases, the rtvquery servlet encoded the numeric values NaN (not a
number), positive infinity, and negative infinity in a json or jsonp response as
"" (an empty string). This makes it impossible for a client application to
distinguish between those three values, when processing a json or jsonp response.
In this release, the rtvquery servlet supports a URL parameter to encode NaN,
positive infinity, and negative infinity in a json or jsonp response as the
strings "NaN", "Infinity", and "-Infinity" respectively. The new parameter is
named "nanok" and a value of true specifies the new behavior. The default value
is false. For example, the following URL specifies the new option:
http://somehost/rtvquery/cache/MyCache/current?fmt=json&nanok=true
The other response formats (xml, xmlrtv, js, text) supported by the rtvquery
servlet have always used NaN, Infinity, and -Infinity. That behavior has not been
changed, so the nanok=true parameter is not needed to make those values appear in
the response in those formats.
21684: Enhanced rtvquery servlet to support CORS
The rtvquery (REST) servlet has been enhanced to support CORS (Cross-Origin
Resource Sharing).
A new optional property named AllowOrigins may now be specified in
rtvquery.properties. The property value is a string that specifies which domains
are allowed to send requests to the servlet. By default AllowOrigins is blank,
which indicates that requests are allowed only from the same domain that hosts
the rtvquery servlet (as in all prior releases). Specify a value of * to indicate
that requests are allowed from any domain:
AllowOrigins=*
Or, specify a comma-separated list of the domains which may make requests, in
this format: protocol://hostname_or_address:port
For example:
AllowOrigins=http://192.168.20.11:3456,https://SomeHost:6789
Data Sources
21646: A new servlet has been added for use with the HTTP Data Source
A new RTVPost Servlet has been added to RTView. This is a proxy servlet for use
with the HTTP Data Source. It is useful for cases where an application cannot
post directly to the application running the HTTP Data Source due to security or
post access limitations. For RTView Enterprise Monitor users, this is useful for
the NODEMON and DOCKERMON solution packages in the case where your node or docker
application is outside the firewall and is limited to posting to port 80.
The RTVPost servlet is in RTV_HOME\servlets\rtvpost\rtvpost.war. The following
properties are supported in rtvpost.properties:
proxyHost: The http host to which to post. The default is localhost.
proxyPort: The http port to which to post. The default is 3275.
proxyPath: The path to which to post. This is commented out by default.
RTView Core users can modify RTV_HOME\servlets\rtvpost\rtvpost.properties and run
the make_war script to rebuild the rtvpost.war file.
RTView Enterprise Monitor users can run RTVAPM_HOME\common\bin\make_rtvpost_war
from their project\webapps directory as follows:
make_rtvpost_war appname -host:somehost -port:someport
Where appname is the name of your application. The host and port options are
optional. If not specified, the defaults above will be used. The appname argument
is used to name the war file, appname_rtvpost.war. To modify the proxyPath, copy
RTV_HOME\servlets\rtvpost\rtvpost.properties to your webapps directory, modify
the proxyPath value and then run make_rtvpost_war as described above.
To use the rtvpost war file, deploy it to your application server. HTTP posts
should use the URL for rtvpost and will be forwarded to the specified proxyHost
and proxyPort.
21658: HTTP REST DS
The RTView HTTP REST Data Adapter, is an extensible data adapter that allows
RTView to interact with REST APIs by means of HTTP Requests.
The Data Adapter provides an extensible framework with RTView, using the Apache
HTTP Client to Make HTTP requests.
Handlers are used to abstract the process of making an HTTP request.
The RTVHttpRest adapter supports data attachments which will execute an HTTP
Request, to get an HTTP Response, which can then be processed to extract a data
table for use within RTView.
The data attachments specify the handlers used for the various parts of making
and processing an HTTP Request and Response.
Default Handlers are available, and the user can implement custom handlers to
extend functionality.There are examples of custom handlers in the
custom/rtvhttprest directory of the RTView installation.
Abstracting the HTTP Request / Response sequence in RTView
Consider the following simplified execution of an HTTP Request using the Apache
HTTP Client library which handles the response and updates a data attachment with
GmsTabularData:
// Get a HTTP Client
CloseableHttpClient httpClient = getHttpClient(dataObj);
// Get a HTTP Request
HttpUriRequest request = getRequest(dataObj);
// Execute request using client to get response
CloseableHttpResponse response = httpClient.execute(request);
// Handle response to get Tablular Data
GmsTabularData table = getTabularData(response, dataObj, ...)
// Update the data attachment(s)
ds.storeData(dataObj, table);
The above code can be used to interact with any HTTP REST API.
The processing that varies has been abstracted out and can be supplied by
pluggable handlers (java classes) which implement the appropriate interface.
These can then be specified in the data attachment for the given HTTP Request and
must be on the classpath of the RTView application at run time.
The Attatch to RTVHttpRestData dialog contains the following fields:
- Client Handler: A text field used to specify the fully qualified name of the
java class used to implement the ClientHandler interface
(com.sl.gmsjhttprestds.ClientHandler).
The ClientHandler returns a CloseableHttpClient (client) that is used to execute
a request (returned by a RequestHandler implementation) to return a response that
is processed by a ResponseHandler.
The DefaultClientHandler (com.sl.com.sl.gmsjhttprestds.DefaultClientHandler) can
be used to return a default client. For more sophisticated client interactions a
custom ClientHandler implementation can be written and used. See the RTView
javadocs for more details.
There are examples of custom handlers in the custom/rtvhttprest directory of the
RTView installation. Typical uses of a custom ClientHandler implementation would
be to set header
fields required to interact with a REST API, e.g. Authentication tokens
- Request Handler: A text field used to specify the fully qualified name of the
java class used to implement the RequestHandler interface
(com.sl.gmsjhttprestds.RequestHandler).
The RequestHandler returns a HttpUriRequest (request) that is executed by a
client handler to return a response that is processed by a ResponseHandler.
The DefaultGetRequestHandler
(com.sl.com.sl.gmsjhttprestds.DefaultGetRequestHandler)
can be used to return a default HTTP GET request. Default request handlers are
provided for all the HTTP request operations.
Typical uses of a custom RequestHandler implementation would be to set header
fields required to interact with a REST API (e.g. Authentication tokens) or
process information supplied in the request string argument to enhance the
contents of a request if it cannot be specified by the request URI alone.
For more sophisticated request handling, a custom RequestHandler implementation
can be written and used.
See the RTView javadocs for more details.
- Request: A Text field used to specify the URI used to make the request executed
by the request handler.
The Request Handler may use the request as is, or process it to extract
additional information used in the request.
The format of a URI, used by an HTTP
request:[//[user:password@]host[:port]][/]path[?query][#fragment]
- ResponseHandler: A text field used to specify the fully qualified name of the
java class used to implement the ResponseHandler interface
(com.sl.gmsjhttprestds.ResponseHandler)
The ResponseHandler returns a GmsTabularData that is extracted by the
RequestHandler from the response as a result of a request obtained from a
RequestHandler being executed by a client obtained from a ClientHandler.
The DefaultResponseHandler (com.sl.com.sl.gmsjhttprestds.DefaultResponseHandler)
can be used to obtain default GmsTabularData containing information from the
response.
Typical uses of a custom ResponseHandler implementation would be to extract
GmsTabularData from a given response.
For more sophisticated response handling a custom ResponseHandler implementation
can be written and used.
See the RTView javadocs for more details.
- Column(s): A combo box for specifying the names of the table columns to include
in the result, or * (the default) for all columns.
- Filter Rows: A checkbox to enable the following 2 fields:
- Filter Column: The name(s) of the columns(s) to which the Filter Value should
be applied.
- Filter Value: The filter value(s) to be applied to the filter columns.
See the RTView documentation for details on the format to be used for specifying
filter values. Note that wild cards and regular expressions are not supported in
the Filter Value field. For that type of filtering, various standard RTView
functions are available.
21680: Fixed an issue with encrypted database passwords
In version 6.7, a problem was introduced that caused an error to print to the
console for sl.rtview.properties.databasePassword property if the property value
was encrypted. In the error message, the databasePassword in the error was shown
in plain text. This problem has been fixed.
Functions
21647: ArrayIndexOutOfBoundsException has been fixed
In previous releases, it was possible to get an ArrayOutOfBoundsException when
closing a display containing a composite that was configured with the
substititons property. This has been fixed.
General
21638: Firefox now displays button states the same as other browsers
In the thin client in Firefox, a button control (obj_c1button) will now appear
depressed when the user clicks on it, as it does in other browsers.
Object Library
21629: Style sheets are now correctly applied
In previous releases, the style sheet was not applied correctly to the icons in
the object grid. The behavior was different in the viewer and the thin client. In
the thin client, the style sheet was never applied to the icons in the object
grid. In the viewer, the stylesheet properties always overrode the property
values specified in iconProperties.
This has been fixed so that both the viewer and thin client behave as follows: If
a property value is specified in iconProperties, this value takes precedence over
the style sheet value. Properties for which no value was specified in
iconProperties will use the style sheet values.
If you have an object grid in a display from a previous release that counts on
the previous behavior, you have 2 options:
1. Modify the iconProperties value for your object grid so that all properties
that should override the style sheet are specified and no properties that should
not override the style sheet are specified.
2. Use the following command line option to revert to the old behavior:
-objgriduseoldss
21666: Tree Grid support added to Table objects
The table object (obj_table02) now supports a "Tree Grid" mode. In this mode, the
first column of the table behaves as a tree, allowing table rows to be
expanded/collapsed in groups according to a hierarchy defined by the index
columns in the data table.
The new mode can be configured in the builder, but the feature is only fully
implemented in the thin client.
Three properties have been added to obj_table02 to support the new mode. These
are visible only if webGridFlag is checked:
webTreeGridFlag: check this to enable the new mode
webTreeLabelColumn: the name of the column to be added as the tree (first) column
of the table
webTreeAggregateColumns: a list of column names and calculations to be applied to
data columns in parent rows
INDEX COLUMNS:
To use the new mode, the table object's indexColumnNames property must be
specified. Each index column in the data table (attached to the valueTable
property) defines a level in the tree -- the first index column specifies the
values for the top level of the tree, the second index column specifies the
values for the second level in the tree, and so on.
For example, here is a portion of a data table containing Major League Baseball
(MLB) standings. The index columns are named League, Division, and Team:
League Division Team W L
American East Red Sox 93 69
American East Blue Jays 89 73
American Central Indians 94 67
American Central Tigers 86 75
American West Rangers 95 67
American West Mariners 86 76
National East Phillies 95 67
National East Mets 87 75
National Central Cubs 103 58
National Central Cardinals 86 76
National West Dodgers 91 71
National West Giants 87 75
(Note: The full MLB table has 5 teams in each division).
The index column values in the above data table can be used to create a 3 level
tree, as follows:
> American
> East
Red Sox
Blue Jays
> Central
Indians
Tigers
... etc ...
> National
> East
Phillies
Mets
... etc
DATA TABLE FORMAT:
When tree grid mode is enabled, the data table is automatically converted to the
format required for the mode, as follows:
1) A row is added to the table for each parent level in the tree.
For example, when the MLB table above displayed in tree grid mode, it will
contain 8 additional "parent" rows which don't appear in the original table.
These rows are added for the parent levels in the tree, one for the American
League, one for the National League, and one for each of the 3 divisions in each
league (American East, American Central, American West, National East, National
Central, National West). The data columns (W, L) for each of the parent rows is
assigned a value of zero. This is because there is no data in the original table
for the parent rows.
2) A new column is added to the beginning of the table to display the tree
levels. By default the column is named "Node Label" but a different name can be
specified in the webTreeLabelColumn property.
3) Columns named Node ID and Parent ID are added to the table. These define the
parent-child relationships in the table, and are used by the thin client to
construct the tree. These columns are automatically hidden, via the columnsToHide
property.
AGGREGATION:
As mentioned earlier, the parent rows added to the data table will contain a zero
in each numeric data column. The webTreeAggregateColumns can be configured to
show aggregated values (sum, min, max, or average) in those data columns. The
property expects a list of column name, calculation pairs, with semicolons
between the pairs.
For example, to show the sum of the W and L columns of the child rows in each
parent row of the MLB table above:
webTreeAggregateColumns: W,sum;L,sum
With that configuration each Division row will show the sum of its teams W and L
columns, and each League will show the sum of its divisions W and L columns.
FILTER & SORT:
In the thin client, all of the web grid filter and sort features are available,
by clicking on the column header. There are a few differences to note.
The column filter menu can be used to hide rows in the table. However, this does
not affect the aggregate calculations (if any), since they are always performed
on all rows in the table, visible or not. Also, a parent row will be shown if any
of its children pass the filter test, even if the parent row itself does not pass
the filter. For example, if the filter Team = Phillies is applied to the MLB
table, only one row passes that filter but the table will display both of that
row's ancestor rows, for a total of 3 rows:
> National
> East
Phillies
The column sort feature in the thin client applies the sort within each level.
That is, the sort will reorder rows within a tree level but won't move rows
between levels of the tree, and parent rows will still appear above the rows of
their children.
Limitations on webTreeGrid mode:
- The webTreeGridMode behavior only works in thin client, and only in desktop
browsers that support the web (HTML5) grid. In all other cases the table will not
display a tree column.
- The webTreeGridMode does not support server-side paging, filtering & sorting.
This means that webTreeGridMode mode does not perform well on large data tables,
because the entire data table must be downloaded to the browser. For best results
it should only be applied to data tables with 1000 rows or fewer. The intended
use is to display the contents of an indexed cache table, with fewer than 1000
rows.
- The export to html/excel/pdf feature does not recognize webTreeGridMode and
instead exports the entire table.
Advanced use:
If the data table attached to valueTable already contains rows for the parent
levels of the tree, with columns named exactly "Node ID" and "Parent ID" that
uniquely identify each row and its parent row, then the table won't be converted
as described above. In this case the column to be used as the tree column should
be identified by the webTreeLabelColumn property.
Scripts
21579: Fixed an issue with the scripts that make .war files
The new make_*_war scripts on Windows would change comment lines when changing
host and port values in properties files. This has been corrected.
21681: Optimized the scripts that make .war files
The scripts used to make war files for the servlets now check that RTVAPM_HOME is
defined before proceeding.
Solution Package
21687: EM enhanced with properties filter collector
The properties filter collector has been added to all cache configuration
properties throughout all of RTView EM. This enhancement will allow the
properties related with cache configuration to exist exclusively on the Data
Server processes.
21692: Fixed an issue with proper shutdown of HSQLDB
Previously the HSQLDB instances provided with the following solution packages
were not able to shut down cleanly using the stop_hsqldb command.
MONGOMON
DOCKERMON
NODEMON
This has been fixed.
General
21628: Custom project has been improved
The custom project in projects/emsample has been updated and its documentation
has been corrected.
Note the instructions for running the sample JMX app have changed, and now apply
to Unix as well as Windows.
IBM Websphere Application Server
21591: Fixed an issue with the All Servers Detail display
A bug that prevented the correct population of the All Servers Detail display in
a sender/receiver configuration has been fixed. This display has also been
enhanced to horizontally adjust the height of the four tables proportionally to
the window size.
MS SQL Server
21574: New Solution Package for MS SQL Server
The MSSQLMON Solution Package has been added to RTView EM.
MS SQL Server Jar location
--------------------------------------------------------------------------------
Provide the correct full path to the MS SQL Server JDBC jar in your
sample.properties file:
collector.sl.rtview.cp=%RTVAPM_HOME%/../ext/mssqlserver/sqljdbc4-4.0.jar
Connection properties
--------------------------------------------------------------------------------
Replace ConnStr, myUser, myPassword with your credentials. Notice that second
line
should match the substitutions $mssqlConnString with the sqldb connection name
(ConnStr):
collector.sl.rtview.sql.sqldb=ConnStr myUser myPassword
jdbc:sqlserver://MyIP:1433 com.microsoft.sqlserver.jdbc.SQLServerDriver - false
false
collector.sl.rtview.cache.config=mssql_sources.rtv $mssqlConnString:ConnStr
Historical Data
--------------------------------------------------------------------------------
Enabled tables are: MSSQL_SERVERSTATS and MSSQL_PERFCOUNTERS.
To disable them, add the following lines to your sample.properties file:
collector.sl.rtview.sub=$MSSQL_SERVERSTATS_TABLE:''
collector.sl.rtview.sub=$MSSQL_PERFCOUNTERS_TABLE:''
Disabled tables are: MSSQL_DBSIZES, MSSQL_SERVERTABLESIZES, and MSSQL_WAITSTATS.
To enable them, add the following lines to your sample.properties file:
collector.sl.rtview.sub=$MSSQL_SERVERDBSIZES_TABLE:MSSQL_DBSIZES
collector.sl.rtview.sub=$MSSQL_SERVERTABLESIZES_TABLE:MSSQL_SERVERTABLESIZES
collector.sl.rtview.sub=$MSSQL_WAITSTATS_TABLE:MSSQL_WAITSTATS
Cache Collection Periods (in sec)
--------------------------------------------------------------------------------
Update Period for MssqlServerDatabaseSizes cache:
collector.sl.rtview.sub=$mssqlDBSizeQueryInterval:300
Update Period for MssqlPerfCounters cache:
collector.sl.rtview.sub=$mssqlPerfCounterQueryInterval:15
Update Period for MssqlServerStats cache;
collector.sl.rtview.sub=$mssqlSystemStatsQueryInterval:15
Update Period for MssqlServerTableSizes cache:
collector.sl.rtview.sub=$mssqlTableSizeQueryInterval:300
Update Period for MssqlWaitStats cache:
collector.sl.rtview.sub=$mssqlWaitQueryInterval:15
Not used at the moment:
collector.sl.rtview.sub=$mssqlQueryInterval:15
collector.sl.rtview.sub=$mssqlQueryPerfQueryInterval:15
Sender/Receiver
--------------------------------------------------------------------------------
The dataserver to be used is MISCMON.
The receiver should be executed with -propfilter:receiver property
Sender: Option 1
Uncomment the following lines on the sender if you will connect through IP and
port
The sender should be executed with -propfilter:sender property
sender.sl.rtview.sub=$rtvAgentName:MyAgentName
sender.sl.rtview.sub=$rtvAgentTarget:'YourReceiverIpAddress:3972'
Sender: Option 2
Uncomment the following lines on the sender if you will connect through agent
servlet
The sender should be executed with -propfilter:sender property
sender.sl.rtview.sub=$rtvAgentName:MyAgentName
sender.sl.rtview.sub=$rtvAgentTarget:'http://publicIPAddress/mssqlmon_rtvagent'
CI Types
--------------------------------------------------------------------------------
MSSQL-INSTANCE
Index: DbConn
Key Metrics
--------------------------------------------------------------------------------
SQL CPU Used
Memory In Use (%)
Alerts
--------------------------------------------------------------------------------
MssqlInstanceSqlCpuUsedHigh
The percentage of CPU utilization on SQL processing has exceeded its threshold.
Default thresholds are: Warning 10%, Alarm 15%
MssqlInstanceUsedMemoryHigh
The percentage of memory used by the SQL Server has exceeded its threshold.
Default thresholds are: Warning 65%, Alarm 85%
MssqlInstanceDeadlocksDetected
The number of current deadlocks has exceeded its threshold.
Default thresholds are: Warning 1, Alarm 2
MssqlInstanceLatchWaitsHigh
The number of current latch waits has exceeded its threshold.
Default thresholds are: Warning 15, Alarm 30
MssqlInstanceLockWaitsHigh
The amount of seconds on lock waits has exceeded its threshold.
Default thresholds are: Warning 15, Alarm 30
MssqlInstancePacketErrorsDetected
The amount of current packet errors has exceeded its threshold
Default thresholds are: Warning 1, Alarm 2
Node.js
21593: Enhanced Node Requests columns
In the All Requests Table, two columns have been added and two have been renamed.
The previous column "Requests Per Sec" is now "Recent Requests Per Sec", and "Avg
Response Time" is now "Recent Avg Resp Time". In both cases their respective data
displayed values from the most recent polling period.
The two new columns are "Requests Per Sec" and "Avg Response Time (ms)". These
columns display their respective data as averaged since the monitored server
began running.
The renamed columns will continue to display the same data as in the previous
release. Nothing has changed here, other than the column names.
The new columns display their respective metrics as averaged during the lifetime
of the server.
21594: Nodemon agent enhanced
A trim() API function has been added to the Nodemon agent which allows for more
accurate grouping and analysis of URL response times.
21595: Enhanced Request URL column
With this release, query strings are removed from URLs before being added to the
All Requests Table. This allows for more accurate grouping of similar URLs.
Solace
21335: Support for Solace VMRs has been added
We now support monitoring of Solace VMRs.
21587: Enhanced performance of SOLMON caches
To improve performance, an unneeded reference to the SolEndpoints cache has been
removed from the function chain that populates the SolAppliances cache.
21589: SEMP version is now parameterized
To support the Solace VMR, the SEMP version has been parameterized with a
substitution that will be included in the connection parameters to each physical
or virtual Solace Message Router.
The sample.properties file contains one example of the connection properties that
includes the connection string name, $solConn, and the SEMP version,
$solSempVersion. In the case of the VMR, the lowest version supported is 7.1.1.
For the physical appliance, the lowest version supported is 6.2.
21603: Fixed an issue with heatmap metrics
A bug that prevented the drop down "Metric" from the All Msgs Routers Heatmap and
the Al VPNs Heatmap to work correctly has been fixed.
21607: Enhanced various SOLMON displays
The main table shown in the Message Router-> Message Spool Table display now is
anchored to the bottom of the window. Also the Message Router->Msg Router VPN
Activity now has vertical resizing to adjust proportionally the height of the
three graphs being shown.
21615: Enhanced SOLMON to differentiate between an Appliance and a VMR
The Solace platform has been added to the Single Message Router Summary. This
information is located in the title of the upper left dividing rectangle in the
display.
21624: Enhanced trends on multiple SOLMON displays
Trends from Message Router Summary and Single VPN Summary have been enhanced to
include one decimal point on mouse over texts.
21655: Support Sender/Receiver architectures for Solace VMR
The sender/receiver configuration has been implemented for SOLMON.
There are two options for the sender configuration:
1. Connecting to the receiver data server through IP address and port.
This option requires accessibility between sender and receiver.
2. Connecting to the receiver data server through the agent servlet.
This option requires an application server running in the receiver with
solmon_rtvagent deployed.
Instructions for both are below:
Step 1. Determine SEMP version of the Solace Appliance or VMR
Use SolAdmin and set its logging properties to INFO. To do so, follow these
steps, which assume you have installed SolAdmin on Windows:
Step 1.1. Go to the location where SolAdmin was installed.
E.g. C:\Program Files (x86)\SolAdmin\
Step 1.2. Look in the bin directory and open the log4j.properties file in a text
editor
Step 1.3. Follow the instructions that are at the beginning of the file, which
essentially explain that you should change the logging level to DEBUG and provide
the full path to the logging file. For instance, if your directory is C:\Logs,
your file should look like the example below. Leave the rest of the file
unchanged.
log4j.appender.A1.File=C:\Logs\soladmin.log
# Categories
log4j.category.com.solacesystems=DEBUG, A1
Step 1.4. Restart SolAdmin
Step 2. Manage the Solace Appliance or VMR by using SolAdmin and searching for
the SEMP version
Step 2.1. Add as a Managed Router your instance
Step 2.2. Go to soladmin.log and search in the SEMP requests for the semp-version
tag
Step 3. Add the correct SEMP version to the connection properties of your SOLMON
properties file
Edit your SOLMON sample.properties file, and replace the value of $solSempVersion
with the one from the log file. Replace any underscores in the value from the log
file with dots.
For instance, 6_2 will become 6.2.
collector.sl.rtview.http.conn=__name=YourVMR url=http://YourIP:8080/SEMP
username=yourUser password=yourPwd
collector.sl.rtview.cache.config=sol_cache_source.rtv $solConn:YourVMR
$solSempVersion:7.2VMR
Step 4. Add the sender properties in your SOLMON properties file
Option 1: Connecting to the receiver through IP address and port
# Sender properties
sender.sl.rtview.sub=$rtvAgentName:MyVMRInstance
sender.sl.rtview.sub=$rtvAgentTarget:'YourReceiverIpAddress:4172'
Option 2: Connecting to the receiver through the agent servlet
# Sender properties
sender.sl.rtview.sub=$rtvAgentName:MyVMRInstance
sender.sl.rtview.sub=$rtvAgentTarget:'http://publicIPAddress/solmon_rtvagent'
Step 5. Start the sender
Go to your project directory and start the sender as follows:
rundata.sh/.bat -properties:sample -propfilter:sender
Step 6. Go to the host where your receiver will run
Step 6.1. Start the receiver
Go to your project directory and start the receiver as follows:
rundata.sh/.bat -propfilter:receiver
Step 6.2. Verify that you are collecting data from the sender by
opening a browser window to reach your deployed SOLMON instance.
NOTE: Syslog data won't be sent from the senders. You'll need to configure syslog
data from your VMRs and appliances on the receiver host.
21693: Enhanced SOLMON syslog event collection
To minimize performance in the SOLMON Solution Package in a sender/receiver
configuration, Syslog events are not sent.
In this configuration, Syslog events for the Solace Message Router or VMR should
not be collected on the sender host. Instead, these events should have to be
redirected to the receiver host.
21695: Fixed a properties file referencing issue in SOLMON
A bug that allowed references from other Solution Packages to exist in SOLMON has
been fixed.
TIBCO ActiveSpaces
21089: Fixed a cosmetic issue in TASMON
The Heatmap/Table buttons on the All Members By Space table and heatmap displays
had nonstandard borders. This has been corrected.
21581: Fixed an error in TASMON
in tasmon/conf/rtvapm.tasmon.properties, there was an error in a property:
collector.sl.rtview.sub=$TAS_SEEDERS_TABLE:
Should have been:
collector.sl.rtview.sub=$TAS_SEEDERS_TABLE:''
This caused errors of the form:
SQLException: ORA-00942: table or view does not exist
while attempting: insert into "$TAS_SEEDERS_TABLE"
This has been corrected.
TIBCO BusinessEvents
21568: New CI type added under TBEMON
A new CI Type, TBE-NODE, has been associated to TbeNodeConnectionLoss,
TbeNodeObjectTableSize and TbeNodeObjectTablleExtIdSize alerts. This new CI Type
solves the issue of blank CI and Primary Service when these alerts were executed
under EM.
TIBCO BusinessWorks
21619: Limited engines no longer marked with red background
The BWMON Single Engine Summary display indicates a stopped engine with a red
background. This was incorrectly applied to limited engines as well. This has
been corrected
21620: Fixed alignment problem in certain displays
The background of some BWMON displays were slightly overlapping the display
objects. This has been corrected.
21627: Engines no longer incorrectly marked as stopped
The BW Engine dropdown lists indicate stopped engines by "(X)". This was
incorrectly applied to limited engines as well. This has been corrected.
Version 3.4.0 Release Notes
Configuration
20690: Added an update_wars script for miscmon
In rtvapm/projects/emsample/servers, the individual servers have "update_wars"
scripts that can be used to make server-specific war files. The "miscmon" server
directory now has update_wars scripts as well.
Deployment
21600: Emsample central servers now support rtvquery servlets
In the emsample project, the script make_all_wars in emsample/webapps will now
also make emsample_rtvquery.war.
Navigation
21399: Customization of default EM tabs now supported
EM has been enhanced to support customizing the order and visibility of the tabs
in emsample either globally or per-role. By default, EM will show the following
tabs in this order:
SERVICE TREE, SERVICE VIEWS, COMPONENTS, ALERTS, ADMIN
These tabs are followed by all user defined tabs from rtv_custom.xml. The
$rtvNavTabList substitution supports a comma separated list of Tab ID's which
will override the default tab list. The initial display will be set to the first
item in the navtree for the first tab in the list. For example, the following
property in central.properties will limit the tabs to Custom, SERVICE TREE and
ADMIN, in that order:
uiprocess.sl.rtview.sub=$rtvNavTabList:Custom,CMDB,Admin
To specify different tabs per role, add this substitution to your roles.xml set
to the list of tabs for that role. For example, the following will set the tabs
for the admin role to ADMIN, SERVICE TREE, ALERTS in that order:
<role>
<name>admin</name>
<displays>
<include>ALL</include>
</displays>
<sub name="$rtvNavTabList" value="Admin,CMDB,Alerts"/>
</role>
Roles that set $rtvNavTabList to blank will get the default tabs (listed above).
Roles that do not set $rtvNavTabList will get the global value set in
central.properties. If no value was set in central.properties, it will get the
default tabs.
These are the Tab IDs for the standard EM tabs:
Tab ID - Tab Label
============
CMDB - SERVICE TREE
Service - SERVICE VIEWS
Components - COMPONENTS
Alerts - ALERTS
Admin - ADMIN
For user defined tabs, use the value in the TabID column of the TabTreeSelection
table in rtv_custom.xml.
RTVMGR
21553: OS Version displays correctly on JVM Summary display
The upper area of the COMPONENTS, Processes > JVM Processes > SingleJVM > JVM
Summary display has been enhanced to avoid the "OS Version" string from
overrunning the allocated width.
RTView Core Functionality
21524: Format Table Columns function enhanced to preserve numeric column types
The Format Table Columns function supports a new argument, described below, to
control its treatment of numeric columns.
Format Mode - If 0 then all numeric columns are converted to strings in the
result, using the local default format for any numeric columns not specified in
Column Format(s). If Format Mode is nonzero, then only the numeric columns
specified in Column Format(s) are formatted, all other numeric columns in the
table remain numeric.
The default value of Format Mode is zero, which makes the function behave as it
did prior to this enhancement.
21582: Thin Client now adds scrollbars at smaller resolutions
Displays in the thin client with a minimum size and resize mode = Layout now
correctly display scrollbars at smaller resolutions.
Commands
21562: Open Browser command enhanced to open the url in a new browser tab
For an Open Browser command with Browser Window = Named and Window Name = _tab,
the thin client will now open the URL in a new browser tab rather than in a popup
browser window. In all other cases the command behaves as in prior versions.
This feature requires the browser's settings to be configured to automatically
open a new tab for popup windows. That is the default setting in all browsers.
But if the settings are configured to open popups in a new window, then the Open
Browser command will open the URL in a new window as in prior releases.
Data Sources
20881: Version Restriction Removed for MQ Client jars
Previously the IBM MQ data adapter checked for the presence of a class that was
only in a version specific set of MQ client jars. This is no longer the case.
Users can now use any version of MQ client jars (greater than or equal to MQ
version 6.0) in their classpath when using the IBM MQ data adapter.
Note: Since the actual set of required MQ client jars varies by version of MQ, it
is suggested that the set of MQ Client jars be put in a directory so that the
java classpath "wildcard" mechanism can be used to refer to all the jars in a
directory, rather than having to enumerate every jar file on the classpath.
The RTV_USERPATH environment variable can be used to set a user defined
classpath.
for example:
SET RTV_USERPATH=".;.\lib_7.1\*"
or
SET RTV_USERPATH=".;.\lib_7.5\*"
Note: for later versions of MQ (8.0, 9.0) a single relocatable jar
com.ibm.mq.allclient.jar is available.
21151: Provide mechanism to connect to secure Tomcat instances via JMX
A mechanism has been added to connect to secure Tomcat instances via JMX. A
secure connection requires the use of the following two parameters:
javax.net.ssl.trustStore
javax.net.ssl.trustStorePassword
Please see the User's Guide for more information.
21313: SSL Protocol field added to Splunk Connection
The Splunk data adapter has been enhanced to allow explicit management of the SSL
Protocol used when communicating to the Splunk server.
A new field "SSL Protocol" has been added to the Add Splunk Connection dialog.
This allows you to explicitly select the SSL Protocol used when communicating to
the Splunk server, by means of a drop down.
The SSL protocols available are SSLv3, TLSv1, TLSv1.1 (TLSv1_1) and TLSv1.2
(TLSv1_2). TLSv1 is selected by default as "TLSv1 is available by default in
every modern version of Java"
SSL protocols are configured on the Splunk server using the "sslVersions"
property as described in
http://docs.splunk.com/Documentation/Splunk/latest/Security/SetyourSSLversion
The client (Splunk data adapter) connection will, obviously, have to use a
compatible SSL protocol connect.
Use of explicit SLL protocol requires use of com.splunk.SSLSecurityProtocol found
in the Splunk Java SDK jar (splunk-sdk-java-1.5.0.jar). A modified version of
this .jar is provided with RTView. It has been modified to remove dependency on
the existence of a ".splunkrc" file in the users home directory, which a client
system may not have.
Protocol Limitations
-----------------------------
Different versions of Java have added and removed support for different SSL
protocols, so users will need to choose an SSL protocol that is supported by your
Java runtime.
TLSv1 is used as default by RTView as "TLSv1 is available by default in every
modern version of Java"
SSLv3 is provided for backwards compatibility, but its use is discouraged due to
the "POODLE" vulnerability as described here:
http://www.splunk.com/view/SP-CAAANKE
SSLv3 is disabled in recent versions of Java (1.7 + 1.8+) for this reason, and
will fail with an error message of the form
"java.lang.RuntimeException: No appropriate protocol (protocol is disabled or
cipher suites are inappropriate)"
TLSv1.1 and TLSv1.2 are not available in Java 1.6 and will fail with an error
message of the form
java.lang.IllegalArgumentException: TLSv1.1
or
java.lang.IllegalArgumentException: TLSv1.2
21596: Custom handler for IBM MQ connections
A custom handler for IBM MQ connections has been added.
Note: This release note assumes you have a working knowledge of writing,
compiling and deploying Java classes
IBM MQ Connections created with RTView may now have a handler associated with
then, which allows the programmatic setting of additional properties associated
with that connection. The handler associated with a connection is specified as a
fully qualified class name, in the IBM connection dialog thus:
Handler Class: Fully Qualified Class Name of GmsRtViewIbmMqDsConnectionHandler
subclass
This is equivalent to the "handler=<fully qualified class name>" field in the
ibmmq connection string.
The named class is loaded at runtime using the user specified class path
(RTV_USERPATH environment variable), and thus the user may specify a unique
handler per connection, or share one handler between multiple connections.
The handler must be a subclass of the
(com.sl.gmsjibmmqds)GmsRtViewIbmMqDsConnectionHandler defined in the
gmsjibmmqds.jar file in the RTV_HOME/lib directory.
Your handler should override the
public Hashtable getConnectionProperties(String connectionName)
method and return a hashtable populated with additional properties for the named
connection.
Example uses might be to set user name and password on a per connection basis, or
establish a secure connection to using user configured SSL.
*** Example - set username / password in MQ data source ***
This example will create a java class named MyMqHandler that extends the
GmsRtViewIbmMqDsConnectionHandler class.
In MyMqHandler.java, define the following method:
public Hashtable getConnectionProperties(String connectionName)
This method will be called to retrieve the additional (userID, password)
properties
used when RTView creates an MQ connection, where the handler field has been set
to MyMqHandler
Add RTV_HOME/lib/gmsjibmmqds.jar to your classpath when you compile MyMqHandler.
The compiled MyMqHandler class file must be
included in the RTView classpath by adding it to the definition for the
RTV_USERPATH environment variable.
The following source code is an example of MyMqHandler:
// import com.sl.gmsjibmmqds to reference the
com.sl.gmsjibmmqds.GmsRtViewIbmMqDsConnectionHandler class
import com.sl.gmsjibmmqds.*;
// import java.util to reference the java.util.Hashtable
import java.util.*;
/**
* This example class MyMqHandler extends the GmsRtViewIbmMqDsConnectionHandler
class
* to set userID and password properties
*/
public class MyMqHandler extends GmsRtViewIbmMqDsConnectionHandler {
/**
* Subclasses should override this method (getConnectionProperties) to return
* a Hashtable of connection properties suitable to pass into the
* MQQueueManager constructor
* as described in the IBM WebSphere MQ classes for Java API documentation.
* <p>
*
* @param connectionName rtview ibmmqds connection name
* @return populated Hashtable of connection properties
*/
@Override
public Hashtable getConnectionProperties (String connectionName)
{
Hashtable connectionProperties = new Hashtable();
System.out.println("MyMqHandler: Setting connection properties for connection: "
+ connectionName);
// Set userID and password variables
String userID = "MyUserID";
String password = "MyPassword";
// Set userID and password variables, differently, based on connection name
if (connectionName.equals("SomeConnection")) {
userID = "MyOtherUserId";
password = "MyOtherPassword";
}
// Set userID and password properties in Hastable to be returned
System.out.println("MyMqHandler:[" + connectionName + "] Setting userID: " +
userID);
connectionProperties.put("userID" /* CMQC.USER_ID_PROPERTY */ , userID);
System.out.println("MyMqHandler:[" + connectionName + "] Setting password: " +
password);
connectionProperties.put("password" /* CMQC.PASSWORD_PROPERTY */ , password);
// return populated connection properties
return connectionProperties;
}
}
Note: users should replace "MyUserID", "MyPassword" / "MyOtherUserId",
"MyOtherPassword" as appropriate, or use some approved method to fetch these
values, to avoid having them exposed in plain text.
Note: This example uses the literal values ("userID", "password") for properties
for simplicity to avoid dependencies on the equivalent property constant values,
in the relevant IBM MQ Java client libraries. The constant values could be used
by adding the appropriate import statement and adding the relevant jar file to
the classpath at build and run-time.
*** Using SSL for MQ connections ***
To use SSL with RTView you will need to create a Java class that extends the
GmsRtViewIbmMqDsConnectionHandler class to provide the relevant properties to
establish an SSL connection.
In our example we will create a handler called MySSLMqHandler
In MySSLMqHandler.java, define the following method:
public Hashtable getConnectionProperties (String connectionName)
This method will be called to set and return the retrieve the additional SSL
properties required for a named MQ connection. In this example we assume a shared
truststore / keystore to be used for multiple connections.
Add RTV_HOME/lib/gmsjibmmqds.jar to your classpath when you compile MyMqHandler.
The compiled MyMqHandler class file must be included in the RTView classpath by
adding it to the definition for the RTV_USERPATH environment variable.
The following is an example of MySSLMqHandler:
// import com.sl.gmsjibmmqds to reference the
com.sl.gmsjibmmqds.GmsRtViewIbmMqDsConnectionHandler class
import com.sl.gmsjibmmqds.*;
// import java.util to reference the java.util.Hashtable
import java.util.*;
/**
* This example class MySSLMqHandler extends the GmsRtViewIbmMqDsConnectionHandler
class
* to set SSL connection properties
*/
public class MySSLMqHandler extends GmsRtViewIbmMqDsConnectionHandler {
/**
* Subclasses should override this method (getConnectionProperties) to return
* a Hashtable of connection properties suitable to pass into the
* MQQueueManager constructor
* as described in the IBM WebSphere MQ classes for Java API documentation.
* <p>
*
* @param connectionName rtview ibmmqds connection name
* @return populated Hashtable of connection properties
*/
@Override
public Hashtable getConnectionProperties (String connectionName)
{
Hashtable connectionProperties = new Hashtable();
System.out.println("MySSLMqHandler: Setting connection properties for connection:
" + connectionName);
// Set userID and password variables
String userID = "MyUserID";
String password = "MyPassword";
// Set userID and password variables, differently, based on connection name
if (connectionName.equals("SomeConnection")) {
userID = "MyOtherUserId";
password = "MyOtherPassword";
}
// Set userID and password properties in Hastable to be returned
System.out.println("MySSLMqHandler:[" + connectionName + "] Setting userID: " +
userID);
connectionProperties.put("userID" /* CMQC.USER_ID_PROPERTY */ , userID);
System.out.println("MySSLMqHandler:[" + connectionName + "] Setting password: " +
password);
connectionProperties.put("password" /* CMQC.PASSWORD_PROPERTY */ , password);
// set SLL variables ( trust store, key store, cipher suite)
String trustStore = "MyTrustStore.jks";
String trustStorePassword = "MyTrustStorePassword";
String keystore = "MyKeyStore.jks";
String keystorePassword = "MyKeyStorePassword";
String transport = "MQSeries Client";
String cipherSuite = "TLS_RSA_WITH_AES_256_CBC_SHA";
// Set connection SSL properties
System.setProperty("javax.net.ssl.trustStore", trustStore);
System.setProperty("javax.net.ssl.trustStorePassword", trustStorePassword);
System.setProperty("javax.net.ssl.keyStore", keystore);
System.setProperty("javax.net.ssl.keyStorePassword", keystorePassword);
System.out.println("MySSLMqHandler:[" + connectionName + "] Setting trustStore: "
+ trustStore);
connectionProperties.put("javax.net.ssl.trustStore", trustStore);
System.out.println("MySSLMqHandler:[" + connectionName + "] Setting
trustStorePassword: " + trustStorePassword);
connectionProperties.put("javax.net.ssl.trustStorePassword", trustStorePassword);
System.out.println("MySSLMqHandler:[" + connectionName + "] Setting keyStore: " +
keystore);
connectionProperties.put("javax.net.ssl.keyStore", keystore);
System.out.println("MySSLMqHandler:[" + connectionName + "] Setting
keyStorePassword: " + keystorePassword);
connectionProperties.put("javax.net.ssl.keyStorePassword", keystorePassword);
System.out.println("MySSLMqHandler:[" + connectionName + "] Setting transport: "
+ transport);
connectionProperties.put("transport" /* CMQC.TRANSPORT_PROPERTY */ , transport
/*CMQC.TRANSPORT_MQSERIES_CLIENT) */) ;
System.out.println("MySSLMqHandler:[" + connectionName + "] Setting SSL Cipher
Suite: " + cipherSuite);
connectionProperties.put("SSL Cipher Suite" /* CMQC.SSL_CIPHER_SUITE_PROPERTY */
, cipherSuite);
// return populated connection properties
return connectionProperties;
}
}
Note: users should replace the "My..." variable values as appropriate, or use
some approved method to fetch these values, to avoid having them exposed in plain
text.
The Cipher suite given is an example. Supported cipher suited vary by MQ server
version, JDK/JRE version and JVM configuration.
Note: This example uses the literal values ("userID", "password", etc) for
properties for simplicity to avoid dependencies on the equivalent property
constant values, in the relevant IBM MQ Java client libraries. The constant
values could be used by adding the appropriate import statement and adding the
relevant jar file to the classpath at build and run-time.
Note: If using the Oracle JRE/ JVM you may need to use the following JVM flags to
achieve the same run time behaviour as the IBM JRE/JVM:
-Dcom.ibm.mq.cfg.preferTLS=false
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
21602: Enhanced error statement provided when malformed JSON encountered by DefaultJsonHandler
The DefaultJsonHandler expects well formed JSON to parse and extract
GmsTabularData. If that JSON is malformed or terminates unexpectedly, Google's
gson JSON parser may throw an exception.
RTView has been enhanced to provide additional error information when this
occurs. The additional context may help in determining the originating source and
cause of the malformed JSON encountered by the JSON parser.
Users will see a stack trace preceded by the following message:
ERROR: Exception when parsing JSON body: ....
...and followed by the following new context information:
ERROR: JSON Body parse error additonal context: ADDRESS = [<ADDRESS>], URI =
[<URI>], Content-length = [<contentLength]
where
<ADDRESS >= address (host:port) of sender of JSON body payload
<URI>=URI for HTTP post request (intended destination of posted data)
<Content-length>=The length of the response body in octets (8-bit bytes)
Demos
20890: Corrected mismatch in column names in the data attachment
Some column names in the eSphere demo were not corrected when the database was
changed to use HSQLDB. This has been corrected.
Display Server
21525: Added support for removing items from thin client context menu
Items can now be removed from the thin client context menu. This is done by
specifying the names of the items in a property named MenuItemsToHide in
rtvdisplay.properties. Multiple names are separated by commas. For example, the
following will remove the "Export Table To HTML", "Export Table to Excel",
"Export PDF", and "Status" items from the menu:
MenuItemsToHide=PDF,ExcelTable,HtmlTable,Stat
After adding the MenuItemsToHide property to rtvdisplay.properties, the
corresponding .war file must be rebuilt and redeployed.
Here are the names of all of the menu items, with the English label string of the
menu item in quotes if it differs from the item name:
Refresh
Back
Next
Command "Execute Command"
Drill "Drill Down"
ExcelTable "Export Table to Excel" (Internet Explorer only)
HtmlTable "Export Table to HTML"
PDF "Export PDF"
CopyCell "Copy Cell Value"
Stat "Status"
Logoff "Log Off"
Use the menu item name when configuring MenuItemsToHide, not the label string.
Logging
19451: Viewer and builder now print copyright to log4j output
Previously the Display Viewer and Builder did not show the copyright banner in
log files created using Log4j. This has been corrected.
Object Library
21564: New Link Path Types have been added
RTView links have been enhanced to support two new linkPathType property values:
Horizontal Square - Links are drawn from the right/left side of the parent
closest to the child to the right/left side of the child closest to the parent.
The link is straight if the parent and child are aligned horizontally, otherwise
the link line has two 90 degree angles. This linkPathType has a limitation when
the right/left side of the parent and child nodes overlap. In this case, the link
line will be clipped.
Vertical Square - Links are drawn from the top/bottom side of the parent closest
to the child to the top/bottom side of the child closest to the parent. The link
is straight if the parent and child are aligned vertically, otherwise the link
line has two 90 degree angles. This linkPathType has a limitation when the
top/bottom side of the parent and child nodes overlap. In this case, the link
line will be clipped.
The links have also been enhanced with a new property, linkCrossBarSpacing, in
the Link Line category. This property is only applied if the linkPathType is set
to Horizontal Square or Vertical Square. If this property is set to -1, the
perpendicular line between the parent and child nodes is positioned in the center
of the space between the parent and child nodes. Otherwise, it is positioned the
specified number of pixels from the parent node. If the value is greater than the
space between the parent and child nodes, the perpendicular line will be drawn in
the center of the available space.
Links with these linkPathTypes have been added to the Links palette in the
builder. The Horizontal Square and Orthogonal links look the same in the palette,
but the linkPathType is shown in the status area to help differentiate them.
RTView Display Panel
21508: Support subtitutions in display value in panel config
The rtvDisplayPanel tag in a PANELS.ini file now supports using an application
level substitution or login substitution for the display value as long as the
substitution name starts with a $. For example:
<?xml version="1.0" ?>
<panels xmlns="www.sl.com" version="1.0">
<rtvLayout title="Example">
<rtvDisplayPanel region="north" name="title" display="$my_title"/>
<rtvDisplayPanel region="center" name="main" display="$my_main"/>
</rtvLayout>
</panels>
TIBCO EMS Manager
21275: EMS Manager retired
The TIBCO EMS Manager application is no longer supported and has been removed
from RTView Core. It has been replaced by the RTView TIBCO EMS Monitor
application. TIBCO EMS Manager users should contact SL about moving over to
RTView TIBCO EMS Monitor.
Transaction Message Monitor
21514: Transaction monitor end-of-life delayed
In RTView 6.5, the Transaction Monitor was updated with a warning regarding the
end of life of that product. The retirement of the Transaction Monitor has been
postponed and the warning has been removed.
Scripts
21337: Windows scripts no longer fail if no rtview.properties file is missing
The rtvapm run scripts (rundata, runhist, etc.) now run without error if
rtview.properties are missing from the project directory.
21439: Added common scripts for making .war files
A new set of common scripts has been added for making .war files for the RTView
servlets. They are:
make_rtvdata_war.bat/sh
make_rtvdisplay_war.bat/sh
make_rtvquery_war.bat/sh
make_rtvagent_war.bat/sh
These scripts may be executed from any directory and will put the war files
there.
When you run the scripts you specify an appname (which will be used to name the
war file) and you may specify a host and port. (For the display servlet you may
also specify a backup port.) You may also put a copy of the servlet's properties
file in the current directory and it will be used in the war. (The original
properties files may be found in rtvapm/rtview/servlets/...) Note that if you put
a properties file in the current directory you may still override its host or
port values when you run the script.
The scripts take the following arguments:
-appname:
-host:
-port:
-ha_port:
-verbose
-help
For example:
make_rtvdata_war -appname:test -host:testhost -port:9999
Only the -appname argument is required. If no other arguments are supplied, the
values in the original properties file will be used. (The original file from the
war, or the file in the current directory if present.)
The -verbose argument will cause the script to print out the original and new
values it puts in the properties file. For example:
make_rtvdata_war -appname:test -host:testhost -port:9999 -verbose
These scripts also support positional arguments, in the order of: appname, host,
port. For example, with an appname of 'test', a host of 'testhost', and a port of
'9999', the user could use the argument this way:
make_rtvdisplay_war test testhost 9999
21505: Solaris systems now run all custom_setup.sh scripts without error
The following two files would fail on some Solaris systems
rtvapm/wsm/src/rtfiles/custom_setup.sh
rtvapm/projects/emsample/servers/miscmon/custom_setup.sh
This has been corrected.
21561: Solution Packages now use common .war scripts
The update_wars.bat/sh scripts in the solution pack project directories have been
updated to use the new make*war.bat/sh scripts in common/bin.
Solution Package
Docker
21447: Number of container restarts is now shown in Engine Table
The number of recent container (re)Starts is shown in the "Starts" column
of the All Containers Table in the All Containers - Table Display (Container
Views -> Containers Table).
The number represents the number of start status events associated the given
container in a "recent period" (1 hour by default).
Well behaved containers will show 1 start event when they initially start, and 0
when they have been up (running) for longer than the "recent period".
Containers that have restarted multiple times in the "recent period" will show a
value of more than 1.
Compare the start value with the Uptime, Running and Status columns for more
insight.
By default the recent period is 1 hour (3600 seconds) controlled by the
$docEventCacheTimeRange subs value.
The most recent statusEvents for a container are captured in the current table of
the DockerContainerEvent cache.
The container statusEvents for the most recent period are captured in the history
table of the DockerContainerEvent cache.
The number of container statusEvents for the history table of the
DockerContainerEvent cache is limited by the docMaxNumberOfHistoryRows subs value
(default: 50000)
The count of container events, summed for the most recent period (history table
of the DockerContainerEvent cache) are captured in the current table of the
DockerContainerEventCount cache.
21546: Updated cadvisor-rtview.sh to add tagging options
A new argument has been added to the cadvisor-rtview.sh container-creation
script.
-v | --version <TAG>
Sets the tagged version of the cadvisor-rtview image to use. Default value is
'latest'
21592: Docker 1.11 support added
Docker 1.11 is now supported
The slcorp/cadvisor-rtview agent for dockermon now supports Docker 1.11
21611: Initial dockermon cache load queries from database are now time bounded
Previously the initial queries to load historical data into the Dockermon data
server caches at startup were not time bounded. This is no longer the case.
IBM Websphere Application Server
21367: Server Summary button now works as intended
The Server Summary button on the WSM Single Server display now correctly links to
the Server Summary display.
21396: Limited support for WebSphere 8.5 now exists
WSM Solution Package now provides limited support for WebSphere 8.5. For an
heterogeneous environment with multiple versions of WebSphere AS, it is
recommended that you use a sender/receiver configuration where each sender sends
data from WebSphere Server Instance of the same major version.
At this time, WebSphere 8.5 is only supported if the dataserver includes the
following library from version 7: com.ibm.ws.admin.client_7.0.0.jar.
The sample.properties file provided with the Solution Package provides the list
of local jars and connection properties required to successfully connect with
secured WebSphere 8.5 Application Server.
21422: All Servers Grid display in Websphere now has consistent style
The background of the composite object in the All WebSphere Servers -> All
Servers Grid now displays the light style correctly.
MongoDB
21516: Collection Summary drop-down list now populates correctly
The Collection drop-down list on the Collection Summary display now correctly
populates when manually changing collections.
21612: Initial mongomon cache load queries from database are now time bounded
Previously the initial queries to load historical data into the mongomon data
server caches at startup were not time bounded. This is no longer the case.
Node.js
21613: Initial nodemon cache load queries from database are now time bounded
Previously the initial queries to load historical data into the nodemon data
server caches at startup were not time bounded. This is no longer the case.
Oracle Database
21614: Initial oramon cache load queries from database are now time bounded
A bug that generated unbounded data base queries at startup for
OraDatabaseAvailability, OraInstanceQueryExecStats, OradatabaseDiskUsage, and
OraInstanceSessionStats caches has been fixed.
Writing historical data to the ORA_DISK_USAGE table has been disabled.
Oracle Weblogic
21348: Optimized performance of the Cache Map by CI
A bug in the WlsJmsDestination cache configuration that forced updates of the
Cache Map by CI every 15 seconds has been fixed.
Solace
20943: XML Parser enhanced to handle bad SEMP requests
A fix to account for bad SEMP requests to "show queue/topic data" has been
introduced in the SOLMON XML parser. This invalid XML reply occurs when
queue/topic names have odd character encoding (E.g. characters from latin
character set).
21542: Drop Down menus enhanced
Drop downs for SOLMON have been improved to increase responsiveness when multiple
connections, including Solace VMRs, have been defined.
21547: Partial router data now available with no defined endpoints
A bug that prevented router data from being shown when no end points were
configured has been fixed. As a result of this fix, if a physical message router
or a Solace VMR is being monitored without any queue or topic being configured,
then the Message Router displays will contain partial information showing some
metrics independent from end points.
21548: Last Data Time now anchors correctly to Interface Summary
The Last Data Time element on the Interface Summary display now anchors
correctly.
21549: Colors of In/Out Msgs/sec trends have been changed
The In Msgs/sec and Out Msgs/sec trends from the VPNs->Single VPN Summary are now
represented by different colors so that they are easier to differentiate.
21550: Standardized color scheme for Top VPNs display
The background color of the State text box from the VPN's -> Top VPNs Grid
display now matches the rest of the display.
21588: Data quality now reflected in status colour across more displays
The state of the data being displayed for SOLMON has been revisited and improved
to account with the quality of current data of the drop downs,
Last Data Time background color, and the quality of the data shown in the main
display area.
These elements are now designed to assist users to understand the degree of
confidence one can have with the data being exposed in our displays.
The information from the Last Data Time refers to the time in which the main
index shown in the display has been updated. When the current selection of
indexes is Expired, the background of Last Data Time graphical object will now
show as dark red. Otherwise it appears as green.
Regarding the main display area, the confidence one can have in the data shown is
associated with a boolean value indicating whether the quality (goodness of the
data shown) is appropriate. Now, all displays that refer to one single Message
Router present a dark red background when the information provided is considered
outdated.
This new behavior can be observed in:
- Message Routers -> Msg Router Summary
- Message Routers -> Msg Router VPN Activity
- VPNs -> Single VPN Summary
- Clients -> Single Client Summary
- Bridges -> Single Bridge Summary
- Endpoints -> Single Endpoint Summary
- Capacity Analysis -> Msg Router Capacity
- Capacity Analysis -> Msg Router Capacity Trends
TIBCO ActiveSpaces
21597: ActiveSpaces connections require unique member names within the same metaspace
The documentation and properties files comments have been updated to provide more
clarity about connection limitations.
To make new connections, memberNames within the same metaSpace must be different.
If when editing a properties file, if you create a new connection by copy and
paste, you must change the memberName as well as the Discovery and Listen URLs.
For example if you copy a connection property such as
collector.sl.rtview.tasmonds.conn=__name=Q1-Domain memberName=RTViewEM
metaspaceName=Q1-Domain discovery=tcp://... listen=tcp://...
... if you remain in the same metaspace then you must change the member name,
e.g.
collector.sl.rtview.tasmonds.conn=__name=AS-Q1-Domain-MS memberName=RTViewEM2
metaspaceName=AS-Q1-Domain-MS discovery=tcp://... listen=tcp://...
TIBCO BusinessEvents
21460: Added optional variable to read cluster-level MBean data
When connecting to a BE4 cluster, it is possible that the version of java used by
the cluster predates the "java 1.6.0_31 or later" required by tbemon. Older java
versions do not support the JMX wildcard queries needed by tbemon data
collection, so the cluster name cannot be auto-discovered. To read the
cluster-level MBean data, you must explicitly pass the name of the cluster to the
input processing chains using an optional variable ($tbe_cluster) as follows:
# Inference Engines
#collector.sl.rtview.cache.config=<cache_source> $tbe_conn:<engineName>
$tbe_cluster:<clusterName>
#collector.sl.rtview.jmx.jmxconn=<engineName> <hostname> <port> URL:- - - 'false'
# Cache Engines
#collector.sl.rtview.cache.config=<cache_source> $tbe_conn:<engineName>
$tbe_cluster:<clusterName>
#collector.sl.rtview.jmx.jmxconn=<engineName> <hostname> <port> URL:- - - 'false'
TIBCO BusinessWorks
21530: Enhanced BW Server Summary display
The BW Server Summary display has been enhanced with the following features:
- Active Engines text boxes on the All Engines table now have drill down
capability.
- Heatmap now reflects stopped engines as gray, and expired engines as dark red.
- Heatmap hover text now displays Status and Expired metrics.
21532: BW Processes Heatmap tooltips optimized
The Process Heatmap display has been optimized so that the metrics displayed in
the tooltip are in the same order as the metrics selector list.
21533: Engine Status now reflected in BW Engine Summary display
The Engine Summary display has been enhanced to display a dark red background if
the engine is not active.
21534: Engine Status now reflected in BW Process Summary display
The Process Summary display has been enhanced to display a dark red background if
the associated engine is not active.
21535: Engine Status now reflected in BW Activity Summary display
The Activity Summary display has been enhanced to display a dark red background
if the associated engine is not active.
21536: Improved heatmap aesthetics
Heatmap displays now have their objects aligned properly.
21555: Alert light indicators now correctly report number of alerts
Alert light indicators in the Single BW Server Summary display now correctly
report both critical alerts and warning alerts. The color of the alert light
indicators will reference the highest severity for the element and the number of
alerts is the sum of the warning and critical alerts for the element.
21569: Empty displays with zero or null data no longer invisible
In BW Monitor when monitoring BW6, if for any reason the BW6 Process data is not
available, some displays would be invisible, rather than visible but showing zero
or null data. The displays were the Table and Heatmap views of BW6 Applications,
AppNodes, AppSlices and Activities. The Summary views were not affected.
This has been corrected so that the displays will show what data is available.
Note that Application, AppSlice, and Activity heatmaps will not display visible
cells, because (as noted in the titles) the cell sizes are controlled by process
metrics.
TIBCO EMS
21567: Multiple bugs fixed with Caches
A bug that forced the initial SQL queries from EmsServerInfoExt, EmsQueuesExt,
and EmsTopicsExt caches to query all available historical data has been fixed.
Also, a bug that prevented correct collection of the data from EmsQueuesExt and
EmsTopicsExt caches in a sender/receiver configuration has been fixed.
Version 3.3.1 Release Notes
Solution Package
TIBCO BusinessWorks
21556: Collection of BW6 appnode memory metrics
BW6 Monitor was not collecting all the data for appnodes; specifically memory and
cpu metrics were missing. This has been corrected.
Version 3.3.0 Release Notes
Alerts
21515: Fixed inaccuracies of Alert Severity Indicators on Single Server Summary
The alert light indicators on the Single EMS Server Summary display have been
fixed.
Configuration
21419: New displays with configuration property information
EM has been enhanced with new displays showing the properties configuration and
values for all connected RTView processes. The displays are in the ADMIN tab
under Property Views.
All of the properties displays have the following fields at the top:
- Source - Select the Source of the connection to the RTView process for which
you want to see property information:
- Data Server - If the RTView process is a Data Server and the thin client has a
defined Data Server connection for it, choose this option and select the name of
the Data Server in the Connection field.
- Local JMX Connection - Select this option if the thin client has a defined JMX
Connection to the RTView process.
- RTVMGR JMX Connection - Select this option if the RTVMGR has a defined JMX
Connection to the RTView process.
- Connection - Select the connection to the RTView process for which you want to
see property information.
- RTVMGR - This is only visible when Source=RTVMGR JMX Connection and you have
multiple RTVMGR's. Select the RTVMGR that has a defined JMX Connection to the
RTView process for which you want to see property information.
- Update Props - Click this button to have the RTView process specified by the
selected Connection re-read all properties files and database properties. Note
that most non-connection properties do NOT support updates. Use the Properties
Descriptions display to see if a specific property supports updates.
Property Views Displays:
Properties Configuration - This display shows the properties configuration
information. The Last Property Read Time lists the last time that properties were
read for the RTView process specified by the selected Connection. The Property
Files table shows all of the properties files that were read by the RTView
process specified by the selected Connection in the order they were read. The
Property Filters table shows all filters that were applied to the properties.
Property Groups shows all property groups that were applied to the properties.
Property Groups are only used when reading properties from a database.
System Properties - This display shows the System properties for the RTView
process specified by the selected Connection.
Applied Properties - This display shows all of the properties that were applied
to the RTView process specified by the selected Connection. There are several
reasons a property specified in a properties file might not be applied to an
RTView process: the filter doesn't match, it was overridden in another property
file, it was specified in a file that is not used by the RTView process, it was a
property that is not supported in that RTView process (ex, a builder specific
property would not be applied to a data server process). You can filter the
Applied Properties table using the Filter Column and Field Value fields. The
Clear Filter button clears the filter. Double-click on a row in the table to
drill down to the All Properties display filtered by the Property Name for that
row. The double-click feature is not supported on IPad. IPad users can access the
All Properties display from the navigation tree. The Applied Properties table
columns:
- Apply Time - The last time this property was applied.
- Action - ADDED, REMOVED, CHANGED
- Success - True if the action was successful.
- File Name - The source of this property. It will be database for properties
read from a database.
- Property Name - The name of the property after the property filter has been
applied.
- Property Value - The value of the property.
- Handler - The RTView Handler that uses this property.
All Properties - This display shows all properties that were read from the
properties files and database regardless of whether or not the RTView process
uses them. There are several reasons a property specified in a properties file
might not be applied to an RTView process: the filter doesn't match, it was
overridden in another property file, it was specified in a file that is not used
by the RTView process, it was a property that is not supported in that RTView
process (ex, a builder specific property would not be applied to a data server
process). You can filter the All Properties table using the Filter Column and
Field Value fields. The Clear Filter button clears the filter. The All Properties
table columns:
- Order - The order in which this property was read. For properties that support
a single value that are specified multiple times, the one with the highest Order
value will be applied.
- File Name - The source of this property. It will be database for properties
read from a database.
- Property Name - The name of the property after the property filter has been
applied.
- Property Value - The value of the property.
- Original Property Name - The name of the property before the property filter
was applied. This will match the literal property string in your properties file.
Properties Descriptions - This display shows one row for each property that is
supported for the RTView process specified by the selected Connection with the
following columns:
- Property - The name of the property
- Multi - True if this property supports multiple values.
- Updates - True if this property supports updates.
- Handler - The name of the RTView Handler that uses this property.
- Deprecated - True if this property is deprecated.
- Depreciation Info - If the property is deprecated, this lists the currently
supported property to use instead.
Data Model
21391: AlertServer cisource processing re-attempted every 5 seconds for a minute
In previous releases, the cisource property processing would fail if the
ConfigServer was not available when the AlertServer started. This can happen when
the AlertServer is started before the ConfigServer or when they are started at
the same time but the ConfigServer is slow to startup. The AlertServer will now
re-attempt the cisource processing every 5 seconds for a minute. If the
ConfigServer is still unavailable at that point, the cisource property processing
will fail and write an error in the log file.
21501: Fixed performance issue due to large list of subs on RtvDisplayServerDisplays cache
A performance issue from misconfigured history on the RtvDisplayServerDisplays
cache has been fixed.
Deployment
21434: Linux file permission handling improved
The scripts rtvapm_init.sh and rtvapm_user_init.sh have been improved so they may
be run multiple times in a terminal session without making unnecessary changes to
the filesystem or the environment. Before converting a file to Unix format or
setting its permissions they will now check the file, and they will now check the
PATH before adding to it.
General
18310: False positive "ciListForDataServerConcatenated" errors removed from central alert server
In previous releases, the log files for the central alert server contained
several of the following erroneous errors at startup:
ERROR: function <ciListForDataServerConcatenated>, Invalid column name <column
name list>
The alert server has been fixed to no longer generate this error except in cases
where the error is valid.
21486: New option to use cross-platform fonts
When the Display Server is running from a host operating system other than the
operating system of the client browsers, label alignment inconsistencies can
occur due to font unavailability. This is especially pronounced for a Linux
server and WIndows client scenario.
RTView EM now provides a rtvapm/rtview/lib/rtvfonts.jar that can be enabled in
the Display Server, so that the client browser will download the fonts used by
the server.
To enable this option, which is recommended for linux hosts, edit
rtvapm/common/conf/rtvapm.properties and uncomment the following two lines:
#sl.rtview.cp=%RTV_HOME%/lib/rtvfonts.jar
#sl.rtview.global=rtv_fonts.rtv
Navigation
21414: New Environment Filter for Service Tree
The navigation panel for the SERVICE TREE and ALERTS tabs has been enhanced with
an Environment filter combo box. Select an Environment from the list to filter
the navigation tree. In the SERVICE TREE tab, it also sets the Environment filter
on the main panel. Note that changing the Environment filter on the main panel
will not set the Environment filter in the navigation panel.
RTView Core Functionality
Customization
18831: Implement a platform-agnostic font solution for display server
A file named rtvfonts.jar is now included with RTView. This jar file is intended
to provide consistent text size on displays that are configured on Windows but
are deployed in the thin client via the display server running on Linux. On some
Linux installations, there can be significant sizing and spacing differences
between the Windows and Linux versions of the "generic" font types (serif,
sans-serif, monospaced). This jar contains open source fonts which can be used
instead, for font indexes 1 - 12. Each of the open source fonts was designed to
be equivalent in sizing and spacing to the corresponding Windows font.
The rtvfonts.jar should be used in the following situation:
1) RTView displays were created on Windows, but are deployed in the thin client
from a display server running on Linux.
2) In the thin client, there are visible problems with text alignment and sizing
that are not seen when the same display is open in the builder/viewer on Windows.
If this situation occurs, then the display server should be configured as
follows:
1) Add rtvfonts.jar to the display server's classpath, for example:
> set RTV_USERPATH=$RTV_HOME/lib/rtvfonts.jar
2) Add rtv_fonts.xml as a global file (rtv_fonts.xml is contained in
rtvfonts.jar). For example, add this line to the display server's OPTIONS.ini
file:
global rtv_fonts.xml
The open source fonts contained in rtvfonts.jar are:
Arimo (sans-serif, equivalent to Arial)
Cousine (monospace, equivalent to Courier)
Tinos (serif, equivalent to Times New Roman)
Each font is provided in regular (plain), bold, italic, and bold italic in .ttf
format (for the display server) and .woff format(for the thin client) for a total
of 24 font files. The .ttf files for each font were downloaded from
https://www.google.com/fonts. Each is licensed by the Apache 2 license.
The font files in this jar contain only the Latin character set, to reduce their
size. This means that CJK (Asian) characters will appear as boxes in text strings
that are rendered by the display server (e.g. a label object with webLabelFlag =
false). In text strings rendered by the browser, the expected characters will
appear in a fallback font, so the style and size may not match the Latin
characters in the font.
Data Historian
21455: New mechanism to 'throttle' historian deletions.
A command line argument has been provided to enable throttling of historian
deletions by separating large deletions into smaller groupings. This option will
help in scenarios where users see the following errors in the log:
SQLException: The transaction log for database <DB Name> is full.
ERROR: java.sql.SQLException: The transaction log for database <DB Name> is full.
retention doing delete in SQL: [delete from <DB Table Name> where "timestamp" <
'YYYY-MM-DD HH:MM:SS'] failed.
To enable multi-chunk retention start the historian with the -retentionChunkSize
argument.
Example of deleting in 2 day chunks:
-retentionChunkSize:2d
Example of deleting in 1 week chunks:
-retentionChunkSize:1w
This argument does not support time segments of multiple units, such as "1h 30m"
Data Sources
21299: Improved hawk error handling
The TIBCO Hawk data source error handling has been enhanced as follows:
1. Improved logging for onErrorExceptionEvent and onWarningExceptionEvent. These
events occur when there is a problem with one of the connected TIBCO Hawk
Transports. Also, RTView will now try reconnecting to the transport if an
onErrorExceptionEvent occurs.
2. Improved logging for subscription error events. Also, RTView will cancel all
subscriptions for a MicroAgent if an onTermination event occurs and attempt to
recreate them.
21392: New reconnect option added to Hawk DS
The TIBCO Hawk data source has been enhanced to attempt to reconnect when the
initial connection to a transport fails. By default, it will attempt to reconnect
once a minute for 60 attempts. You can set the max number of reconnect attempts
by command line or property.
command line: -hawkmaxreconnect:3
property: sl.rtview.hawk.hawkmaxreconnect=3
Every time a reconnect is attempted, you will see this in the console:
016-03-07 13:00:50.282 re-attempt connection to transport <test_ems>: 1 of 60
016-03-07 13:00:52.911 re-attempt connection to transport <test_ems>:
succeeded/failed
To disable reconnection attempts, set the max reconnect to 0.
21393: New connection table added to Hawk DS
The TIBCO Hawk Data Source has been enhanced with a new method,
getConnectionTable, in the RTViewDs microagent. This table shows one row for each
defined connection with the following columns:
- Name - the connection name
- Connected - true if we are connected, false otherwise
This table updates with all rows regardless of the Disable Data Caching setting.
21421: Unexpected JMX Mbean objects no longer cause exception
Unexpected JMX object types could cause a NullPointerException. This has been
fixed.
21428: Fix bug preventing removal of rows from current_condensed table
A bug in the cache data source has been fixed that prevented rows in
current_condensed tables from being removed by the row expiration feature.
(The current_condensed table exists on caches that have the row condense feature
enabled. It has one row for the most recent condense result computed for each
unique index value).
The properties that remove rows from the current table are rowExpirationMode,
rowsToDeleteTable, and maxNumberOfCurrentRows.
21437: Corrected slow Hawk Agent discovery by Hawk Datasource
A change was introduced in RTView 6.4 that caused the Hawk Agent discovery to
slow down in cases where the Hawk Agents were slow in servicing requests for
MicroAgent Descriptors. This has been fixed.
Display Server
21435: Mouse wheel scrolling for tables when using Firefox 42 or newer
In prior releases, the thin client did not support scrolling of table objects
using the mouse wheel, if webGridFlag = false, in Firefox version 42 or newer.
This is fixed.
21436: Fixed crash with -clearsubs:true command line option
A bug has been fixed which caused the display server to throw a
StackOverflowError at startup if the command-line option "-clearsubs:true" was
specified. This bug was introduced in RTView 6.4.
(Note: The default value of the clearsubs option is true, so there is no need to
specify -clearsubs:true).
21440: New new style for tab controls
The Display Server has been enhanced to support a new style for tab controls in
the thin client only. This style is flat with square edges and no highlight. To
use this style, set the styleClass property for the tab object to em-nav-tabs and
add this line to your OPTIONS.ini:
displayserver.css rtv_tab.css
General
18198: New option to change default fonts or use additional fonts
The Extended Font feature, new in this release, allows users to extend the list
of fonts available on RTView displays beyond the 12 standard fonts. Extended
fonts can be used in the Builder/Viewer, or in the thin client, or in both
deployments.
The configuration and use of this feature requires a basic understanding of font
technology and terms, described below.
Two example configurations are provided in the RTV_HOME/custom/fonts directory
BACKGROUND
The following terms apply to font usage in RTView.
- System fonts: System or platform fonts are provided by the local operating
system. A web browser can make use of the system fonts from the local (client)
machine. The system fonts vary between different operating systems, and between
versions of the same operating system. This presents a challenge to web
developers, since a font available to a browser on one system (e.g. Tahoma on
Windows) may not be available to a browser running on other systems, although
similar fonts (e.g. Helvetica on Mac OS) may be available. The solution is to (a)
use only web-safe fonts, (b) use font families or font stacks, or (c) use web
(downloaded) fonts. These are described below.
- Web-safe fonts: The serif, sans-serif, and monospace fonts are known as
"web-safe" or standard fonts because they are available in all browsers on all
platforms. They are also available in Java on all platforms.
- Font-family: A font-family is a comma separated list of font names, used in the
CSS style applied to text elements on a web page. The browser will attempt to use
the fonts in the order they are listed until it finds one that is available. This
browser also applies this process on a per-character basis if the text element
contains a character not defined in the specified font. The last font in the list
should be a web-safe font. This technique is also known as a "font stack" or
"fallback fonts". For example:
font-family: Helvetica, Lucida Sans, Arial, sans-serif
- Web fonts: A web page can identify a specific font to be downloaded from a web
server, rather than using a stack of system fonts. A specific font downloaded
from the web server is known as a "web font".
- Font files: A file that defines a font. A common format is TrueType (.ttf). In
a java application, additional fonts can be used by providing TrueType font
(.ttf) files. On a web page, web fonts can be downloaded as ttf files. Other
formats (.woff, .woff2) are also supported for web fonts. Font files are
licensed. Many system fonts are licensed by the OS vendor (e.g. Microsoft). A
large number of fonts are available under open source licenses (Apache 2.0, SIL).
The Web Font example in the custom/fonts directory uses several open source fonts
published on http://www.google.com/fonts.
FONTS IN RTVIEW
By default RTView uses only the web-safe font types: serif, sans-serif, and
monospace. For each web-safe font type RTView provides a plain, bold, italic, and
bold-italic style, for a total of 12 font choices. Each is assigned an index, as
follows:
1: sans-serif, plain
2: monospace, bold
3: monospace, plain
4: serif, plain
5: monospace, italic
6: serif, bold
7: sans-serif, bold
8: sans-serif, italic
9: serif, bold italic
10: serif, italic
11: sans-serif, bold italic
12: monospace, bold italic
The font indexes are used when configuring a font property (e.g. labelTextFont)
on an object in the RTView display Builder.
The Extended Font feature allows users to extend the list of fonts available on
RTView displays, beyond the 12 standard fonts. Extended fonts can be used in the
builder/viewer, or in the thin client, or in both deployments.
For use in Java (builder/viewer, display server) an extended font must be
available from a local .ttf or .otf file.
In the thin client, either the font-family (stack) or the web font (downloaded)
technique can be used. The font stack technique provides better performance and
requires no additional font files or licensing since it uses system fonts already
available on the local system. However, since different physical fonts are used,
a text element that uses a font stack may have a different appearance and size
when viewed in a browser on (say) Windows, vs iOS, vs Android. The web font
technique provides a consistent appearance and size in all browsers regardless of
the local platform, but requires additional time to download the web fonts the
first time the page is opened. Fonts that contain non-latin characters (Cyrillic,
Arabic, and especially CJK) can be large. Also, web fonts should be properly
licensed.
For use in a browser as a web font, the font must be downloadable as a .ttf,
.woff, .woff2, or .otf file. Internet Explorer will complain if a .ttf file is
not embeddable (most Microsoft-provided .ttf files are not embeddable).
EXTENDED FONTS CONFIGURATION AND USE
The extended fonts are specified in a table created by the user, with one row per
font. The table has these columns:
- Index (int): the font's index, an integer value between 13 and 255 (see Note 1
below)
- Name (string): the name of the font as it should appear in the Builder property
sheet and font selection list
- Bold (Boolean): if true, a bold style font is created
- Italic (Boolean): if true, an italic font style is created
- CSS Font Family (string): for use by the RTView thin client (see Note 2)
- URL (string): for the thin client, when using web fonts (see Note 3)
- TTF Path (string): a local path to the fonts .ttf file, for use by RTView
builder/viewer and display server (see Note 4)
The required columns are Index, Name, Bold, and Italic. The other columns are
optional depending on the deployment(s) of interest, and the type of fonts used.
*** The extended font table must be made available to RTView by creating a global
function named RtvExtFontTable. ***
The RtvExtFontTable function must return a table that contains the required
column names and types listed above. Typically, the RtvExtFontTable function
would be a global Reference function with its Table argument attached to a static
XML or SQL table.
- Note 1: The examples in the custom/fonts directory use index values of 100 and
above, as a convention. Index values of 1 - 12 can also be specified, but that
will override the default RTView font assignments and is not recommended.
- Note 2: The CSS Font Family string is used by the thin client to assign the CSS
font style to a client-side object that uses the corresponding font. If the thin
client should use a system font, then the string should specify the font family
or "font stack" to be used, as a comma-separated list of fallback font names,
ending with a web-safe font. For example:
Trebuchet MS, Helvetica, sans-serif
If instead the thin client should download a web font, then the string in the CSS
Font Family column can contain a single name, for example:
Roboto
- Note 3: The URL column can be omitted or left blank if the thin client should
use a system font. If the thin client should download a web font then the value
in this column should specify the URL for the thin client to use to download the
font file. For example:
fonts/Roboto-Regular.ttf
The above example assumes that the user has created a subdirectory named "fonts"
beneath the rtvdisplay servlet's webapp directory, and it contains the indicated
ttf file. The URL can also specify an address on a different web server (e.g.
http://somewhere.com/fonts/xyz.woff), provided that server supports CORS
(cross-domain) requests.
Internet Explorer will complain if a .ttf file is not embeddable (most
Microsoft-provided .ttf files are not embeddable).
CHARACTER SETS
The web-safe fonts support all Unicode characters. Other fonts may not. (In
particular, open source fonts may not support CJK characters). If a text string
contains a character that is not found in the specified font, the effect is as
follows:
In a browser, if a text element contains a character that is not found in the
specified font, the browser will try the fonts listed in the font-family, and
finally its default web-safe font, until it finds a font that supports the
character. This means the thin client always displays all of the characters in a
text string, but when using an extended font non-Latin characters may be
displayed using a fallback or system font.
In a Java application, if a text string contains a character that is not defined
in the specified font, the character may appear as a "tofu" character (a box or a
?) or it may not be drawn. This means that the builder/viewer will display tofu
or empty characters for non-Latin characters that are not found in an extended
font. This is also the case for the thin client, for text objects that are
rendered in the display server and not in the browser.
The google Noto Sans CJK fonts are in .OTF format with Postscript Type 1 glyphs
(.OTF w/PS Type1) which is not recognized by Java.
EXAMPLES
Two example configurations are provided in the RTV_HOME/custom/fonts directory.
See the README.txt file in that directory for more information. The beginning of
the README file contains the same sections that appear above in this note, but
see the EXAMPLES section in the README for a description of each example.
21177: Update-able single value properties now update when the property is removed
In previous releases, the following update-able properties did not reset to the
default value if they were removed. This has been fixed.
sl.rtview.customWindowTitle
sl.rtvapm.mx.mxtrace
sl.rtvapm.km.kmtrace
sl.rtview.sql.sqltime
sl.rtview.jmx.jmx_metrics_period
sl.rtview.alert.notifiertimetrace
sl.rtview.alert.notifierdebug
sl.rtview.hawk.hawkdstraceagentstatus
Platform Support
21076: Windows 10 and Edge Browser support
Windows 10 and the Edge Browser are now supported by RTView products.
Viewer - Applet
21366: Applet support dropped
Due to dropped support for applet technology from browsers and Oracle, RTView has
discontinued support of deploying using java applets. All applet demo examples
have been removed from the product
Solution Package
Host Infrastructure
21343: Components -> Hosts -> General Hosts dataserver dropdown added
In previous releases, the General Hosts display on the COMPONENTS tab did not
allow you to select a Data Server when multiple Host Data Servers were available.
This has been fixed.
21432: rtvHostAgent moved to hostmon\agents directory
The rtvHostAgent.zip file was moved from rtvapm\hostmon\lib to
rtvapm\hostmon\agents, and the extracted rtvHostAgent directory was moved from
hostmon\projects\sample to hostmon\agents.
The hostmon\README.txt now contains information about dataserver configuration
and running the demo, whereas the hostmon\agents\rtvHostAgent\README.txt is
targeted towards the requirements for installing, configuring, and running the
agent.
IBM Websphere Application Server
19694: WSM App Metric caches now use "cell" as index column
The caches of the WSM Solution Package have been updated to take into account
"cell" as an index.
21381: Deprecated requests for javaVersion and javaVendor removed
A request for the deprecated attributes javaVersion and javaVersion in
Application data has been fixed.
MongoDB
21444: Show replication lag for each secondary
The replication lag is now shown for SECONDARY members of replication sets.
Oracle Weblogic
21329: Fixes for WlsJmsDest* alerts
Previously the WlsJmsDestinations* alerts would not always fire correct. This has
been fixed.
Solace
21357: SolMsgRouterSyslogAlert fixed under EM
A bug that prevented correct behaviour of the SolMsgRouterSyslogAlert discrete
alert under RTView EM has been fixed.
This alert will be executed when the Syslog event messages have a level of WARN
or higher. The events with WARN level will trigger a warning alert and the events
with ERROR or higher level will trigger an alarm alert. When enabled, no
threshold modifications for this alert are required.
This problem did not effect the standalone RTView Monitor for Solace.
21359: Drop-down lists in the Syslog Events table display do not populate under EM
Previously, when running within a full EM project, the dropdown list selectors on
the Syslog Events display were blank. This has been fixed.
This problem did not effect the standalone RTView Monitor for Solace.
21500: Improved navigational displays
The supplemental navigation displays that provide an optional alternative to the
navtree have been enhanced to contain all available displays, and a navigation
display has been added for Syslog.
TIBCO ActiveSpaces
20925: MemberName column has replaced the Member column as an index
The MemberName column has replaced the Member column as an index for the
TasMembers, TasMemberStatistics, and TasSeeders caches.
This change was made because the ID string identifying the ActiveSpaces cluster
member can change when the member is restarted. The new ID disconnected the
history for the member, and the Member Summary trend chart would no longer
display any history for the member prior to the restart.
The MemberName can be statically assigned by the user, or defaulted to a shorter
version of the ID which appears to persist across restarts. In either case, the
full history is now available on the Member Summary trends.
This change requires that the following database tables for TASMON be deleted and
recreated:
TAS_MEMBER
TAS_SPACESTATISTICS
TAS_SEEDERS
21087: Navigation corrections in Members displays
Some navigation corrections have been made in the Members section of the Tasmon
navtree. All Members By Space Heatmap is added to the tree, and an incorrect
"heatmap" button has been removed from the all Spaces By Members Table.
TIBCO BusinessEvents
21453: TbeClusterMalformed in now triggered in the case of a brain-split
The TBEMON alert TbeClusterMalformed will now be triggered for any cluster where
the member count is not equal to the expected cluster size.
The "expected" cluster size is simply a count of the number of nodes that have
the same cluster name, as discovered by reading the cluster mbean for each node
in the connection property file. The MemberCount attribute is also read from the
same cluster mbean, and is the number of nodes in the (sub)cluster which the
current node has joined.
The condition where these counts differ can occur if there are missing
connections in the property file (ie, some nodes are unmonitored). It can also
occur if, due to network anomalies, some nodes do not join the "main" cluster,
but instead form a "sub-cluster" of one or more nodes. This condition is commonly
referred to as "split-brain".
21454: Fixed blank CI column in the Alerts Table for TbeClusterMalformed
Previously the TbeClusterMalformed alert did not correctly display the name of
the cluster it triggered for in the CI column of the alert table.
This has been fixed.
21462: Clusters with only one type of node now show up in the All Clusters table
If a cluster contained only inference nodes or only cache nodes, the top level
All Clusters table would not display the cluster. This has been fixed.
TIBCO BusinessWorks
19233: Engine status now indicated in Engine heatmap drop down list
BW Monitor displays have been enhanced such that the engine selector dropdown
list will show if an engine is not running by appending "(X)" to the entry in the
list.
20674: Add jmxconn settings for rtview servers pages
The jmx connections specified for connecting to RTView Server JVMs have been
moved from rtvapm.bwmon.properties into a new file bwmon_jvm.properties, which is
now called from the standalone rtvservers.dat.
This will prevent an EM collector from incorrectly trying to connect to these
servers.
21263: Total Engine Statistics now displayed on Engine Level
The BW All Engines Table and Heatmap have been enhanced with the addition of
columns giving the total count of created, completed, and aborted processes for
each engine. These columns are displayed in the table and in the mouse tooltip in
the heatmap
21290: New Alerts and key metrics for correlating process activity vs. resources
BW Monitor has been enhanced with new alerts and new Key Metrics.
The following new alerts have been added:
Name Metric
---- ------
BwProcessAvgExecutionTimeHigh AverageExecution
BwProcessAvgElapsedTimeHigh AverageElapsed
BwProcessCreatedRateLow RateCreated
BwProcessCreatedRateHigh RateCreated
BwProcessTotalCpuPercentHigh TotalCpuPercent
For EM users, the following new Key Metrics have been added to the BW-PROCESS CI
Type:
Name Alert
---- -----
Process Avg Elapsed Time BwProcessAvgElapsedTimeHigh
Processes Created / sec BwProcessCreatedRateHigh
Process Total CPU Percent BwProcessTotalCpuPercentHigh
21382: History for Tomcat metrics now disabled by default
Tomcat history has been turned off by default.
To enable Tomcat history, add the following properties to your sample.properties
file:
collector.sl.rtview.sub=$TOMCAT_GLOBALREQUESTSTATS_TABLE:TOMCAT_GLOBALREQUESTSTATS
collector.sl.rtview.sub=$TOMCAT_WEBMODULESTATS_TABLE:TOMCAT_WEBMODULESTATS
collector.sl.rtview.sub=$TOMCAT_WEBMODULETOTALS_TABLE:TOMCAT_WEBMODULETOTALS
21409: Added AvgElapsedTime, AvgExecTime, and TotalCpuPercent to BwProcesses cache
The BW Process metrics Average Execution and AverageElapsed are now calculated by
dividing the delta execution or elapsed time for the interval by the delta
completed, or the number of process instances that completed in the interval.
Previously they were calculated by dividing the total execution or elapsed time
by the total number of process instanced (over all time).
Users will need to update the table structure of the BW_PROCESSES historian
tableby executing the following alter table SQL sentences in your selected
database administrative tool:
DB2:
ALTER TABLE "BW_PROCESSES" ADD "AverageExecution" BIGINT;
ALTER TABLE "BW_PROCESSES" ADD "AverageElapsed" BIGINT;
ALTER TABLE "BW_PROCESSES" ADD "TotalCpuPercent" DOUBLE;
SQL Server:
ALTER TABLE [BW_PROCESSES] ADD [AverageExecution] BIGINT;
ALTER TABLE [BW_PROCESSES] ADD [AverageElapsed] BIGINT;
ALTER TABLE [BW_PROCESSES] ADD [TotalCpuPercent] FLOAT;
MySQL:
ALTER TABLE "BW_PROCESSES" ADD "AverageExecution" BIGINT;
ALTER TABLE "BW_PROCESSES" ADD "AverageElapsed" BIGINT;
ALTER TABLE "BW_PROCESSES" ADD "TotalCpuPercent" DOUBLE;
Oracle:
ALTER TABLE "BW_PROCESSES" ADD ("AverageExecution" NUMBER, "AverageElapsed"
NUMBER, "TotalCpuPercent" REAL);
SyBase:
ALTER TABLE "BW_PROCESSES" ADD "AverageExecution" BIGINT NULL, "AverageElapsed"
BIGINT NULL, "TotalCpuPercent" FLOAT NULL;
21410: Enhancements to Activity metrics on Process displays
The trends on the BW Process Summary page have been enhanced as follows:
The Process Elapsed/Exec Time per Sec trends have been replaced with Average
Elapsed and Execution Time trends. A Total CPU Percent trend has been added. The
"All Activities Exec Count and Time" trends have been removed.
The BW All Processes table has also been enhanced as follows:
A Total CPU Percent column has been added, and the columns have been rearranged
to put the Key Metrics among the first columns displayed.
21411: Implement filter-in and filter-out patterns for process cache
The BwProcess cache has been enhanced with the ability to filter the processes by
name using regular expressions before they are added to the cache.
Two filter expressions may be set by using new properties in sample.properties.
Each property specifies a regular expression which will be applied to the process
name. If the name matches the pattern the process will be included.
To exclude processes, start the filter pattern with "^" (negation).
collector.sl.rtview.sub=$bwprocessFilterPattern:''
collector.sl.rtview.sub=$bwprocessFilterPattern2:''
For example, say you have these processes:
process01.process
process02.process
process03.process
process04.process
process05.process
process06.process
process07.process
If you set the first property as follows:
collector.sl.rtview.sub=$bwprocessFilterPattern:'0[3-5]'
you will get:
process03.process
process04.process
process05.process
If you set the second property as follows:
collector.sl.rtview.sub=$bwprocessFilterPattern:'0[^4]'
you will get, finally:
process03.process
process05.process
21433: BWAgentPlugin moved to bwmon\agents directory
The BWAgentPlugin files have been moved from bwmon\lib to
bwmon\agents\BWPluginAgent.
TIBCO EMS
19085: Expose bridge associations between related topics and queues
Two new menu options have been added to the contextual menu of the right button
of the mouse in the Bridges table from the EMS Bridges, Users, Ports for Server
display. The options are "Go to Source" and "Go to Target" that allow navigation
between bridged destinations.
In the case the end points of the bridge are unavailable destinations (e.g.
dynamically created), the corresponding option is disabled. The same behaviour
applies when the source destination of the bridge contains wild cards, the option
"Go to Source" is disabled as well.
Known Limitation: Due to the existence of two drilling down possibilities, the
Drill Down option from the contextual menu of the right button of the mouse is
enabled but non functional.
21333: New alerts to determine if Consumers have been idle for too long
Two new alerts, EmsQueueConsumerIdleTimeHigh and EmsTopicConsumerIdleTimeHigh,
have been implemented.
These alerts are attached to the newly added ConsumerIdleTime metric which is
included into the EmsQueuesExt and EmsTopicsExt caches. This metric computes the
time in seconds since an EMS Queue or Topic hasn't delivered any outgoing
message.
You should update the table structure of the EMS_QUEUESEXT and EMS_TOPICSEXT
caches by executing the alter table SQL sentences provided on 21412.
21379: History for Tomcat metrics now disabled by default
Tomcat history has been turned off by default.
To enable Tomcat history, add the following properties to your sample.properties
file:
collector.sl.rtview.sub=$TOMCAT_GLOBALREQUESTSTATS_TABLE:TOMCAT_GLOBALREQUESTSTATS
collector.sl.rtview.sub=$TOMCAT_WEBMODULESTATS_TABLE:TOMCAT_WEBMODULESTATS
collector.sl.rtview.sub=$TOMCAT_WEBMODULETOTALS_TABLE:TOMCAT_WEBMODULETOTALS
21389: New alerts Ems[Server|Queue|Topic]InboundDeltaHigh
Three new alerts have been added for the delta of inbound messages for EMS
Server, Queues, and Topics (EmsServerInboundDeltaHigh, EmsQueueInboundDeltaHigh,
and EmsTopicInboundDeltaHigh respectively), which will be triggered when the
number of new inbound messages has reached the threshold.
21395: Added deltas to the trends in Server, Queue, and Topic displays
The metrics associated with the Inbound and Outbound Message Rates for EMS
Server, Queue, and Topic in the corresponding Summary displays have been replaced
with calculated metrics based in their counts.
Additionally, a new check box, labelled "Use Rates", to toggle these trends
between rates and deltas has been implemented. By default this element is checked
and rates are displayed.
21412: ProviderIdleTime metric added for Queues and Topics
The ProviderIdleTime metric has been added to the EmsQueuesExt and EmsTopicsExt
caches. This metric computes the time in seconds since an EMS Queue or Topic
hasn't received any incoming message.
The existing EmsQueueProviderIdleTimeHigh and the EmsTopicProviderIdleTimeHigh
alerts are using these metrics.
You should update the table structure of the EMS_QUEUESEXT and EMS_TOPICSEXT
caches by executing the following alter table SQL sentences in your selected
database administrative tool:
DB2:
ALTER TABLE "EMS_QUEUESEXT" ADD "ProviderIdleTime" DOUBLE;
ALTER TABLE "EMS_QUEUESEXT" ADD "ConsumerIdleTime" DOUBLE;
ALTER TABLE "EMS_QUEUESEXT" ADD "MessageLatency" DOUBLE;
ALTER TABLE "EMS_TOPICSEXT" ADD "ProviderIdleTime" DOUBLE;
ALTER TABLE "EMS_TOPICSEXT" ADD "ConsumerIdleTime" DOUBLE;
ALTER TABLE "EMS_TOPICSEXT" ADD "MessageLatency" DOUBLE;
SQL Server:
ALTER TABLE [EMS_QUEUESEXT] ADD [ProviderIdleTime] FLOAT;
ALTER TABLE [EMS_QUEUESEXT] ADD [ConsumerIdleTime] FLOAT;
ALTER TABLE [EMS_QUEUESEXT] ADD [MessageLatency] FLOAT;
ALTER TABLE [EMS_TOPICSEXT] ADD [ProviderIdleTime] FLOAT;
ALTER TABLE [EMS_TOPICSEXT] ADD [ConsumerIdleTime] FLOAT;
ALTER TABLE [EMS_TOPICSEXT] ADD [MessageLatency] FLOAT;
MySQL:
ALTER TABLE "EMS_QUEUESEXT" ADD "ProviderIdleTime" DOUBLE;
ALTER TABLE "EMS_QUEUESEXT" ADD "ConsumerIdleTime" DOUBLE;
ALTER TABLE "EMS_QUEUESEXT" ADD "MessageLatency" DOUBLE;
ALTER TABLE "EMS_TOPICSEXT" ADD "ProviderIdleTime" DOUBLE;
ALTER TABLE "EMS_TOPICSEXT" ADD "ConsumerIdleTime" DOUBLE;
ALTER TABLE "EMS_TOPICSEXT" ADD "MessageLatency" DOUBLE;
Oracle:
ALTER TABLE "EMS_QUEUESEXT" ADD ("ProviderIdleTime" REAL, "ConsumerIdleTime"
REAL, "MessageLatency" REAL);
ALTER TABLE "EMS_TOPICSEXT" ADD ("ProviderIdleTime" REAL, "ConsumerIdleTime"
REAL, "MessageLatency" REAL);
SyBase:
ALTER TABLE "EMS_QUEUESEXT" ADD "ProviderIdleTime" FLOAT NULL, "ConsumerIdleTime"
FLOAT NULL, "MessageLatency" FLOAT NULL;
ALTER TABLE "EMS_TOPICSEXT" ADD "ProviderIdleTime" FLOAT NULL, "ConsumerIdleTime"
FLOAT NULL, "MessageLatency" FLOAT NULL;
21413: MessageLatency metric added to Queues and Topics caches
The MessageLatency metric has been added to the EmsQueuesExt and EmsTopicsExt
caches. This metric computes the time in seconds since an EMS Queue or Topic
hasn't received any incoming message.
The existing EmsQueueMsgLatencyHigh and the EmsTopicMsgLatencyHigh alerts are
using these metrics.
You should update the table structure of the EMS_QUEUESEXT and EMS_TOPICSEXT
caches by executing the alter table SQL sentences provided on 21412.
21451: Connections display enhanced with filtering options
New filtering options have been added to the EMS Connections for Server display.
- a "Show Active Only" check box to filter on the active connections
- a "Client ID FIlter" text box to filter by Client ID
21468: Improved performance when monitoring large environment
The calculation of the ProviderIdleTime and the ConsumerIdleTime for producers
and consumers for destinations has been enhanced to account for large
environments. This enhancement will only compute the idle time for those
destinations that have been active since the starting of the EMSMON data server.
The inactive destinations will have the ProviderIdleTime and the ConsumerIdleTime
set to zero.
21480: Fixed incorrect data for durable pending mesages
A missing index that prevented correct storage of pending message count and
pending message size in the EmsDurables cache and history has been fixed.
To upgrade, you should drop the EMS_DURABLES_TABLE from your RTVHISTORY data base
and recreate the table with the appropriate table creation SQL statement for your
platform. These statements are available in rtvapm\emsmon\dbconfig directory.
21489: Collecting queues and topics is now turned on by default
Collection of all available EMS Queues and EMS Topics has been enabled by
default. To avoid performance issues due to large amounts of destinations, the
collection of each type of data has been limited per EMS Server to 2,000 rows.
To modify this limit, use the following property, which is provided in
sample.properties:
collector.sl.rtview.jmsadm.maxMetricsRowCount=2000
Increase this limit with caution as performance issues may arise.
21493: Fixed incorrect In/Out msgs/sec in All EMS Queues/Topics for Server displays
A bug that prevented In/Out Msgs/sec below 1 msgs/sec from trending correctly in
the EMS Queues/Topics ->All Queues/Topics Summary displays has been fixed.
21509: Streamlined high/low alert logic for Topics/Queues
The function chain to process EMS Queue/Topics for high and low limits alerts has
been enhanced to improve performance.
TIBCO Hawk
21390: New hawk debug caches added to hawkmon
The hawkmon package (included in bwmon and amxmon) has been enhanced with new
caches that will assist in debugging problems with Tibco Hawk agents. The new
caches are:
HawkAgentStatus - This contains one row for each Hawk agent and shows the status
of that agent.
HawkConnections - This contains one row for each hawkconsole property line and
shows the status of that connection.
UX Monitor
21431: UX robot agent moved to uxmon\agents directory
An extracted copy of the UX Robot has been provided at uxmon\agents\UXRobot, and
the UXRobot_*.zip file has been moved from uxmon to uxmon\agents.
Version 3.2.0 Release Notes
Configuration
21256: New builder option to show properties definitions under App Options
The Display Builder Application Options dialog has been enhanced as follows to
better work with properties in EM:
1. The Save button in the Display Builder saves .ini configuration files which
are not compatible with EM. This button is now disabled to prevent accidental
saving of .ini configuration files.
2. A Show Properties button has been added which shows a dialog containing all of
the non-default property values in the currently selected category. You can copy
and paste these properties into your EM properties files.
General
21304: Selecting data server for components pages streamlined
The top level pages in the COMPONENTS tab that show the Select Data Server combo
have been enhanced as follows:
- The combo box now sets the selected data server without requiring the user to
click OK.
- The selected data server is validated to the first one of the correct type for
the selected component type.
Note that, as before, the Select Data Server combo is only visible when running
EM with multiple data servers of the same type.
21325: rtv_appmon_panels.xml removed from emsample
The file emsample\servers\central\rtv_appmon_panels.xml has been removed so that
the library version is used instead. This should not cause any change in user
projects as the library version of rtv_appmon_panels.xml is the same as the
emsample version that was removed.
Upgrade Notes: Users upgrading projects from versions previous to EM 3.2 should
remove the rtv_appmon_panels.xml file from their project directory if they want
to use the tab framework that was introduced in EM 3.0.
Monitor
21309: Display Server status icon accuracy improved
A bug that was causing the connection status of the Display Server in the
Architecture -> System Overview to sometimes be incorrect has been fixed.
21321: RTVCONFIG icon removed from Systems Overview page
The RTVCONFIG icon from the Architecture->Systems Overview display has been
removed.
RTVMGR
21303: RTView Server displays now show active RTVMGR server
The Data Server, Display Server and Historian displays have been enhanced to show
the currently selected RTVMGR data server.
21305: Function Stats display no longer uses direct jmx attachments
The Function Stats display, available from the Data Server Summary display, has
been enhanced. Previously, it required the thin client to have a JMX connection
to the selected server. Now, it uses the JMX connection from RTVMGR. If the
RTVMGR does not have a JMX connection for the selected Connection, the Function
Stats button is disabled.
RTView Core Functionality
18875: Support added for property groups for database properties
The properties database has been enhanced to support a new column, PROP_GROUP.
This column is used as an additional optional index when the database properties
are processed. Specify the property group for an application using the
-propgroup:xx command line option (where xx corresponds to a value in the
PROP_GROUP column of your database). If no -propgroup command line option is
used, it will query for rows where PROP_GROUP is an empty string.
Properties queried from the database are ordered as follows:
1. Order by PROP_GROUP according to the order of the -propgroup command line
options.
2. Within each PROP_GROUP, order by PROP_FILE according to the order of the
-properties command line options.
3. Within each PROP_FILE, order by PROP_FILTER according to the order of the
-propfilter command line options. Note that rows with blank PROP_FILTER that
match the PROP_GROUP and PROP_FILE filters are always included.
If your application reads properties from a database and you are using the
properties database from a previous release, run the following alter table
command on your database table to add the new column:
ALTER TABLE PROP_TABLE ADD PROP_GROUP VARCHAR DEFAULT ''
Builder - Editing
21221: Tab Control object no longer crashes the Builder if valueTable cannot be resolved
A bug in the tab control object (obj_c1tabs) has been fixed that caused the
Builder to throw a NullPointerException, or to perform an unexpected drilldown,
if a tab control's actionCommand was configured to perform a drilldown but the
control's valueTable property was attached to a nonexistent data table.
Builder - Property Dialogs
21074: Substitutions listbox in Builder no longer throws ArrayIndexOutOfBoundsException
In prior releases, the Builder would sometimes throw an
ArrayIndexOutOfBoundsException while updating the list of substitutions shown in
the property sheet. This is fixed.
Data Sources
21273: RTView now attempts to re-subscribe to failed subscriptions
A bug was introduce in version 6.0.2 that caused RTView not to attempt to
re-subscribe to failed subscriptions. This has been fixed.
Demos
19855: Demo applets updated to use signed jars
The RTView Core demo applets provided in the demo Apache Tomcat server
(servers\apache-tomcat-6.0.18-sl\webapps\ROOT) have been updated to use .jar
files signed with SL's certificate.
At this time, SL's certificate is valid until May 2018.
Functions
21262: Dataserver no longer turns inactive (zombie process) after an "Unlock Error"
A problem in the function data source has been fixed that could cause an
IllegalMonitorStateException to be thrown while updating a function.
General
21301: New stop_hsqldb script
New "stop_hsqldb" scripts for cleanly shutting down an HSQLDB instance are now
available.
The stop_hsqldb script requires a server.rc file in the directory you run it from
that is a counterpart to your server.properties file.
Example server.properties:
server.port=9099
server.database.0=file:../../DATA/alertdefs
server.dbname.0=alertdefs
server.database.1=file:../../DATA/rtvhistory
server.dbname.1=rtvhistory
Example corresponding server.rc:
urlid alertdefs
url jdbc:hsqldb:hsql://localhost:9099/alertdefs
username SA
password
urlid rtvhistory
url jdbc:hsqldb:hsql://localhost:9099/rtvhistory
username SA
password
All demos with HSQLDB instances have been updated to include a server.rc file.
21302: Support for enabling/disabling individual db properties
The properties database has been enhanced to support a new column, PROP_ENABLED.
This column is used to enable/disable the use of the property. This allows you to
temporarily disable the use of a database property without having to remove it
from the database.
If your application reads properties from a database and you are using the
properties database from a previous release, run the following alter table
command on your database table to add the new column:
ALTER TABLE PROP_TABLE ADD PROP_ENABLED INTEGER DEFAULT 1
Object Library
20625: Text properties handling in html5 chart improved
The following problems have been fixed in the thin client for trend chart objects
with webChartFlag enabled:
1). For obj_trendgraph02, the labelTextColor property now sets the color of the
axes labels and lines, as expected. Previously in the thin client the axes lines
and labels were always black.
2) For obj_trendgraph02, the labelTextFont and labelTextHeight property now set
the font used for the chart's title as expected. Previously they were ignored.
3) On mouseover, the text color of legend items no longer changes to black.
21219: bgClipTextFlag property now hidden for unsupported background styles
In the Builder the bgClipTextFlag property is hidden for the indicator objects
obj_ind_multi, obj_ind_limits, and obj_ind_discrete if the bgStyle is set to
Circle or Diamond, since the flag is only supported for rectangular background
styles.
In prior releases the bgClipTextFlag property was always visible but did not work
in those 2 cases.
Platform Support
20734: Deprecate Windows installers & Bundled Docs
The Windows Installers for RTView Core have been deprecated. Windows users should
now use the cross-platform .zip archive. Please see the documentation for more
instructions on how to install RTView.
Also, the User Guide is now available as a separate downloadable PDF, rather than
bundled in the product installation.
Scripts
21278: status_rtv.bat on Windows again shows Uptime, CPU, Heap
On Windows the status_rtv.bat script, while listing running dataservers, was
omitting the JMX info (e.g. Uptime 000:00:00:46 CPU 00:00:24 Heap 3.6% ...)
This has been fixed.
21328: Enhance stop scripts to stop HSQLDB
The stop_rtv scripts have been enhanced to stop the HSQLDB database if it is
running.
Solution Package
Host Infrastructure
20896: Agent now returns actual used memory, excluding buffer/cache memory
The Host Agent has been adjusted to return actual used memory via the Sigar API
mem.getActualUsed(), instead of used memory via Sigar API mem.getUsed(). The new
approach excludes buffer/cache memory.
Users who prefer the old method can continue to use the previous version of the
Host Agent.
IBM Websphere Application Server
19895: Users can now open multiple display windows to different sets of indices
The Solution Package for IBM WebSphere has been upgraded to use shared variables
instead of global variables, which allows users to drill down to different sets
of indices in different displays (using the "+" icon to open displays in a
seperate window).
20227: WSM server startup no longer unreliable on Windows
A bug that prevented WSM from loading properties correctly under Windows has been
fixed.
IBM Websphere MQ
19896: Users can now open multiple display windows to different sets of indices
The Solution Package for IBM MQ has been upgraded to use shared variables instead
of global variables, which allows users to drill down to different sets of
indices in different displays (using the "+" icon to open displays in a seperate
window).
Oracle Weblogic
19628: New configuration option to address JVM CPU % discrepancy
A new substitution has been added to address the discrepancy in the JVM CPU %
metric from Solaris systems and other OSes.
For Solaris systems, to match the JVM CPU % metric shown in the Single WebLogic
Server -> WLS JVM Summary display with the value obtained with standard tools,
add the following property to your properties file:
collector.sl.rtview.sub=$wlsJvmCpuPercentMultiplier:N
where N is the multiplier needed to match the measurements.
For example, if you have a difference in the hundreds, you should add:
collector.sl.rtview.sub=$wlsJvmCpuPercentMultiplier:0.01
21288: New KMs for WLS-JMS
New Key Metrics have been added for the WLS-JMS-SERVER and the
WLS-JMS-DEST CI Types. The key metric associated to these CI Types is
MessagesPendingCount.
Solace
21258: Syslog data acquisition now supported
Syslog data acquisition for solace message routers has been added to SOLMON. To
configure the syslog connection properties, copy the following properties into
your system properties file in the solmon project directory, uncomment the lines
that apply, and make appropriate changes to the connection parameters:
#####################################################
# SYSLOG CONNECTIONS
#
#For messages sent via TCP, use
#collector.sl.rtview.syslogds.conn=__name=syslogTCP protocol=TCP host=[hostname]
port=601
#collector.sl.rtview.cache.config=sol_syslog_cache_source.rtv $conn:syslogTCP
#For messages sent via UDP, use
#collector.sl.rtview.syslogds.conn=__name=syslogUDP protocol=UDP host=[hostname]
port=514
#collector.sl.rtview.cache.config=sol_syslog_cache_source.rtv $conn:syslogUDP
21259: New SolMsgRouterSyslog alert for syslog event messages
Syslog events with Severity WARN or higher are now incorporated into the RTView
Alert Framework through the SolMsgROuterSyslogAlert alert.
To trigger syslog event alerts under RTView, go to the Administration->Alert
Administration display in SOLMON or EM and enable the SolMsgRouterSyslog alert.
21276: Historical data disabled for all caches except appliance and vpns
Storage of historical metrics has been disabled on all SOLMON caches except for
SolAppliances and SolVpns.
To enable storage of historical data, edit the sample.properties file and
comment out the line associated to the cache you want to store historical data as
follows:
- For SolApplianceInterfaces cache:
#collector.sl.rtview.sub=$SOL_INTERFACE_TABLE:''
- For SolBridgeStats cache:
#collector.sl.rtview.sub=$SOL_BRIDGE_STATS_TABLE:''
- For SolClientStats cache:
#collector.sl.rtview.sub=$SOL_CLIENT_STATS_TABLE:''
- For SolEndpoints cache:
#collector.sl.rtview.sub=$SOL_ENDPOINT_TABLE:''
- For SolEndpointStats cache:
#collector.sl.rtview.sub=$SOL_ENDPOINT_STATS_TABLE:''
- For SolApplianceMessageSpool cache:
collector.sl.rtview.sub=$SOL_MESSAGE_SPOOL_TABLE:''
TIBCO BusinessEvents
21289: Node Table button added to Cluster Summary page for ease of navigation
To improve navigation, a Node Table button has been added to the Cluster Summary
display.
21327: "Up to All Clusters" button now navigates to correct display
Previously the Up button on the Node Table display did not correctly go to the
All Clusters display. This has been fixed.
TIBCO BusinessWorks
20858: BW Engine name with spaces now shows in alert message
The my_alert_actions.sh script (rtvapm/common/bin) failed to process the
AlertIndex field correctly if the value contained a space, and would pass "N/A"
to subsequent commands.
For example, a BW alert BWProcessExecutionTimeHigh is executed and the BW Engine
name contains a space, "prod.com-Process Archive1". The script sends an email,
and in the message the engine name appears as "N/A".
This has been corrected.
21260: Source column in sender/receiver configuration corrected
Previously, when BW Monitor dataservers were deployed in sender/receiver mode,
the dashboards did not show the correct Source column values. They should reflect
the name of the sender dataserver as configured by
sender.sl.rtview.sub=$rtvAgentName:MyMachineName
but instead the column showed "localhost".
This has been corrected.
TIBCO EMS
20818: Support EMSMON topology map in EM
A bug that prevented correct visualization of the All EMS Servers Topology
display has been fixed.
21181: All jmsadm calls removed from displays
The performance of the RTView EMS Monitor has been improved by redirecting all
JMS Admin calls through their corresponding caches.
TIBCO Hawk
21320: BwEngineCpuUsedHigh alerts now propagated to service level views
A bug that prevented BwEngineMemUsedHigh alert from being propagated to Service
level displays has been fixed.
Version 3.1.0 Release Notes
Configuration
20993: Only solution pack data servers that require TIBCO data sources include TIBCO data sources
Only solution pack data servers that require TIBCO data sources include TIBCO
data sources by explicitly including the -includetibco command line option. This
overrides the -notibco command line option which is now added by default.
Previously this was not the case.
Data Model
20888: Filter field added to CMDB Admin page
A text field has been added to the CMDB Admin page to filter the list of
available CIs. The filter string can be set up as plain text or a Regex.
General
21194: Moved per-sp jar, nav and citype def properties out of central.properties to new package ref properties
EM has been enhanced to simplify the content required in
emsmaple\servers\central.properties for each solution package. Several
per-solution package properties have been moved out of central.properties into
new properties files that are read from the solution package directories. In
order to reference those solution packages, a new entry is needed in
emsample\servers\rtview.properties.
For each solution package, the following properties are no longer needed in
central.properties:
sl.rtview.cmd_line=-rtvapm_packages:pck
sl.rtview.cp=%RTVAPM_HOME%/emsmon/lib/rtvapm_pck.jar
# CI Type Defs
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.emsmon.xml 0 rtvconfig.pck.xml
0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:pck
# Navigation
uiprocess.sl.rtview.xml.xmlsource=pck_navtree.xml 0 pck_navtree.xml 0 1
uiprocess.sl.rtview.xml.xmlsource=pck.navinfo.xml 0 pck.navinfo.xml 0 1
uiprocess.sl.rtview.cache.config=rtv_tabtree_cache_source_comp.rtv $package:pck
For each solution package, the following property is needed in rtview.properties:
rtvapm_reference=pck
For example, these lines for emsmon have been removed from central.properties:
sl.rtview.cmd_line=-rtvapm_packages:emsmon
sl.rtview.cp=%RTVAPM_HOME%/emsmon/lib/rtvapm_emsmon.jar
# CI Type Defs
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.emsmon.xml 0
rtvconfig.emsmon.xml 0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:emsmon
# Navigation
uiprocess.sl.rtview.xml.xmlsource=emsmon_navtree.xml 0 emsmon_navtree.xml 0 1
uiprocess.sl.rtview.xml.xmlsource=emsmon.navinfo.xml 0 emsmon.navinfo.xml 0 1
uiprocess.sl.rtview.cache.config=rtv_tabtree_cache_source_comp.rtv
$package:emsmon
And the following property is needed in rtview.properties:
rtvapm_reference=emsmon
The properties removed from central.properties can now be found in
RTVAPM_HOME\pck\conf\rtvapm.pck.ref.properties.
UPGRADE NOTES:
If you have created an EM project against a previous release:
No changes are required to projects created in previous versions. However, we
encourage you to modify your central.properties files to remove all of the
properties listed above for all solution packages and to add an rtvapm_reference
property to rtview.properties for each solution package you are using. This will
make it easier for you to merge changes to central.properties in future releases.
If you have created a custom solution package:
No changes are required. However, we encourage you to use the new properties file
shceme to make it easier to merge changes to central.properties in fugure
releases. Add a new file to the conf directory in your custom solution package
named rtvapm.pck.ref.properties (where pck is the name of your solution package).
For example rtvapm.emsmon.ref.properties. Add the following lines to your new
properties file (filling in your package name for pck). Once you have done this,
upgrade your project as listed above.
sl.rtview.cmd_line=-rtvapm_packages:pck
sl.rtview.cp=%RTVAPM_HOME%/emsmon/lib/rtvapm_pck.jar
# CI Type Defs
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.emsmon.xml 0 rtvconfig.pck.xml
0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:pck
# Navigation
uiprocess.sl.rtview.xml.xmlsource=pck_navtree.xml 0 pck_navtree.xml 0 1
uiprocess.sl.rtview.xml.xmlsource=pck.navinfo.xml 0 pck.navinfo.xml 0 1
uiprocess.sl.rtview.cache.config=rtv_tabtree_cache_source_comp.rtv $package:pck
If you are not using the standard EM run scripts:
No changes are required if you did not upgrade your project as listed above.
However, we encourage you to upgrade your project to make it easier to merge
changes to central.properties in the future. Look at the changes in
common\bin\rtvapm_common.bat/sh and apply the same changes to your custom
scripts. These scripts have been enhanced to look for rtvapm_reference in
rtview.properties and for all found, to add the
RTVAPM_HOME\pck\conf\rtvapm.pck.ref.properties properties file to the command
line.
21195: Simplified per-sp ci source lines in central.properties
EM has been enhanced to simplify the content required in
emsample\servers\central.properties for each solution package. The per-solution
package rtv_alerts_source.rtv, rtv_cistats_source.rtv and rtv_cimap_source.rtv
properties in central.properties have a new cisource property. For example, these
lines for the EMSMON solution packge in central.properties
AlertAggregator.sl.rtview.cache.config=rtv_alerts_source.rtv
$rtvDataServer:EMSMON-LOCAL
AlertAggregator.sl.rtview.cache.config=rtv_cistats_source.rtv
$rtvDataServer:EMSMON-LOCAL
AlertAggregator.sl.rtview.cache.config=rtv_cimap_source.rtv $ciType:EMS-SERVER
$rtvDataServer:EMSMON-LOCAL
AlertAggregator.sl.rtview.cache.config=rtv_cimap_source.rtv $ciType:EMS-QUEUE
$rtvDataServer:EMSMON-LOCAL
AlertAggregator.sl.rtview.cache.config=rtv_cimap_source.rtv $ciType:EMS-TOPIC
$rtvDataServer:EMSMON-LOCAL
Have been replaced with this single property:
AlertAggregator.sl.rtvapm.cisource=dataserver=EMSMON-LOCAL packages=emsmon
You can only have one cisource property per data server. The cisource property
supports 3 parameters:
dataserver - The name of the data server connection.
packages - A comma separated list of packages that are hosted on the data server.
All CI Types will be mapped for each package specified. This parameter is ignored
if the types parameter is specified.
types - A comma separated list of CI Types that are hosted on the data server.
This should be used when you do not want to map all CI Types for the packages
that are hosted on the data server.
This property supports updates. However, removing or editing a cisource property
will not remove mapping that have previously been added to the RTView CI Stats
tables.
UPGRADE NOTES
No changes are required to projects created in previous versions. However, we
encourage you to modify your central.properties files to replace the
rtv_alerts_source.rtv, rtv_cistats_source.rtv and rtv_cimap_source.rtv with the
new cisource property for each solution package you are referencing . This will
make it easier for you to merge changes to central.properties in future releases.
Key Metrics
20982: New CalcMode for percent values associated with low alerts
The Key Metrics feature has been enhanced to include a new CalcMode: invpct. This
CalcMode is used for KM's that are percent values associated with low alerts.
Monitor
21134: The date picker no longer generates incomplete date format.
In previous releases, the date chooser dialog in the trend graph views did not
set the end time correctly for servers that were not in the same time zone as the
client. This has been fixed.
Navigation
21129: Custom Views now filtered from Component tab
In the previous release of EM, the Custom Views nodes were not filtered out of
the Components tree. This has been fixed.
21130: Duplicate Hosts views under TIBCO ActiveMatrix removed
In the previous release, the Components tab navigation tree incorrectly contained
Host Views under TIBCO Active Matrix. This was a duplicate of the items in the
General Hosts section of the navigation tree. This has been fixed by removing the
Host Views from the TIBCO Active Matrix section of the navigation tree.
RTVMGR
20814: Display Servers display works again
The background state of the Display Server in the Administration -> System
Overview in the Admin tab has been fixed.
The list of Active Displays in the RTView Display Server display in the RTView
Servers section has been also fixed.
To designate the Display Server that the System Overview display gives the status
of, edit central.properties and modify the following substitutions with the
appropriate values for your system:
1. Display Server Connection Name (by default DISPLAYSERVER):
monitor.sl.rtview.sub=$rtvEmDisplayServerJmxConn:DISPLAYSERVER
2. Display Server Source (by default localhost):
monitor.sl.rtview.sub=$rtvEmDisplayServerJmxSource:localhost
3. RTVMGR Data Server Name (by default RTVMGR-LOCAL):
monitor.sl.rtview.sub=$rtvEmDisplayServerRtvmgr:RTVMGR-LOCAL
RTView Core Functionality
21152: Additional destination (topics/queues) metrics included from EMS Server
The following columns have been added to the EMS Topics cache:
prefetch
expiryOverride
store
The following columns have been added to the EMS queues cache:
prefetch
expiryOverride
store
deliveredMessageCount
Alerts
19820: Alert notifications no longer fail if invalid global file is specified in properties
In previous releases, if an invalid global file was specified in your properties
file, alert notifications failed to execute. This has been fixed.
Builder - Palette Handling
21046: Graph palette no longer sometimes shows only one object per row
A problem has been fixed in the Builder which sometimes caused the Graphs tab of
the Obejct Palette to display just one graph object per row, with extra spacing
on all sides, rather than packing as many objects per row as can fit.
Data Sources
20871: New Expiry field added to connection definition
A new field, Expiry, has been added to the definition of IBM MQ connections.
20977: New destination filter for Consumers and Producers metric data attachments
The TIBCO EMS Data Adapter has been enhanced to include pattern filters in the
collection of Producer and Consumer data. In the Attach To Data Dialog the
Pattern field now becomes visible when the metric is Producers or Consumers (as
for Topics and Queues).
These patterns will be used via the Admin API to select the destinations for
which Producer and Consumer data will be fetched when the data attachment is
updated. This will make the operations faster and more efficient, by virtue of
being more specific.
21146: Queries no longer made against inactive EMS servers configured with JSON
In version 8.1 of TIBCO EMS a change was made such that inactive EMS servers
configured with JSON could no longer be queried via the admin interface. The
TIBCO EMS data adapter has been enhanced to detect this condition and avoid
making the queries.
Display Server
21178: Copy Cell Value menu item supported in Chrome & Firefox
The thin client now supports the "Copy Cell Value" context menu item on the table
object, in Chrome 9version 43 or newer) and Firefox (version 41 or newer). This
menu item allows the user to copy a table cell's text contents to the clipboard.
Previously this menu item was only available in Internet Explorer.
General
20179: Support custom schedules for SQL queries
BACKGROUND:
A new Update Mode named "Run Query On Schedule" is now available in the Attach to
SQL Data dialog. When that mode is selected, a dropdown list labelled "Schedule
Name" appears, allowing the user to select the name of a schedule.
This new mode is intended to give users more control over when specific queries
are run. A schedule is defined by one or more rules. A rule specifies the days of
the week, hours of the day, and frequency during those hours that a query should
be run. A rule can also specify days of the week or specific dates on which a
query should not be run.
SCHEDULE AND RULE TABLE FORMATS:
The query schedules are defined in a table with these columns:
# Name : the unique name for the schedule
# Rules : the name(s) of the rules (see below) that define the schedule,
separated by commas
# Enabled : set Enabled = false to disable all queries that use the schedule
# Description : a description of the schedule
Schedule names should contain only letters, digits, space, underscore and dash.
They should not contain newlines, or tabs, or punctuation characters such as
colon, semicolon, or comma. The $ character should also not be used in a schedule
name to avoid conflicts with substitutions.
Each schedule is defined by one or more rules. The rules are defined in a table
with these columns:
# Name: the unique name for the rule
# Days: a list of days of the week (e.g Mon, Wed, Fri) or specific dates
(dd-MMM-yyyy) that this rule is in effect.
# Start Time: the time of day that this rule goes into effect, in 24 hour
HH::mm:ss format. If empty, 00:00:00 is used.
# End Time: the time of day that this rule is no longer effect, in 24 hour
HH:mm:ss format. If empty, 23:59:59 is used.
# Exception: If false, then when this rule is in effect the query is run at the
indicated interval. If true, then when this rule is in effect the query is NOT
run.
# Interval: the time interval between queries when this rule is in effect (e.g.
1m, 30m, 1h, etc).
# Enabled : if false the rule is never in effect.
# Time Zone: the name of the time zone for the rule (e.g. US/Central). A blank
string indicates the local time zone.
Rule names should follow the same restrictions as schedule names, described
earlier.
All of the column types in the rule and schedule tables are strings, except for
the Enabled and Exception columns, which are boolean.
EXAMPLES:
Here is a Rule Table with a few Rule examples:
Name Exception Days Start Time End Time Interval Time Zone Enabled Description
workdays_30m false Mon,Tue,Wed,Thu,Fri 09:00:00 17:00:00 30m true weekdays 9 - 5
every 30 min
weekends_9_12_15 false Sat,Sun 09:00:00 17:00:00 3h true weekends at 9am, noon,
3pm
lunch_hour_ex true Mon,Tue,Wed,Thu,Fri 12:00:00 12:59:59 true no queries during
lunch
holidays_2016_ex true 1-Jan-2016,4-Jul-2016,25-Dec-2016 true no queries during
holidays
workdays30m_central false Mon,Tue,Wed,Thu,Fri 09:00:00 17:00:00 30m US/Central
true weekdays 9 - 5 every 30 min in US/Central timezone
The "workdays_30m" rule will run a query every 30 minutes between 9 am and 5 pm,
Mon - Fri.
The "weekends_9_12_15" rule will run a query on weekends at 9am, noon, and 3pm.
The "lunch_hour_ex" rule is an exception rule and prevents a query from being run
between 12:00 and 12:59 on weekdays.
The "holidays_2016_ex" rule is an exception rule and prevents a query from being
run on 3 specific dates in 2016. (Note that this rule does not specify a Start
Time or End Time, so it is in effect for the entire day).
The "workdays30m_central" rule is the same as the "workdays_30m" rule, except
that it uses the US/Central timezone when checking the time of day against the
Start/End Time.
Here is a Schedule Table using some of the above rules:
Name Rules Enabled Description
Weekday30 9to5 workdays_30m, lunch_hour_ex, holidays_ex true weekdays @30 minutes
from 9 - 5, except lunchtime & holidays
AllWeek workdays_30m, weekends_9_12_15 true weekdays @30 minutes from 9 - 5,
weekends @ 9 & noon & 3pm
test_timezone workdays30m_central true weekdays 9 - 5, in central timezone
CREATING SCHEDULES AND RULES:
RTView does not provide any predefined rules or schedules nor does it provide a
UI for creating rules and schedules. Instead, the user can create a rule table
and schedule table in a database, an XML file, or any other table that can be
retrieved using an RTView data source. The tables must contain the columns
specified above.
The user must make the schedule table available to RTView by creating a global
function named RtvScheduleTable, using Function Type = Reference, and attaching
the function's Table argument to the XML file, or SQL query, or other rtview data
attachment that retrieves the schedule table. The attachment can specify a remote
Data Server if necessary.
Similarly, the user makes the schedule available to RTView by creating a global
function named RtvScheduleRuleTable, using Function Type = Reference, and
attaching the function's Table argument to the rtview data attachment that
retrieves the rule table.
If schedules and rules are added or modified at runtime, then the next update of
the data attachment used as the input to the RtvScheduleTable and
RtvScheduleRuleTable will apply those changes to all SQL queries using those
schedules and rules.
SCHEDULE SELECTION:
Typically, when configuring a scheduled query in the Attach to SQL Data dialog,
the user selects the name of a schedule from the Schedule Name dropdown list. But
there are two other possibilities: (1) The user can enter a substitution string,
e.g. $mySchedule or (2) the user can enter a list of rule names separated by
commas, e.g. rule1,rule2,rule3. The 2nd option creates an "anonymous schedule"
and is useful in the case where no schedule is defined with the desired set of
rules.
DIAGNOSTICS:
Two columns named Schedule and Next Query Time have been added to the
RTViewDS.Keys meta-table of the SQL data source. For each SQL query in the table,
the Schedule column shows the name of the Schedule, if any, configured for the
query. The Next Query Time shows the next time the query will be run according to
its schedule or, if the query doesn't have a schedule, the next time it will be
run according to its configured query interval. For Static and On Demand queries,
the Next Query Time will show 1/1/1970 GMT.
If the -sqltime option is specified, the console log will contain an additional
message for scheduled queries, indicating the next time the query will be run:
query for <schedule name>,<rule name> next due at <time>: <query string or query
ID>
For example:
query for Weekday30 9to5,workdays_30m next due at 2015-Oct-05 16:30:00: select *
from "plants"
The SQL data source checks for scheduled queries that should be run on each
update cycle. The default update cycle is 2 seconds. This means that a query will
typically be run within a second or two of its scheduled time. For example, if
the Next Query Time for a query is 16:30:00 the query may actually run between
16:30:00 and 16:30:02.
OPTIONS:
The accepted formats for days of the week, specific dates, and time zones in the
Rule table will be printed to the console if the option
-scheduler.dumpFormats:true is specified on the command line.
For time zone, names that don't specify daylight savings, such as "US/Eastern",
should be used.
To add additional formats for specifying dates in rules, use the property
sl.rtview.scheduler.dateFormat, for example:
sl.rtview.scheduler.dateFormat=MMM dd, yyyy
Security
21179: Check column names in servlet URL for code injection attacks
The rtvquery servlet will now encode any < or > characters that appear in the
"cols" parameter as < and > in the response, to avoid possible XSS hacks.
Scripts
19498: Fixed error in script update_wars_package.sh
The shell script rtvapm/common/bin/update_wars_package.sh used the Linux rename
utility which does not exist on some versions of UNIX. This has been corrected.
20961: start_rtv.sh, status_rtv.sh and stop_rtv.sh corrected for Mac
On Macintosh systems the start_rtv.sh script would give the error "command not
found" when trying to start a server. this has been fixed.
21051: RTView Processes now named in greater detail
When an Rtview process is launched it is given a Java argument of the form
-DPROCESS_NAME=xxx. Previously the value "xxx" was a generic tag such as
"dataserver". Now this will specifically identify the process by constructing a
tag from the line in rtvservers.dat used to launch the process.
The tag will be of the form {config name}_{server name}_{server JMX port}. For
example, the server "AlertServer" in the config "central" will be given the tag
central_AlertServer_10023.
This can be seen on Unix with ps:
> ps -ef | grep java
m 19558 1 0 06:29 pts/2 00:00:00 java -DPROCESS_NAME=central_AlertServer_10023
-DRTV_HOME=/u/rtvdemos/rtvapm/rtview
-DRTV_DEMOSERVER=/u/rtvdemos/rtvapm/rtview/servers/apache-tomcat-6.0.18-sl
-Xmx256m -Xms128m
-Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager
. . .
Or with jps (if available):
> jps -vV
19558 RTViewDataServer -DPROCESS_NAME=central_AlertServer_10023
-DRTV_HOME=/u/rtvdemos/rtvapm/rtview
-DRTV_DEMOSERVER=/u/rtvdemos/rtvapm/rtview/servers/apache-tomcat-6.0.18-sl
-Xmx256m -Xms128m
-Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager
Solution Package
Oracle Coherence
21202: Data Server Selection screen now drills down to to the Cluster Overview screen
The Oracle Coherence - Data Server Selection screen (the top level Middleware ->
Oracle Coherence screen in the Components tab) now drills down to the Cluster -
Overview screen (Middleware -> Oracle Coherence -> Cluster Views -> Overview) for
the selected data server. For a multi-cluster data server, the first cluster in
the cluster selector drop down will be selected.
Solace
20999: Optional display removed from navigation tree
The Endpoints – Single Endpoint Summary Rates display was inadvertently added to
the navtree. It is an optional display and should not appear by default.
21139: "Appliance" changed to "Message Router" throughout package
The term Appliance to refer to a solace device has been replaced by Message
Router in the navigation tree and the displays. Also Appliance has been changed
to MsgRouter in alert names and index types, e.g.
alertName="SolApplianceFailoverDetected"
description="The backup appliance in a HA pair has assumed control."
indexTypes="PerAppliance:Connection"
... changed to ...
alertName="SolMsgRouterFailoverDetected"
description="The backup message router in a HA pair has assumed control."
indexTypes="PerMsgRouter:Connection"
21184: Allow 7 days of data to show in trend charts
All trends in SOLMON have been reviewed to show 7 days of data.
21206: New Msg Router Capacity Table and Summary displays
All Message Router Capacity
This display allows you to view the Message Router Capacity data for all message
routers in a table format. You can view client, spool usage, incoming message,
outgoing message, incoming bytes, and outgoing bytes data for the message router.
Clicking on a row in the table displays the selected message router data in the
“Single Message Router Capacity” display.
Single Message Router Capacity
This display allows you to view the Message Router Capacity data for a specific
message router. You can view client, spool usage, incoming message, outgoing
message, incoming bytes, and outgoing bytes data for the message router.
21207: New Msg Router Capacity Trend display
This display allows you to view the Message Router Capacity data for a specific
message router in a trend graph format. You can view client, spool usage,
incoming message, outgoing message, incoming bytes, and outgoing bytes data for
the message router.
21208: Enhancements to SolAppliances and SolApplianceMessageSpool caches
The SolAppliances and SolApplianceMessageSpool caches have been enlarged with
more metrics and some have been included in history.
Two new caches, related to capacity displays, have been added:
SolApplianceCapacity and SolVpnCapacity.
The new metrics stored in history are the following:
SolAppliances cache:
- total-clients-connected
- total-egress-discards-per-sec
- total-ingress-discards-per-sec
- current-egress-byte-per-sec
- current-egress-per-sec
- current-ingress-byte-per-sec
- current-ingress-per-sec
SolApplianceMessageSpool cache:
- cur-spool-usage-in-mb
- active-disk-partition-usage
- standby-disk-partition-usage
- deliverd-unacked-msgs-util-pct
- ingress-flow-count
- queue-topic-subscriptions-used
- message-count-util-pct
- spool-files-total-used
- transacted-sessions-used
- transactd-session-res-util-pct
21209: New alerts related to capacity
New Message Router alerts have been added. These are the following:
SolMsgRouterActiveDiskUtilHigh: The utilization of the active disk partition for
the message router is excessive
SolMsgRouterByteEgressUtilHigh: The egress rate (bytes/sec) utilization (current
egress rate divided by max allowed) for the message router is excessive
SolMsgRouterByteIngressUtilHigh: The ingress rate (bytes/sec) utilization
(current ingress rate divided by max allowed) for the message router is excessive
SolMsgRouterConnectionUtilHigh: The connection utilization for the message router
(current number of connections divided by max allowed) is excessive
SolMsgRouterDelvrdUnAckMsgUtilHigh: The delivered unacked messages as a
percentage of all messages delivered for the message router is excessive
SolMsgRouterIngressFlowUtilHigh: The ingress flow utilization (current flows
divided by max allowed) for the message router is excessive
SolMsgRouterMsgCountUtilHigh: The message count utilization for the message
router is excessive
SolMsgRouterMsgEgressUtilHigh: The message egress rate utilization (current
message egress rate divided by max allowed) for the message router is excessive
SolMsgRouterMsgIngressUtilHigh: The message ingress rate utilization (current
message ingress rate divided by max allowed) for the message router is excessive
SolMsgRouterStandbyDiskUtilHigh: The utilization of the standby disk partition
for the message router is excessive
SolMsgRouterSubscriptionUtilHigh: The subscription utilization (current number of
subscriptions divided by max allowed) for the message router is excessive
SolMsgRouterTranSessionCntUtilHigh: The transacted session count utilization for
the message router is excessive
SolMsgRouterTranSessionResUtilHigh: The transacted session resource utilization
for the message router is excessive
21210: Change CIType SOLACE-APPLIANCE to SOLACE-MSGROUTER
The CI Type SOLACE-APPLIANCE has been changed to SOLACE-MSGROUTER. Central
Servers and SOLMON Data Server need to be restarted for this change to take
effect.
21211: New display Single Endpoint Summary Rates
This optional display, which is not visible by default, allows you to view
endpoint information, message data, and a trend graph for pending messages, spool
messages, incoming message rates, and outgoing message rates for a specific
endpoint connected to a message router/VPN combination. Choose a message router,
VPN, and an endpoint from the drop-down menus, and use the Time Range to
“zoom-in” or “zoom-out” on a specific time frame in the trend graph.
The “Single Endpoint Summary” display is provided by default and should be used
if you do not want to collect message spool data for specific VPNs. However, if
you do want to configure message spool monitoring for specific VPNs, then you
should use this display instead, which is not included in the navigation tree by
default.
To collect message spool data for specific VPNs, disable the Single Endpoint
Summary display, and enable the Single Endpoint Summary Rates display in the
navigation tree, perform the following steps:
1. Uncomment and copy the following line in your sample.properties file to
configure message spool monitoring for each VPN:
#collector.sl.rtview.cache.config=sol_cache_source_msg_spool.rtv
$solConn:UNIQUE_APPLIANCE_NAME $solVpnName:VPN_NAME
2. To edit the navigation tree, extract solmon.navtree.xml from the
rtvapm\solmon\lib\rtvapm_solmon.jar file and save it in the
emsample\servers\central directory.
3. In the solmon.navtree.xml file, comment out the following line:
<!--
<node label="Single Endpoint Summary" display="sol_endpoint_summary"></node>
-->
and add/uncomment this line:
<node label="Single Endpoint Summary Rates"
display="sol_endpoint_summaryWithRates"></node>
Once the file is edited and saved in emsample\servers\central directory, it will
get picked up automatically during startup.
Note: Collecting data for a large number of VPNs might impair the performance of
the appliance.
TIBCO BusinessEvents
20628: Connection and Node ID fields in BE summary page adjusted
On the Inference Node Summary and Storage Node summary displays the Connection
and Node ID values would sometimes overflow their corresponding text fields.
Those fields will now clip the string if it is too long, and display the full
string in the mouseover tooltip.
TIBCO EMS
20171: New destination (topics/queues) metrics added
Four new metrics for EMS Queues and EMS Topics have been added to the caches:
prefetch, expiryOverride, store, and deliveredMessageCount. These metrics are
collected by default.
20934: Better support for TIBCO EMS 8.2 and JSON configuration files
Multiple log messages coming from Fail Tolerant EMS Servers configured with JSON
have been fixed. Now, the log files will have a single message informing about
the inability to collect data from such servers.
21066: Query rates for EMS Server caches now configurable
A new substitution to configure the update period of EMS Server caches has been
added. This substitution is called $emsServerUpdatePeriod and is set by default
to 15,000 msec. To modify this default, include the following property in the
sample.properties file in your project directory:
collector.sl.rtview.sub=$emsServerUpdatePeriod:15000
and change the value to the appropriate update period for your system. Notice the
units of this substitution are milliseconds.
This same update period is used as well in the following caches:EmsAdmStats,
EmsBridges, EmsDurables, EmsRoutes, EmsFTServerTable, EmsListenPorts,
EmsServerRouteTable, EmsServerTable, EmsUsers, and EmsDestinations.
21067: Query update rates for queues and topics now configurable
Two new substitutions to configure the update period of EMS Queues and Topics
caches have been added.
These substitutions are called $emsTopicUpdatePeriod and $emsQueueUpdatePeriod
and are set by default to 30,000 msec. To modify these defaults, include the
following properties in the sample.properties file in your project directory:
collector.sl.rtview.sub=$emsQueueUpdatePeriod:30000
collector.sl.rtview.sub=$emsTopicUpdatePeriod:30000
and change the values to the appropriate update period for your system. Notice
the units of these substitutions are milliseconds.
21068: Query rate for Producer, Consumer, and Connections caches now configurable
Three new substitutions to configure the update period of EMS Producers,
Consumers, and Connections caches have been added.
These substitutions are called $emsProducerUpdatePeriod,
$emsConsumerUpdatePeriod, and $emsConnectionUpdatePeriod and are set by default
to 60,000 msec. To modify these defaults, include the following properties in the
sample.properties file in your project directory:
collector.sl.rtview.sub=$emsProducerUpdatePeriod:60000
collector.sl.rtview.sub=$emsConsumerUpdatePeriod:60000
collector.sl.rtview.sub=$emsConnectionUpdatePeriod:60000
and change the values to the appropriate update period for your system. Notice
the units of these substitutions are milliseconds.
21228: Disabled alerting for Fault Tolerant EMS servers
Alerting for FT Standby EMS Server has been disabled. Also, EMS Active Servers
that go down will automatically clear all alerts except EmsServerNotStarted if
their state change to non-active.
21243: Fixed navigation bug in All Topics Table and All Queues Table displays
A bug that prevented the correct counts of EMS Queues/Topics and the proper
drilling down from the All EMS Queues/Topics Table has been fixed.
UX Monitor
20743: UX Robot installers merged into one cross-platform archive
The UX Robot installation packages have been reduced to one multi-platform ZIP
package named "UXRobot_VERSION.zip" that contains both run_ux_robot.sh and
run_ux_robot.bat.
20994: Restored -propfilter:receiver to uxmon entry in rtvservers.dat
In the previus release of RTView EM, the file rtvservers.dat in
rtvapm/projects/emsample had an incorrect entry for the uxmon dataserver. This
has been corrected.
Version 3.0.0 Release Notes
Alerts
20920: RtvAlertStatsByCI MaxSeverity is sometimes incorrectly initialized as a string instead of an integer
In previous releases, the MaxSeverity column in the RtvAlertStatsByCI cache was
sometimes incorrectly initialized as a String instead of an Integer which
resulted in an error when storing the cache history to a database. This problem
has been fixed.
Drill Down
20899: Health State Display now drills down to correct CI when multiple dataservers
In previous releases, the Service Summary Views->Service Health Heatmap sometimes
did not drill down to the correct CI in the case where multiple CI's of the same
type in the same services were hosted on different servers. This problem has been
fixed.
General
20924: All option now supported in Services combo in service level displays
The Service Summary Views have been enhanced to support the All in the Service
combo box. When All is selected, the CI's in all Services in that Group and
Environment will be displayed.
20991: New icons in title area of main display
The back, up, data ok, new window, help and alert drilldown icons in the title
area of all displays have been updated.
21072: EM enhanced with new navigation framework
The EM user interface has been enhanced with a new look and feel that breaks up
the old navigation tree into tabs by category. Users upgrading projects or custom
solution packages from previous releases of EM will need to follow the
instructions in the Upgrade Notes section of the documentation in order to use
the new navigation framework. The new tabs are as follows:
SERVICE TREE - This tab shows your service model in the navigation panel with an
alert indication showing the highest alert state for that item. Click on an
Owner, Area, Group or Service to navigate to views for that item in the main
panel. Each level in the tree is associated with multiple displays which you can
access via the view combo box at the top left of the display. EM will remember
which display you used last for each level and use that display next time you
view an item at that level. Type a service into the Service Filter field and
click on the magnifying glass icon to filter the tree by that service name. Note
that the Service Filter is case sensitive. Enter * to show all services.
SERVICE VIEWS - This tab shows the same views as the Service Tree, along with the
Components Views and Metric Explorer, using the old navigation scheme.
COMPONENTS - This tab shows all Solution Package views organized by Technology
and Vendor. Previously, only a few nodes per Solution Package were included in
the navigation tree. The Components tab includes the full stand-alone tree for
each Solution Package. See the Customizing the Central Servers section of the
documentation for information on adding and removing Solution Packages in the
Components tab.
ALERTS - This tab shows your service model in the navigation panel with an alert
indication showing the highest alert state for that item and the Alert Table in
the main panel. Click on an Owner, Area, Group or Service to filter the Alert
Table. Type a service into the Service Filter field and click on the magnifying
glass icon to filter the tree by that service name. Note that the Service Filter
is case sensitive. Enter * to show all services.
ADMIN - This tab shows Alert and CMDB administration views as well as
Architecture views.
CUSTOM - This tab is included as a location for user-defined views. Some sample
views are included by default. For users with no user defined views, this tab can
be removed. See the documentation for instructions on adding your custom views to
this tab or removing this tab.
RTView Core Functionality
Configuration
20941: sl.rtview.dataserver and sl.rtview.cache.config properties now dynamic
The properties sl.rtview.dataserver and sl.rtview.cache.config now support
updates. This allows named data server connections and cache files to be added or
removed via properties at runtime.
Data Server
20910: RTVquery no longer hangs when the target data server re-boots
In previous releases, the rtvquery servlet would occasionally fail to respond to
queries after its target data server was restarted. This problem is fixed
20911: REST servlet enhanced for history queries
The URL applied to the rtvquery servlet now supports a parameter named "arr". If
the value of the arr parameter is 1 then, if fmt = json or jsonp, the javascript
array format will be used for data rows in the response. This is intended for use
with fmt=jsonp, to reduce the response size.
Also, server-side paging and sorting are now applied properly to queries on cache
history tables. In prior releases, the sorting and paging was applied incorrectly
which could give confusing results.
Data Sources
19866: Splunk data adapter no longer generates NullPointerException message.
In previous versions under certain circumstances, the Splunk data adapter would
generate a NullPointerException message. This is no longer the case.
20867: Improved performance of ConsumerDetails queries
The process of getting detail info on EMS Consumers has been optimized; customers
who have previously found it necessary to disable collection of this data may
find this is no longer necessary.
20967: ConsumerCount and ProducerCount added to the ServerInfo table
Two columns have been added to the jmsadm ServerInfo table: ProducerCount and
ConsumerCount. These are the total counts before any filtering is applied.
20975: Enhanced to work with rvtrace version 8.2.0+.
The TIBCO Rendezvous data source has been enhanced to work with rvtrace version
8.2.0+. In 8.2.0, TIBCO modified the rvtrace output to add the SCid and R columns
to the Multicast Packet Statistics source rows and to add the SCid column to the
Multicast Subject Staticstics source rows. The TIBCO Rendezvous data source has
added the SCid and R columns to the RTViewDs.MulticastPacketsSource table and the
SCid column to the RTViewDs.MulticastSubjectsSource table. The rvmonitor demo has
been updated to show these new columns.
Note that versions of rvtrace older than 8.2.0 are no longer supported in the
TIBCO Rendezvous data source.
Display Server
20929: New logout properly in multi-panel layout
In the thin client, clicking the Log Off item in the context menu will navigate
back to the login screen, after logging off the user.
Layouts
20966: New option to hide draggable divider on panel in thin client
In an RTView panels file with resizable dividers enabled, a panel can be
configured to hide its divider in the thin client by setting nodivider="true".
For example, in this panels file the divider that would normally appear below the
north panel is hidden:
<?xml version="1.0" ?>
<panels xmlns="www.sl.com" version="1.0">
<rtvLayout title="My Panels" dividers="true">
<rtvDisplayPanel region="north" display="title.rtv" nodivider="true"/>
<rtvAccordionPanel region="west" width="200" height="544" navdata="navtree.xml"/>
<rtvDisplayPanel region="center" name="main" display="test1"/>
</rtvLayout>
</panels>
The nodivider attribute is only supported in the thin client, it is ignored by
the viewer. It is also ignored on the center panel.
Licensing
20926: Generic PIN no longer returned on Red Hat Linux 7
The license registration process will now correctly obtain a non-generic PIN from
Redhat Linux 7 servers.
Object Library
20921: Tree/accordion L&F enhancements
Several properties have been added to the tree (obj_c1tree) and accordion
(obj_c1accordion) controls.
In all cases, the default value of the new property matches the default behavior
of the control in previous releases.
bgBorderFlag : This property appears in the Background category in the Builder's
property sheet, for the tree and the accordion. If bgBorderFlag is checked then a
1 pixel dark border is drawn around the control, otherwise no border is drawn. By
default the flag is checked and the border is visible, as it was in all prior
releases. [Note that the border color and width are not configurable, only the
visibility].
accordionCollapseFlag : This property appears in the Interaction category in the
Builder's property sheet, for the accordion only. If accordionCollapseFlag is
checked, only one branch of the accordion is open at a time. If the user clicks a
node to open another branch, then the previously open branch is automatically
closed. If accordionCollapseFlag is unchecked, opening another branch has no
affect on other open branches. By default the flag is checked, to match the
behavior in all previous releases.
nodeClosedImage/nodeOpenImage : These two properties appear in the Node category
in the Builder's property sheet, for the tree only. Use these properties to
specify the names of the images to be shown to the left of a closed/open parent
(non-leaf) tree node, respectively. By default these properties are blank,
indicating that the default closed/open images should be used, as in all previous
releases.
nodeSelectColor/nodeSelectTextColor : These two properties appear in the Node
category in the Builder's property sheet, for the tree only. Use these properties
to set the background and text colors for the selected tree node. If set to
"Default", then the platform or browser default selection colors are used.
In addition, two thin client problems have been fixed: (1) A problem specific to
IE9 has been fixed in which a drilldown triggered from an accordion control would
sometimes fail and leave the target panel in the "Loading..." state. (2) A
problem that caused the navigation panel containing a tree/accordion control or
occasionally other panels to have the incorrect initial size has been fixed.
20922: Padding and hovering enhancements for the tab control
Several properties have been added to the tab control(obj_c1tabs).
In all cases, the default value of the new property matches the default behavior
of the control in previous releases.
1. paddingVertical : Extra padding, in pixels, to add above and below the label
of each tab. This can be used to make the tabs taller without increasing the font
size.
2. paddingHorizontal : Extra padding, in pixels, to add to the left and right of
the label of each tab. This can be used to make the tabs wider, without
increasing the font size. The default value is zero.
3. webHoverTabColor: The background color for an unselected tab when the cursor
is over it. The default value is the same as the normal tab background color.
This property only affects the thin client, it is ignored in the builder/viewer.
4. webHoverTextColor: The text color for an unselected tab when the cursor is
over it. The default value is the same as the normal tab text color. This
property only affects the thin client, it is ignored in the builder/viewer.
20965: New properties to set selected tab bg and text color
The tab control (obj_c1tabs) supports new properties named selectBgColor and
selectTextColor to set the background and text color of the selected tab. The
default value for both is Default, meaning that the background color of the
selected tab will be a brighter shade of the unselected tabs in the thin client,
and a darker shade in the viewer, and the text color of the selected tab is the
same as the unselected tabs.
20985: Fixes to objects with webLabelFlag enabled
Two problems involving the webLabelFlag property have been fixed.
1. If a composite object has a command or drilldown defined, and the subdisplay
within the composite contains an label object with webLabelFlag = 1, then a click
on that label object does not trigger the composite's command or drilldown.
2. Link lines drawn between objects with webLabelFlag = 1 may be mispositioned.
Both problems are fixed.
20996: Enable copy to clipboard on multiselect Kendo grid
The text in selected row or rows of the web (kendo) grid can now be copied to the
clipboard by pressing Ctrl+c when the grid has keyboard focus.
Only text cells are copied. If a cell contains an image, its value is not copied
to the clipboard. The grid must have keyboard focus for the Ctrl+c keystroke to
have effect.
21006: New property rowSeriesTraceMode added to the bargraph object.
A property named rowSeriesTraceMode has been added to the bargraph object. This
allows row-series behavior to be enabled or disabled on the traces independently
of the row-series setting for the bars.
The default value of rowSeriesTraceMode is "Use rowSeriesFlag". With this value,
the row-series behavior is enabled or disabled on the bars and the traces by the
rowSeriesFlag property, as in previous releases.
To enable row-series behavior on the bars but not the traces, check the
rowSeriesFlag property and set traceRowSeriesMode = Off.
To enable row-series behavior on the traces but not the bars, uncheck the
rowSeriesFlag property and set traceRowSeriesMode = On.
Scripts
20963: Corrected start/stop/status shell script error on Solaris 11
In the latest release of RTView EM the "start_rtv.sh" script failed on
Solaris-11with this error: "shift: (null): bad number". This has been corrected.
20995: “stop_rtv.bat all” will now process all the entries in the rtvservers.dat file consistently
The command "stop_rtv all" on Windows (stop_rtv.bat) in the most recent version
did not correctly process the rtvservers.dat file. Processing would terminate
prematurely if it encountered uncommented configs with servers that were not
started.
This has been fixed.
Solution Package
Solace
20916: New Solace metrics to support capacity planning
New metrics have been added to the SolAppliances cache to support capacity
planning. The following table identifies the changes, listing both the xml name
from the SEMP reply, and the shortened name in the cache.
New Metrics for SolAppliances cache
XML name SolAppliances cache name
total-clients-connected-with-compression total-clients-connected-comprsd
total-clients-connected-with-ssl total-clients-connected-ssl
denied-authorization-failed denied-authorization-failed
denied-client-connect-acl denied-client-connect-acl
denied-subscribe-topic-acl denied-subscribe-topic-acl
current-ingress-rate-per-second current-ingress-per-sec
current-egress-rate-per-second current-egress-per-sec
average-ingress-rate-per-minute avg-ingress-per-min
average-egress-rate-per-minute avg-egress-per-min
current-ingress-byte-rate-per-second current-ingress-byte-per-sec
current-egress-byte-rate-per-second current-egress-byte-per-sec
average-ingress-byte-rate-per-minute avg-ingress-byte-per-min
average-egress-byte-rate-per-minute avg-egress-byte-per-min
zip-stats.ingress-compressed-bytes ingress-comp-bytes
zip-stats.ingress-uncompressed-bytes ingress-uncomp-bytes
zip-stats.current-ingress-compressed-rate-per-second current-ingress-comp-per-sec
zip-stats.average-ingress-compressed-rate-per-minute avg-ingress-comp-per-min
zip-stats.current-ingress-uncompressed-rate-per-second
current-ingress-uncomp-per-sec
zip-stats.average-ingress-uncompressed-rate-per-minute avg-ingress-uncomp-per-min
zip-stats.egress-compressed-bytes egress-comp-bytes
zip-stats.egress-uncompressed-bytes egress-uncomp-bytes
zip-stats.current-egress-compressed-rate-per-second current-egress-comp-per-sec
zip-stats.average-egress-compressed-rate-per-minute avg-egress-comp-per-min
zip-stats.current-egress-uncompressed-rate-per-second
current-egress-uncomp-per-sec
zip-stats.average-egress-uncompressed-rate-per-minute avg-egress-uncomp-per-min
ssl-stats.ingress-ssl-bytes ingress-ssl-bytes
ssl-stats.current-ingress-ssl-rate-per-second current-ingress-ssl-per-sec
ssl-stats.average-ingress-ssl-rate-per-minute avg-ingress-ssl-per-min
ssl-stats.egress-ssl-bytes egress-ssl-bytes
ssl-stats.current-egress-ssl-rate-per-second current-egress-ssl-per-sec
ssl-stats.average-egress-ssl-rate-per-minute avg-egress-ssl-per-min
New metrics have been added to the SolApplianceMessageSpool cache to support
capacity planning. The following table identifies the changes, listing both the
xml name from the SEMP reply, and the shortened name in the cache.
New Metrics for SolApplianceMessageSpool cache
XML name SolApplianceMessageSpool cache name
message-count-utilization-percentage message-count-util-pct
spool-files-utilization-percentage spool-files-util-pct
transacted-session-count-utilization-percentage transacted-session-cnt-util-pct
transacted-session-resource-utilization-percentage
transacted-session-res-util-pct
delivered-unacked-msgs-utilization-percentage delivered-unacked-msgs-util-pct
spool-files.total-used-percent spool-files-total-used-pct
spool-files.total-used spool-files-total-used
message-spool-entities-used-by-dte message-spool-used-by-dte
New metrics have been added to the SollVpns cache to support capacity planning.
The following table identifies the changes, listing both the xml name from the
SEMP reply, and the shortened name in the cache.
New Metrics for SolVpns cache
XML name SolVpns cache name
max-subscriptions max-subscriptions
max-connections max-connections
stats.ingress-compressed-bytes ingress-compressed-bytes
ingres-compressed-bytes-per-sec (calculated)
stats.egress-compressed-bytes egress-compressed-bytes
egress-compressed-bytes-per-sec (calculated)
stats.average-egress-byte-rate-per-minute avg-egress-byte-per-min
stats.average-egress-rate-per-minute avg-egress-per-min
stats.average-ingress-byte-rate-per-minute avg-ingress-byte-per-min
stats.average-ingress-rate-per-minute avg-ingress-per-min
stats.current-egress-byte-rate-per-second current-egress-byte-per-sec
stats.current-egress-rate-per-second current-egress-per-sec
stats.current-ingress-byte-rate-per-second current-ingress-byte-per-sec
stats.current-ingress-rate-per-second current-ingress-per-sec
TIBCO ActiveSpaces
21085: Button positions adjusted for consistency
The back and up button positions have been adjusted so that their position is the
same on all of the displays in the Tibco ActiveSpaces monitor. This eliminates
the "wiggle" effect seen when flipping thru the screens quickly.
TIBCO BusinessWorks
20764: Checkboxes to control labels added to BW Monitor heatmaps
In the BW Monitor heatmap displays for Engines, Processes, and Activities, the
slider which controlled the visibility of the heatmap labels has been replaced
with checkboxes, following the standard for EM displays.
TIBCO EMS
19007: EmsQueues|TopicsProducer alerts overrides can now be set
EmsQueuesProducerCountHigh, EmsQueuesProducerCountLow,
EmsTopicsProducerCountHigh, and EmsTopicsProducerCountLow have been fixed to set
properly overrides.
20104: Fixed errors in emsmon dataserver.log: alertConsumerStalled
An error in the dataserver log file about alertConsumerStalled has been fixed.
20655: High Availability configuration finalized
An ommission that prevented out-of-the-box configuration of High Availability for
EMSMON has been fixed.
20730: EmsConsumerStalled description enhanced to include min. uptime server sub
The description of the EmsConsumerStalled alert has been improved to include
description of the minimum startup time (default 5 minutes), during which this
alert will not be triggered.
20821: EMS Summary consumers and producer count now more accurate
The EMS Single Server Summary display has been modified so that the Producer and
Consumer count fields are taken directly from the EMS server data. This has two
implications:
1. The values will be non-zero if collection of consumer and producer data is
disabled.
2. If collection of consumer and producer data is enabled, the counts shown will
differ from the row counts of the corresponding tables, because the tables as
displayed are filtered to remove irrelevant rows (system, temporary, etc.)
20970: Corrected discrepancy between queue counts across displays
Queue counts from the EMS Server Summary are now consistent with the value
displayed at the EMS Queues->All Queues for Server display. The total and the
filtered counts as well as the regex patterns being used are provided also in the
associated help button.
20971: Corrected discrepancy between topic counts across displays
Topic counts from the EMS Server Summary are now consistent with the value
displayed at the EMS Topics->All Topics for Server display. The total and the
filtered counts as well as the regex patterns being used are provided also in the
associated help button.
20972: Corrected discrepancy between connection counts across displays
Connection count from the EMS Server Summary is now consistent with the value
displayed at the EMS Clients->Connection display. The total and the filtered
counts as well as the regex patterns being used are provided also in the
associated help button.
Version 2.3.0 Release Notes
Key Metrics
20799: Service level heatmaps sometime show no node borders
In previous releases, if you navigated to one of the Key Metrics Views before
viewing any of the heatmap displays under All Management Areas, Multi-Area
Service Views or Service Summary views, the heatmap node borders were lost. This
has been fixed.
Monitor
20875: New combo box to toggle between the Current and History alert views
The RTView Alerts Table and Alert History Table have been enhanced to support a
navigation combo box. This combo box allows you to toggle between the Current and
History alert views.
Navigation
20766: Drilldown navigation now defaults to last viewed display in display group
The EM navigation for the following sections in the navigation tree has been
enhanced to re-use the last viewed display per section:
All Management Areas
Multi Area Service Views
Single Area Service Views
Service Summary Views
Key Metrics Views
In previous releases, when navigating from within a display to a display in a
different section of the navigation tree, the drill down display was hardcoded.
Now the displays use the last viewed display as follows:
1. The displays under All Management Areas drill down to the last viewed display
in the Multi-Area Service Views.
2. The displays under Multi Area Service Views drill down to the last viewed
display in the Service Summary Views or KM Metrics Views. The up button on the
Multi Area Service Views drill up to the last viewed display in All Management
Areas.
3. The displays under Single Area Service Views drill down to the last viewed
display in the Service Summary Views or KM Metrics Views. The up button on the
Single Area Service Views drill up to the last viewed display in All Management
Areas. Note that the Single Area Service Views are commented out of the emsample
navigation tree by default.
4. The displays under Service Summary Views and Key Metrics Views drill up to the
last viewed display in Multi-Area Service Views.
For example, you drill down on an All Management Areas display which navigates to
Multi-Area Service Views->Group / Service Heatmap. In that display, you select By
Region from the navigation combo box. The next time you drill down on an All
Management Areas display, it will navigate to Multi-Area Service Views->Region/
Service Heatmap since that was the last display viewed in the Multi-Area Service
Views section.
A few additional changes have also been made:
1. By CI Type and History have been added to the navigation combo box on the
Multi-Area Service Views.
2. The navigation combo box on the Component Views has been standardized across
all views to contain Tree, CMDB, Heatmap, Table which corresponds to the 4
displays in the Component Views section of the navigation tree.
3. Support for the following substitutions has been removed:
$rtvNavServiceHeatmapDisplayName
$rtvNavServiceTableDisplayName
$rtvNavServiceHeatmapDisplayName
$rtvNavServiceTableDisplayName
$rtvNavAppDisplayName
RTView Core Functionality
Alerts
18023: Alert ds no longer crashes if if indexTypes syntax is incorrect
In previous releases, the alert data source threw a NullPointerException if there
was a syntax error in the indexTypes property. This has been fixed.
Builder
20693: Builder no longer fails on Mac with JDK 1.7 or greater
The RTView Builder no longer fails on Mac with JDK 1.7 or greater.
Commands
17078: Data attachments in multi-commands now work in thin client
In prior releases, data attachments used in commands within a multiple command
did not work in a display server deployment. This is fixed.
Data Historian
19992: New Smooth Compaction configuration options
New arguments have been added to customize how compaction smoothing is performed.
-smoothingonly
Run smoothing only without data being provided
-smoothcompaction:table1,table2
Restrict the tables being smoothed to those specified
Data Sources
18403: Fixed cache bug with maxNumberOfCurrentRows and blank timestampColumnName
The cache data source no longer throws a NullPointerException if a cache has
maxNumberOfCurrentRows > 0 and a blank timestampColumnName.
20692: Fixed bogus timeout of sql query
A problem has been fixed in the SQL datasource which would sometimes cause a
query to fail with a bogus timeout error showing a very large and incorrect
timeout value.
20767: xml parser no longer throws exception if token >= 8192 chars
In previous releases, the JMS and XML data sources would throw an
ArrayIndexOutOfBoundsException if an XML string token contained 8192 or more
characters and none of those characters was a space. This is fixed.
20895: Time range no longer ignored in cache history attachment if multi-column filter value = *
The following bug in the cache data source has been fixed: If an attachment to a
cache history table specifies a time range, and also specifies a filter on
multiple columns but the filter value for each of those columns is * then the
time range is ignored and all rows from the history table are returned.
Display Server
19512: Support audio and threshold command in thin client
The thin client now supports the Play Audio File command and threshold commands.
In addition, a new property named valueCommandResetTrigger has been added to the
display objects that support threshold commands.
-------------------
Play Audio File command:
The thin client now supports the Play Audio File command. The support for audio
file formats varies by platform, as follows.
- The Play Audio File command is not supported in Internet Explorer version 8 and
older.
- In a desktop browser (Internet Explorer 9 or newer, Firefox, Chrome) .wav and
.mp3 files are supported. However, Internet Explorer uses the Windows Media
Player to play .wav files, which may require user confirmation or may fail due to
security settings.
- In mobile browsers (e.g. Safari on iOS) only .mp3 files are supported, and the
user must click on the "Enable Audio" button that appears in a display the first
time an audio command is executed.
- The "Beep" command is still not supported in the thin client.
Note that in the builder/viewer, only .wav files are supported by the Play Audio
File command. This has always been the case and has not changed in this release.
---------------------
Threshold command:
There are four objects that support threshold commands: obj_circ2d_ilvx_ra4,
obj_rect_ilvx_ra4, obj_circ2d_ilvx_da3, and obj_rect_ilvx_da3. A threshold
command can be defined using any of the properties named value*Command on those
objects.
In this release, if the webChartFlag property is checked on an object with a
threshold command, the threshold command will be executed in a thin client
deployment when appropriate. In prior releases, threshold commands were ignored
in a thin client deployment.
If the threshold command is a supported client-side command it will be executed
in the browser. The client-side commands are: Play Audio File, Drilldown/Set
substitution, Execute Custom Command (if the custom command has a javascript
implementation), Open Browser. All other commands are executed by the display
server or (for a data source command) in the data server.
A new property named valueCommandResetTrigger was added to the objects that
support threshold commands. Typically, once a threshold command has been executed
by one of those objects because the value exceeds or equals a limit, the command
will not execute again until the value exceeds another limit. But now, if the
value of valueCommandResetTrigger property is changed, then the object's
threshold command will be executed again even if the value property has not
changed. Changing the value of valueCommandResetTrigger when the object's value
is not at or above a limit has no effect.
19979: Added Sessions table to display server mbean
The Display Server's JMX Manager mbean supports a new tabular attribute named
Sessions. The Sessions table contains one row for each active client session.
Typically, there will be one client session for each browser instance that is
currently viewing a thin client display.
The Sessions table contains the following columns.
- Session ID: unique ID for client session
- Client Address: the IP address of the client.
- Duration: elapsed time since this client session was created.
- Last Reference Time: elapsed time since this client opened or refreshed a
display.
- User: the login user name
- Role: the login user role
Notes on each column:
The Session ID is also a column in the mbean's DisplayData table, which contains
one row for each display that is currently open in a thin client. The Session ID
is a unique string assigned to a session by RTView and is not the same value as
the session identifier assigned by the webapp mananger (tomcat).
The Client Address will be in IPv4 (e.g. x.x.x.x) or IPv6 (x:x:x:x:x:x:x:x)
notation, depending on which protocol the client browser used to connect to the
rtvdisplay servlet. For example, if the client is on localhost then the client
address could be shown as 127.0.0.1 for IPv4, or 0:0:0:0:0:0:0:1 for IPv6.
The Duration column and the Last Reference Time column show elapsed time as "d
hh:mm:ss" where d = days, hh = hours, mm = minutes, and ss = seconds.
By default, a session expires and is removed from the table after about 10 or 11
minutes of inactivity (that is, when the elapsed time shown in the Last Ref Time
column is "0 00:11:00" or more). If the display server's display_timeout property
has been set, then the session expiration is 10 times the display_timeout value.
(The default display_timeout is 60 seconds).
The User and Role columns will be blank if the login feature of the rtvdisplay
servlet is disabled.
20679: Table row selection in AW grid no longer unreliable in IE >= 10
In previous releases, when using the thin client in IE 10 and 11, after
performing a drilldown from a table object subsequent row clicks in the same
table may be ignored. This is fixed.
Functions
20846: New function Execute Java Method
Introduction
The Execute Java Method function allows the user to write code for a Java method
that will be executed when the function is updated. The method can take zero or
more arguments of type String, Integer, Double, or GmsTabularData, and it can
return an object of any of those same types.
The Java code is saved with the display (.rtv) file that contains the function.
On the first update, the function compiles the given java code. Then, on all
updates, the function applies the given arguments to the compiled method and
executes it.
The Execute Java Method function is intended for implementing a 'one-of-a-kind'
java method that is useful on a single RTView display, in cases where the
Evaluate Expression functions are not adequate or perform poorly, and the
reusability of a custom function implementation is not required or is
inconvenient.
Requirements
- The Java Development Kit (JDK) must be installed on systems which will be used
to configure or run the Execute Java Method function. The Java Runtime Kit (JRE)
is not sufficient since it does not include the java compiler tools.
- The person configuring the Execute Java Method function must be familiar with
Java.
- The person configuring the Execute Java Method function should be familiar with
the com.sl.gmsjrt.GmsTabularData class, as described in the RTView customization
document, if the function will deal with tabular data.
- The Code argument of the function must be a valid code string for a Java method
named eval with this signature: public Object eval()
- The method can take zero or more arguments of type String, Integer, Double, or
GmsTabularData.
- The method's return type must be Object, and the returned Object must be a
String, Integer, Double, or GmsTabularData instance.
- The heap usage of the RTView application increases by about 6 to 10 MB to
support the compiler.
Recommended usage:
The Execute Java Method function is a useful feature but it should be use when
appropriate, to avoid maintenance and performance problems.
- The Execute Java Method function is intended for implementing a 'one-of-a-kind'
java method that is useful on a single RTView display, since its result can only
be used on the same display (.rtv file) in which it is defined. If a method is
needed on multiple RTView displays then it should be implemented in an RTView
custom function handler class, instead.
- The display containing the Execute Java Method function must only be deployed
on systems with the JDK installed, otherwise the function's java code will not be
compiled.
Configuration:
The internal name of the function is EVALJ. Its external name is "Execute Java
Method". It appears just after "Evaluate Expression as String" in the dropdown
list in the Builder's Edit Function dialog.
The function takes one predefined string argument named Code, plus any number of
user-defined arguments as described later. The Code string must be a java method
named eval with this signature: public Object eval(args) For each new instance of
the function, the Edit Function dialog will set the Code string to a "skeleton"
implementation of the eval method as shown below:
public Object eval() {
return "";
}
The eval method can take zero or more arguments of type String, Integer, Double,
or GmsTabularData. The method's return type must be declared as Object, but it
can return a String, Integer, Double, or GmsTabularData object.
The arguments declared for the eval() method become arguments to the rtview
function instance, just like the %x, %y tokens in an Evaluate Expression
function. For example, here is a simple eval method that concatenates two String
args named s1 and s2:
public Object eval(String s1, String s2) {
return s1 + ":" + s2;
}
In the Edit Function dialog, s1 and s2 will appear as argument fields so their
values can be assigned to constants or attached to data:
Here is a more complex example that takes a GmsTabularData argument. The input
table is assumed to have an integer column named Value, and the function returns
a copy of the input table with all rows removed where the Value column item is <
25 or > 75. The method makes use of utility methods named cloneInputTable and
printErrorMessage, which are defined in the base class named
com.sl.gmsjrtview.GmsJavaCodeExecutor:
public Object eval(GmsTabularData t) {
if (t == null)
return t;
int valCol = t.getColumnIndex("Value");
if (valCol < 0) {
printErrorMessage("no Value column in table");
return t;
}
ArrayList<Integer> rowsToRemove = new ArrayList<Integer>();
for (int row = 0; row < t.getNumRows(); ++row) {
int val = t.getIntCellValue(row, valCol);
if (val < 25 || val > 75) {
rowsToRemove.add(row);
}
}
if (rowsToRemove.size() > 0) {
// don't modify input table, clone it
t = cloneInputTable(t);
t.removeRows(rowsToRemove);
}
return t;
}
For documentation on the GmsTabularData and GmsJavaCodeExecutor classes, refer to
the javadoc pages in the customization section of the RTView documentation.
Compilation:
The java code entered as the value of the Code argument for a function named F101
is used to generate the source code for a subclass of
com.sl.gmsjrtview.GmsJavaCodeExecutor, as follows:
package rtvfuncs;
import com.sl.gmsjrt.GmsTabularData;
import com.sl.gmsjrtview.*;
import java.util.*;
public class F101_Cnn extends com.sl.gmsjrtview.GmsJavaCodeExecutor {
// begin user-defined code
public Object eval() {
return "";
}
// end user-defined code
}
The suffix _Cnn on the generated class name is not significant and will vary. The
source code for the class will be generated and compiled the first time the
function is updated after the .rtv file is loaded. In the Builder, source code
for the class will also be generated and compiled each time the user changes the
code for the eval method and clicks OK or Apply. The compiler will use the same
classpath as the RTView application.
No external .java or .class files are produced for an Execute Java Method
function. All source generation, compilation, and class loader operations are
performed using memory buffers. The user-defined java code for the eval method is
saved with the function in the .rtv file.
As shown above, the generated source code imports com.sl.gmsjrtview.*,
com.sl.gmsjrt.GmsTabularData, and java.util.*. If additional imports are needed
they can be defined on lines above the eval() method in the Code argument, or
globally with a property named sl.rtview.function.compiler_import. For example,
these lines could be added to an rtview .properties file to import java.sql.* and
java.math.* for all function instances:
sl.rtview.function.compiler_import=java.sql.*;
sl.rtview.function.compiler_import=java.math.*;
Compiler errors are logged to the console. The complete generated source code, as
described above, is shown before the compiler error so that the user can make
sense of the line numbers in the error message.
Examples:
The following eval() implementation returns a table with 2 columns, "Name" and
"Value", where the Name column contains "this is row N" and the Value column
contains a random integer between 0 and 100. The number of rows in the table is
determined by the numRows argument. The "trigger" argument could be attached to
the result of a "Date Now" function, to trigger the function periodically.
Otherwise it will only update once.
public Object eval(int numRows, String trigger) {
GmsTabularData t = new GmsTabularData();
t.addColumn("Name", GmsTabularData.STRING);
t.addColumn("Value", GmsTabularData.INTEGER);
for (int row = 0; row < numRows; ++ row) {
String name = "this is row " + row;
int val = (int) (Math.random() * 100);
t.addRow("");
t.setCellValue(name, row, 0);
t.setCellValue(val, row, 1);
}
return t;
}
This eval method takes a table as an argument. The input table is assumed to have
an integer column named Value (e.g. the table returned from the previous
example), and the function returns a copy of the input table with all rows
removed where the Value column item is < 25 or > 75:
public Object eval(GmsTabularData t) {
if (t == null)
return t;
int valCol = t.getColumnIndex("Value");
if (valCol < 0)
return t;
ArrayList<Integer> rowsToRemove = new ArrayList<Integer>();
for (int row = 0; row < t.getNumRows(); ++row) {
int val = t.getIntCellValue(row, valCol);
if (val < 25 || val > 75) {
rowsToRemove.add(row);
}
}
if (rowsToRemove.size() > 0) {
// don't modify input table, clone it
t = cloneInputTable(t);
t.removeRows(rowsToRemove);
}
return t;
}
This eval method implements a simple counter function. It declares an integer
member variable named "count" and increments it on each update and returns the
new count. The "trigger" argument could be attached to the result of a "Date Now"
function, to trigger the function periodically. Otherwise it will only update
once.
private int count = 0;
public Object eval(String trigger) {
return ++count;
}
This eval method implements a counter function, similar to the previous example,
but it demonstrates the use of the skipUpdate() method to prevent updating the
function result in certain cases:
private int count = 0;
public Object eval(String trigger) {
++count;
if (count % 5 == 0) {
// don't update result for multiples of 5
System.out.println("skip counter update: " + count);
skipUpdate();
}
return count;
}
This eval method takes a table as an argument. The input table is assumed to have
an string column named Status (e.g. production_table in update.xml produced by
the RTView xml data simulator). The function returns a copy of the input table
with the string in the Status column truncated to the length specified by the
second argument, numCharsForStatusCol:
public Object eval(GmsTabularData prodTable, int numCharsForStatusCol) {
if (prodTable == null || prodTable.getNumRows() < 1)
return prodTable;
prodTable = cloneInputTable(prodTable);
int statusCol = prodTable.getColumnIndex("Status");
if (statusCol < 0) {
printErrorMessage("no Status column");
return prodTable;
}
for (int row = 0; row < prodTable.getNumRows(); ++row) {
String sts = prodTable.getCellValue(row, statusCol);
if (sts != null && sts.length() > numCharsForStatusCol) {
sts = sts.substring(0, numCharsForStatusCol);
prodTable.setCellValue(sts, row, statusCol);
}
}
return prodTable;
}
General
20326: New -version flag that prints version information without starting the app
Each of the RTView applications now supports a -version option on the command
line which will cause the app to print the RTView version information and then
exit immediately.
For example:
run_dataserver -version
20815: Fixed array index exception thrown when client receives bad table delta
A bug has been fixed that in certain conditions caused an
ArrayIndexOutOfBoundsException to be thrown by a client when it received an
update from a data server. This was most likely to occur if the update was for
the current table of a cache which recently had multiple rows removed via its
rowsToDeleteTable property.
Logging
19543: Alert notification script output error when using log4j
Alert notifications from an RTView now go to a log4j output as desired.
Object Library
19936: Added support for data quality to obj_statushistory
The status history chart (obj_statushistory) has been enhanced to indicate data
quality.
Two new properties have been added, named valueQualityColumnName and
valueQualityBadValuesList. These properties can be used to set a color and
pattern to be plotted when on a bar when the data quality is bad.
The valueQualityColumnName property can be set to the name of the table column
that contains a value indicating the data quality for each row. The column can
contain string, integer, or boolean values. The valueQualityBadValuesList
property can be set to a string containing value,label pairs with each pair
separated by semicolons. This is used to assign a label to a numeric bad quality
value, for example "-1,no data;0,stale data"
The default value for valueQualityColumnName is blank, which means that the new
feature is disabled. In this mode the color and pattern for each bar is
determined by getting the value for that row from the column specified by
valueColumnName, and looking up that value in the chart's barProperties. (This is
the behavior in all prior releases).
If valueQualityColumnName non-blank, then for each row R the row's value to be
plotted is determined as follows:
- let Q = value of quality column for row R, and V = value of value column for
row R
- if Q is blank, then the quality is considered good and V is used at the row
value, as normal.
- else if the valueQualityBadValuesList property is blank, then Q is used as the
row value.
- else if valueQualityBadValuesList contains an entry "Q,X" then X is used as the
row value
- else the quality is considered good (since no match was found in
valueQualityBadValuesList) and V is used at the row value
Then the row value is looked up in barProperties, as usual, to determine the
color and fill pattern. That value is also shown in the mouseover text as usual.
For example, consider the following data table:
Plant Status Quality
----- ------ -------
A online 1
B offline 1
C online -1
D offline 0
... where 1 = data OK, -1 = no data, and 0 = stale data.
Next, consider a status history chart with these properties:
indexColumnNames = Plant
valueColumnName = Status
valueQualityColumnName = Quality
valueQualityBadValuesList = -1,no Data;0,stale data
barProperties =
online : green
offline : blue
no data : red
stale data : orange
Note that valueQualityBadValuesList has no entry for quality = 1, because that is
the "good" quality value.
With that configuration, when the data table shown above is applied to the chart,
it will plot a segment for each Plant as follows:
A green (since Status = online and Quality = 1 / OK)
B blue (since Status = online and Quality = 1 / OK)
C red (since Quality = -1 / no data)
D orange (since Quality = 0 / stale data)
20710: Enhanced text controls to only execute actions if text changed
A new property named executeOnlyIfChangedFlag has been added to the text control
objects (obj_c1text*).
If executeOnlyIfChangedFlag is true, and if the text control's varToset and its
valueString or value property are attached to the same local variable, then the
control's command will be executed only if the text in the control is changed.
By default executeOnlyIfChangedFlag is false, in which case the control's command
is executed whenever the control loses focus (if executeOnFocusLostFlag = true or
if the control is a text area) or whenever the user presses the Enter key in the
control (if the control is not a text area), regardless of whether the text in
the control was changed. This matches the text control behavior in all previous
releases.
20771: New Tab Control object
A tab control object is now supported in RTView. The name of the object is
obj_c1tabs. It appears on the Controls tab of the Builder's object palette.
The tab control has two "fake" tabs labelled A and B when it is drawn on the
palette, and also when the user places an instance on a display. The fake tabs
are replaced with the actual tabs by attaching the tab control's valueTable
property to a data table containing one row for each tab.
The size given to the control in the Builder determines the space available for
tabs. The tabs are drawn horizontally with the first tab at the left edge of the
control. If the control is not wide enough to show all of the tabs, the tabs will
wrap vertically. If the control is not tall enough to show all of the tabs, some
of the tabs may be clipped or invisible.
Changing the control's labelTextSize property will change the size of the tab
label text, which will also affect the size of the tabs.
The tab control is populated from a data table attached to its valueTable
property, with one tab created for each row in the table. The following tab
control properties are used to map the columns of the data table to each tab:
labelColumnName - the value from this column is used as the tab label. If
labelColumnName does not specify a column in the valueTable or if it contains an
empty string, then the tab for row N in the valueTable will be labelled "Tab N".
The labelColumnName property appears in the Label category.
valueColumnName - the value from this column is assigned to the variable (if any)
attached to the tab control's varToSet property when the corresponding tab is
selected by the user. If valueColumnName does not specify a column in the
valueTable, then the tab's index (0 through N - 1, for a table with N rows) is
used as the tab value. The valueColumnName property appears in the Data category.
imageColumnName - the value from this column is used to load an icon image, shown
to the left of the tab's label . If imageColumnName does not specify a column in
the valueTable, or if the column is empty, or if the image can't be found, the
tab will not contain an icon. An icon will affect the size of the tab. The
imageColumnName property appears in the Image category.
mouseOverColumnName - the value from this column is used as the tooltip for each
tab. If mouseOverColumnName does not specify a column in the valueTable, or if
the column is empty, the tab will not display a tooltip. The mouseOverColumnName
property appears in the Interaction category.
The tab control supports the drillDownColumnSubs property, which can be useful in
cases where the tab's command is a drilldown. As with other objects that support
drillDownColumnSubs, it can be used to set the values for substitutions and local
variables from columns in the row of the valueTable that corresponds to the
selected tab.
As usual, the control's visFlag property can be used to toggle the control's
visibility.
Unlike the other control objects, the tab control does not support the
enabledFlag property so it is always enabled.
As on other control objects, the predefined substitution named $value can be used
in the control's command. The value of the selected tab will be substituted for
$value when the command is executed. (See the valueColumnName property for a
description of how a tab's value is determined).
If a tab control has a command defined and the commandConfirm property is
checked, the user will be asked to confirm the command when a tab is clicked, but
the clicked tab will become the selected tab regardless of the user's response.
Limitations / Differences:
- In the thin client, the tab control is not supported in IE version 8 or older
and will not appear in displays opened in those versions.
- The tab sizes and appearance may differ somewhat when viewed in the
Builder/Viewer vs. thin client.
- In the thin client, the background color of the selected tab is brighter than
the unselected tabs, while in the builder/viewer the selected tab is darker than
the other tabs. (This difference is intentional, to conform with the standard
appearance of tabs in Swing vs. a browser.)
20790: New Google Map object
Introduction:
-------------
A new display object for embedding a Google Map in an RTView display is now
supported. The new object is named obj_gmap and is located on the Graphs tab in
the Builder's object palette.
In the builder, an obj_gmap instance appears as a gray "placeholder" rectangle
which is used to set the size and position of the map on the display, and to
allow configuration of the latitude, longitude, zoom level and other map
properties via the Builder's property sheet. The Google Map is only rendered when
the display is opened in the thin client. In the Builder and Viewer, and obj_gmap
instance will always appear as an empty gray rectangle.
Using the map properties and RTView data attachments, the map can be populated
with marker objects at specific lat/long positions, and also links between the
markers. RTView drilldown and command operations can be triggered by clicks on
the map, or on the markers or links on the map. Double click and right click
actions, and drillDownColumn subs are supported, as on other RTView table-driven
objects. Map operations such as zoom, pan, and marker selection can be tied to
rtview variables.
Requirements:
-------------
The thin client must have internet access in order to download the Google Maps
javascript API and map data. The thin client supports Google Maps in Internet
Explorer version 9 or newer, and any other RTView-supported browsers (Firefox,
Chrome, iOS Safari). The Viewer does not support the map object.
The thin client loads the Google Maps Javascript API to render and manipulate the
map. In most cases a key or license must be obtained from Google for business use
of the Google Maps Javascript API. See the "Licensing" section later in this
document.
Map Object Properties and Features:
-----------------------------------
A Google Map is added to an RTView display by creating an instance of the
obj_gmap display object, found on the Graphs tab of the Builder's object palette.
In the builder, an obj_gmap instance appears as a gray "placeholder" rectangle
which is used to set the size and position of the map on the display, and to
allow configuration of the latitude, longitude, zoom level and other map
properties via the Builder's property sheet. The Google Map is only rendered when
the display is opened in the thin client.
The following properties are supported by obj_gmap:
("Data" category):
+ valueTable: This property can be used to place markers (icons) on the map, at
specific locations. The property should be attached to a table that contains one
row for each marker, with the columns shown below. The column names are
unimportant, but the column order and type must be as follows. The first 3
columns are required, the others are optional.
column 1 (string): name
column 2 (number): latitude
column 3 (number): longitude
column 4 (string): icon name/path
column 5 (integer): icon height in pixels
The marker name is used is drilldowns to indicate the selected (clicked) marker,
and can also be used to select a marker, so it should be unique.
If column 4 (icon name) is omitted or is empty, the default Google Maps marker
will be used. If column 5 (icon height) exists and its value is > 0, the value is
used to center the icon on the marker's lat/long position, otherwise the 0,0
pixel of the icon will be placed on the marker's lat/long position.
+ valueTableForLinks: This property can be used to draw links between markers on
the map. The property should be attached to a table that contains one row for
each link, with the columns shown below. The column names are unimportant, but
the column order and type must be as follows. The first 2 columns are required,
the others are optional.
column 1 (string): name of marker at start of link
column 2 (string): name of marker at end of link
column 3 (string): link line color, as a css color name or #rrggbb hex value.
column 4 (integer): link line width
column 5 (integer): arrow mode
The first two columns specify the names of the markers at the start and end of
the link. These must correspond to the names of markers in the valueTable. If
column 3 is omitted the link color is black. If column 4 is omitted the link
width is 2 pixels. The arrow mode values are 1 (one arrow, pointing to start
marker), 2 (one arrow, pointing to end marker) and 3 (two markers, at each end of
link). If column 5 is omitted the default mode of 3 is used.
("Interaction" category):
+ command: the command to invoke when the user clicks on the map, a marker, or a
link
+ drillDownColumnSubs: this property is treated the same as for other
table-driven objects. If a marker is clicked, the drillDownColumnSubs are set
using values from the valueTable row that corresponds to that marker. If a link
is clicked, the drillDownColumnSubs are set using values from the
valueTableForLinks row that corresponds to that link. In addition, the following
predefined substitutions are also set when a drilldown is executed:
$mapSelLat : the latitude of the map location or marker clicked
$mapSelLng : the longitude of the map location or marker clicked
$mapLat : the latitude of the map's current center location
$mapLng : the longitude of the map's current center location
$mapZoom : the current zoom level of the map, a value between 0 and 21
+ drillDownSelectMode: This property can be set to the following values:
Anywhere: a click anywhere on the map will trigger the object's command or
drilldown.
Markers: only a click on a marker will trigger the command or drilldown.
Links: only a click on a link will trigger the command or drilldown.
Markers & Links only a click on a marker or a link will trigger the command or
drilldown.
+ menuItemGroup: As with other objects (table, heatmap, tree) this property is
used to add custom items to the context menu, when a map marker is right-clicked.
+ label: The label string for the map placeholder object. This is visible only in
the Builder.
("Map" category):
+ labelsZoomThreshold: If this property is set to a value > 0 a label balloon
will appear next to each marker when the zoom level is greater than or equal to
that value. The label text in the balloon is the name assigned to the marker, by
the first column in the valueTable. A label can be closed by clicking its "x"
button. The label will reappear if the display is closed and reopened or if the
zoom threshold is crossed again later. The default value of labelsZoomThreshold
is zero which disables the labels.
+ latitude: the latitude of the point on which the map is to be centered
+ longitude: the longitude of the point on which the map is to be centered
* selectedMarker: the name of the marker to select
+ zoom: the zoom level of the map, between 0 and 21.
The other properties supported by the map object but not listed here are common
to all display objects, and have the same purpose and behavior as on the other
display objects.
Licensing:
----------
Business use of the Google Maps Javascript API typically requires a key or
license from Google. For more information, see the following:
https://developers.google.com/maps/licensing
SL does not provide a key or license for the Google Maps Javascript API. However,
the thin client can be configured to download the API using a custom URL that
contains specific key or license information obtained from Google. The custom URL
is defined by modifying the rtv_custom.js file contained in rtvdisplay.war.
(Refer to the customization section of the RTView documentation for details on
modifying rtvdisplay.war)
To specify a custom URL to download the Google Maps Javascript API, add the
following line to rtv_custom.js:
rtv.customGoogleMapsApiBaseURL = 'url';
For example, to specify a URL containing a Google API key:
rtv.customGoogleMapsApiBaseURL =
"https://maps.googleapis.com/maps/api/js?key=YOUR_GOOGLE_API_KEY";
Or, to specify a "Google Maps API for Work" client ID and release version 3.20:
rtv.customGoogleMapsApiBaseURL =
"https://maps.googleapis.com/maps/api/js?client=YOUR_GOOGLE_CLIENT_ID&v=3.20";
If no rtv.customGoogleMapsApiBaseURL value is specified, the thin client will use
the following public URL to download the latest "experimental" version of the API
with no key or license information: https://maps.googleapis.com/maps/api/js
20828: New bgClipTextFlag property added to obj_rect* label objects
The following objects support a new property named bgClipTextFlag:
obj_rect_il
obj_rect_ilv
obj_rect_ilvs
obj_rect_ilvx_da3
obj_rect_ilvx_ra4
obj_ind_discrete
If the object's bgClipTextFlag is checked and its bgVisFlag is checked then its
label and/or its valueString (whichever string is drawn within the background
rectangle) will be clipped by the object's background rectangle.
That is, the object's label will be clipped by the background rectangle if
labelTextPosX is Inside Left, Center, or Inside Right AND labelTextPosY is Inside
Top, Center, or Inside Bottom . The object's value or valueString (if any) will
be clipped by the background rectangle if valueTextPosX is Inside Left, Center,
or Inside Right AND valueTextPosY is Inside Top, Center, or Inside Bottom.
In the Builder, the bgClipTextFlag property appears in the Background category on
the property sheet. By default, bgClipTextFlag is unchecked. The property is not
visible if bgVisFlag is unchecked.
Only the visible text can be copied to the clipboard, in the thin client.
20877: New property selectedValueColumnName to enhanced tree node selection
A property named selectedValueColumnName has been added to the tree/accordion
controls. The property can be used to specify the name of the column in the
valueTable to which the selectedValue should be compared, for selecting a node in
the tree/accordion.
This can be useful in cases where the value from one column (specified by
valueColumnName) in the valueTable should be used to set the $value substitution
when a tree node is clicked by the user, but a value in a different column
(specified by selectedValueColumnName) should be used to highlight a tree node
via the selectedValue property,
If the selectedValueColumnName property is not set, then the existing
valueColumnName property value will be used instead as in prior versions when
highlighting the tree node that matches selectedValue.
Platform Support
19925: Support Java 1.8
Java 1.8 is now officially supported.
NOTES:
As noted in the release notes for 19927 and 19928, the JdbcOdbc driver is no
longer supported by Oracle beginning in Java 1.8.
Version v4.14.137 of IBM DB2's db2jcc.jar driver is required to work with Java
1.8
Security
20794: Fixed XSS Security Issue in Thin Client Deployment
A cross-site scripting (XSS) vulnerability in the thin client has been fixed.
Transaction Message Monitor
20672: Transaction monitor end of life announced
The Transaction Monitor application will be end of life in RTView version 6.7. A
warning about this has been added to the console and the tmdisplays demo has been
removed from the RTView demos directory.
In previous releases, the Transaction Monitor threw an exception at startup. This
has been fixed.
Scripts
19395: start/stop/status scripts argument handling enhanced and new verbose option
The RTView start/stop/status scripts have been enhanced as follows:
1. Improved argument handling for start_rtv
The new start_rtv command line is as follows:
start_rtv config or 'all' [server or 'all'] [-verbose] [-console] [-args...]
Note the following:
a) it is no longer necessary to specify 'all' for server. If the server argument
is omitted (and the next argument starts with "-") then 'all' will be assumed. In
other words, these commands are equivalent:
start_rtv default all -properties:xxx
start_rtv default -properties:xxx
b) The flags -verbose, -console must appear before any other optional args. Note
also they may be abbreviated to their first letter (-v, -c).
2. Improvements in stop_rtv
a) The script now runs kill_dataserver using its verbose mode and examines the
output for errors or exceptions. If found it displays something like this:
>> stop_rtv central ConfigServer
ConfigServer: Stopping PID 6432 via JMX port 10013 ...
ConfigServer: Error report from kill_dataserver:
java.lang.NoClassDefFoundError: invokeJmxOperation
Caused by: java.lang.ClassNotFoundException: invokeJmxOperation
ConfigServer: was not stopped.
b) The script now verifies that the process was killed by re-running the netstat
command to see if its ports were freed. It will say either
XXXServer: ... stopped.
...or...
XXXServer: ... was not stopped.
c) The script now takes an optional argument "-dump":
stop_rtv config or 'all' [server or 'all'] [-verbose] [-dump] [-args...]
This will cause the script to take three stack dumps 30 seconds apart
before attempting the kill. (This assumes jstack is in your path.)
Note also the argument may be abbreviated to its first letter (-d).
3. Addition of verbose mode
All the scripts now take an optional argument "-verbose". Annotated examples of
the output follow.
a) start_rtv emsmon dataserver -verbose
---------------------------------------
Start emsmon:
[ echo args, echo dir/server/command from rtvservers.dat ]
...start_rtv.bat: emsmon dataserver: ./emsmon dataserver rundata
[ output from rtvapm_common ]
...rtvapm_ports.bat calling rtvapm_common.bat dataserver
java version "1.6.0_38"
Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) Client VM (build 20.13-b02, mixed mode, sharing)
... using RTVAPM packages: emsmon
Setting standard package properties:
-properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon
***** OPTIONS=-rtvapm_packages:emsmon+
-properties:C:\rtvdemos\rtvapm\common\conf\rtvapm -properties:C:\rtvdemos\rtvapm
\emsmon\conf\rtvapm.emsmon -properties:rtview -propfilter:dataserver
-propfilter:collector
[ output from rtvpropreader ]
[ note: disregard error re. emcommon.properties ]
[ note: CMD block has complete command line ]
...calling rtvpropreader.bat dataserver dataserver
ERROR: Cannot load properties file: emcommon.properties
JVM: -Xmx256m -Xms128m
-Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sl.rtview.useLog4j=true
-Dcom.sl.rtvie
w.RTVLog4jLevel=info -Dcom.sl.rtview.showLogCategory=true -Xmx768m -Xms128m
-Dlog4jFile=logs/dataserver.log -Xmx1024m -X
ms256m -Dcom.sun.management.jmxremote.port=3168
JMX:3168
DATA:3178
CMD:-log4jprops:C:\rtvdemos\rtvapm/common/conf/sl.log4j.properties -daemon
-proctag:RTVAPM.RtvDataServer -sub:$domainName:SL-EMSDEMOS-1 -jmsadmdsdebug
-proctag:EMSMON.RtvDataServer -sub:$domainName:SL-EMSDEMOS-1 dataserver
-rtvapm_packages:
emsmon+ -properties:C:\rtvdemos\rtvapm\common\conf\rtvapm
-properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview
-propfilter:dataserver -propfilter:collector -properties:emcommon
-propfilter:ConfigClient
[ results from rtvpropreader ]
...got datport=3178, jmxport=3168
[ output from netstat command ]
...data port 3178: netstat -anop tcp finds:
...jmx port 3168: netstat -anop tcp finds:
[ results from netstat command]
...got datpid=, jmxpid=
[ not running, okay to start ]
dataserver: Executing rundata -bg
b) stop_rtv emsmon dataserver -verbose
--------------------------------------
Stop emsmon:
[ output from rtvapm_common ]
...rtvapm_ports.bat calling rtvapm_common.bat dataserver
java version "1.6.0_38"
Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) Client VM (build 20.13-b02, mixed mode, sharing)
... using RTVAPM packages: emsmon
Setting standard package properties:
-properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon
***** OPTIONS=-rtvapm_packages:emsmon+
-properties:C:\rtvdemos\rtvapm\common\conf\rtvapm
-properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview
-propfilter:dataserver -propfilter:collector
[ output from rtvpropreader ]
...calling rtvpropreader.bat dataserver dataserver
ERROR: Cannot load properties file: emcommon.properties
JVM: -Xmx256m -Xms128m
-Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sl.rtview.useLog4j=true
-Dcom.sl.rtview.RTVLog4jLevel=info -Dcom.sl.rtview.showLogCategory=true -Xmx768m
-Xms128m -Dlog4jFile=logs/dataserver.log -Xmx1024m -Xms256m
-Dcom.sun.management.jmxremote.port=3168
JMX:3168
DATA:3178
CMD:-log4jprops:C:\rtvdemos\rtvapm/common/conf/sl.log4j.properties -daemon
-proctag:RTVAPM.RtvDataServer -sub:$domainName:SL-EMSDEMOS-1 -jmsadmdsdebug
-proctag:EMSMON.RtvDataServer -sub:$domainName:SL-EMSDEMOS-1 dataserver
-rtvapm_packages:emsmon+ -properties:C:\rtvdemos\rtvapm\common\conf\rtvapm
-properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview
-propfilter:dataserver -propfilter:collector -properties:emcommon
-propfilter:ConfigClient
[ results from rtvpropreader ]
...got datport=3178, jmxport=3168
[ output from netstat command ]
...data port 3178: netstat -anop tcp finds:
TCP 0.0.0.0:3178 0.0.0.0:0 LISTENING 3016
...jmx port 3168: netstat -anop tcp finds:
TCP 0.0.0.0:3168 0.0.0.0:0 LISTENING 3016
TCP 127.0.0.1:1570 127.0.0.1:3168 ESTABLISHED 3016
TCP 127.0.0.1:3168 127.0.0.1:1570 ESTABLISHED 3016
[ results from netstat command ]
...got datpid=3016, jmxpid=3016
[ running, okay to stop ]
dataserver: Stopping PID 3016 via JMX port 3168 ...
[ output from kill_dataserver (-verbose) ]
[ note: disregard UnmarshalException ]
...calling kill_dataserver -port:3168
Trying to connect to [service:jmx:rmi:///jndi/rmi://localhost:3168/jmxrmi] ...
Finding mBean [RTViewHistorian:name=Manager] ...
Locating operation: [killHistorian] ...
Invoking operation: [killHistorian] ...
InvokeJmxOperation: an UnmarshalException occurred.
Success: the operation was successfully invoked.
The Data Server has been shut down.
[ repeat call to rtvapm_ports to verify kill ]
...verifying kill ...
...rtvapm_ports.bat calling rtvapm_common.bat dataserver
[ output from rtvapm_common ]
java version "1.6.0_38"
Java(TM) SE Runtime Environment (build 1.6.0_38-b05)
Java HotSpot(TM) Client VM (build 20.13-b02, mixed mode, sharing)
... using RTVAPM packages: emsmon
Setting standard package properties:
-properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon
***** OPTIONS=-rtvapm_packages:emsmon+
-properties:C:\rtvdemos\rtvapm\common\conf\rtvapm
-properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview
-propfilter:dataserver -propfilter:collector
[ output from rtvpropreader ]
...calling rtvpropreader.bat dataserver dataserver
ERROR: Cannot load properties file: emcommon.properties
JVM: -Xmx256m -Xms128m
-Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -Dcom.sl.rtview.useLog4j=true
-Dcom.sl.rtview.RTVLog4jLevel=info -Dcom.sl.rtview.showLogCategory=true -Xmx768m
-Xms128m -Dlog4jFile=logs/dataserver.log -Xmx1024m -Xms256m
-Dcom.sun.management.jmxremote.port=3168
JMX:3168
DATA:3178
CMD:-log4jprops:C:\rtvdemos\rtvapm/common/conf/sl.log4j.properties -daemon
-proctag:RTVAPM.RtvDataServer -sub:$domainNam
e:SL-EMSDEMOS-1 -jmsadmdsdebug -proctag:EMSMON.RtvDataServer
-sub:$domainName:SL-EMSDEMOS-1 dataserver -rtvapm_packages:
emsmon+ -properties:C:\rtvdemos\rtvapm\common\conf\rtvapm
-properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview
-propfilter:dataserver -propfilter:collector -properties:emcommon
-propfilter:ConfigClient
[ results from rtvpropreader ]
...got datport=3178, jmxport=3168
[ output from netstat command ]
...data port 3178: netstat -anop tcp finds:
...jmx port 3168: netstat -anop tcp finds:
...got datpid=, jmxpid=
[ kill verified ]
dataserver: ...stopped.
20789: RTV_USERPATH no longer incorrectly set when project directory changes
Previously it was not possible to reuse a command window to start different
RTView EM projects. This has been fixed.
20869: TIBCO RV datasource disabled when launching central and non-tibco components
The rtvservers.dat file in emsample/servers has been edited so that the argument
-notibco is specified for any dataserver that does not require TIBCO data. This
allows for more efficient startup and shutdown.
Service Model
19984: Increased CIName column size for CMDB database
The size of the CIName column has been increased from 50 to 255 characters to
account for large CI Names being included in the CMDB database table.
To update your existing tables, follow the alter table sql sentence to apply to
each of our supported DB platforms.
DB2:
ALTER TABLE "RTVCMDB"
ALTER COLUMN "CIName" SET DATA TYPE VARCHAR(255);
Oracle:
ALTER TABLE "RTVCMDB"
MODIFY "CIName" VARCHAR2(255) NOT NULL;
SQL Server:
ALTER TABLE [RTVCMDB]
ALTER COLUMN [CIName] VARCHAR(255)
MySQL:
ALTER TABLE "RTVCMDB"
MODIFY "CIName" VARCHAR(255);
SyBase:
ALTER TABLE "RTVCMDB"
MODIFY "CIName" VARCHAR(255) NOT NULL
Solution Package
Amazon CloudWatch
20629: ACWMON enhanced to provide instance IP address and name
The previous versions of the Amazon CloudWatch solution package used an
"instance" identifier assigned by ACW as the index for the AwsEc2InstanceStats
cache. No other host data was available that could be used to relate host data in
this cache with host data collected by other solution packages.
For this release, the public IP address of the instance has been added to the
AwsEc2InstanceStats cache, and additional information about the instance is
available in a new AwsEc2Instances cache.
GlassFish Application Server
20900: Decommission Glassfish
The Solution Package for Glassfish has been removed from RTView Enterprise
Monitor.
IBM Websphere Application Server
20095: WSM historian entry in rtvservers.dat corrected
The rtvservers.dat file in emsample/servers contained an incorrect entry for
"wsm historian". This has been corrected.
The rtvservers-ha.dat file in emsample/servers contained incorrect entries for
"wsm historian" and "uxmon historian". These have been corrected.
IBM Websphere MQ
20845: New substitution to filter MQ queries
A new substitution has been defined to limit the Channels that are being queried
from MQ. This is useful when the user does not have access to all Channels, to
prevent permission errors.
The substitution can be set with the following line in the properties files:
sl.rtview.sub=$mqChannelFilter:*
20887: Improved configuration of sample MQMON project
The sample MQMON project has been enhanced to specify an example connection in
the sample.properties file instead of the IBMMQOPTIONS.ini file.
JBoss
20685: JBoss Solution Package
JBOSSMON is released supporting the following versions:
- JBoss EAP 6.1
- JBoss EAP 6.3.
- JBoss AS 7.1.1
- WildFly 9
The current Solution Package collects information about key performance metrics
from JBoss Servers and Web Applications. JBOSSMON is integrated by default under
RTView EM in the miscmon directory.
The JBOSSMON Solution package contains five displays:
- All Servers Heatmap,
- All Servers Table,
- Server Summary,
- Applications Heatmap, and
- Applications Summary.
The All Servers Heatmap|Table and the Server Summary displays provide metrics
about
Alert Level, JVM monitoring information like Process CPU %, Memory Utilization
as well as Session information (Created, Active, Rejected Expired).
For Web Applications, the Heatmap and Summary displays provide information about
Requests, Processing Time, and Average Response Time being calculated as the
ratio
between the former two metrics. The Average Response Time is a relevant metric
to evaluate Web Applications performance. The number of Active Sessions,
the rate of Sessions Created, the rate of Requests, and the Average Response
Time are kept in history and trended in the Applications Summary.
The Alerts that have been implemented are the following:
- JbossServerSystemCpuLoadHigh,
- JbossServerSwapUsedHigh,
- JbossServerProcessCpuLoadHigh,
- JbossServerMemoryUsedPercentHigh,
- JbossServerActiveSessionsHigh,
- JbossAppWithDuplicateIds, and
- JbossAppActiveSessionsHigh.
These alerts are implemented under the RTView Self-Service Alerts Framework and
operate equivalently to the alerts under RTView EM. JBOSSMON displays provide
light indicators to inform when alerts or warnings have been raised.
To establish connection, you need to reference the jars from your JBoss
installation
in the properties file. There is one example on that under
rtvapm\jbossmon\projects\sample\sample.properties and also under EM in
rtvapm\projects\emsample\miscmon\sample.properties. You should copy the
connection and the cache config source files and provide an appropriate name to
each of your connections. This name should be the same in the $jbsConnString
substitution.
Example of connection to WildFly 9:
collector.sl.rtview.cp=C:/WILDFLY/wildfly-9.0.0.CR1/bin/client/jboss-cli-client.jar
collector.sl.rtview.jmx.jmxconn=MyWildFlyInstance - -
URL:service:jmx:http-remoting-jmx://yourIPAddress:port myUser myPassword false
collector.sl.rtview.cache.config=jboss_server_cache_source.rtv
$jbsConnString:'MyWildFlyInstance'
collector.sl.rtview.cache.config=jboss_deployment_cache_source_wildfly.rtv
$jbsConnString:'MyWildFlyInstance'
Example of connection to JBoss EAP 6.3:
collector.sl.rtview.cp=C:/JBOSS/jboss-eap-6.3/bin/client/jboss-cli-client.jar
collector.sl.rtview.jmx.jmxconn=MyJBOSS6.3 - -
URL:service:jmx:remoting-jmx://yourIPAddress:port myUser myPassword false
collector.sl.rtview.cache.config=jboss_server_cache_source.rtv
$jbsConnString:'MyJBOSS6.3'
collector.sl.rtview.cache.config=jboss_deployment_cache_source.rtv
$jbsConnString:'MyJBOSS6.3'
The connectivity required for monitoring JBoss in standalone or domain launching
modes is identical. You can switch between launching modes without further
changes in the connection to the server unless you use a different JBoss Server
to manage the domain.
Oracle Coherence
19009: Optimized JMX data retrieval option using custom MBeans (JMX Tables)
An option is available to speed up retrieval of Coherence MBean information (over
JMX) by providing the aggregated MBean data in tabular form by using custom
MBeans.
This option is useful when monitoring large clusters (clusters with a large
number of nodes, caches and or services) using JMX,
where the volume of data retrieved can effect the time taken to retrieve all the
data, and thus limit the sampling rate for monitoring data.
By using custom MBeans the data is aggregated within the cluster, and transmitted
in the form of tabular data, rather than as individual attributes, reducing the
time taken to query the data.
Enabling this requires (unlike default JMX monitoring) that the custom MBeans
(contained in a jar) are deployed and registered on all nodes in the cluster, and
the monitoring is configured to query the custom MBeans.
The Oracle Coherence Documentation describes registering custom mbeans in a
declarative manner in detail
https://docs.oracle.com/cd/E18686_01/coh.37/e18682/custom_mbeans.htm#COHMG4712
The key points are:
* The Custom MBeans must be found at run time. Make sure to place the library
that contains the MBeans in the classpath of the coherence nodes/members
including the JMX management-enabled member.
* The Custom MBeans are specified using a MBean Configuration Override File
The Custom MBeans (CacheTable, ServiceTable, StorageManagerTable) are contained
in the jar ocjmxtables.jar.
The jar ocjmxtables.jar is located in the rtvapm/ocmon/lib directory of the ocmon
installation.
This jar file must added to the classpath of the Coherence members to be
monitored. This may require that the jar be copied to a location that is visible
to all the coherence members. This may vary based on your deployment. It may
prove convenient to copy it to where the coherence jars are deployed, so they can
use the same classpath root.
The tangosol.coherence.mbeans system property specifies an MBean configuration
override file to be used instead of the default custom-mbeans.xml override file.
The MBean configuration file to be used is called sl-custom-mbeans.xml and is
contained at the root of the ocjmxtables.jar.
Thus when the ocjmxtables.jar is added to the Coherence members classpath, it can
be specified by setting the tangosol.coherence.mbeans system property for the
Coherence cluster members to reference it thus
-Dtangosol.coherence.mbeans=/sl-custom-mbeans.xml
The above should be applied to all Coherence cluster members so that the
tangosol.coherence.mbeans system property is set to /sl-custom-mbeans.xml
If you have configured your coherence cluster correctly, you should be able to
connect to the cluster using JConsole, and see in addition to the previous Cache,
Service, and StorageManager MBeans the new custom CacheTable, ServiceTable, and
StorageManagerTable MBeans.
To configure the ocm monitoring system to use the Custom MBeans, you should
configure your monitoring system to use JMX as normal, and then uncomment the
(rtview.properties) line below
# JMX TABLES
#
# Uncomment the line below to use the JMX tables custom mbeans
#maincollector.sl.rtview.cmd_line=-ocjmxtables
so that the -ocjmxtables command line argument is passed to the maincollector
program (typically this is the dataserver)
If this is done, then the log file will contain the following text at startup
... using OC JMX Tabular Data
And at runtime, the previous JMX queries (
as seen in the JMX Metrics Administration display in the MBean Query Key column
of the RTView JMX Query Statistics table )
* Coherence:type=Cache,* 0 * -1 *-
* Coherence:type=Cluster 0 * -1 *-
* Coherence:type=Service,* 0 * -1 *-
Will now be
* Coherence:type=CacheTable,* 0 CacheTable -1 *-
* Coherence:type=ServiceTable,* 0 ServiceTable -1 *-
* Coherence:type=StorageManagerTable,* 0 StorageManagerTable -1 *-
And should have a reduced execution time leading to a reduced total (Jmx Query)
Execution time.
In Summary
* Add the ocjmxtables.jar to the classpath of the cluster members
* Set -Dtangosol.coherence.mbeans=/sl-custom-mbeans.xml for the cluster members
JVM's
* Use the maincollector.sl.rtview.cmd_line=-ocjmxtables property for the OCM
monitoring system.
20641: New Top Level Cluster Selection Screen
A new top level cluster selection screen has been added. The new top level screen
consists of a single table where each row represents a coherence cluster that is
being monitored.
Selecting a row in the Cluster Selector table will navigate to the Cluster -
Overview screen for that cluster. Data will come from the selected dataserver,
and the named connection will be selected cluster drop down selector on the
cluster overview screen.
Each row in the table has summary overview data for the monitored (coherence)
cluster.
The Columns in the table are described as follows.
Connection: The name of the used defined connection used to connect to the
monitored coherence cluster.
Alert Severity: A "traffic light" icon representing the max alert severity of
alerts on that cluster.
* Red - Alerts have triggered for the given cluster.
* Amber - Warning Alerts have triggered for the given cluster.
* Green - No Alerts have triggered for the given cluster.
Alert Count: The number of Alerts for the given cluster.
Cluster Size: The total number of nodes for the given cluster.
Caches: The total number of caches for the given cluster.
Objects: The total number of objects stored in the given cluster.
Data Sever:The name of the Data Server (connection) used to monitor the given
cluster
For Standalone OCM Systems where there is only one (default) dataserver - the
dataserver is named __default.
In systems where there are multiple dataservers used to monitor coherence
clusters, each dataserver is named using the named dataserver connection used to
connect to that dataserver.
In this way the table contains all the (declared) dataservers used to monitor
coherence clusters.
In the case of dataservers monitoring multiple coherence clusters via multi
cluster monitoring, there will be one row for each connection on that cluster.
Selecting that row in the table will navigate to the Cluster - Overview screen
for that cluster. Data will come from the selected dataserver, and the named
connection will be selected cluster drop down selector on the cluster overview
screen.
20761: Add background colors for new StatusHA Values
Background colors have been added for the new StatusHA Values RACK-SAFE and
SITE-SAFE, where the StatusHA value is displayed in existing displays. A
contrasting text color is used
20763: New Alert OcHATargetFailed
A new alert OcHATargetFailedhas been added. This alert triggers when the
(distributed service) target status (HATarget) has not been met. The HA Target
value is determined using the PartitionAssignment MBean in Coherence Versions 12
and above. In prior versions of coherence, the default value of MACHINE-SAFE is
used. The default value can be overridden by setting the substitution variable
$ocmDefaultHATarget to the desired value.
20854: New CPU Metric in Cache, UI and Alert
A new metric is available to monitor average CPU use across a cluster by storage
class, and alert if it is excessive.
A new Metric AvgCpuPercent has been added to the OcNodeTotals cache. This metric
is the average CPU usage of all the nodes of a given storage class in a cluster.
The storage class is represented by the StorageEnabled index column, which can be
true or false. Thus metrics for storage enabled nodes in a cluster are aggregated
into a cache row where StorageEnabled = true, and non storage enabled nodes in a
cluster are aggregated into a cache row where StorageEnabled = false.
This metric is displayed as trace on the Cluster - Memory/Network Health display.
The Metric has the legend "Avg. CPU %" and is displayed (for storage enabled
nodes) in the Storage Nodes trend grouping and (for non storage enabled nodes) in
the Process Nodes trend grouping.
A new alert - OcClusterNodesCPUHigh has been added. This alert will trigger when
the average CPU usage for the cluster / storage class goes above the specified
threshold for the specified duration.
This alert has a per cluster and a per (cluster) storage class override.
This alert appears in the "Other" Category when triggered.
20865: New Cluster Nodes Alerts
New Alerts are available to monitor memory use and network health across a
cluster by storage class, and alert if it is excessive.
The metrics are averaged across all of the nodes of a given storage class in a
cluster. The storage class is represented by the StorageEnabled index column,
which can be true or false. Thus metrics for storage enabled nodes in a cluster
are aggreagated into a cache row where StorageEnabled = true, and non storage
enabled nodes in a cluster are aggreagated into a cache row where StorageEnabled
= false.
A new alert - OcClusterNodesMemHigh has been added. This alert will trigger when
the average memory usage for the cluster / storage class goes above the specified
threshold for the specified duration.
This alert has a per cluster and a per (cluster) storage class override.
This alert appears in the "Memory" Category when triggered.
A new alert - OcClusterNodesSentFailureRateHigh has been added. This alert will
trigger when the average (network/packet) sent failure rate for the cluster /
storage class goes above the specified threshold for the specified duration.
This alert has a per cluster and a per (cluster) storage class override.
This alert appears in the "Memory" Category when triggered.
A new alert - OcClusterNodesRcvdFailureRateHigh has been added. This alert will
trigger when the average (network/packet) received failure rate for the cluster /
storage class goes above the specified threshold for the specified duration.
This alert has a per cluster and a per (cluster) storage class override.
This alert appears in the "Network" Category when triggered.
20866: New Cache Activity Alerts
New alerts are available to monitor cache activity across cache tiers and alert
if it is excessive.
The metrics represent rate of various activities against a given tier of a given
cache for a given service in a given (coherence) cluster. The tier can be front,
where appropriate, or back. Caches and services are named, and (coherence)
clusters are represented by their named monitoring connection.
A new alert - OcCacheRateTotalPutsHigh has been added. This alert will trigger
when the rate of cache puts goes above the specified threshold for the specified
duration.
This alert has per cluster, per (cache) service, per cache and per (cache) tier
overrides. This alert appears in the "Other" Category when triggered.
A new alert - OcCacheRateTotalGetsHigh has been added. This alert will trigger
when the rate of cache gets goes above the specified threshold for the specified
duration.
This alert has per cluster, per (cache) service, per cache and per (cache) tier
overrides. This alert appears in the "Other" Category when triggered.
A new alert - OcCacheRateCacheMissesHigh has been added. This alert will trigger
when the rate of cache misses goes above the specified threshold for the
specified duration.
This alert has per cluster, per (cache) service, per cache and per (cache) tier
overrides. This alert appears in the "Other" Category when triggered.
A new alert - OcCacheRateStoreReadsHigh has been added. This alert will trigger
when the rate of cache store reads (load operations) goes above the specified
threshold for the specified duration.
This alert has per cluster, per (cache) service, per cache and per (cache) tier
overrides. This alert appears in the "Other" Category when triggered.
A new alert - OcCacheRateStoreWritesHigh has been added. This alert will trigger
when the rate of store writes (store and erase operations) goes above the
specified threshold for the specified duration.
This alert has per cluster, per (cache) service, per cache and per (cache) tier
overrides. This alert appears in the "Other" Category when triggered.
These alerts are disabled by default as appropriate threshold values will vary by
installation an will need to be set accordingly.
20878: Cache activity Alerts enabled as EM key metrics
New Cache Activity Alerts are available as Key Metrics to monitor cluster health
based on excessive cache activity.
The new Alerts are of CI-TYPE OC-CACHE, and monitor cache activity.
CI-TYPE OC-CACHE has indices that represent (coherence) Cluster, (Cache) Service,
Cache (Name) and Tier (front or back as appropriate).
The Top Level (Level 0) Cache Key Metric Alerts are as follows
The OcCacheRateTotalPutsHigh Alert sets the threshold for the (Cache) Rate Cache
Puts metric.
The OcCacheRateTotalGetsHigh Alert sets the threshold for the (Cache) Rate Cache
Gets metric.
The OcCacheRateStoreReadsHigh Alert sets the threshold for the (Cache) Rate Cache
Misses metric.
The Top Level 1 Cache Key Metric Alerts are as follows
The OcCacheRateStoreReadsHigh Alert sets the threshold for the (Cache) Rate Store
Reads metric.
The OcCacheRateStoreWritesHigh Alert sets the threshold for the (Cache) Rate
Store Writes metric.
These alerts are disabled by default as appropriate threshold values will vary by
installation and will need to be set accordingly.
Solace
20791: Kendo grid enabled for SOLMON tables
Support for the "web grid" has been added to all tabular displays in the Solace
solution package. For the details on this new capability, see the release note
for MTL 20185.
TIBCO ActiveSpaces
20583: New columns that enable correlation of AS Usage with JVM and Host metrics
Additional columns (HostAddress, HostPort, ProcessID, and ProcessName) have been
added to the TasMembers cache and All Members tabular display. This data allows
this cache to be "joined" with the HostProcesses and HostNetwork caches, or the
VmwVm* caches in order to correlate host and process data with ActiveSpaces
members.
20723: TASMON alerts no longer show wrong metaspace information.
When monitoring multiple ActiveSpaces metaspaces, the TASMON data adapter
mistakenly associated each cluster member with all monitored metaspaces, causing
the TasMembers cache to contain #metaspaces * #members rows, and erroneous rows
in the "All Members" tabular display. Another consequence was invalid CI-Type
indexes in alerts (ie, an alert that indicated member x in metaspace y, when x
was clearly not a member of y).
The TASMON datasource now correctly manages member data by metaspace.
20752: Collect additional metrics for space (space status, whether member is a manager
A new data element, "spaceState", has been added to the TasSpaceStatistics cache,
"All Spaces Table", and "Space Summary" displays. Valid values of space are
"INITIAL", "INVALID", "LOADING", "READY", "RECOVER", and "SUSPENDED".
A new data element, "ManagementRole", has been added to the TasMembers cache,
"All Members Table", and "Member Summary" displays. Valid values are "MANAGER",
"MEMBER", and "NO_ROLE".
20775: New data adapter for ActiveSpaces
Previous versions of the Tibco ActiveSpaces solution package (tasmon) used the
admin API to collect metrics. The results returned by this API are identical to
the admin command-line interface, and consists of text blobs that must be parsed
by the RTView adapter. The adapter has been re-written to more efficiently
collect data by connecting to the metaspace as a client and browsing the system
spaces. This approach has an additional benefit in that the adapter is more
robust, since it is not affected by format changes in the admin text blobs that
randomly occur with each release of ActiveSpaces.
20795: New Use Rates checkbox added to summary displays
A "Use Rates" control has been added to each summary display. This control
switches the displayed trends from deltas (ie, counts of gets, puts, etc, per
interval) to rates (ie, gets per second, puts per second, etc.).
20797: CapacityPerSeeder support
This enhancement provides support for monitoring the memory utilization of each
space by seeder. CapacityPerSeeder has been added to the metrics collected for
spaces (see the TasSpaceStatistics cache).
A corresponding alert (TasMemberSeederCapacity) can be raised when then number of
entries in a space exceeds the % utilization set for each seeder (ie, # entries
for member divided by CapacityPerSeeder times 100). However, CapacityPerSeeder
must be set when the space is defined (see ActiveSpaces documentation). If not
set, CapacityPerSeeder defaults to -1
(not available) and the alert cannot be used.
This Detailed statistics collected from ActiveSpaces results in (#members *
#spaces) rows of data in the TasMemberStatistics cache. In some customer
deployments, this data volume can easily scale to levels exceeding the ability of
EM to maintain this data in cache and the history database.
Hence, beginning in EM 2.3, history has been disabled for the TasMemberStatistics
cache, and a new TasSeeders cache has been introduced with structure identical to
TasMemberStatistics. This makes it possible to store history at a reduced level
for space seeders only. History for seeders can be enabled by setting the
$TAS_SEEDERS_TABLE substitution in tasmon\conf\rtvapm.tasmon.properties. Be
certain that you really need this level of detail and have available database
capacity before enabling this feature.
The TAS-MEMBERBYSPACE CI-TYPE is disabled for the default EM project
configuration. This type is useful in the Key Metrics module when the volume of
data (~ (#members * #spaces)) is manageable. This capability can be enabled by
uncommenting the definition in central.properties.
20798: New Alert to indicate space is not READY
A new alert (TasSpaceState) is now available to indicate when a space is not in
the "READY" state.
20852: LD_LIBRARY_PATH added to miscmon's custom_setup.sh
For linux systems, the Tibco ActiveSpaces client API used by the tasmon
datasource requires that LD_LIBRARY_PATH be defined in the environment. If this
variable is undefined, an RTView dataserver will throw exceptions when it
attempts to load the necessary ActiveSpaces libraries. Hence, LD_LIBRARY_PATH is
now included in the custom_setup.sh script for the miscmon dataserver. This
script must be edited to set the correct path as part of the RTView EM
installation procedure.
TIBCO BusinessEvents
19884: Deleted stylesheet override for buttons
The button styles on the Inference Summary and Node Summary displays were updated
for consistency with other displays.
20782: Enhanced TBEMON to work for cases where no backing store is used
For BusinessEvents configurations that do not use a backing store, no mbean is
created by the BE engines for backing store statistics. As a consequence, the
TbeBackingStore cache will not contain any rows for the cluster, which ultimately
results in no summary data for the cluster (ie, a missing row in the top level
display for "TIBCO BE Clusters").
TBEMON now properly handles the case where the backing store mbean is missing.
TIBCO EMS
19283: sample.properties now includes reference to jms-2.0.jar (for EMS 8)
The new jar jms-2.0.jar needed to connect on EMS 8 has been included in the
sample.properties file. This addition will allow users to automatically connect
with EMS 8 seamlessly.
20547: Overrides can now be set for Server alerts on inactive servers
A bug that prevented setting alert overrides on inactive servers has been fixed.
The alerts affected were the following: EmsServerConnectionCountHigh,
EmsServerOutMsgRateHigh, EmsServerPendingMsgsHigh, EmsServerRouteState,
EmsServerMemUsedHigh, EmsServerInMsgRateHigh, EmsServerConnectionCountHigh, and
EmsServerStaleData.
20555: Overrides can now be set for Queue and Topic alerts on inactive servers
It is now possible to set overrides on EMS Queues and EMS Topics coming from
inactive EMS Servers.
The alerts that have been fixed are the following:
- EmsQueueProviderIdleTimeHigh
- EmsQueuesConsumerCountLow
- EmsQueuesInMsgRateHigh
- EmsQueuesOutMsgRateHigh
- EmsQueuesPendingMsgsHigh
- EmsQueuesProducerCountHigh
- EmsQueuesProducerCountLow
- EmsTopicProviderIdleTimeHigh
- EmsTopicsConsumerCountLow
- EmsTopicsInMsgRateHigh
- EmsTopicsOutMsgRateHigh
- EmsTopicsPendingMsgsHigh
- EmsTopicsProducerCountHigh
- EmsTopicsSubscriberCountHigh
20729: EmsServerAsyncDBSizeHigh alert description improved
The description of the EmsServerAsyncDBSizeHigh alert has been updated to
explicitly declare the units of the metric associated to the alert.
20737: Up arrows now go to correct display from all queues|topics.
On the EMS Monitor All Topics Heatmap and All Queues Heatmap displays, the
up-arrow control now goes correctly to All Servers Heatmap.
20784: Added caches for in/outbound message counts and bytes
Three new optional caches have been added to EMSMON: EmsServerInfoExt,
EmsQueuesExt, and EmsTopicsExt, which collect and store into history the inbound
/ outbound message counts and bytes.
By default, these caches are not storing data into history. To enable these
caches from store data into the RTV_HISTORY database, add the following lines to
sample.properties:
collector.sl.rtview.sub=$EMS_SERVERINFOEXT_TABLE:EMS_SERVERINFOEXT
collector.sl.rtview.sub=$EMS_QUEUESEXT_TABLE:EMS_QUEUESEXT
collector.sl.rtview.sub=$EMS_TOPICSEXT_TABLE:EMS_TOPICSEXT
20787: Enhanced navigation of queue and topic displays
The navigation of EMS Destinations have been improved by unfolding EMS Queues and
EMS Topics into two new menu sections. Each section contains the following five
displays:
1. All Queues|Topics Heatmap
The heatmap can be filtered by EMS Queue|Topic pattern across all EMS Servers.
Also Topic Count and Queue Count have been split into Filtered Count / Total
Count.
2. All Queues|Topics Table
The table of all EMS Servers or just one EMS Server from the former All
Queues|Topics for Server with Topic Count and Queue Count as previous display.
3. All Queues|Topics Summary
Provides current metrics about Inbound, Outbound, and Pending Message rates and
totals as well as historical trend graphs for all topics in the selected EMS
Server for Pending Message Count and Inbound|Outbound Message Rate.
4. Single Queue|Topic Summary
This display is the former EMS Destinations->Single Queue|Topic Summary. It now
has enhanced navigation through the ByServer button to the Single Queue|Topic By
Server display.
5. Single Queue|Topic By Server
This display is the former EMS Destinations->Queue|Topic Detail By Server. It now
has enhanced navigation through the Summary button to the Single Queue|Topic
Summary display.
20822: Metrics asyncDBSize and syncDBSize have been added as 2nd Level Key
The metrics asyncDBSize and syncDBSize have been added as 2nd Level Key Metrics
for EMS Servers. These metrics are associated to the EmsServerAsyncDBSizeHigh and
EmsServerSyncDBSizeHigh alerts respectively.
20868: Fixed bug in EmsServerAsyncDBSizeHigh alert
A bug that prevented EmsServerAsyncDBSizeHigh alert from being executed when the
EMS Server State was not Active has been fixed. Also, the unit of this alert
alert has changed to bytes to conform the requirements of usage as a RTView EM
Key Metric alert.
TIBCO Hawk
19488: WAR files created for hawkmon
HAWKMON was updated to include war files, as per solution package standards.
VMWare vSphere
20857: VMWMON now able to return more than first 100 virtual machines
The vSphere 5.5 API now enforces paging for query results. The previous vmwmon
data adapter expected all objects to be returned in a single batch, so it
considered the query complete when the first page of (100) results was retrieved.
The adapter now loops to retrieve all of the pages in a query.
Version 2.2.0 Release Notes
Alerts
20639: Restrict number of chars user can enter for comments
EM has been enhanced with a new property, sl.rtview.alert.commentlimit, to limit
the number of characters it will store in the Comments field of the Alert table.
In previous releases, new comments were appended to the existing contents of the
Comments field with no limit on the amount of text. This caused problems for
alert persistence and alert history if the Comment field became longer than
corresponding database field could handle.
For this enhancement, the order of the comments has been reversed so that new
comments are added before existing contents in the Comments field. If the
sl.rtview.alert.commentlimit is greater than 0 and a new comment is added to an
alert, the content of the Comments field will be trimmed by removing characters
from the end of the contents if necessary to stay under the limit.
By default, this feature is disabled and the Comments field will grow unbounded
as new comments are added. To enable the limit, set the
sl.rtview.alert.commentlimit property in conf\emcommon.properties under your
project directory to a value greater than 0. This property should be set to the
same value for all servers.
This limit is enforced in the Set Owner and Comments dialog which is accessible
from the Annotate button on the Alert Table. Note that the UI limits the user to
100 characters less than the sl.rtview.alert.commentlimit value to allow for the
timestamp and user name that is added to the comment. This character limit
includes non-visible characters such as returns and spaces.
Persisted alerts with comments from a previous versions will have mixed order on
the Comments contents. It will be oldest->newest for persisted comments, then
newest->oldest for new comments added in this and later releases. Persisted
comments from previous versions that have been persisted and are longer than the
specified sl.rtview.alert.commentlimit value will be trimmed on startup.
Configuration
19202: CMDB Admin doesn't check for duplicates
The CMDB Admin display now prevents the addition of CI's multiple times to the
same Service via the addition of an index.
Existing users should use the following SQL to add the new index to their product
database:
CREATE UNIQUE INDEX "RTVCMDB_UNIQUE_INDEX" ON
RTVCMDB("Owner","Area","ServiceGroup","ServiceName","CIType","CIName");
20545: Removed hostbase comments from miscmon\sample.properties
Some misleading (commented out) properties for configuring host collection were
removed from sample.properties in hostbase. This file was concatenated with other
sample properties from other solution packages that are by default hosted in a
miscmon dataserver. Hence, the miscmon dataserver property file is now correct.
20564: RTVMGR rtview.properties simplified
The rtview.properties file under rtvapm\projects\emsample\servers\rtvmgr has been
simplified.
20573: Improved startup responsiveness of viewer and thin client during startup
An unnecessary property filter (-propfilter:monitor) has been removed from the
viewer, builder, and display server scripts, to improve response time at startup.
General
19897: Service Health Heatmap now filters correctly
In previous releases, the Service Summary Views->Service Health Heatmap didn't
filter correctly based on the Owner/Area/Group/Service combo box values. It only
filtered correctly based on drilldown. This has been fixed.
20667: Selected row now highlighted in RTView Cache Table to enable scrolling
The RTView Cache Tables display has been enhanced so that when a cell is selected
in either table, the whole row is highlighted instead of just the cell.
Monitor
20158: Enhanced mouse over in History Table Statistics display
The RTView History Table Statistics display has been enhanced so that the light
indicator of each row in the table is more self-explanatory. The mouse over now
provides the string "Time since last update" to indicate the meaning of the value
provided and the units in which it's defined (minutes).
20659: Fixed sorting on area and group/service tables
In previous releases, All Management Areas->Area Table and Multi Area Service
Views->Group / Service Table were not sorted correctly. This has been fixed.
Platform Support
20536: Support added for Red Hat Linux 7
RHEL 7 is now a supported platform for RTView.
RTVMGR
18882: RTVMGR RTView Servers Data Server and Display Server displays do not populate selection lists
In previous releases, the Source and Connection combo boxes in the following
displays were not populated correctly unless you navigated to one of the JVM
pages first:
RTView Servers->Data Servers
RTView Servers->Display Servers
This has been fixed.
19472: New Version Info display added to rtvmgr
The RTVMGR has been enhanced with a new RtvServerVersions cache and Version Info
page. The information in this cache and display is useful when reporting problems
to SL Technical Support as it contains very detailed information about the
version of each jar used in each connected RTView application.
The Version Info display is accessible from the navigation tree under RTView
Servers->Version Info or from the About display. The table contains one row for
each RTView jar in each RTView application for which the RTVMGR has a jmx
connection defined. This display combines the values for all connected RTVMGR
data servers.
The table contains the following columns:
Source: The name of the RTVMGR source.
Connection: The name of the jmx connection to the RTView application.
ApplicationName - The name of the application. Ex.RTView Data Server.
ApplicationConfiguration - The configuration string for the application. This
string contains the main application version that corresponds to the version
information that is printed to the console at startup.
JarName - The name of the jar.
JarConfiguration- The configuration string for the jar.
JarVersionNumber - The version number for the jar.
JarVersionDate - The version name for the jar.
JarReleaseType - The release type for the jar.
JarMicroVersion - The micro version for the jar.
Expired - True if the row in the RtvServerVersions cache has expired. The
expiration is set by the $jvmRowExpirationTime substitution.
time_stamp - The timestamp when this information was last received. This data is
queried once a minute.
DataServerName - The name of the RTVMGR data server connection.
Rows where the JarConfiguration does not match the ApplicationConfiguration are
highlighted in teal. RTView applications running versions previous to this
enhancement will only have one row in the table and will say "version info not
support in this version" in the ApplicationConfiguration column.
Filter the table using the controls at the top of the display:
Source: Select a value to filter on the Source column
Connection: Select a value to filter on the Connection column
Filter Field: Select an additional column to filter on
Filter Value: Enter a value to filter on in the Filter Field column
Use RegEx: Set to true to use the Filter Value as a regular expression when
filtering
Not Equals: Set to true to show rows where the Filter Field value does not match
the Filter Value. This is only available if Use RegEx is selected.
Clear: Clears the Filter Field, Filter Value and Not Equals.
20574: Fixed "tomcatManagerStats77DeltaRate" function error
Previously the message "ERROR: function <tomcatManagerStats77DeltaRate>, Invalid
(non-numeric) data column" would appear when Tomcat connections were not present.
This has been fixed
RTView Core Functionality
20643: New option to restrict number of characters in alert comments in the alert ds
The Alert data source has been enhanced with a new Maximum Characters Allowed in
Comments Field property to limit the number of characters it will store in the
Comments field. In previous releases, new comments were appended to the existing
contents of the Comments field with no limit on the amount of text. This caused
problems for alert persistence and alert history if the Comment field became
longer than corresponding database field could handle.
For this enhancement, the order of the comments has been reversed so that new
comments are added before existing contents in the Comments field. If the Maximum
Characters Allowed in Comments Field is greater than 0 and a new comment is added
to an alert, the content of the Comments field will be trimmed by removing
characters from the end of the contents if necessary to stay under the limit.
By default, this feature is disabled and the Comments field will grow unbounded
as new comments are added. To enable the limit, set the Maximum Characters
Allowed in Comments Field in the Alerts tab of the Application Options dialog to
a value greater than 0. You can set it using the following property:
sl.rtview.alert.commentlimit
This comment limit is be available via a data attachment to alert-commentlimit to
facilitate building a UI that will prevent users to enter comments longer than
this limit. Note that the UI text entry limit should be set to 100 characters
less than the comment limit in order to account for the time stamp, user name and
hard returns between comments.
Persisted alerts with comments from a previous versions will have mixed order on
the Comments contents. It will be oldest->newest for persisted comments, then
newest->oldest for new comments added in this and later releases. Persisted
comments from previous versions that have been persisted and are longer than the
specified Maximum Characters Allowed in Comments Field will be trimmed on
startup.
Alerts
20664: New option to exit if alert persistence is enabled but database table is unavailable
The Alert data source has been enhanced with a new property:
sl.rtview.alert.exitOnPersistInitFailed
This property controls what happens when alert persistence is enabled but cannot
be initialized due to a database problem or configuration issue. When
exitOnPersistInitFailed is set to false (default), RTView will initialize the
alerts with persistence disabled. This is the behavior in previous releases. When
exitOnPersistInitFailed is set to true, RTView will exit after the persistence
initialization has failed without initializing the alerts.
Commands
19854: Email command no longer garbles Japanese chars in name of attached file
The Send Email command no longer garbles Japanese and other non-ascii characters
in the names of files attached to an email.
Data Sources
19563: -sqltryodbc:false is now the default RTView behavior
By default, the SQL data source will no longer attempt to make an ODBC connection
to XYZ if an sql query or command is executed that references a database XYZ but
there is no definition of XYZ in OPTIONS.ini. Instead the following error message
will appear in the console:
Undefined SQL database XYZ
To force the SQL data source to attempt an ODBC connection when an undefined
database is referenced as in prior releases, specify the following command-line
options:
-sqltryodbc:true
The option can also be specified in OPTIONS.ini:
sqltryodbc true
or in a properties file:
sl.rtview.sql.sqltryodbc=true
Note that RTView will still make an ODBC connection to database XYZ if it appears
in OPTIONS.ini with the odbc driver specified, regardless of the -sqltrodbc
option.
However, note that the ODBC driver is not supported in Java 1.8 or newer. If an
ODBC connection is attempted in java 1.8 or newer, the following error messages
will appear in the console:
ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver (ODBC driver is not
available in Java 1.8 or newer)
Unable to connect to database <XYZ>:
No suitable driver found for jdbc:odbc:XYZ
19928: ODBC option removed from Builder and Historian GUI
The checkbox labeled "Use ODBC Driver" has been removed from the SQL Add Database
dialog in the Builder and also from the Database Options panel of the Historian
UI. This change was made because the JdbcOdbc driver is no longer supported by
Oracle beginning in Java 1.8 and in earlier releases it was not intended for
production use.
If an existing OPTIONS.ini or HISTORY.ini file contains a database connection
that was saved with the "Use ODBC Driver" box checked, those connections will
still work in this release if run with java < 1.8. In the new UI, such entries
will now show:
JDBC Driver Class Name : sun.jdbc.odbc.JdbcOdbcDriver
JDBC Database URL : jdbc:odbc:<dbname>
... rather than showing the checked "Use ODBC Driver" box.
But, if run with java 1.8 or newer, the following error will appear in the
console for each database that is configured to use ODBC:
ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver (ODBC driver is not
available in Java 1.8 or newer)
19993: JMX handler now provides context information for operations
The API "public String getTarget()" was added to GmsRtViewJmxDataObject for use
by JMX custom data handlers.
Demos
19927: ODBC connections in demos replaced with JDBC connections
The use of ODBC for the dstutorial and esphere demos has been deprecated. These
demos now use JDBC HSQLDB databases.
20130: Remove Windows start menu demo launchers
The Windows Installer now produces a much smaller set of Start Menu shortcuts.
The remaining shortcuts are:
About
Documentation
Registration
RTView Command Prompt
Uninstaller
20644: Restricted the number of characters for alert comment in self service alerts
Set Owner and Comments dialog in the Self Service Alerts demo has been enhanced
to respect the new Maximum Characters Allowed in Comments Field property on the
Alert data source. If the Maximum Characters Allowed in Comments Field has been
set, the field for entering comments enforces a limit of 100 characters less that
the Maximum Characters Allowed in Comments Field. This is to allow for the
timestamp and user name to be added to the comment. If the character limit is
exceeded, an error message is displayed and the Add Comment button is disabled.
Display Server
18024: Fixed ArrayIndexOutOfBounds on Grid containing more than 1 icon type
In prior releases, the display server threw an ArrayIndexOutOfBounds exception if
a display was opened containing an object grid configured with more than one icon
per item, and the display was not rendered in the thin client. This is fixed.
20621: Fixed: obj_rect_il may not draw in comp grid if webLabelFlag=1
A bug in the thin client has been fixed that sometimes caused objects with the
webLabelFlag property checked to not to be drawn if the objects were in a
composite display inside an object grid instance.
General
19466: Version info now available via RTView Manager MBean
The RTView Manager MBean has been enhanced to support a new method,
VersionInfoDetails, which returns detailed version information about the RTView
application. The table will contain one row for each RTView jar in the
application and contains the following columns:
ApplicationName - The name of the application. Ex.RTView Data Server.
ApplicationConfiguration - The configuration string for the application. This
string contains the main application version that corresponds to the version
information that is printed to the console at startup.
JarName - The name of the jar.
JarConfiguration- The configuration string for the jar.
JarVersionNumber - The version number for the jar.
JarVersionDate - The version date for the jar.
JarReleaseType - The release type for the jar.
JarMicroVersion - The micro version for the jar.
This table is useful when reporting problems to SL Technical Support as it
contains very detailed information about the version of each jar used in an
RTView application.
RtvCacheDoc
18909: rtvcachedoc no longer generates incorrect "Expired" column
In previous releases, rtvcachedoc incorrectly included the column specified in
the rowExpiredColumnName property in the generated db schemas. This only happened
for caches with a blank value for the historyColumnNames property. This has been
fixed.
Scripts
19835: projects\emsample\make_all_wars.bat no longer breaks the 2nd time it is run
The "make_all_wars" scripts in rtvapm/projects/emsample/webapps would give errors
if run twice in succession. This has been fixed.
19952: Solaris 10 Script change not always executed
On Solaris 10 systems the rtvapm_init.sh script modifies other scripts in
common/bin to use the bash shell. Under certain conditions this operation was not
executed. This has been fixed.
Service Model
19251: All Service Status History graph time range fix
In previous releases, the All Service Status History graph included the current
time regardless of the Time Range and End Time selected. This has been fixed.
Solution Package
20592: Fixed SQL schemas for UXMON & GFMON
The database schema files (dbconfig\*sql) for two Solution Packages, UXMON and
GFMON, were previously broken due to an incorrect 'Expired' column. This column
has been removed.
The GFMON Sybase schemas were also updated to explicitly set columns to NULL
where appropriate.
Users who have successfully worked around these bugs in the schemas and have been
storing data should not need to make any changes to their existing tables.
Oracle Database
20055: New alert for tablespace utilization
OraDatabaseTablespaceUsedHigh alert has been added to the Oracle database
monitoring package. When enabled, an alert will be generated when the tablespace
utilization exceeds a specified threshold.
Oracle Weblogic
20617: Removed duplicated custom function ScaleAndFormatBytes
A duplicate custom function to format up to the highest unit memory values has
been removed.
20654: Single Server directory page now navigates to correct JVM Summary display
The "JVM Summary" drilldown from the Single Server parent node now loads the
correct display.
TIBCO ActiveMatrix
20006: "Process CPU Percent" column removed from "All Nodes Table" and "Node Summary" views
Process % CPU was available in ActiveMatrix 2.3, but this data was removed from
the internal metrics data for ActiveMatrix 3.x. Hence, the "Process CPU Percent"
column has been removed from the "All Nodes Table" and "Node Summary" views.
Process CPU is still available in the caches and is accurate for version 2.3, but
is zero for ActiveMatrix 3.x installations.
20010: Corrected stats for count of events in 5 minute interval
Previously the Service Summary and Service Node Summary displays for Tibco
ActiveMatrix displayed counts per collection interval rather than counts per last
5 minutes when the "Statistics for Last" selector was set to the 5 minute scale.
This has been changed to display the actual number of hits and faults in the last
5 minutes (rolling average updated each collection interval).
TIBCO ActiveSpaces
20633: Support ActiveSpaces 2.1.5
The Tibco ActiveSpaces monitor has been tested and validated for use with
ActiveSpaces version 2.1.5.
TIBCO BusinessEvents
19372: Add All Nodes Heatmap
An "All Nodes Heatmap" has been added to the Tibco Business Events Monitor
solution. Either all nodes or the inference or cache nodes can be displayed for a
selected cluster or all clusters. The following features may be of particular
interest.
1. For clusters with a large number of inference nodes, either "Total Rules
Fired" or "Received Events Rate" as the selected color metric can show that the
load is balanced across the cluster.
2. When the Color Metric is "Alert Severity" and the TbeClusterMalformed alert is
enabled, problems with cluster formation are easily seen.
19435: Sender/receiver capability implemented
Remote collectors and data aggregators (senders and receivers) are now supported
by the Business Events solution. Multiple dataservers can be configured to
monitor BE clusters and forward their current caches to a central dataserver that
manages history and display functions.
For RTView EM users:
Out of the box, RTView EM provides a simple demonstration of this functionality,
as shown by the following commands:
cd projects\emsample
rtvapm_user_init.bat
cd servers
Set up a sl.properties file in the miscmon folder. at a minimum it must have the
connection properties to a demo BE cluster; For example,
collector.sl.rtview.jmx.jmxconn=new51Cache 192.168.2.14 58700 URL:- - - 'false'
collector.sl.rtview.cache.config=tbe_cache_source_be5.1_cacheagent.rtv
$tbe_conn:new51Cache
collector.sl.rtview.jmx.jmxconn=new51Inf 192.168.2.14 58701 URL:- - - 'false'
collector.sl.rtview.cache.config=tbe_cache_source_be5.1_inferenceagent.rtv
$tbe_conn:new51Inf
Launch the EM processes as follows:
start_rtv central
start_rtv miscmon dataserver -receiver
start_rtv miscmon dataserver -properties:sl -propfilter:sender
This example starts a single receiving dataserver and a single collector/sender
on the same host. If additional senders are deployed on remote hosts, override
the following settings in rtvapm.miscmon.properties to specify the host where the
receiver resides ($rtvAgentTarget). Set $rtvAgentName to identify the source of
data seen in the receiver's caches (ie, the name of the host where the sender is
deployed).
sender.sl.rtview.sub=$rtvAgentTarget:'localhost:3972'
sender.sl.rtview.sub=$rtvAgentName:MyMachineName
20011: High availability option configured
Missing files to configure High Availability for TBEMON have been added.
TIBCO BusinessWorks
19293: Cleaned up incorrect symbols appear in Heatmap mouseover
NaN special-character symbols have been replaced in the mouse over of All Engines
Heatmap display with a 0 value.
19961: BW Engine heatmap box size adjusted to accomodate outliers
In previous versions, the heatmap on the "BW Engine Summary" screen would fail to
show a box for each process in certain cases. The box size was proportional to
the number of process instances that had been created for a given process. Hence,
boxes would be missing when either
a) one process creation count was so large that it crowded out the other process
creation values, or
b) one or more processes had a zero creation count.
The box size is now proportional to the log(+1) of the creation count, so a box
should now be visible in all cases to support visualization and drill-down.
20020: Prevent Hawkmon from filtering out blank Processor fields
Under some conditions Hawkmon would fail to correctly identify Hawk agents, which
could then affect other parts of the product such as Servers in BWmon. This
occurred if the Hawk data contained a blank value for the getCpuInfo Processor
field . This has been corrected.
20052: Tibco Spotfire reports added for Engine Metrics
An example Tibco Spotfire dashboard is available to run for both MySQL and Oracle
SQL databases. The dashboard can report on historical data for BW Engine Metrics
and can be run using Tibco Spotfire Desktop version 7.0.
The dashboards and associated SQL custom query text files are located in the
rtvapm/bwmon/projects/reports/Spotfire directory. They include:
bw_engines_mysql.dxp (for MySQL)
bw_engines_mysql.txt
bw_engines_sql.dsp (for Oracle SQL)
bw_engines_sql.txt
For more information, please refer to the User Guide.
20425: BW Process Alerts now associated with BW-PROCESS CI Type
BW Process and BW Activity alerts have been associated to the BW-PROCESS CI Type.
20616: Odd square shape drawn atop center ListBoxes of "Single BW Activity Summary"
Under some circumstances the BW Monitor Activity Summary display would show some
extraneous objects when displayed in the thin client. These objects are small
rectangles (about 4 X 2 pixels) drawn on top of the selector combo boxes. This
has been fixed.
20702: BW6 Support
The BW solution has been enhanced with the ability to monitor TIBCO ActiveMatrix
BusinessWorks 6 Applications and AppNodes. The BW6 solution displays show current
and historical resource usage and error states across BW Applications and down to
the level of BW Processes and Activities.
RTView Alerts are implemented on key metrics at the Application, AppNode, and
Process levels and are incorporated into the displays.
The following displays are added to the navigation tree of the standalone
solution:
BW6 Applications
All Applications Heatmap
All Applications Table
Single Application Summary
BW6 AppNodes
All AppNodes Heatmap
All AppNodes Table
Single AppNode Summary
BW6 AppSlices
All AppSlices Heatmap
All AppSlices Table
Single AppSlice Summary
BW6 Processes
All Processes Heatmap
All Processes Table
Single Process Summary
BW6 Hosts
All Hosts Heatmap
All Hosts Table
The layout of the displays follows RTView standards and is similar to BW(5)mon.
In each section of the tree the table view shows all the data, allowing for
filtering, and the heatmap allows you to select the metric for the color scale.
The summary views show current and historical metrics for a single instance.
Process and Activity metrics are essentially unchanged from BW(5) and AppNode
metrics are similar to BW(5) Engine metrics. BW6mon adds the viewpoint of
Application and AppSpace. Process metrics, including such things as creation and
completion, exec and elapsed times, are summarized for the application and also
for each slice of the application on multiple appnodes. Specifically:
BW6 Applications
Shows Applications and AppSpaces across BW6 Domains with Process metrics totaled
by Application.
The summary display also shows the AppNodes of the deployment and Process metrics
totaled by AppNode. This is useful to see the deployment and load balancing of
the Application in current and historical time.
BW6 AppNodes
Shows ApppNodes and their resource usage in terms of internal JVM memory and host
CPU. This is useful because the AppNode performance is dependent on both internal
and external factors and sometimes they interact.
BW6 AppSlices
The AppSlice is the part of an Application running on a specific AppNode when the
Application is deployed to multiple AppNodes. These displays show process metrics
totaled by Application and AppNode. this is useful to see how the application is
distributed and how each part of it is peforming.
BW6 Processes
Very similar to the BW(5) Process metrics, including the addition of Delta and
Rate columns for many metrics. These displays are useful for a closer look at the
performance and resource usage of specific Processes in the Application.
BW6 Hosts
These displays show the health and history of the host systems running the
AppNodes.
BW6mon can be installed along with BW(5)mon and an RTView data server can include
one or the other or both according to the user's configuration. The configuration
is similar to BW(5)mon, using Hawk for data collection.
===========================
Limitations in this release:
===========================
TIBCO ActiveMatrix BusinessWorks 6.2.1 has issues with the Hawk microagent that
impose the following limitations on BW Monitor.
(1) Activity statistics are not completely implemented in Hawk. Activity-level
metrics and displays are not available in this release of BW Monitor.
(2) Process statistics are not completely implemented in Hawk. Min/Max/Average
Elapsed Time will be zero.
(3) Some statistics are not implemented in Hawk on Windows. This release of
BW6mon does not support TIBCO ActiveMatrix BusinessWorks 6 on Windows.
(4) The bwadmin command "enablestats" command does not enable statistics in the
Hawk microagent. You must enable process statistics for your BW6 applications via
hawk, e.g. using the Hawk Display tool.
20759: Removed “Invalid column name” startup errors
When BW Monitor would start up the following messages would appear one time in
the log.
<bwProcessDefinitionDataUnix41>, Invalid column name
<bwProcessDefinitionDataWin41>, Invalid column name
This did not indicate a problem and the messages have been removed.
TIBCO EMS
19618: Fixed errors with ASync/Sync DB metrics
The EMS Server Summary display has been enhanced to provide the Message Memory
Pooled metric. Several labels have been improved for accuracy;
- AsynDB Size now reads Async Storage
- SyncDB Size now reads Sync Storage
- Used % has been formatted to 2 decimal points
- Added Message Memory Pooled
TIBCO Hawk
20581: Adjusted margins for tables in Hawk displays
Cosmetics (margins around tables and fields) have been adjusted for the Hawk
Agent Table and Hawk Alert Table for the sake of consistency with other displays.
No functional changes were made to these displays.
20624: Added buffer to HawkAgents cache to prevent missed updates
In previous versions where multiple sender dataservers forwarded copies of their
HawkAgents cache to a single receiving dataserver (ie, remote collectors with a
central aggregator), it was possible that the receiver could drop updates. This
has been corrected by adding row buffering to the receiver.
20646: Expiration removed from the HawkAgent cache
Rows in the HawkAgents cache only update when asynchronous events like hawk
alerts or onAgentAlive/onAgentExpired are received, so it is normal for rows to
not update for lengthy periods. Hence, the Expired column has been removed from
the HawkAgents cache and associated tabular display.
UX Monitor
20684: Packaging and documentation reorganization
The UXMON solution packaging has been changed to reduce confusion.
- The UX Robot installers (.zip/.gz) are now included inside the
rtvapm_uxmon_X.zip.
- The "UX Robot Read Me.doc" has been removed, as this information was duplicated
in the User Guide
- The README.txt now refers you to the User Guide.
Version 2.1.0 Release Notes
20181: Support Tomcat 8 and TC-Server
Tomcat 8 and TC Server are now supported in RTView EM, RTVMGR Tomcat displays.
To start monitoring your Tomcat 8 / TC Server instances, follow these steps:
1. Enable JMX access and set the monitoring port by following the Tomcat 8 / TC
Server installation documentation.
2. Add to your sample.properties file the JMX connection information of your
instances. To do so, add the following property for each instance:
collector.sl.rtview.jmx.jmxconn=MY_CONNECTION <IPAddress> <Port> URL:- <user>
<password> false
where you should replace:
- MY_CONNECTION with the name of your connection,
- <IPAddress> with the IP address of the machine hosting your Tomcat instance
- <Port> with the monitoring port you enabled in the previous step
If JMX authentication is used replace
- <user> with the username to connect to your Tomcat instance
- <password> with the password to connect to your Tomcat instance
Otherwise, replace <user> and <password> with a single - (dash)
Alerts
19545: Fixed error "cannot find $alertSourceList" in viewer and thin client logs
In previous releases, the viewer and thin client log files contained this error
after a user navigated to the RTView Alert Table view:
ERROR: GmsRtViewXmlDs -- $alertSourceList not found.
This error has been fixed.
Monitor
20537: New properties to limit Display Server table cells
The Monitor has been enhanced to support 3 new properties to limit the amount of
data that is passed from the Display Server to the browser for tables. The
following properties have been added to common\conf\rtvapm.properties:
cellsperpage - This limits the number of cells (columns*rows) that will be
displayed in a table object. This avoids the sluggish performance, timeouts,
and out-of-memory exceptions that might otherwise occur from processing and
transmitting all of the rows at once Table objects with more than the specified
number of cells are paged. This means that the Display Server only sends the rows
that are visible plus a few rows before and after the visible rows. As the user
scrolls, the new rows are requested from the Display Server. This results in a
small delay between the scroll action and the data showing up in the table. The
default is 20000.
cellsperexport - This limits the number of cells (columns*rows) that will be
exported for the Export to Excel and Export to HTML operations. The default is
40000.
cellsperreport - This limits the number of cells (columns*rows) that will be
exported for the Export to PDF operation. The default is 20000.
For all of the new properties, a value of less than 1000 will disable the
property. Values larger than the defaults may result in slower performance,
timeouts and/or out-of-memory exceptions when interacting with tables in displays
in the thin client.
RTView Core Functionality
Data Historian
20637: New option to limit length of strings from cache table stored in db
The historian has been enhanced to support a limit on the length of a string from
a cache table column that it will store in the database. If a string is longer
than the specified limit, it will be truncated to the limit before it is stored
in the database table. This can avoid SQL exceptions encountered when the length
of a string exceeds the capacity of the column's data type (for example, 4000
characters in an VARCHAR2 column in Oracle).
The limit is specified by a new property named stringColMaxLen. This can be
specified in HISTORY.ini as follows:
stringColMaxLen 3500
It can also be specified on the command line or a properties file. By default the
property has no value, so no limit is enforced.
Data Server
20596: Fixed duplication in connection error messages
A bug has been fixed which caused duplication of log messages when a client lost
its connection to a data server.
Data Sources
20589: Improved timezone support
The Round Robin Database (RRD) data source now handles variations of start/stop
times in different time zones.
Display Server
20582: Enable mouse cursor to change appearance when hovering over composites
If a composite object has its drilldownTarget set, then in the thin client the
"hand" cursor will appear when the mouse is over the composite. This is
consistent with the behavior of other objects that have a drilldownTarget.
20623: Table no longer fails to populate when cellsperpage is smaller than visible cells
A bug in the display server has been fixed which sometimes caused table cells in
the thin client to always contain "..." if the cellsperpage property was set.
Typically this occurred if the cellsperpage value was small (in the range of 1000
to 2000) and a table with many columns was opened. It was unlikely to occur with
a typical cellsperpage value of 10000 or more. The problem is fixed for all
cellsperpage values. As before, a value less than 1000 is ignored.
Object Library
20638: New property to limit text entered into text area control
The text area control (obj_c1textarea) has been enhanced to enforce an optional
maximum character limit. (The text field control, obj_c1textedit, has supported
this feature for several releases).
The text area control has one new property in the Data category:
maxCharacters - The maximum number of characters that will be submitted to the
command associated with the text area. If no value is specified there will be no
limit on the maximum number of characters. By default, there is no limit. Note
that the limit does not restrict the length of the text in the control, only the
length of the text that is sent to the control's command. See below.
The limit is checked whenever the control executes. If the executeOnFocusLostFlag
is selected, the control executes whenever the control loses focus. If the
executeOnKeyStrokeFlag is selected, the control also executes whenever a key is
pressed while the control has focus.
If the limit is exceeded, the control's actionCommand is not executed.
The text area control has two new properties in the Interaction category:
inputValidVarToSet - Attach to a local variable. This variable will be updated
when the control executes with a value of 1 if the maxCharacters limit is blank
or the text is less than or equal to the maxCharacters limit, or updated with a
value of 0 if the text length exceeds the maxCharacters limit.
invalidInputMsgVarToSet - Attach to a local variable. This variable will be
updated when the control executes with an error message if the text length
exceeds the maxCharacters limit, or updated with an empty string if the text
length is less than or equal to the maxCharacters limit.
Solution Package
IBM DB2 Database
20593: Corrected Sybase SQL schema definitions for datetime columns
The SyBase sql schema has been updated to account for the non-index date fields
that can be set to null.
TIBCO ActiveSpaces
20598: TAS-METASPACE CI-Type change
A change was made to a configuration file to support proper indexing of
TAS-METASPACE CI-Types. The previous configuration yielded similar results when
browsing CMDB screens, so no obvious changes in behavior will be evident.
20599: CMDB screens now drill down to table display instead of summary display
The drill-downs from CMDB screens have been changed to the summary screens for
Active Spaces CI-Types, which is consistent with drill-downs to other packages.
Previously, the drill-downs for ActiveSpaces CI-Types took you to the
corresponding tabular display.
TIBCO EMS
19162: Dataserver selection problem fixed
A bug that prevented the correct selection of the EMSMON dataserver under RTView
EM on some displays has been fixed. The displays are:
- "Admin Metrics" (ems_admin_metrics.rtv)
- "All Routes Table" (ems_allroutes_table.rtv)
- "All Other Info Server" (ems_otherinfo_forserver.rtv)
- "Server Route Table" (ems_server_route_table.rtv)
- "All Servers Topology" (ems_server_topology.rtv)
19495: Removed receiver count from All Topics Heatmap drop-down
Receiver count has been removed from the drop down in the All Topics Heatmap
display.
19496: Consumers added to the mouseover of All Queues Heatmap
Consumers count has been added to the mouse over in the All Queues Heatmap
display.
19546: Fixed "serverActivity3WithSeverity" function error
The error at startup: ERROR: function <serverActivity3WithSeverity>, Invalid left
column name(s) <URL> has been fixed.
19558: All Servers Grid display readability improved
The visibility of the EMS Server state in the All Servers Grid display has been
improved. Previously it was hard to read against the background color.
20050: Tibco Spotfire reports added for Server/Queue Message Metrics
With this release of EMSMON, Tibco Spotfire reports are available for both the
Server Message Metrics and the Queue Message Metrics. This initial set of reports
can be generated against historic data stored in either Oracle SQL or MySQL
databases. The reports can be run using Tibco Spotfire Desktop version 7.0.
The dashboards and associated SQL custom query text files are located in the
rtvapm/emsmon/projects/reports/Spotfire directory. They include:
Server Message Metrics:
ems_serverinfo_mysql.dxp (for MySQL)
ems_serverinfo_mysql.txt
ems_serverinfo_sql.dsp (for Oracle SQL)
ems_serverinfo_sql.txt
Queue Message Metrics:
ems_queues_mysql.dxp (for MySQL)
ems_queues_mysql.txt
ems_queues_sql.dxp (for Oracle SQL)
ems_queues_sql.txt
For more information, please refer to the User Guide.
20054: Expired bridges removed from "Bridges, Users, Ports" display
Expired bridges are being differentiated from unexpired by highlighting the
expired rows and displaying its Expiration flag. As prevously, expired bridges
will be deleted from the cache after 1h.
20081: New alerts for message latency
New two alerts, EmsQueueMsgLatencyHigh and EmsTopicMsgLatencyHigh, have been
created. These alerts are executed when the time to process the pending messages
based on current outbound message rate for a EMS Queue or Topic have reached
their maximum. The units of these alerts are seconds. The default thresholds for
both alerts for warning and alert are 60 and 80, respectively.
20134: New alert for async DB size
The alert EmsServerAsyncDBSizeHigh has been added to EMS Monitor. It will trigger
when an EMS server's async DB size exceeds the warning or alarm thresholds. The
default thresholds are 50 MB and 100 MB respectively.
20135: EmsConsumerStalled alertdef override now useable
The EmsConsumerStalled alert has been fixed to enable alert overrides.
20141: New alert for pending message count
A new alert, EmsServerPendingMsgSizeHigh, has been created. This alert is
triggered when the size of the pending messages stored on the EMS Server has
reached its maximum. The unit of this alert is KB and the default thresholds for
warning and alert are 60 and 80, respectively.
20233: Fixed typos in Consumers display
Typos in Ems Consumers for Server have been fixed.
20585: Corrected units in EMS Server Summary
Memory units have been fixed to show KB instead of kB.
TIBCO Hawk
20566: Hawk Alert time now mapped to the alert event's time
In previous releases, the HawkAlerts cache Time was not mapped to the Hawk alert
event time, but instead used the time that RTView received the Hawk alert event.
This has been fixed so that the Hawk alert event time is used instead. Note that
the Time on the HawkAlerts cache is also used as the Last Update Time on the
HawkAlert alert so that has been fixed by this change as well.
In previous releases, the HawkAlerts cache often missed alert updates, especially
at startup. This has been fixed for most cases. There are 2 cases where the
HawkAlerts cache sill may not be in sync with the Hawk Alerts on an agent (these
are noted in the PAL for task 20568:
1. If RTView does not receive any updates for a HawkAlert for the amount of time
specified in $rtvHawkAlertClearTime + $rtvHawkAlertDeleteTime (defaults to 10
days + 1 hour), it is removed from the HawkAlerts cache.
2. When using a sender to update the HawkAlerts cache, any events that occur when
the sender is running but the receiver is not will be missed. To fix this,
restart the sender after any restart of the receiver.
20567: Added expiration to avoid orphaned alerts
In previous releases, it was possible to get in a state where a HawkAlert alert
would be active with no corresponding row in the HawkAlerts cache. These orphaned
alerts would never clear. This has been fixed. Now, HawkAlert alerts are cleared
due to expiration after they have not received updates for 10 days. This matches
the time when a row that has not received updates will be removed from the
HawkAlerts cache.
This time period can be configured using the following property, which controls
both the alert expire time and the cache row delete time:
sl.rtview.sub=$rtvHawkAlertDeleteTime:864000
20579: Hawk Alert row expiration time configurable
The HawkAlerts cache has been enhanced to make the row expiration time
configuration. In previous releases, a row would be deleted from this cache if it
did not receive an update for 10 days. This time period still defaults to 10 days
but is now configurable using the following property:
# Default time to remove expired Hawk Alerts from the cache
sl.rtview.sub=$rtvHawkAlertDeleteTime:864000
20605: Filters added to HawkAlerts cache
Previous releases of EM's Hawk Monitor did not handle high-frequency Hawk alerts
gracefully. Properties (substitution variables) have been added to control the
manner in which Hawk alerts are applied to the HawkAlerts cache. This change
reduces the rate at which high frequency alert data is displayed in the "Hawk
Alerts Table".
The cases addressed by this change include the following:
1. Alert text changes continuously - for example, it contains the value of some
metric (eg, cpu%). In this case, you would want to specify to just ignore
updates.
2. Alert text includes a repeating set of discrete values - for example duplicate
serial number errors where the alert text contains host urls.
We don't want the alert cache entries to stop updating altogether or they will
expire, so a parameter is needed to allow occasional updates through.
The rows going into the HawkAlerts cache are now pre-processed to ignore or
append text updates according to these new subs:
$rtvHawkAlertTextToIgnore - set to a regex value that will match AlertText to
ignore. This will cause all updates to the alert text for those alerts to be
ignored until the amount of time specified in the $rtvHawkAlertTextUpdateTime sub
$rtvHawkAlertTextToAppend - set to a regex value that will match the AlertText
content that you want to append. This will cause all unique updates to the alert
text to be appended to the previous alert text value. All unique alert texts will
be appended until the value specified for the $rtvHawkAlertTextToAppendMax sub is
met. Then a ... will be added to the end of the alert text to indicate that other
alert text values were not appended. The delimiter between AlertTexts is |\n ad
can be changed with the $rtvHawkAlertTextToAppendSep sub.
$rtvHawkAlertTextToAppendMax - defaults to 0 which means an unlimited number of
AlertTexts will be appended. By default, the string "|\n" is used as the
separator between alert text values. Change this using the
$rtvHawkAlertTextToAppendSep sub. The $rtvHawkAlertTextUpdateTime also applies to
this case.
$rtvHawkAlertTextUpdateTime - set to an amount of time to ignore updates for
matches of the above 2 subs, 3600 default. Note that the
$rtvHawkAlertTextUpdateTime sub should not be set to 0 - you want it to update
occasionally so the alert won't expire.
Examples:
collector.sl.rtview.sub=$rtvHawkAlertTextToIgnore:<some string>
collector.sl.rtview.sub=$rtvHawkAlertTextToAppend:<some string>
collector.sl.rtview.sub=$rtvHawkAlertTextToAppendMax:5
#collector.sl.rtview.sub=$rtvHawkAlertTextToAppendSep:-->
collector.sl.rtview.sub=$rtvHawkAlertTextUpdateTime:120
The recommended place to add these properties is the connection properties file
for the applicable dataserver(s).
Version 2.0.0 Release Notes
Alerts
20198: Error messages and failure of custom alert filters with some configs
In previous releases, the Custom Alert Filter did not work when EM was configured
to access the ALERTDEFS database via the Config Server instead of directly in the
Central Alert Server. Even if no Custom Alert Filters were defined, the Central
Alert Server log would contain errors about the ALERTDEFS database connection
when running in this configuration.
This has been fixed by using a substitution for the dataserver running ALERTDEFS
database.
If the Central Alert Server is configured to connect to the ALERTDEFS database
directly, no changes are needed to take advantage of this fix.
If the Central Alert Server is configured to access the ALERTDEFS database via
the Config Server, uncomment the following line in conf\emcommon.properties:
#AlertClient.sl.rtview.sub=$rtvAlertFilterDataServer:CONFIG_SERVER
20199: Alert cache history storage settings changed
The history settings for the RtvAlertTable cache in the Central Alert Server have
been enhanced. In previous releases, 2 weeks of history were kept in-memory and 2
days were kept in the database. It now keeps 2 weeks in the database and 1 hour
in memory. These settings can be changed using the following properties:
# Sets the in-memory limit to the number of seconds specified (30 minutes in this
example)
AlertServer.sl.rtview.sub=$rtvAlertHistoryTimeSpan:1800
# Sets the database limit to the time period specified (1 hour in this example)
AlertServer.sl.rtview.sub=$rtvAlertCompactionRules='1h -'
20228: Row count and enhanced filter added to Alert History display
The Alerts History Table display has been enhanced with a new row count field and
better filtering.
To filter the table, select a table column from the Field Filter combo box. In
the Search Text field, enter the (case-sensitive) string to search for in the
selected Field Filter. Press <enter> to apply the filter. The Clear button clears
the Field Filter and Search Text fields. The Regex button behaves as it did
before: it toggles the Seach Text field to use Regular Expressions for filtering.
The Count label shows 2 values: the filtered row count before the "/" and the
unfiltered row count after the "/".
20538: Alert history display limit changed to 20k rows
The Alerts History Table has been enhanced to set the maximum number of rows to
20,000. Previously, the display queried up to 50,000 rows from the cache, but
only displayed 10,000 of those rows in the display. Now, it limits both the cache
query and the table rows to 20,000.
20543: Fixed column type mismatch errors in central alert server log
In previous release, the central alert server log file occassionally contained
multiple instances of the following error message:
GmsTabularData.insertData(): column type mismatch
This error did not indicate a real problem, but cluttered the log file. It has
been fixed.
Configuration
20189: Naming convention cleanup for alert and config server connections
The JMX Connection name and the data server name for the Alert Data Server and
the Config Data Server have been made consistent with other naming practices.
Enforcing the match of both parameters reduces the level of indirections needed
to associate JVM data with monitoring data from Data Servers.
Customization
20182: Fixed historian configuration bug in custom example
A bug that prevented history being displayed properly in the Summary display of
the custom example has been fixed. Also, the validation for Connection and Bird
have been fixed to allow all data sources to be validated properly.
20204: Cleanup of the custom solution package
Minor improvements have been made to the custom solution package example to
improve consistency with the documentation.
General
20197: Cleanup of properties files to improve performance
Previously, several highly used properties file defined global substitutions
unnecessarily. This had the effect of reducing performance in the Display Server
due to excessive substitutions being included in the URL of RTView Servlets.
This has been fixed.
JVM metrics
20229: JVM Memory data no longer gaps in trends received from sender
A bug that prevented correct visualization of Memory in the JVM Summary display
has been fixed.
Key Metrics
20016: Key metrics added for RTVMGR
The rtvmgr solution package has been enhanced to support Key Metrics.
The following Key Metrics are supported for the JVM CI Type:
CPU %
Memory %
The following Key Metrics are supported for the TOMCAT and TOMCAT-APP CI Types:
Active Sessions
Accesses / sec
20023: Key metrics implemented for RTVRULES CI Types
The RTVRULES solution package has been enhanced to support Key Metrics. The
following Key Metric is supported for the EM-SERVICE CI Type:
Alert Impact
20025: Key metrics implemented for IBM DB2 CI Types
Key Metrics have been added to the db2mon solution package. The following Key
Metrics are supported:
Response Time
20027: Key metrics implemented for Host CI Types
Key Metrics have been added to the hostbase solution package. The following Key
Metrics are supported:
% CPU Utilization
% Memory Used
20028: Key metrics implemented for IBM MQ CI Types
Key Metrics have been added to the MQMON solution package. The following Key
Metrics are supported:
MQ-BROKER
Queue depth
MQ-QUEUE
Queue depth
20030: Key metrics implemented for Oracle Coherence CI Types
Key Metrics have been added to the ocmon solution package. The following Key
Metrics are supported:
OC-CLUSTER:
Packet Loss
OC-CACHE:
Queue Size
20031: Key metrics implemented for Oracle Database CI Types
Key Metrics have been added to the oramon solution package. The following Key
Metrics are supported:
Response Time
20033: Key metrics implemented for Solace CI Types
Key Metrics have been added to the Solace solution package. The following Key
Metrics are supported:
SOLACE-APPLIANCE
# Msgs Spooled
SOLACE-VPN
Connections
20035: Key metrics implemented for TIBCO ActiveSpaces CI Types
Key Metrics have been added to the TIBCO Active Spaces solution package. The
following Key Metrics are supported:
Gets/sec
Puts/sec
20037: Key metrics implemented for User Experience CI Types
Key Metrics have been added to the uxmon solution package. The following Key
Metrics are supported:
Response Time
20038: Key metrics implemented for VMWare CI Types
Key Metrics have been added to the vmwmon solution package. The following Key
Metrics are supported:
VMWARE-VM
Host CPU Usage
Host Memory Usage
VMWARE-HOST
VM CPU Usage
VM Memory Usage
20039: Key metrics implemented for WebLogic CI Types
Key Metrics have been added for WebLogic CI Types. The following metrics are
supported:
WLS:
JVM CPU %
JVM Memory %
Open Sockets
WLS-APP:
Open Sessions
20040: Key metrics implemented for WebSphere CI Types
Key metrics for WebSphere have been added.
The Websphere Server (WAS CI Type) has:
Live Session Count
WAS CPU %
Memory Used %
WebSphere Applications (WAS-APP CI Type) has:
Response Time
Requests / sec.
20041: Added navigation from Service Summary Views to Key Metrics
The Service Summary Views have been enhanced to allow navigation to the Key
Metrics views from the navigation combo box.
20131: Key Metrics added
RTView EM has been enhanced with a new Key Metrics feature. The Key Metrics (KM)
feature is an entirely new way of looking at and interpreting application health
and performance data.
In contrast to the traditional Alert Impact view showing your ACTIVE alerts and
their impact on the overall application or service, the Key Metrics view shows
how close a metric is approaching its threshold over a period of time – both
before and after the alert threshold is reached.
This allows you to both proactively anticipate performance problems BEFORE the
alert threshold is crossed as well analyze the circumstances that led up to error
conditions AFTER you got an alert. Armed with this knowledge, you an avert
disasters before they happen and resolve problems faster after they happen.
RTView does this by correlating the most valuable key metrics over multiple
components within a service and displaying them in context with both real-time
and historical data. This is valuable because health problems in one component
may be caused by performance problems in another and only by viewing each of
these metrics in context with one another over a period of time are you able to
visually link the relationship between troubled components.
It is important to note that your Alert Impact heatmaps may look very different
from your Key Metrics heatmaps given that KM will indicate potential threats
BEFORE they show up as alerts.
There are 4 views under the new Key Metrics Views item in the navigation tree:
- Service KM Heatmap - shows the current Key Metrics values in a heatmap
- Service KM Table - shows the current Key Metrics values in a table
- Service KM History - shows historical Key Metrics values in a status history
graph
- Service KM History (Alt) - shows historical Key Metrics values in a heatmap
There is also a new view under Architecture, RTView KM Defs. This view shows the
Key Metrics definitions for each CI.
See the documentation for more information on the new Key Metrics displays.
Upgrade Notes
When upgrading from previous releases, perform the following steps to add KM to
your project:
1. Add the following to the rtview.properties file in your central directory (In
emsample, servers\central\rtview.properties):
# Include km package
rtvapm_package=km
2. Add the following to your navigation tree (in emsample, servers\central\
rtv_appmon_navtree.xml):
<node label="Key Metrics Views" mode="" display="rtv_dir_km">
<node label="Service KM Heatmap" mode="" display="rtv_km_current_heatmap"/>
<node label="Service KM Table" mode="" display="rtv_km_current_table"/>
<node label="Service KM History" mode="" display="rtv_km_history_heatmap_sh"/>
<node label="Service KM History (Alt)" mode="" display="rtv_km_history_heatmap"/>
</node>
Dependencies
The KM package is dependent on the Metric Explorer package. Both must be included
in your project in order for KM to work. If you are upgrading from a version
previous to 1.5.0 and have not added Metric Explorer to your project, refer to
the EM User Guide Upgrade Notes section for information on including it.
20163: Key metrics implemented for Amazon Cloudwatch CI Types
Key Metrics have been implemented for the acwmon solution package. The following
Key Metrics are supported:
Instance CPU Usage
20165: Key metrics implemented for Glassfish CI Types
Key Metrics have been added to the GFMON solution package. The following Key
Metrics are supported:
Service Time
Request Count
20166: Detail-level key metrics implemented for TIBCO EMS CI Types
Second level metrics for the EMS Servers, Queues, and Topics have been added.
These metrics are:
EMS-SERVERS
Msg Mem %
Connections
EMS-TOPICS
Consumers
Subscribers
EMS-QUEUES
Consumers
20167: Detail-level key metrics implemented for WebLogic CI Types
Detail level metrics for the WebLogic Servers have been added. These metrics are:
Open Sockets
Thread Total Count
20168: Detail-level key metric added for JVM CI Type
ThreadCount has been included as a Key Metric Detail for the JVM CI Type.
20176: Key metrics example added to Custom example
An example of Key Metrics has been added to the Custom Solution Package.
Navigation
20169: Service Summary View navigation cleanup
The Service Summary Views have been enhanced as follows:
1. The Service Browser display has been removed from the navigation tree and from
the navigation combo box in the other Service Summary Views. This display was
removed because the CI / Service Tree View under the Component Views section
provides the same functionality.
2. The MX (Metric Explorer) button was moved to the right of the navigation combo
box in the Service By CI Type and Service Summary Views. The functionality of
this button has not changed, just the position.
Platform Support
20071: Properties now loaded from all solution packages defined
In previous releases, solution package specific properties were only loaded for
one solution package even if multiple solution packages defined properties. This
has been fixed.
RTVMGR
20108: New alerts TomcatActiveSessionsHigh and TomcatAppActiveSessionsHigh
Two new Tomcat alerts, TomcatActiveSessionsHigh and TomcatAppActiveSessionsHigh,
have been added to alert when the number of active sessions of a Tomcat Server
and a Tomcat Application reach their thresholds.
20183: JVM Operating System Cache no longer shows PhysicalMemory = 0
A bug that prevented the JvmOperatingSystem cache from correctly collecting the
TotalPhysicalMemory metric has been fixed.
20190: New Jvm Thread Count High alert
A new alert, JvmThreadCountHigh, has been added. This alert fires when the number
of threads exceeds the established thresholds.
20214: Process Name and PID added to Data Server display
The RTView Data Server metrics display has been enhanced to include Process Name
and PID columns in the Data Server Clients table.
The value that appears in the Process Name column depends on the type of client.
If the client is an RTView application, then the Process Name shows the value of
the PROCESS_NAME property when the app was started. If the client process was
started with a standard RTView script (e.g. run_viewer, run_displayserver, etc)
then the Process Name will be viewer, builder, dataserver, displayserver, or
historian. For a server, a "d" at the end of the process name indicates it was
started with the -daemon option. If the PROCESS_NAME property was undefined when
the client process was started, then the Process Name will be RTView (the
viewer), RTView Display Builder, Display Server, Data Server, or Historian, or
the OEM names assigned to those applications. If the client is the viewer applet,
then "applet" is appended to the name.
If the client is the rtvdata or rtvquery servlet, the Process Name will be
RTVDataServlet and rtvquery, respectively, or the custom servlet name that has
been configured for the deployed servlet instance.
The PID column shows the PID (process ID) of the client process. Typically the
PID column value will appear as nnnn@hostname, where nnnn is the PID from the
client's host system (as reported by jps, top, or tasklist) and hostname is the
name of the client's host. If the client is the rtvdata or rtvquery servlet, then
the PID will correspond to the app server (e.g. tomcat) process on the client
host. The PID column may be blank if the client is unable to obtain its PID from
the local operating system. The @hostname portion may be omitted if it cannot be
obtained from the local operating system.
The PID and Process Name columns will both be blank if the client process is
running an older version of RTView that does not have this enhancement.
RTView Core Functionality
Builder
20330: Support aligning and distributing objects against objects from include files
The Builder has been enhanced to support Aligning and Distributing objects in the
local .rtv file against objects in an included .rtv file. When the selection
contains both objects in the local file and objects in an include file, ony the
objects in the local file will move. Objects in include files can still only be
edited directly in the include file.
Builder - Editing
20091: Display Data option enabled for read-only data attachments
The Builder has been enhanced so that the Display Data option is now available
for read-only data attachments.
Data Historian
20019: Compaction smoothing no longer sets incorrect "run after" date
Previously, the smooth compaction option caused an an incorrect "run after" date
to be set for further compaction. This could result in a small portion of data
not being compacted. This has been fixed.
20067: Data retention (purging) now correctly performed after compaction/smoothing
Previously, database retention logic was incorrectly postponed after
smoothing/compaction had taken place on a table. This could result in the
retention of more data than specified in historian configuration. This has been
fixed.
20159: Sync up data from the history cache when historian starts
The Historian supports a new option named persistInitTimeRange which affects the
cache persistence feature.
Normally, when the cache persistence feature is enabled in the historian, the
historian begins collecting cache history data starting at the time when each
data server connects. This is adequate in most situations. The
persistInitTimeRange option can be used to specify a time range, in seconds, back
from the current time that the historian should get cache history data from the
data server. This can be useful if the historian is started sometime after the
data server, so the data server has collected cache history that hasn't been sent
to the historian. For example, if the data server was started an hour before the
historian, then the historian could be started as follows, so that it will
request an hour of cache history from the data server:
run_historian -persistCaches:true -persistInitTimeRange:3600
20187: Option to perform compaction for a time range prior to "now"
An option was added to the Historian to allow for the smoothing process to only
go back as far as a specified range in the form:
-smoothCompactionRecent:NN Where NN is '1d' or '1w'
20254: Retention-only compaction now executed correctly
Previously the historian would fail to run compaction if the Compaction Rules
consisted of a single rule that only specified a duration of Raw data (-).
This has been fixed.
Data Server
20138: add ProcessName, PID columns to ClientData attrib of data server mbean
The data server's Manager mbean has a tabular attribute named ClientData which
contains one row for each client connected to the data server. In this release
the ClientData table has two new columns named PID and Process Name. These are
intended to help administrators identify the process that corresponds to each
client connection.
The value that appears in the Process Name column depends on the type of client.
If the client is an RTView application, then the Process Name shows the value of
the PROCESS_NAME property when the app was started. If the client process was
started with a standard RTView script (e.g. run_viewer, run_displayserver, etc)
then the Process Name will be viewer, builder, dataserver, displayserver, or
historian. For a server, a "d" at the end of the process name indicates it was
started with the -daemon option. If the PROCESS_NAME property was undefined when
the client process was started, then the Process Name will be RTView (the
viewer), RTView Display Builder, Display Server, Data Server, or Historian, or
the OEM names assigned to those applications. If the client is the viewer applet,
then "applet" is appended to the name.
If the client is the rtvdata or rtvquery servlet, the Process Name will be
RTVDataServlet and rtvquery, respectively, or the custom servlet name that has
been configured for the deployed servlet instance.
The PID column shows the PID (process ID) of the client process. Typically the
PID column value will appear as nnnn@hostname, where nnnn is the PID from the
client's host system (as reported by jps, top, or tasklist) and hostname is the
name of the client's host. If the client is the rtvdata or rtvquery servlet, then
the PID will correspond to the app server (e.g. tomcat) process on the client
host. The PID column may be blank if the client is unable to obtain its PID from
the local operating system. The @hostname portion may be omitted if it cannot be
obtained from the local operating system.
The PID and Process Name columns will both be blank if the client process is
running an older version of RTView that does not have this enhancement.
20231: Cache extend-by-sql option now supported in REST api
The REST (rtvquery) servlet now supports the "Extend with SQL" option on queries
of cache history tables. This is enabled by setting the parameter named sqlex to
true in a query URL. For example, the following URL is a query of the history
table of a cache named Apps for the past 24 hours with the Extend with SQL option
set:
http://host/rtvquery/cache/Apps/history?fmt=text&tr=86400&sqlex=true
Note that the new option only applies to a history table query, and only in the
case where the time range (tr), begin time (tb), or end time (te) parameter is
also specified. Use this option with caution as it may generate a large result.
Data Sources
19986: RRD data adapter fixed for Linux
In previous versions the the RRD data adapter was not correctly executing rrdtool
on linux systems. This has been fixed.
20100: Cache extend-by-sql query now ignores row filters with value=*
A bug has been fixed in the cache data source which affected cache data
attachments using the Extend with SQL option and which also use a row filter with
multiple columns or multiple values, where * is used as one or more filter
values. In those cases, the "where" clause in the SQL query generated by the
cache data source was incorrect and returned no rows. This is fixed.
20191: Prevent data with timestamp < historyTimeSpan from going to history
In prior releases, a row with a timestamp older than a cache's historyTimeSpan
could be added to the cache's history table and would not be removed until the
next update. In this release this has been fixed so that such a row is not added
to the history table in the first place.
Display Server
20009: Animated gif labels no longer mispositioned
In previous releases, the animated gif image on a label object would sometimes
appear in the top left corner of the display, rather than positioned correctly on
the label object. This is fixed.
20021: Images now found when rtv file loaded from subdirectory
In prior releases, the thin client would fail to load images for some objects if
the images and the display containing the objects were in a subdirectory of the
display server's working directory. This is fixed.
20097: “loading …” label no longer remains after loading finished
A problem has been fixed in the thin client that would sometimes cause the
"loading..." message to remain on the display after the display had finished
loading.
20151: Fixed bogus string for checkboxes when tabIndex > 0
A bug has been fixed in the thin client which affected displays containing any
control object with its tabIndex property assigned to a nonzero value, as
follows:
1) For each checkbox control on the display an unexpected string "tabIndex=nn"
appears at the top of the display.
2) The initial keyboard focus may not be set to the expected control object.
3) If the javascript console or debugger window is open, an error is reported.
All of these symptoms have been fixed.
20185: Kendo grid now supported
The "web grid" is a new HTML implementation of the RTView table object
(obj_table02) that provides enhanced filtering, sorting, and other interactive
features. The web grid is available in the thin client only.
1. Enabling the Web Grid:
A new property has been added to obj_table02, named webGridFlag. To enable the
web grid in the thin client for a specific obj_table02 instance, check the
object's webGridFlag property in the Builder property sheet. Alternatively, the
web grid can be enabled on all obj_table02 instances by adding the following rule
to an rtview stylesheet (.rts) file loaded by the display server:
obj_table02 {
webGridFlag : 1
}
The default value of webGridFlag is false, which indicates that the "classic"
html grid should be used in the thin client.
2. Requirements:
If webGridFlag = true then the web grid will appear in the thin client in any
modern version of a supported browser. No plugin is required. For Internet
Explorer users, version 9 or newer is required and version 11 is recommended for
best performance. In IE8 or older, the web grid is not supported so the classic
grid will be used regardless of the webGridFlag setting. In this release the web
grid is not supported on iPad but may be supported in the future.
3. New Features:
The web grid supports a number of new, interactive features: sorting on multiple
columns, filtering on multiple columns, column resizing, column reordering, and
hiding columns. In addition the user can "unsort" a previously selected sort
column, returning it to its original unsorted order. In a grid with
rowHeaderEnabledFlag = true, additional columns can be locked into the row header
so they remain visible regardless of the horizontal scroll position.
Many of these features are accessed from the column menu opened by clicking on
the menu icon that appears near the right edge of each column's header.
The user can save all of the aforementioned column settings/options permanently,
in the browser's local. The saved settings are automatically restored when the
user later reopens the display, with the same username and role.
Also, for improved performance and usability, if a data table contains more than
200 rows the web grid will display it in pages of 200 rows, using a page control
that appears at the bottom of the grid.
Each new feature is described below:
3a. Column Sorting:
The user can click on a column header to sort the table by that column. On the
first click, the column is sorted in ascending order (smallest value at the top),
on the 2nd click the sort is in descending order, and on the 3rd click the column
is returned to its original unsorted state. A sort on a string column is
case-insensitive.
The user can select multiple sort columns. In that case, the sorting is performed
in the order that the column headers were clicked. Multiple column sorting is a
very useful feature, but can also cause confusion if the user intends to sort on
a single column, but forgets to "unsort" any previously selected sort columns
first. Users should check for the up/down sort icon in other column headers if a
sort gives unexpected results.
Column sorting is reflected in an export to html/excel.
3b. Column Visibility:
The user can hide or show columns in the table by clicking on any column's menu
icon, and picking Columns from the menu. This will open a submenu with a checkbox
for each column that toggles the visibility of the column. All columns in the
data table will appear in the Columns menu, even those that are initially hidden
by the obj_table02 property columnsToHide. If the grid has the
rowHeaderEnabledFlag property checked then the leftmost column (the row header
column) cannot be hidden.
Column visibility changes are NOT reflected in an export to html/excel.
3c. Column Filtering:
The user can create a filter on any column. If filters are created on multiple
columns, then only the rows that pass all of the filters are displayed. That is,
if there are multiple filters they are logically ANDed together to produce the
final result.
The background of a column's menu icon changes to white to indicate that a filter
is defined on that column. This is intended to remind the user which columns are
filtered.
The user can configure a filter on any column by clicking on the column's menu
icon and picking Filter from the menu. This will open the column filter dialog,
which varies according to the data type of the selected column:
- For a string column, the user can enter a filter string such as "abc" and, from
the dropdown list, select the operator (equal to, not equal to, starts with,
contains, etc) to be used when comparing the filter string to each string in the
column. All of the filter comparisons on strings are case-insensitive. The user
can optionally enter a second filter string (e.g. "xyz") and specify if an AND or
OR combination should be used to combine the first and second filter results on
the column.
- For a numeric column, the user enters numeric filter values and selects
arithmetic comparison operators, (=, !=, >, >=, <, <=). The user can optionally
enter a second filter value and comparison operator, and specify if an AND or OR
combination should be used to combine the first and second filter results.
- For a date column, the user can select a date and time and choose whether
matching items should have a timestamp that is the same as, before, or after the
filter time. The date is selected by clicking on the calendar icon and picking a
date from a calendar dialog. The time is selected by clicking on the time icon
and picking a time from a dropdown list. Alternatively, a date and time can be
typed into the edit box. (See the limitations section for a note on time
filtering when the client and server are located in different time zones).
- For a boolean column, the user simple selects whether matching items should be
true or false.
Data updates to the grid are suspended while the filter menu is opened. The
updates are applied when the menu is closed.
Column reordering is reflected in an export to html/excel.
3d. Column Locking:
This feature is available only if the obj_table02 instance has the row header
feature enabled (rowHeaderEnabledFlag is checked). If so, the leftmost column is
"locked" in position, meaning that it will not scroll horizontally with the other
columns in the table. If the row header is enabled, then two items labelled Lock
and Unlock will appear in the column menu. These can be used to add or remove
additional columns from the non-scrolling row header area. If the row header is
enabled, at least one column must remain locked.
3e. Column Reordering:
The user can reorder the grid columns by dragging and dropping a column's header
into another position. If the grid has rowHeaderEnabledFlag checked, then
dragging a column into or out of the row header area (the leftmost columns) is
equivalent to locking or unlocking the column.
Column reordering is NOT reflected in an export to html/excel.
3f. Paging:
If the data table contains more than one page of rows, the page controls are
displayed at the bottom of the grid. The default page size is 200 but can be set
on each obj_table02 instance via the new property named webGridRowsPerPage. The
default value of that property is zero, which indicates that the default size
(200) should be used. If the height of the grid is less than about 64 pixels,
there is insufficient space to display the page controls so only the rows on the
first page will be viewable.
3g. Row mouseover:
A new property named webGridHoverColor is available on obj_table02. It is visible
only if webGridFlag = true. The default value of webGridHoverColor is checked. If
it is set to any other color index value, then that color will be used to
highlight the row that is under the mouse cursor. But if the obj_table02
filterProperties feature is used to color rows, that color will take precedence,
so the webGridHoverColor may not be useful in those cases. Also, if the row
header is enabled, the row header column and the other columns are highlighted
separately, according to which section of the grid the mouse is over.
3h. Saving settings:
The user can permanently save all of the custom settings made to the grid,
including filtering, sorting, column size (width), column order, column
visibility, and column locking. This is done by opening any column menu, clicking
Settings, and then clicking Save All.
The grid's settings are written as an item in the browser's local storage. The
item's value is the a string containing the grid's settings. The item uses a
unique key comprised of the URL path name, the display name, and the obj_table02
instance's rtview object name. If the thin client's login feature is enabled, the
key will also include the username and role, so different settings can be saved
for each user and role for a grid on any given display, in the same browser and
host.
If the user saves the grid settings and navigates away from the display or closes
the browser, then the next time the user returns to the display in the same
browser the settings are retrieved from the browser's local storage and applied
to the grid. The browser's local storage items are persistent, so the grid
settings are preserved if the browser is closed and reopened or if the host
system is restarted.
If the obj_table02 has autoResizeFlag = true then the column widths will not be
restored from the saved settings, and the values computed by the auto-resize
feature will be used instead. This is by design.
The user can delete the grid's item from local storage by clicking Settings ->
Clear All in any column menu. This will permanently delete the saved settings for
the grid and return the grid to the state defined in the display file.
Note that each browser has its own local storage on each host. The local storage
items are not shared between browsers on the same host or on different hosts. So,
if a user logs in as Joe with role = admin, in Internet Explorer on host H1, and
saves grid settings for display X, then those grid settings will be restored each
time a user logs in as Joe, role admin, on host H1 and opens display X in
Internet Explorer. But if all the same is true except that the browser is Chrome,
then the settings saved in Internet Explorer will not be applied. Or if the user
is Joe and role is admin and the browser is IE and the display is X, but the host
system is H2 not H1, then the grid settings saved on H1 will not be applied.
4. Support for large tables:
The web grid can support data tables with many rows and columns. However, for
best performance the display server's cellsperpage property should be specified
so that the server will send large tables to the client in pages, rather than
sending all of the rows. In this server paging mode, large tables are also
filtered and sorted in the display server, to improve performance and decrease
data traffic. The cellsperpage option is not new or specific to the web grid, it
has been available for several years. See the RTView documentation for a
description of the cellsperpage property, and the related cellsperexport and
cellsperreport properties. A typical value for cellsperpage is 20000.
5. Unsupported obj_table02 features:
The following are existing features of obj_table02 that are not supported by the
web grid
-The rowHeaderEnabledFlag property is supported, but rowHeaderBgColor,
rowHeaderTextColor, rowHeaderTextFont, rowHeaderTextSize are ignored. Instead the
row header column is rendered like all other columns.
- The columnResizeEnabledFlag is ignored if it is false, the web grid always
allows column resizing.
- The editDataEnabledFlag is ignored, the table editing feature using custom
commands is currently not supported.
6. Other limitations, and differences between the new & classic grids:
- Time zones: The strings shown in a date column are formatted by the display
server using its time zone. But if a filter is specified on a date column, the
date and time for the filter are computed using the client system's time zone.
This can be confusing if the display server and client are in different time
zones.
- Selected rows: The grid's row selection is cleared if the sort is changed or if
columns are resized or reordered.
- Scrollbars: In general the grid will only display scrollbars when they are
needed. However, the web grid and the classic grid use different algorithms for
deciding when to show or hide scrollbars, and do not use identical row heights
and column widths. So the web grid may sometimes display scrollbars when the
classic grid does not, for a grid instance with a given width and height.
- Keyboard traversal: In the classic grid, selecting a row and then using the
up/down arrow keys will change the selection to the previous/next row. In the web
grid, the arrow keys will move the keyboard focus to another row, as indicated by
a highlight border around the focused table cell, but the user must press the
space bar to select the row that contains the highlighted (focused) cell.
- Column widths: On a web grid with no locked columns (rowHeaderEnabledFlag =
false), columns will expand to fill any unused width in the table, even if
autoResizeFlag = false. That is, if the total width of the columns is less than
the grid width (ie. the columns don't use all of the available width) then each
column is expanded proportionally to fill the table. In contrast, the classic and
Swing (viewer) grids just leave unused space at the right edge of the grid. If
the grid has locked columns (rowHeaderEnabledFlag = true), then the web grid
behaves the same as the classic and Swing grids.
- Export: The export to html and export to excel features are supported on the
web grid, and behave much the same as on the classic grid. The exported table
respects the grid's filter and sort settings but ignores any column reordering,
sizing, or hiding changes made by the user.
- Data updates to the grid are suspended while the filter menu is opened. The
updates are applied when the menu is closed.
7. An implementation note, for custom web page developers only:
The rtview thin client now uses 2 versions of the jQuery javascript library
jQuery 1.3.2, to support the jQuery UI components used for panels, layout, and
(some) navigation controls
jQuery 1.9.1, to support the web grid
Version 1.3.2 is bundled into the thin client js file named rtvNav1.js, while
version 1.9.1 is loaded as a separate js file. To prevent conflicts between the
two libraries, the jQuery $ alias is no longer used by rtview and is
intentionally removed. Instead the jQuery 1.3.2 library is referenced by the
alias rtv.jqNav as needed, and the jQuery 1.9.1 library is referenced by the
alias rtv.jq as needed.
This could affect existing custom javascript code that users have written. For
example, the following is a snippet of javascript from a custom html page that
uses jQuery UI tabs for navigation
<script src="rtvNav1.js"></script>
<script>
$(document).ready(function () {
var outerLayout = $('body').layout({
north__size:64, north__spacing_open: 0,
});
$('#tabs').tabs();
...
The code above uses the jQuery $ alias, which it assumes is defined in the
rtvNav1.js file. But that is no longer true, so the custom code should be
rewritten to use the rtv.jqNav alias for jQuery in place of the $ alias, as
follows:
<script src="rtvNav1.js"></script>
<script>
rtv.jqNav(document).ready(function () {
var outerLayout = rtv.jqNav('body').layout({
north__size:64, north__spacing_open: 0,
});
rtv.jqNav('#tabs').tabs();
...
20237: Touchscreen PCs no longer display thin client in tablet mode
In prior releases, if the thin client was opened in a browser on a PC with a
touchscreen, items would be missing from in the right-click context menu. The
missing items includied the Drill Down, Execute Command, and Export Table to
Excel items, plus any custom menu items. This is fixed.
Functions
19950: Fixed Group By Unique Values function error
Previously, when the restrict to value list option was enabled, all rows from the
original table that were not found in the value list were incorrectly assigned to
the first element of the value list.
This has been fixed.
General
19901: Stylesheet processing bug fixed
When colors of objects are driven by both stylesheets and functions, the
functions should take precedence.
In the previous release, the stylesheet was being incorrectly applied to
properties that were attached to data. In many cases this was not noticeable
because an update to the data attachment would override the stylesheet setting.
However, in some cases where the data attachment didn't update after the display
was processed, the stylesheet value was used. This has been fixed so that
stylesheet values are no longer applied to properties that are attached to data.
20017: rtvquery servlet now uses "UTF-8" instead of "UTF8"
The rtvquery servlet will now specify UTF-8 character encoding for all responses.
Previously, the servlet specified UTF8 which was not recognized by Internet
Explorer versions 9 and older and caused an exception with the message "Could not
complete the operation due to error c00ce56e"
Object Library
19989: Default format for date columns added to table objects
A property named columnFormatDate has been added to the table object
(obj_table02). By default the property's value is blank. If the property is set
to a valid time format, then that format will be used for all time/date columns
in the table that do not have a format specified in the table's columnFormat
property.
For example if an obj_table02 instance contains a date column named X, then the
format for column X is determined as follows:
1. If the table object's columnFormat property contains a valid date/time format
for column X, then that format is applied to column X.
2. If the table object's columnFormatDate contains a valid date/time format, then
that format is applied to column X.
3. Otherwise the default date/time format for the current locale, as returned by
java.text.DateFormat.getDateTimeInstance(), is applied to column X.
As with any object property, an rtview stylesheet entry can be used to set
columnFormatDate globally on all obj_table02 instances, for example:
obj_table02 {
columnFormatDate: "yyyy-MMM-dd HH:mm:ss"
}
20007: HTML5 - Color of the Navigator Trace now matches the trace it is representing
The navigator trace on the html5 chart will now use the same color as the trace
assigned to the chart's webChartNavigatorTrace. In previous releases, the
navigator trace was always blue.
20142: Fixed minor usability problems with tree/accordion control
The following minor problems with the tree and accordion control object are
fixed:
1 The initialExpandDepth property is now only applied to new branches.
Previously, on a tree control with valueTableType = Row-node the
initialExpandDepth was improperly reapplied on each update to the tree, reopening
any existing branches that the user may have closed.
2. In the thin client, the labels on accordion buttons are now aligned properly:
Parent (non-leaf) node labels are left aligned, and leaf node labels are center
aligned. This is consistent with the accordion in the builder/viewer. Previously,
parent node labels were center aligned in the thin client, which was incorrect.
3. On a tree control In the thin client, a click on the +/- icon now opens/closes
the tree branch as expected but it no longer selects the node or triggers the
tree control's command. This is now consistent with the tree control behavior in
the viewer.
4. On an accordion control In the thin client in most browsers, a click on a
left/down arrow icon now opens/closes the branch as expected but it no longer
activates the accordion button or triggers the accordion control's command.
However, in IE version 8 or older, and in the viewer, the accordion button is
still activated and the control's command is executed.
Solution Package
Amazon CloudWatch
20588: ACW api has changed
In 2015 Amazon added two additional metrics (CPUCreditBalance and CPUCreditUsage)
to those available using the basic API. These metrics caused the CloudWatch data
adapter to fail.
The adapter has been modified to be robust and work correctly when Amazon adds or
deletes metrics. In the case of deletion, the adapter may print a warning that an
expected metric is not available.
Note that ACW monitoring will fail for all versions of the ACW monitor prior to
EM version 2.0.
Host Infrastructure
20206: Fixed scaling of CPU % column
The "CPU %" column in the "Host Views" / "All Processes Table" was improperly
scaled. The data inserted into the HostProcesses cache is now multiplied by a
correction of 100 divided by the number of host processors (threads for
hyperthreaded architectures).
IBM Websphere Application Server
20184: Adjustments to allow processes to be run with a Sun JVM
A problem that prevented WSM being executed out of the box in Sun JVMs has been
fixed.
To use a Sun JVM, after setting WAS_HOME in custom_setup.bat/.sh, edit the
sample.properties file and comment out the line:
collector.sl.rtview.cp=%RTVAPM_HOME%/wsm/lib/rtvapm_wsm_plus.jar
This line is only required for IBM JVM.
Oracle Weblogic
20107: Added MemoryUsedPercent to WLM Server cache
The metric MemoryUsedPercent which is the JVM Memory Used % that was previously
calculated has been included in the WlsJvmStats cache and history.
To update the history table use the following ALTER TABLE sentences:
DB2:
ALTER TABLE "WLS_JVMSTATS"
ADD "MemoryUsedPercent" DOUBLE;
SQL Server:
ALTER TABLE [WLS_JVMSTATS]
ADD [MemoryUsedPercent] FLOAT
MySQL:
ALTER TABLE "WLS_JVMSTATS"
ADD"MemoryUsedPercent" DOUBLE ;
SyBase:
Altering the data type of columns in a Sybase table requires enabling the “select
into” option for your database. Consult with your DB Admin on the correct
procedure for your installation.
ALTER TABLE "WLS_JVMSTATS" ADD "MemoryUsedPercent" FLOAT NULL
Oracle:
ALTER TABLE "WLS_JVMSTATS"
ADD "MemoryUsedPercent" NUMBER;
TIBCO ActiveMatrix
20022: Key metrics implemented for TIBCO AMX CI Types
Key Metrics have been added to the amxmon solution package. The following Key
Metrics are supported:
AMX-SERVICE:
Service Hits/Min
Service Response Time
AMX-SERVICENODE:
Node Hits/Min
Node Response Time
TIBCO BusinessEvents
20036: Key metrics implemented for TIBCO BusinessEvents CI Types
Key Metrics have been added to the TBEMON solution package. The following Key
Metrics are supported:
Rules Fired Rate
Received Events Rate
Concept Cache Ops Rate (where Ops means operations - get, put, remove)
Backing Store Ops Rate (where Ops means operations - load, store, erase)
20193: Cluster Summary display added with new cluster-level metrics
The Tibco Business Events solution has been updated with additional displays and
alerts relating to Cluster metrics.
1. New aggregated cluster-level metrics
A new cache TbeClusterSummary contains metrics aggregated across all nodes in the
cluster.
2. New alerts
The new alerts have names starting with "TbeCluster", and are bound to
cluster-level metrics.
3. Display Changes
The previous top-level view of the same name has been renamed "Cluster Nodes".
"Clusters" - New top-level tabular view of all currently monitored clusters.
"Cluster Summary" - New summary view of a single cluster, with current values of
aggregated metrics and trend charts for key metrics.
"Agent Event Summary" - The Events screen has two separate tables; previously,
the lower table for agent event data had no drill-down. In this release, clicking
on a row of agent event data takes you to a "BE Agent Event Summary".
20255: Performance and architectural improvements
The Tibco Business Events solution has been refactored to bring it into full
compliance with the best practices for our other solutions.
Due to the extensive nature of changes required for this change, existing history
data from older versions will not be retained. Users will have to re-create their
database tables using the updated .sql schemas under tbemon\dbconfig.
Changes to Caches
1. rename cache TbeCluster to TbeClusterNode. This change differentiates the
contents (one row for each node in the cluster) from the new TbeClusterSummary
cache, which aggregates node data to create new cluster-level metrics.
2. The column ordering in all caches now conforms with best practice (timestamp
followed by index columns).
3. Total count columns in history have been replaced by interval deltas. Delta
columns have been added to the following caches:
TbeInferenceAgent
TbeBackingStore
TbeNodeEvents
TbeAgentEvents
TbeNodeConcepts
Performance
1. The displays were optimized to minimize the amount of data sent to thin
clients, so the displays should render faster in web browsers.
New Features:
1. added alert TbeClusterMalformed that triggers when the cluster node count is
not equal to the number of neighbors sensed by a given node. This is a sign that
a node did not see cluster members and created it's own "single node cluster".
2. combo controls at top of screens that select which item to display now resize
with the window so that long object names can be fully displayed.
3. The addition of delta columns to history support the "Use Rates" checkbox on
trend charts for following summary displays:
Agent Event Summary
BE Concept Summary
BE Event Summary
"Use Rates" allows you to toggle between the display of "counts per collection
interval" and "counts per second".
20586: Dropped 2 Heap columns from cache and the extra JMX calls eliminated
Several releases ago, the Tibco BE monitor was modified to display %CPU and heap
memory metrics from rtvmgr. In order to avoid any changes to cache strucure in
either package, the TbeObjectTable cache was not updated; two columns for
collected JVM heap data were retained. In this release, BE Monitor has had a
major update of both displays and caches, so these unused columns have been
removed.
TIBCO BusinessWorks
20024: Key metrics implemented for TIBCO BW CI Types
The bwmon solution package has been enhanced to support Key Metrics. The
following Key Metrics are supported
BW-SERVER CI Type:
CPU Usage %
BW-ENGINE CI Type:
CPU Usage %
Memory Used %
BW-PROCESS CI Type:
Process Exec Time / sec
20113: New BwProcessElapsedTImeHigh alert
A new alert has been added: BwProcessElapsedTimeHigh.
This is driven by the metric RateTotalElapsed in the BwProcesses table.
20143: Improved resize behavior of top-level common selectors
The resize behavior of the Activity displays has been improved so there will be
more room to show the Process and Activity names as the display is resized.
20218: Accuracy of BW Process columns improved
The data types of Active and DeltaCreated columns in the BW_PROCESSES table have
been converted to real numbers to account for the loss of resolution when
compaction is taking place by averaging the metrics.
As part of upgrading you must use alter table SQL like provided below for your
supported DB platform (Oracle not required).
DB2:
ALTER TABLE "BW_PROCESSES"
ALTER COLUMN "Active" SET DATA TYPE DOUBLE;
ALTER TABLE "BW_PROCESSES"
ALTER COLUMN "DeltaCreated" SET DATA TYPE DOUBLE;
ALTER TABLE "BW_PROCESS_TOTALS"
ALTER COLUMN "Active" SET DATA TYPE DOUBLE;
SQL Server:
ALTER TABLE [BW_PROCESSES]
ALTER COLUMN [Active] FLOAT
ALTER TABLE [BW_PROCESSES]
ALTER COLUMN [DeltaCreated] FLOAT
ALTER TABLE [BW_PROCESS_TOTALS]
ALTER COLUMN [Active] FLOAT
MySQL:
ALTER TABLE "BW_PROCESSES"
MODIFY "Active" DOUBLE ,
MODIFY "DeltaCreated" DOUBLE ;
ALTER TABLE "BW_PROCESS_TOTALS"
MODIFY "Active" DOUBLE ;
SyBase:
Altering the data type of columns in a Sybase table requires enabling the “select
into” option for your database. Consult with your DB Admin on the correct
procedure for your installation.
ALTER TABLE "BW_PROCESSES" MODIFY "Active" FLOAT
ALTER TABLE "BW_PROCESSES" MODIFY "DeltaCreated" FLOAT
ALTER TABLE "BW_PROCESS_TOTALS" MODIFY "Active" FLOAT
TIBCO EMS
18002: Consumer and producer counts now exclude expired entries
The producer and consumer count from the Single Server Summary display now only
take into account non-expired indexes.
19497: Drop-down lists adjusted to accomodate for longer values
The drop-down lists have been enhanced to accomodate for longer Server, Queue,
and Topic names.
19962: Collection of consumers, producers, and connections can now be disabled
The collection of consumers, producers, and connections has been reorganized to
allow disabling their collection independently. If you would like to collect
metrics for these elements, you should copy the following lines from the
sample.properties file in the EMSMON project directory and make appropriate
changes in your properties file:
# To disable consumers collection, comment out this line:
sl.rtview.cache.config=ems_consumers_cache_source.rtv
# To disable producers collection, comment out this line:
sl.rtview.cache.config=ems_producers_cache_source.rtv
# To disable connections collection, comment out this line:
sl.rtview.cache.config=ems_connections_cache_source.rtv
Please note that if these lines are not included in any of your properties files,
you would not gather any metric for consumers, producers, and connections.
20026: Key metrics implemented for TIBCO EMS CI Types
Key Metrics have been added to EMSMON CI Types.
EMS-SERVER:
Pending Msgs
In Msgs / sec
Out Msgs / sec
EMS-QUEUE:
Pending Msgs
In Msgs / sec
Out Msgs / sec
EMS-TOPIC:
Pending Msgs
In Msgs / sec
Out Msgs / sec
20058: Convert PendingMessageCount and PendingMessageSize to DOUBLE
The types of several rate metrics have been converted to real numbers to account
for the loss of resolution when compaction is taking place by averaging the
metrics.
Follow the appropriate alter table SQL syntax to apply the change to your
supported DB platforms (Oracle not needed).
DB2:
ALTER TABLE "EMS_CONSUMERS"
ALTER COLUMN "consumerByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_CONSUMERS"
ALTER COLUMN "consumerMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_DURABLES"
ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_DURABLES"
ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_PRODUCERS"
ALTER COLUMN "producerByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_PRODUCERS"
ALTER COLUMN "producerMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUETOTALS"
ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUETOTALS"
ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUETOTALS"
ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUETOTALS"
ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUETOTALS"
ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUETOTALS"
ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUES"
ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUES"
ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUES"
ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUES"
ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUES"
ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_QUEUES"
ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_ROUTES"
ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_ROUTES"
ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_ROUTES"
ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_ROUTES"
ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_SERVERINFO"
ALTER COLUMN "inboundBytesRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_SERVERINFO"
ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_SERVERINFO"
ALTER COLUMN "outboundBytesRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_SERVERINFO"
ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_SERVERINFO"
ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_SERVERINFO"
ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICTOTALS"
ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICTOTALS"
ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICTOTALS"
ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICTOTALS"
ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICTOTALS"
ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICTOTALS"
ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICS"
ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICS"
ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICS"
ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICS"
ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICS"
ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE;
ALTER TABLE "EMS_TOPICS"
ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE;
SQL Server:
ALTER TABLE [EMS_CONSUMERS]
ALTER COLUMN [consumerByteRate] FLOAT
ALTER TABLE [EMS_CONSUMERS]
ALTER COLUMN [consumerMessageRate] FLOAT
ALTER TABLE [EMS_DURABLES]
ALTER COLUMN [pendingMessageCount] FLOAT
ALTER TABLE [EMS_DURABLES]
ALTER COLUMN [pendingMessageSize] FLOAT
ALTER TABLE [EMS_PRODUCERS]
ALTER COLUMN [producerByteRate] FLOAT
ALTER TABLE [EMS_PRODUCERS]
ALTER COLUMN [producerMessageRate] FLOAT
ALTER TABLE [EMS_QUEUETOTALS]
ALTER COLUMN [inboundByteRate] FLOAT
ALTER TABLE [EMS_QUEUETOTALS]
ALTER COLUMN [inboundMessageRate] FLOAT
ALTER TABLE [EMS_QUEUETOTALS]
ALTER COLUMN [outboundByteRate] FLOAT
ALTER TABLE [EMS_QUEUETOTALS]
ALTER COLUMN [outboundMessageRate] FLOAT
ALTER TABLE [EMS_QUEUETOTALS]
ALTER COLUMN [pendingMessageCount] FLOAT
ALTER TABLE [EMS_QUEUETOTALS]
ALTER COLUMN [pendingMessageSize] FLOAT
ALTER TABLE [EMS_QUEUES]
ALTER COLUMN [inboundByteRate] FLOAT
ALTER TABLE [EMS_QUEUES]
ALTER COLUMN [inboundMessageRate] FLOAT
ALTER TABLE [EMS_QUEUES]
ALTER COLUMN [outboundByteRate] FLOAT
ALTER TABLE [EMS_QUEUES]
ALTER COLUMN [outboundMessageRate] FLOAT
ALTER TABLE [EMS_QUEUES]
ALTER COLUMN [pendingMessageCount] FLOAT
ALTER TABLE [EMS_QUEUES]
ALTER COLUMN [pendingMessageSize] FLOAT
ALTER TABLE [EMS_ROUTES]
ALTER COLUMN [outboundByteRate] FLOAT
ALTER TABLE [EMS_ROUTES]
ALTER COLUMN [outboundMessageRate] FLOAT
ALTER TABLE [EMS_ROUTES]
ALTER COLUMN [inboundByteRate] FLOAT
ALTER TABLE [EMS_ROUTES]
ALTER COLUMN [inboundMessageRate] FLOAT
ALTER TABLE [EMS_SERVERINFO]
ALTER COLUMN [inboundBytesRate] FLOAT
ALTER TABLE [EMS_SERVERINFO]
ALTER COLUMN [inboundMessageRate] FLOAT
ALTER TABLE [EMS_SERVERINFO]
ALTER COLUMN [outboundBytesRate] FLOAT
ALTER TABLE [EMS_SERVERINFO]
ALTER COLUMN [outboundMessageRate] FLOAT
ALTER TABLE [EMS_SERVERINFO]
ALTER COLUMN [pendingMessageCount] FLOAT
ALTER TABLE [EMS_SERVERINFO]
ALTER COLUMN [pendingMessageSize] FLOAT
ALTER TABLE [EMS_TOPICTOTALS]
ALTER COLUMN [inboundByteRate] FLOAT
ALTER TABLE [EMS_TOPICTOTALS]
ALTER COLUMN [inboundMessageRate] FLOAT
ALTER TABLE [EMS_TOPICTOTALS]
ALTER COLUMN [outboundByteRate] FLOAT
ALTER TABLE [EMS_TOPICTOTALS]
ALTER COLUMN [outboundMessageRate] FLOAT
ALTER TABLE [EMS_TOPICTOTALS]
ALTER COLUMN [pendingMessageCount] FLOAT
ALTER TABLE [EMS_TOPICTOTALS]
ALTER COLUMN [pendingMessageSize] FLOAT
ALTER TABLE [EMS_TOPICS]
ALTER COLUMN [inboundByteRate] FLOAT
ALTER TABLE [EMS_TOPICS]
ALTER COLUMN [inboundMessageRate] FLOAT
ALTER TABLE [EMS_TOPICS]
ALTER COLUMN [outboundByteRate] FLOAT
ALTER TABLE [EMS_TOPICS]
ALTER COLUMN [outboundMessageRate] FLOAT
ALTER TABLE [EMS_TOPICS]
ALTER COLUMN [pendingMessageCount] FLOAT
ALTER TABLE [EMS_TOPICS]
ALTER COLUMN [pendingMessageSize] FLOAT
MySQL:
ALTER TABLE "EMS_CONSUMERS"
MODIFY "consumerByteRate" DOUBLE ,
MODIFY "consumerMessageRate" DOUBLE ;
ALTER TABLE "EMS_DURABLES"
MODIFY "pendingMessageCount" DOUBLE ,
MODIFY "pendingMessageSize" DOUBLE ;
ALTER TABLE "EMS_PRODUCERS"
MODIFY "producerByteRate" DOUBLE ,
MODIFY "producerMessageRate" DOUBLE ;
ALTER TABLE "EMS_QUEUETOTALS"
MODIFY "inboundByteRate" DOUBLE ,
MODIFY "inboundMessageRate" DOUBLE ,
MODIFY "outboundByteRate" DOUBLE ,
MODIFY "outboundMessageRate" DOUBLE ,
MODIFY "pendingMessageCount" DOUBLE ,
MODIFY "pendingMessageSize" DOUBLE ;
ALTER TABLE "EMS_QUEUES"
MODIFY "inboundByteRate" DOUBLE ,
MODIFY "inboundMessageRate" DOUBLE ,
MODIFY "outboundByteRate" DOUBLE ,
MODIFY "outboundMessageRate" DOUBLE ,
MODIFY "pendingMessageCount" DOUBLE ,
MODIFY "pendingMessageSize" DOUBLE ;
ALTER TABLE "EMS_ROUTES"
MODIFY "outboundByteRate" DOUBLE ,
MODIFY "outboundMessageRate" DOUBLE ,
MODIFY "inboundByteRate" DOUBLE ,
MODIFY "inboundMessageRate" DOUBLE ;
ALTER TABLE "EMS_SERVERINFO"
MODIFY "inboundBytesRate" DOUBLE ,
MODIFY "inboundMessageRate" DOUBLE ,
MODIFY "outboundBytesRate" DOUBLE ,
MODIFY "outboundMessageRate" DOUBLE ,
MODIFY "pendingMessageCount" DOUBLE ,
MODIFY "pendingMessageSize" DOUBLE;
ALTER TABLE "EMS_TOPICTOTALS"
MODIFY "inboundByteRate" DOUBLE ,
MODIFY "inboundMessageRate" DOUBLE ,
MODIFY "outboundByteRate" DOUBLE ,
MODIFY "outboundMessageRate" DOUBLE ,
MODIFY "pendingMessageCount" DOUBLE ,
MODIFY "pendingMessageSize" DOUBLE ;
ALTER TABLE "EMS_TOPICS"
MODIFY "inboundByteRate" DOUBLE ,
MODIFY "inboundMessageRate" DOUBLE ,
MODIFY "outboundByteRate" DOUBLE ,
MODIFY "outboundMessageRate" DOUBLE ,
MODIFY "pendingMessageCount" DOUBLE ,
MODIFY "pendingMessageSize" DOUBLE ;
SyBase:
Altering the data type of columns in a Sybase table requires enabling the “select
into” option for your database. Consult with your DB Admin on the correct
procedure for your installation.
ALTER TABLE "EMS_CONSUMERS" MODIFY "consumerByteRate" FLOAT
ALTER TABLE "EMS_CONSUMERS" MODIFY "consumerMessageRate" FLOAT
ALTER TABLE "EMS_DURABLES" MODIFY "pendingMessageCount" FLOAT
ALTER TABLE "EMS_DURABLES" MODIFY "pendingMessageSize" FLOAT
ALTER TABLE "EMS_PRODUCERS" MODIFY "producerByteRate" FLOAT
ALTER TABLE "EMS_PRODUCERS" MODIFY "producerMessageRate" FLOAT
ALTER TABLE "EMS_QUEUETOTALS" MODIFY "inboundByteRate" FLOAT
ALTER TABLE "EMS_QUEUETOTALS" MODIFY "inboundMessageRate" FLOAT
ALTER TABLE "EMS_QUEUETOTALS" MODIFY "outboundByteRate" FLOAT
ALTER TABLE "EMS_QUEUETOTALS" MODIFY "outboundMessageRate" FLOAT
ALTER TABLE "EMS_QUEUETOTALS" MODIFY "pendingMessageCount" FLOAT
ALTER TABLE "EMS_QUEUETOTALS" MODIFY "pendingMessageSize" FLOAT
ALTER TABLE "EMS_QUEUES" MODIFY "inboundByteRate" FLOAT
ALTER TABLE "EMS_QUEUES" MODIFY "inboundMessageRate" FLOAT
ALTER TABLE "EMS_QUEUES" MODIFY "outboundByteRate" FLOAT
ALTER TABLE "EMS_QUEUES" MODIFY "outboundMessageRate" FLOAT
ALTER TABLE "EMS_QUEUES" MODIFY "pendingMessageCount" FLOAT
ALTER TABLE "EMS_QUEUES" MODIFY "pendingMessageSize" FLOAT
ALTER TABLE "EMS_ROUTES" MODIFY "outboundByteRate" FLOAT
ALTER TABLE "EMS_ROUTES" MODIFY "outboundMessageRate" FLOAT
ALTER TABLE "EMS_ROUTES" MODIFY "inboundByteRate" FLOAT
ALTER TABLE "EMS_ROUTES" MODIFY "inboundMessageRate" FLOAT
ALTER TABLE "EMS_SERVERINFO" MODIFY "inboundBytesRate" FLOAT
ALTER TABLE "EMS_SERVERINFO" MODIFY "inboundMessageRate" FLOAT
ALTER TABLE "EMS_SERVERINFO" MODIFY "outboundBytesRate" FLOAT
ALTER TABLE "EMS_SERVERINFO" MODIFY "outboundMessageRate" FLOAT
ALTER TABLE "EMS_SERVERINFO" MODIFY "pendingMessageCount" FLOAT
ALTER TABLE "EMS_SERVERINFO" MODIFY "pendingMessageSize" FLOAT
ALTER TABLE "EMS_TOPICTOTALS" MODIFY "inboundByteRate" FLOAT
ALTER TABLE "EMS_TOPICTOTALS" MODIFY "inboundMessageRate" FLOAT
ALTER TABLE "EMS_TOPICTOTALS" MODIFY "outboundByteRate" FLOAT
ALTER TABLE "EMS_TOPICTOTALS" MODIFY "outboundMessageRate" FLOAT
ALTER TABLE "EMS_TOPICTOTALS" MODIFY "pendingMessageCount" FLOAT
ALTER TABLE "EMS_TOPICTOTALS" MODIFY "pendingMessageSize" FLOAT
ALTER TABLE "EMS_TOPICS" MODIFY "inboundByteRate" FLOAT
ALTER TABLE "EMS_TOPICS" MODIFY "inboundMessageRate" FLOAT
ALTER TABLE "EMS_TOPICS" MODIFY "outboundByteRate" FLOAT
ALTER TABLE "EMS_TOPICS" MODIFY "outboundMessageRate" FLOAT
ALTER TABLE "EMS_TOPICS" MODIFY "pendingMessageCount" FLOAT
ALTER TABLE "EMS_TOPICS" MODIFY "pendingMessageSize" FLOAT
20272: New flag to enable topic/queue browsing
A new flag to enable the Browse button for browsing messages on queues and topics
has been added. By default browsing is disabled.
Once this flag is enabled, a button for browsing queues will be visible on the
Single Queue Summary page
To enable this flag, add the following property to a properties file in use by
your servers:
sl.rtview.sub=$emsDestBrowseButtonVisFlag:1
For users of standalone BW Monitor, we recommend adding it to sample.properties.
Users of RTView EM should add it to servers\central\central.properties (or their
own custom properties file loaded by central servers).
20539: Drill down to Topics Summary from All Topics Heatmap fixed
A bug that prevented correct drilling down from All Topics Heatmap to the Topic
Summary has been fixed.
TIBCO Hawk
20200: Sorting, navigation, and appearance improvements to Hawk Agent Table
Several defects have been corrected for the Hawk Agents Table.
1. The table now shows rows sorted by "Domain" and "Host Name" in ascending
order. Clicking on a column name will resort the table by that column.
2. An Expired column has been added to the table to indicate stale data, and the
row background is shaded by the standard "Expired" color.
3. Row background is also shaded in a slightly different color for rows for which
drill-down is not available (ie, the host solution package is not configured to
collect from the given agent). The display does not change when such a row is
clicked. Clicking on an unshaded row leads to the corresponding "Host Summary"
screen.
Note: for drill-down to work correctly, the configured hawk console connection
name must be the same as the hawk domain name, as shown in the following example
(slwin).
sl.rtview.hawk.hawkconsole slwin rvd slwin 7474 ; tcp:7474
20201: Standardized Time column in Hawk Alert Table
The time format for Hawk alerts displayed in "Tibco Hawk Monitor" / "Hawk Alerts
Table" has been changed to match the time formats used elsewhere in RTView EM:
"dd-MMM-yyyy HH:mm:ss".
VMWare vSphere
19382: VM's now retain history when changing hosts
This release of vmwmon provides a new indexing scheme which is independent of the
index values assigned by the vSphere server. The previous vmwmon relied on
vSphere indexes, which changed when a virtual machine was moved to a different
host. This index change caused EM to think that the old VM had simply been turned
off, and a new VM created. There was no linkage between the old and new VMs, and
so the new VM could not access the history saved for the old VM.
Using the new indexing scheme, VMs can migrate to new hosts and history is
preserved (a short outage will be observed in the trend charts for the period
required to stop, move, and restart the VM).
Due to the extensive nature of changes required for this change and for task
20160 (vSphere 5.5 support), existing history data from older versions will not
be retained. Users will have to re-create their database tables using the updated
.sql schemas under vmwmon\dbconfig.
20160: Support for vSphere SDK 5.5
The RTView datasource for vmwmon has been updated to use vSphere 5.5 SDK
(necessary because previous datasource used vSphere 4.1 SDK which is end of life
and unsupported).
The older 4.1 API will not work with this new data source. Configuration is now
much simpler, as the Apache Axis jars are no longer required. Java 1.6 is
required. Download the 5.5 SDK from the following URL, extract the vim25.jar, and
add to the classpath in your property file. (See sample.properties in the vmwmon
project\samples folder for an example.)
https://communities.vmware.com/community/vmtn/developer/forums/java_toolkit
20203: New metrics and a new display added
The VMWMON solution package has been updated with the following changes:
1. new cache (VmwVmDiskUsage) with disk utilization metrics for each VM. A
tabular display has been added to view disk utilization, and a new alert for high
disk utilization was added.
2. new host metrics (host physical memory size, num CPU threads/cores, num
packets Rx/Tx and packet errors, % packet drops/errors and alerts )
3. new guest metrics (guest configured memory size, guest OS name, VM tools
status, num CPUs, num packets Rx/Tx , % packet drops and alerts ).
4. mem.consumed.average was changed to mem.active.average, as this VM metric
better describes actual memory usage by the running guest OS. See
https://vdc-download.vmware.com/vmwb-repository/dcr-public/2d445149-7707-4c7d-98a7-9f00394b7df2/7322d611-ef3b-454a-ab63-ad3302d8b218/SDK/vsphere-ws/docs/ReferenceGuide/index.html
for more details.
Note: with the cumulative changes to VMWare vSphere monitor for this release,
this is effectively a new solution package, and the history schema and CMDB
definitions are incompatible with previous versions. Customers are advised to
delete previous history and CMDB references from their databases.
Version 1.5.3 Release Notes
Monitor
19865: New display for History table monitoring
A new display to monitor the History tables has been added. Go to Architecture ->
Data Server Summary and click on the History Tables button. A new display with
all information about the existing tables for each cache in the selected Data
Server will appear.
RTVMGR
19956: New Tomcat alerts for access rates of server and apps
Two new alerts for Tomcat have been added: TomcatAccessRateHigh and
TomcatAppAccessRateHigh. The former alerts when the Access Rate of a Tomcat
Server reaches its maximum and the latter alerts when a given application
deployed on a Tomcat Server reaches its maximum.
19958: MemoryUsedPercent added to history cache for Operating System
A new metric, MemoryUsedPercent, has been included in the history of the
JvmMemory cache. This addition impacts the previous sql schema provided in the
product.
To update previous schema, execute the following sentence in your DB admin tool:
For DB2 and MySQL:
ALTER TABLE "JVM_MEMORY"
ADD "MemoryUsedPercent" DOUBLE;
For Oracle:
ALTER TABLE "JVM_MEMORY"
ADD "MemoryUsedPercent" REAL;
For SQL Server:
ALTER TABLE [JVM_MEMORY]
ADD [MemoryUsedPercent] FLOAT;
For SyBase:
ALTER TABLE "JVM_MEMORY"
ADD "MemoryUsedPercent" FLOAT NULL;
19999: New alert for high memory usage after GC
A new alert, JvmMemoryUsedAfterGCHigh, has been added to RTVMGR. This alerts is
activated when the percentage of the minimum memory used relative to the maximum
memory used after GC reaches the threshold.
RTView Core Functionality
Data Historian
19987: Compaction now recovers after a lost database connection is restored
Compaction now recovers correctly after a lost database connection is restored.
Data Sources
19960: Fixed bogus extend-by-SQL query if history has future timestamps
A bug in the cache data source has been fixed that triggered an unnecessary SQL
query if an attachment to a cache history table had the Extend with SQL option
checked, and the history table contained timestamps in the future as compared to
the current time on the system hosting the cache data source.
20072: Fixed concurrency exception when updating sql RTViewDs.Connections table
A bug has been fixed in the sql data source which, in rare cases, caused a
ConcurrentModificationException to be thrown if a display was open with a data
attachment to the sql RTViewDs.connections table.
Object Library
20002: Right/Double-click features supported for status history chart
The status history chart (obj_statushistory) can now be configured to extend the
right-click context menu and support double-click behavior, in the same manner as
the heatmap, table, and grid objects. To support this feature properties named
menuItemGroup and rightClickActionFlag have been added to the chart. See 17835
for more information on using these properties to extend the context menu and
control the double-click behavior.
Solution Package
Amazon CloudWatch
19501: CPU % no longer incorrectly is shown as >100%
In previous versions the CPU % sometimes showed a value greater than 100 %. This
has been fixed.
Host Infrastructure
19955: The HostStats cache no longer misses asynchronous updates from sender
An advanced feature of RTView EM is the ability of remote data servers to serve
as collectors and forward their data to a central server for aggregation (the
alternative is for the central displayserver to simply refer the client to the
remote dataserver to display the data directly). An example of how one or more
remote collectors are started is as follows:
rundata -properties:my.properties -propfilter:sender
The aggregating dataserver is started as follows:
rundata -propfilter:receiver
This release corrects two problems in the sender/receiver architecture.
1. several columns were not updated in the receiver's cache.
2. occasionally, an entire row in the receiver's cache might not be updated.
Oracle Weblogic
20000: New alert for high number of threads waiting for JDBC connections
A new alert, WlsJDBCConnectionsWaitingHigh, has been implemented that will be
triggered when the number of threads waiting for a JDBC connection has reached
the threshold.
TIBCO ActiveMatrix
19881: Updates to history table columns
The SQL schemas have been updated with two changes.
1) In the previous version, the table definition for AMX_BW_PROCESS_TOTALS was
incorrect - it was missing an initial index column "MicroAgentName". This
omission has been fixed.
Users affected by this bug will need to delete and re-create the
AMX_BW_PROCESS_TOTALS table according to the new definition under
rtvapm\amxmon\dbconfig
2) The data type for "Hits Per Interval" and "Faults Per Interval" columns in the
table AMX_SERVICE_TOTALS changed from integer to double/float. This is in support
of the change for 20012 in 1.5.2.
Users with existing tables should consult with their DBA on the correct "alter
table" syntax for their database
DB2 Example:
ALTER TABLE "AMX_SERVICE_TOTALS" ALTER "Hits Per Interval" SET DATA TYPE DOUBLE;
ALTER TABLE "AMX_SERVICE_TOTALS" ALTER "Faults Per Interval" SET DATA TYPE
DOUBLE;
20012: Hits and Faults per interval calculation now more sensitive
When the incoming hits per minute reported by AMX is small, the Total Hits
counter displayed in the "All Services" and "All Service Nodes" tables was zero.
This was due to inappropriate integer math in the calculation, which has been
corrected in this release. The following supplementary explanation describes how
Total Hits is calculated, and limitations in the approach.
Total hits is not directly provided by Tibco; rather, it is derived from the
average hits per minute that we get from AMX internal stats. Tibco documentation
is not available for how this average is computed, but we can be certain that the
total hits we display are approximately correct but can be delayed by up to half
the averaging interval. For example, say Tibco gives us a metric value of .2 hits
per minute. Obviously, we did not receive .2 hits in the preceding minute; an
averaging period of perhaps several minutes is implied.. If the averaging
interval is 5 minutes, then we can say that 1 hit was received in some 5 minute
interval. But, EM provides metrics by polling interval, so with a 30 second
interval, we add .1 hits/interval to our accumulator for the next 10 intervals
and finally display an integer hit count incremented by 1 (with no rounding).
This works regardless of whether Tibco uses fixed periods like 0-5, 6-10, etc, or
a rolling average. Hence, the rounded total hits values displayed in EM have a
lag of up at least half the averaging period. That is, it could be 2.5 minutes if
their averaging period is 5 minutes before we see the hit count increment. Hence,
the hit count is most useful as an activity indicator, rather than an absolute
readout of real-time activity.
TIBCO ActiveSpaces
19983: Active Spaces added to the Services By CI Type grid display
The Active Spaces CI has been added to the XML file that drives the Services By
CI Type grid display.
TIBCO BusinessEvents
19998: Enhanced sample.properties
A new sample.properties file has been provided that describes the connection
properties necessary to monitor each BusinessEvents engine in a cluster.
Additional detail can be found in the documentation for TIBCO RTView for TIBCO
BusinessEvents.
VMWare vSphere
19953: New VmwHostMemoryUsageHigh alert
An alert for memory usage by a VMWare virtual machine (VmwHostMemoryUsageHigh)
was referenced in a configuration file but not implemented. An implementation for
the alert has been added.
Version 1.5.2 Release Notes
Monitor
19976: HTML5 labels and trend charts enabled as EM defaults
In EM, the default settings for the display server now set the webChartFlag
property to true on all obj_fxtrend objects and set the webLabelFlag to true on
all of the label objects that support that property.
For more information on webChartFlag, see the release note for 19454.
For more information on webLabelFlag, see the release note for 19861.
RTView Core Functionality
Builder - Editing
19879: Fixed NPE when deleting local var with same name as global
A bug has been fixed in the Builder which caused a NullPointerException to be
thrown if a local variable was deleted and the local variable had the same name
as a global variable.
Data Historian
19469: Avoid removal of all batch data when some data is wrong.
The historian will no longer discard all rows in a batch if a SQL exception is
thrown during an row insert. Instead it will catch the exception and continue
with the other row inserts in the batch and commit all of the successful inserts
at the end of the batch.
19786: smoothCompaction no longer throws NPE when there are no compaction rules
Previously a NPE was thrown when -smoothcompaction was used with a cache with a
compaction type of "aggregate" but with no compaction rules.
Now this scenario fails silently.
19915: Simple retention now applied only to tables without compaction rules
If a cache history table that was persisted by the historian had no compaction
rules, then the simple retention time limit was applied to ALL tables persisted
by the historian. This was incorrect. The simple retention limit will now only be
applied to tables without compaction rules.
Data Sources
19977: New onData Length column
The TIBCO Hawk data source has been enhanced to include a new onData Length
column in the RTViewDs GetSubscriptionStatus method. This column contains the
amount of time, in milliseconds, that the last onData call took to process the
subscription data.
Display Server
19880: Fixed unstable dropdown list in FF & Chrome
In prior versions of the thin client, on each display refresh the dropdown list
of the combo box control would scroll and the highlighted list item would change,
even if the refresh did not change the items in the list. This behavior could
make it difficult to use the dropdown list. This problem has been fixed.
Note that this problem affected the thin client in Firefox and Chrome, but not
Internet Explorer.
General
19933: rtvquery default time range for current table changed from 30s to ALL
The rtvquery servlet will no longer apply a default time range of 30 seconds to
queries on the current table of a cache. Instead, it will apply a default time
range of zero, which will return all rows from the current table regardless of
their timestamp.
A default of 30 seconds will still be applied to all queries on cache history
tables.
Note that the time range, in seconds, can be specified with the tr parameter in
the URL. For example, this query will return the last 10 minutes of history data
from a cache named Servers:
http://host:port/rtvquery/cache/Servers/history?tr=600
Object Library
19861: Support HTML label object in the thin client
A number of simple RTView graphical objects have been enhanced to allow them to
be rendered as HTML elements in a thin client deployment, rather than rendered in
the image generated by the Display Server. This enhancement can improve system
performance in some cases and also allows the user to copy text strings in the
objects to the clipboard. Most of the objects affected by this enhancement are
found on the General tab and Labels tab in the Builder's object palette. The
enhanced objects are:
obj_rect
obj_rect_il
obj_rect_ilv
obj_rect_ilvs
obj_rect_ilvx_da3
obj_rect_ilvx_ra4
obj_circ2d
obj_circ2d_il
obj_circ2d_ilv
obj_circ2d_ilvs
obj_circ2d_ilvx_da3
obj_circ2d_ilvx_ra4
obj_label05
obj_label05s
obj_label11
obj_label11s
obj_text01
obj_c1btn_chk
These objects now support a new a new property named webLabelFlag. In a display
server deployment, if webLabelFlag is true (checked) then the object will be
rendered as HTML in the thin client, rather than rendered in the image by the
display server. This allows the display server to update the individual object,
if necessary, when the display is refreshed, rather than regenerating the entire
display image.
If all of the dynamic objects on a display can be rendered as HTML, this can
improve the performance of the display server and thin client. The list of
objects that can be rendered as HTML now includes all the objects listed above,
all objects on the Controls tab in the object palette (obj_c1*), the table object
(obj_table02), and the trend chart (obj_fxtrend). Another advantage of setting
webLabelFlag on an object is that it allows the user to select the object's text
and copy it to the clipboard.
By default webLabelFlag is false (unchecked). The webLabelFlag property is listed
in the "Label" category in the Builder's property sheet. The webLabelFlag can be
set on all of the objects listed above via the following entry in an rtview
stylesheet (.rts) file:
rtv-all {
webLabelFlag: 1;
}
In certain cases, an object included in the list above will still be rendered in
the image by the display server even if webLabelFlag = true. These cases are:
- the display is opened in Internet Explorer 8 or older.
- the display server is run with the -nohtml5 option on the command-line.
- an obj_text01 instance with rotated text (a nonzero value for rotationAngle).
- an obj_rect* with labelTextPosY = Tab Top
- an obj_rect* with labelTextPosY= Title Top and bgBorderFlag = true
- an obj_label* with bgStyle = Round Rectangle
- the object is inside an object grid, and is not inside a composite object in
that grid
- the object is an obj_rect* and there is a non-html object above it in Z-order
which overlaps (for example, an obj_rect instance used as a background behind
several meter objects)
In other cases, an object may have a slightly different appearance in the thin
client when it is rendered as HTML, as follows:
- only vertical and horizontal gradients are supported on HTML objects in the
thin client, so if an object has its bgGradientMode property set to "Diagonal
Edge" or "Diagonal Center" it is treated as "Vertical Edge" instead.
- the object's bgShadowFlag property is ignored
Note that the webLabelFlag property has no effect in the builder or viewer (thick
client).
19934: New property to limit size of label area
The status history object (obj_statushistory) supports a new property named
barLabelMaxLengthPct. This can be used to specify the maximum length for each bar
label as a percentage of the plot area width. The default is zero which means no
limit is applied to the label length.
If a positive value is specified for both the barLabelMaxLength and
barLabelMaxLengthPct properties, then the smaller length limit of the two will be
used.
19935: Newlines now supported in mouseover
The status history chart (obj_statushistory) will now properly convert a
backslash-n sequence into a newline when displaying the mouseover (tooltip)
string. This string is acquired from the column specified by the chart's
descriptionColumnName property.
19938: HTML5 obj_trendgraph02 no longer ignores data table with 1 column
A problem in the display server has been fixed which prevented an
obj_trendgraph02 instance with webChartFlag = 1 from plotting any data points on
trace N if traceNValue was attached to a table containing a single numeric
column.
Reporting
19939: obj_trendgraph02 using HTML 5 can now be exported to PDF
A problem has been fixed which prevented an obj_trendgraph02 instance with
webChartFlag = 1 from being included in the output of the thin client's "Export
to PDF" option.
Solution Package
19893: Removal of empty references
References to empty files containing global variables have been removed.
Amazon CloudWatch
19712: SQL schemas updated to conform to explicit structure of cache
Previous to 1.5.1, the structure of the acwmon caches was not explicitely
defined, but was instead dependent on the structure returned by Amazon. This
could cause storage and read of historical data to be unreliable.
The cache structure has now been explicitly defined, and as a consequence, the
database schemas under acwmon\dbconfig have been adjusted to reflect this
definitive column order.
IBM Websphere MQ
19888: Added mqmon to sample EM probject
A server directory for the mqmon solution package has been added to the RTView EM
sample project
Oracle Weblogic
19892: AllProcessorAverageLoad no longer reporting incorrect data
A bug that caused AllProcessorsAverageLoad to report incorrect values has been
fixed.
TIBCO ActiveMatrix
19836: Look and feel improvements made to trend graphs
The trend graphs in the AMX Service and Service Node Summary pages and on the BW
Process Summary page have had their trace colors improved for readability with
light styles.
TIBCO EMS
19941: Updated description of EmsConsumerStalled alert
The description of the EmsConsumerStalled alert has been improved to include
include the units of the alert.
UX Monitor
19803: UXMon robot now works with a buttonInputElementType of ID
Previously the UXMon robot would throw an NullPointerException with a
buttonInputElementType of ID. This has been fixed.
19804: UXMon robot now supports encrypted passwords in URLs
The UX Robot now supports encrypted passwords in URLs.
Version 1.5.1 Release Notes
Customization
19790: Improvements to custom example
The sample project for the creation of Custom Solution Packages has been updated
to use the startup scripts. Its properties files have been simplified and a
sample.properties file with custom configuration properties has been included.
Deployment
19788: WSM added to projects/emsample/servers
WSM directory has been added to emsample. This inclusion will allow monitoring of
WebSphere deployments under EM.
RTView Core Functionality
18643: japanese chars no longer garbled by "Send Email" command
The email command will now properly encode Japanese and other Asian characters
contained in the text of the email. In prior release, such characters were
garbled.
19813: Fixed javascript error thrown by obj_datechooser in IE
A bug in the thin client has been fixed which caused an "unterminated string
constant" error message to appear in Internet Explorer's javascript console when
the date chooser control was clicked.
Splunk
19379: Splunk data adapter updated
The Splunk data adapter has been updated to make it compatible with recent
versions of Splunk (6.0+).
The Splunk data adapter uses the recent splunk java SDK so is compatible with
compatible with recent versions of Splunk (6.0+). This version of the SDK
requires java SE version 6 or higher (for both the splunk server and the data
adapter client).
If you are using Windows, make sure the JAVA_HOME system variable is set to the
directory where the JDK is installed. The required jars are included in the
delivery and added to the classpath by the GmsLauncher; The user does not need to
use RTV_USERPATH as in previous versions.
Splunk Connections are now defined using explicit Host and Port values rather
than a single URL as previously.
The Splunk options now contains a search job wait time field (in ms). This is
used to control the wait time when polling for search job completion; the user
will typically not need to modify this value.
The Attach To Splunk Data dialog has some new fields compared with previous
versions.
The new fields are as follows.
Earliest Time: Filters the (splunk search) returned objects by their timestamp.
Only objects that have a timestamp that is >= earliest_time will be returned.
The time format is always ISO-8601 formatted. Ex:2008-01-29T11:40:58-0800. If
omitted, then no earliest time bound is used.
Latest Time: Filters the (splunk search) returned objects by their timestamp.
Only objects that have a timestamp that is < latest_time will be returned.
The time format is always ISO-8601 formatted. Ex:2008-01-29T11:40:58-0800. If
omitted, then no latest time bound is used.
Example Times are
2014-06-05T00:00:00-0800
2014-06-06T00:00:00-0800
ISO-8601 format is described on the web
http://en.wikipedia.org/wiki/ISO_8601
http://www.iso.org/iso/home/standards/iso8601.htm
http://www.w3.org/TR/NOTE-datetime
Offset: The starting offset (0-based) of the first object to return in the
(search result) list. Can be used together with Max Results: to "cursor" through
a large result set, a small "chunk" at a time. (not the effect on the internal
"_serial" splunk data column)
Divide Data Column: When Selected, this check box makes additional fields visible
for use in dividing up data in a returned column ,by means of a Java regular
expression, into numbered columns in the returned data. Typically this is used to
extract data that has an implicit token or field based positional location in the
raw data returned by splunk. Examples of use would be to break up raw log line /
HHTP request into fields / columns.
The additional Divide Column Data fields are as follows
Divide Column Name: The name of the column to divide (split) into individual
values - typically this will be the raw data column returned from splunk "_raw"
Column Data Regexp: The Java Regular Expression (Regexp) specification used to
split the data in the named column into individual numbered columns that contain
matched occurrences of the regular expression, where the new column name is the
number of the occurrence (e.g. "1", "2", "3", etc)
The Column Data Regexp field contains a drop down with a number of predefined
regular expression literals, or you can enter your own.
Note: Normally Splunk will recognize and extract fields and make them available
for searching on, but sometimes you need to split up the raw data to extract
meaningful information.
TIBCO Hawk Data Source
19818: Hawk 5.1 support
The TIBCO Hawk data source has been enhanced to support running against Hawk 5.1.
Support for running against Hawk 5.0 has been removed. This means that the system
where you are running RTView must have the HAWK_ROOT environment variable
pointing to a Hawk 4.x or Hawk 5.1+ installation. The TIBCO Hawk data source can
still connect to agents that are running version 5.0, the limitations is only
that cannot run on a system where HAWK_ROOT is set to a Hawk 5.0 installation.
If RTView is run on a system where HAWK_ROOT is set to a Hawk 5.0 installation,
it will crash with the following exception:
Exception in thread "main" java.lang.IncompatibleClassChangeError: Found class
COM.TIBCO.hawk.console.hawkeye.AgentMonitor, but interface was expected
at com.sl.gmsjhawkds.GmsHawkConsole4x.initAgentMonitor(GmsHawkConsole4x.java:160)
at com.sl.gmsjhawkds.GmsTibConsole.initHawk(GmsTibConsole.java:513)
at com.sl.gmsjhawkds.GmsRtViewHawkDs.initHawk(GmsRtViewHawkDs.java:1192)
at com.sl.gmsjhawkds.GmsRtViewHawkDs.initializeData(GmsRtViewHawkDs.java:1296)
at
com.sl.gmsjrtview.GmsRtViewAppManager.initializeData(GmsRtViewAppManager.java:4099)
Tables
19796: Table Rows containing larger images no longer clip
A problem in the display server has been fixed which could cause the heights of
table rows containing images to be too small to display the entire image. This
problem only occurred if multiple instances of the rtvdisplay servlet were
connected to the same display server instance.
Solution Package
General
19806: Style sheet cleanup
To improve the readability, several style overrides have been fixed. These
changes have been made in AMXMON, OCMON, UXMON, SOLMON, TBEMON, and OEMCON.
IBM Websphere MQ
19699: Time gaps now displayed correctly on trends
Trend graphs in the MQ package previously showed gaps incorrectly in data; it
filled all gaps with a continuous line. Now all trend graphs show gaps when a
period with no data has been detected.
19791: Alerts no longer missing Connection index and description
A bug has been fixed that prevented many MQ alerts from being displayed properly
in RTView EM.
The CI Type MQ-CHANNEL has been added to the MQ package.
19792: Added Alert State to Broker, Channel, and Queue tables
Broker, Channel, and Queue tables have been enhanced to indicate alert severity.
A bug has been fixed in Queue Managers table where the contents of the table
disappear intermittently under certain circumstances.
Oracle Coherence
19690: Added OutgoingByteBacklog to proxy node and extend client caches
OutgoingByteBacklog has been added to history in the OcProxyServiceStats,
OcProxyServiceTotals, and the OcExtendConnections caches.
As part of this change, the column "OutgoingByteBacklog" has been added to the
history tables OCM_PROXYSERVICESTATS, OCM_PROXYSERVICETOTALS, and
OCM_EXTENDCONNECTIONS. These history tables are not enabled in a default
configuration, so not all users will already be using these tables. Users who do
have existing database tables will need to alter their table to include this
additional column. (Task 19797 also has caused changes to OCM_PROXYSERVICESTATS.
See that release note for more information.)
The new table structure (DB2 example) is:
CREATE TABLE "OCM_EXTENDCONNECTIONS" (
"TIME_STAMP" TIMESTAMP ,
"OutgoingByteBacklog" BIGINT ,
"UUID" VARCHAR(100) ,
"name" VARCHAR(100) ,
"Connection" VARCHAR(100) ,
"Location" VARCHAR(100) ,
"RemoteEndpoint" VARCHAR(100) ,
"DeltaTotalBytesReceived" BIGINT ,
"DeltaTotalBytesSent" BIGINT ,
"DeltaTotalMessagesReceived" BIGINT ,
"DeltaTotalMessagesSent" BIGINT ,
"DeltaRefreshTime" BIGINT ,
"RateTotalBytesReceived" DOUBLE ,
"RateTotalBytesSent" DOUBLE ,
"RateTotalMessagesReceived" DOUBLE ,
"RateTotalMessagesSent" DOUBLE )
IN "USERSPACE1" ;
CREATE INDEX "rtvts_ocm_extendconnections" ON "OCM_EXTENDCONNECTIONS"
("TIME_STAMP");
CREATE INDEX "rtvpk_ocm_extendconnections" ON "OCM_EXTENDCONNECTIONS"
("Connection","Location","name","UUID","RemoteEndpoint","TIME_STAMP");
CREATE TABLE "OCM_PROXYSERVICESTATS" (
"TIME_STAMP" TIMESTAMP ,
"name" VARCHAR(100) ,
"Location" VARCHAR(100) ,
"RequestPendingCount" BIGINT ,
"Connection" VARCHAR(100) ,
"ConnectionCount" INTEGER ,
"OutgoingByteBacklog" BIGINT ,
"DeltaTotalBytesSent" BIGINT ,
"DeltaTotalBytesReceived" BIGINT ,
"DeltaRefreshTime" BIGINT ,
"RateTotalBytesSent" DOUBLE ,
"RateTotalBytesReceived" DOUBLE )
IN "USERSPACE1" ;
CREATE INDEX "rtvts_ocm_proxyservicestats" ON "OCM_PROXYSERVICESTATS"
("TIME_STAMP");
CREATE INDEX "rtvpk_ocm_proxyservicestats" ON "OCM_PROXYSERVICESTATS"
("Connection","Location","name","TIME_STAMP");
CREATE TABLE "OCM_PROXYSERVICETOTALS" (
"TIME_STAMP" TIMESTAMP ,
"Connection" VARCHAR(100) ,
"name" VARCHAR(100) ,
"ConnectionCount" INTEGER ,
"DeltaTotalBytesSent" BIGINT ,
"DeltaTotalBytesReceived" BIGINT ,
"RateTotalBytesSent" DOUBLE ,
"RateTotalBytesReceived" DOUBLE ,
"DeltaTotalMessagesSent" BIGINT ,
"DeltaTotalMessagesReceived" BIGINT ,
"RateTotalMessagesSent" DOUBLE ,
"RateTotalMessagesReceived" DOUBLE ,
"RequestPendingCount" BIGINT ,
"OutgoingByteBacklog" BIGINT )
IN "USERSPACE1" ;
CREATE INDEX "rtvts_ocm_proxyservicetotals" ON "OCM_PROXYSERVICETOTALS"
("TIME_STAMP");
CREATE INDEX "rtvpk_ocm_proxyservicetotals" ON "OCM_PROXYSERVICETOTALS"
("Connection","name","TIME_STAMP");
See rtvapm/ocmon/dbconfig/*.sql for the example schema that pertains to your
database.
19797: Added the Service Name as an index to proxy/extend caches
The Proxy / Extend Overview, Proxy /Extend Connections, and Proxy /Extend Detail
displays have been enhanced to provide better drill down capabilities and
additional information about alert state of Proxy Services and Extend
Connections.
As part of this change, the column "name" has been added to the history table
OCM_PROXYSERVICESTATS as an index column. Users with existing database tables
will need to alter their table to include this additional column. (Task 19690
also has caused changes to this table. See that release note for more
information.)
The new table structure (DB2 example) is:
CREATE TABLE "OCM_PROXYSERVICESTATS" (
"TIME_STAMP" TIMESTAMP ,
"name" VARCHAR(100) ,
"Location" VARCHAR(100) ,
"RequestPendingCount" BIGINT ,
"Connection" VARCHAR(100) ,
"ConnectionCount" INTEGER ,
"OutgoingByteBacklog" BIGINT ,
"DeltaTotalBytesSent" BIGINT ,
"DeltaTotalBytesReceived" BIGINT ,
"DeltaRefreshTime" BIGINT ,
"RateTotalBytesSent" DOUBLE ,
"RateTotalBytesReceived" DOUBLE )
IN "USERSPACE1" ;
CREATE INDEX "rtvts_ocm_proxyservicestats" ON "OCM_PROXYSERVICESTATS"
("TIME_STAMP");
CREATE INDEX "rtvpk_ocm_proxyservicestats" ON "OCM_PROXYSERVICESTATS"
("Connection","Location","name","TIME_STAMP");
See rtvapm/ocmon/dbconfig/*.sql for the example schema that pertains to your
database.
19864: Enhanced visibility of Status in Summary pages
The visibility of the Status text has been enhanced in the Single Cache -> Cache
Summary and the Cache Service -> Single Service Summary displays.
Oracle Weblogic
19808: Location no longer wrong in ThreadPool, JdbcDatasource, JMSServer
A parsing bug that caused incorrect information in the ThreadPool,
JdbcDatasource, and JMSServer caches has been fixed.
Solace
19627: New Extension - Solace Solution Package
A new extension, the Solace Solution Package (SOLMON), has been added.
The Solace Appliance is an advanced messaging platform that allows customer
applications to efficiently exchange messages over dedicated "VPN"s. SL's Solace
Solution Package provides pre-configured alerts and dashboards to monitor current
status and manage history for the Solace Appliance. This Solution Package can
help operators avoid or detect many problems relating to configuration, topology,
and performance.
See the README.txt file included with the solmon package for configuration
details.
TIBCO ActiveSpaces
19842: New Extension - TIBCO Active Spaces Solution package
A new extension, the Solution Package for TIBCO ActiveSpaces (TASMON), has been
added.
TIBCO ActiveSpaces is a distributed in-memory data grid for building highly
scalable, fault-tolerant applications. The Solution Package for TIBCO
ActiveSpaces is a plug-in application to RTView Enterprise Monitor that allows
you to monitor the health and performance of TIBCO ActiveSpaces® instances and
services in real-time.
See the README.txt file included with the tasmon package for more details.
TIBCO BusinessWorks
19462: Update in the TRA microagent set to 300 seconds
The RTView plugin microagent for BW Monitor has an update setting which will
cause it to re-read the Tibco deployment files on the specified period. This
enables it to find engines that have been newly deployed or undeployed.
The default update setting is now 300 seconds (5 minutes) and may be changed by
editing the line "<arg>-update:300</arg>" in
$TIBCO_HOME/tra/domain/<name>/plugin/BWAgentPlugin.hma.
19566: CPU% utilization no longer rounded to zero if ess than 1
BWMON 6.1 was modified to use EM's hawkmon solution package to collect host and
process metrics. In the case of process CPU utilization (as displayed in BWMON's
all engines table), hawkmon used the integer CPU utilization directly from hawk,
whereas earlier versions of BWMON calculated %CPU from the CPU Time metric.The
result is that BWMON 6.1 displayed zero % CPU when the actual percentage was less
than 0.5, whereas older BWMON versions displayed a fraction. Hawkmon has been
updated to calculate % CPU the same way previous versions of bwmon did, so the
older behavior is now present in newer releases of bwmon.
19621: Sorting consistency improved on BW Table displays
The BWmon Server and Process tables are now sorted initially by the item they
display, like the Engines table. The order of Activities in the table is left as
it comes from the source.
19802: BW versions no longer read incorrectly on certain BW servers
In certain cases the BW Monitor Servers data would include the incorrect BW
Version, i.e., when there are additional BusinessWorks plugins installed in the
BW server. This has been fixed.
19809: BW Process history table now disabled by default
By default BW Monitor will no longer save historical BW Process data to the
database. To enable the collection of historical BW Process data find the
following section in rtvapm.bwmon.properties and proceed as indicated.
##########################
# HISTORIAN PROPERTIES
#
# By default we disable collection of historical data for Processes.
#
sl.rtview.sub=$BW_PROCESSES_TABLE:''
sl.rtview.sub=$BW_ACTIVITY_TOTALS_TABLE:''
#
# To enable this, copy the following two lines into your local properties and
uncomment them:
#
#sl.rtview.sub=$BW_PROCESSES_TABLE:BW_PROCESSES
#sl.rtview.sub=$BW_ACTIVITY_TOTALS_TABLE:BW_ACTIVITY_TOTALS
19850: Default server expiration time raised to 300 seconds
The default value for $bwserverExpirationTime has been raised to 300 (seconds),
so as to be less sensitive to network delays, variance in system clocks, etc.
To change this value copy the following line into your local properties and edit
it:
sl.rtview.sub=$bwserverExpirationTime:300
19851: Flashing "expired" status fixed
Under some conditions in a multi-dataserver environment, a BW Server that was
expired would cycle between expired and unexpired in the displays. This has been
corrected.
TIBCO EMS
19316: Enhanced visibility of Last Data Time in the Server Summary page
The visibility of the Last Data Time text has been enhanced.
19544: Improve visibility of Consumer ID from EMS Consumer Summary
The Consumer ID field on the EMS Consumer Summary display will now resize
correctly.
19815: Disabled Connections/Consumers/Producers tables in history
By default EMS Monitor will no longer save historical EMS Connections, Producers,
and Consumers data to the database. To enable the collection of this historical
data find the following section in rtvapm.emsmon.properties and proceed as
indicated.
##########################
# HISTORIAN PROPERTIES
#
# By default we disable collection of historical data for these tables:
#
sl.rtview.sub=$EMS_CONNECTIONS_TABLE:''
sl.rtview.sub=$EMS_PRODUCERS_TABLE:''
sl.rtview.sub=$EMS_CONSUMERS_TABLE:''
#
# To enable history for them, copy any of the following three lines
# into your local properties and uncomment them:
#
#sl.rtview.sub=$EMS_CONNECTIONS_TABLE:EMS_CONNECTIONS
#sl.rtview.sub=$EMS_PRODUCERS_TABLE:EMS_PRODUCERS
#sl.rtview.sub=$EMS_CONSUMERS_TABLE:EMS_CONSUMERS
Version 1.5.0 Release Notes
Configuration
18822: Enabled purging of stale data for display server
To improve the performance of the display server, the property
sl.rtview.staledatapurgerate has been enabled.
19612: Properties file cleanup
The properties files for each Solution Package have been simplified to contain
the minimum set of properties to provide functionality. Examples of properties
files for customization are provided on each sample directory.
Logging
19450: Log4j diagnostic console statements removed
Some diagnostic messages containing "Log4j is not yet initialized" were removed.
Metric Explorer
19334: New Metric Explorer
RTView EM has been enhanced with a new feature called the Metric Explorer. RTView
EM provides many out of the box displays which show performance metrics of
various components of an application stack. However sometimes the pre-defined
views of data do not encapsulate all the related information that a user needs to
analyze. The Metric Explorer allows you to configure Views showing up to 5 CI
metrics in a trend graph. These configured Views can be named and saved and then
available to use as a list of predefined configurations to bring up to examine
the real time historical information.
Running the Metric Explorer:
The emsample application has been updated to contain the Metric Explorer. To
access it, navigate to Metric Explorer->Metric Explorer. To view an already
configured view, select it from the View list.
To add, edit or delete Views, click on the Edit (pencil) button to open the Edit
Pane. Navigate through your CMDB in the Service Tree and select the Service that
contains the CI with the metric you want to add to your view. Once you have
selected a Service, the Metric Tree will populate with the available metrics for
the selected Service. Add up to 5 metrics to your view and save it. When you are
finished adding or editing your view, click on the Done button to hide the Edit
Pane.
Views that have the Share View with Others checkbox selected will be available to
all users when the Shared Views option is selected. Views that do not have the
Share View with Others checkbox selected will only be available to you.
You can also access the Metric Explorer from the following Service Summary Views:
- Service Summary Views->Service By CI Type
- Service Summary Views->Service Summary
- Service Summary Views->Service Browser
The MX button and the table context menu in these displays will take you to the
Metric Explorer Edit Pane with the selected Service already selected in the
Service Tree. If you have a CI Type or CI selected, it will also be selected in
the Metric tree. This makes it easy to create a new View for the selected
service.
Configuration:
1. If you are using a database other than the hsqldb database included in
emsample\DATA, you will need to do the following:
- add a database connection named RTVMX that points to the database you will use
to store your Views by overriding the following property:
ConfigCollector.sl.rtview.sql.sqldb=RTVMX sa -
jdbc:hsqldb:hsql://localhost:9099/rtvmx org.hsqldb.jdbcDriver - false true
- use the schema in the appropriate file under rtvapm\mx\dbconfig to create the
RTVMX_VIEW_TABLE and RTVMX_METRICS_TABLE in your RTVMX database
2. If you are updating an existing application instead of starting with the
emsample application, do the following in addition to #1:
- Add the following to rtview.properties in the directory where you are running
the central EM servers: rtvapm_package=mx
- Add the following to your navigation tree:
<node label="Metric Explorer" mode="" display="mx_dir">
<node label="Metric Explorer" mode="" display="rtv_mx_view"/>
</node>
3. The Service Tree in the Metric Explorer Edit Pane is filtered by the following
login substitutions: $rtvOwnerMask, $rtvAreaMask, $rtvGroupMask, $rtvServiceMask.
Limitations
- When you save a view, RTView writes to both the view table and the metrics
table when you save even if only one or the other changed.
- When you save a view, the UI temporarily reverts back to the previous version
for one update, then updates with the latest changes.
- The search button will fail without an error if the service that was selected
when you initially added the metric is no longer in your CMDB. To fix this,
delete the metric and add it again from a service that is currently in your CMDB.
NOTE: The missing service will only make the search button fail. It will not
cause any problems with the viewing the metric.
- When you try to add a metric to a view that already contains that metric, it
will not be added again. In the viewer, an error message will come up saying that
the metric is already in the view. In the thin client, no error is shown.
- Views are limited to 5 metrics. Once a view contains 5 metrics, the Add Metric
button is disabled.
- There is no indicator that the database or config server (which is the server
connected to the database) if offline. This means that you could edit a view,
save and lose your changes.
- By default, the metric explorer attaches to the history_combo table for the
metric history. If the cache is not configured with a history_combo table, the
metric explorer will instead make a one-time attachment to the history table. In
this case, toggling the Log Scale checkbox will cause all points plotted after
the initial history query to be lost. On the next update of current data a
straight line will be drawn from the last history point to the new current data
point.
Monitor
19615: Extraneous navtree file removed
Some inconsistencies from the EM sample directory have been removed. In
particular, the navigation tree under emsample\servers\ocmon has been removed.
19617: Removed war files for packages in miscmon
War files from Solution Packages that are used under the miscmon data server have
been removed from the deliverable.
RTVMGR
19593: Readability improvements for RTView Servers views
In the RTVMGR, the Function Stats button in on the "Data Servers" and "Display
Servers" displays has been enlarge to better present well on various browsers.
RTView Core
Alerts
19141: alertExpireMode added to event alerts
Event Alerts have been enhanced with a new property, alertExpireMode. This
property supports 2 options:
- Initial Time - if selected and the alertExpireTime is greater than 0, the alert
will clear if the alertExpireTime has passed since the alert was generated.
- Last Update Time - if selected and the alertExpireTime is greater than 0, the
alert will clear if the alertExpireTime has passed since the alert received a
data update
Note that only indexed event alerts can receive data updates, so the Last Update
Time option will not work for unindexed event alerts.
19291: Cleared event alerts no longer regenerated in ssa
In previous releases, event alerts that did not have a mapping for Cleared in the
valueTableMap were erroneously regenerated after being cleared when running with
Self Service Alerts enabled. This has been fixed.
19292: unindexed event alerts can't be disabled in ssa
In previous alerts, unindexed event alerts could not be disabled using Self
Service Alerts. This has been fixed.
19714: Sybase schemas corrected
Errors have been corrected in two sql scripts:
RTV\dbconfig\alert_persist\createtables_sqlserver.sql
demos\selfservicealerts\dbconfig\createtables_sybase.sql
Commands
18643: japanese chars no longer garbled by "Send Email" command
The email command will now properly encode Japanese and other Asian characters
contained in the text of the email. In prior release, such characters were
garbled.
Data Sources
19164: Cache data source now reports missing config file
The cache data source will now generate an error message if a cache definition
file cannot be loaded. For example, if a cache definition file named MyCaches,rtv
is specified in CACHEOPTIONS.ini but the file does not exist then the following
error message will be printed to the console:
ERROR: can't load cache definition file MyCaches.rtv, file not found.
In previous releases, no message was printed if a cache file could not be loaded.
19216: Added per-index row limit to cache history table
To allow more control over the number of rows stored in a cache history table, a
new property named maxNumberOfRowsPerIndex has been added to the cache table
object (obj_cachetable).
In the Builder's property sheet, the new maxNumberOfRowsPerIndex property appears
in the Cache History Table category. The property is visible only if the cache's
maxNumberOfHistoryRows value is greater than zero. (Otherwise the cache does not
have a history table).
If a positive number N is assigned to maxNumberOfRowsPerIndex, then the cache's
history table will contain at most N rows for each unique combination of the
cache's index column values.
For example if a cache has one index column named Server and
maxNumberOfRowsPerIndex is 500, then the cache's history table will contain no
more than 500 rows for each unique name in the cache's Server column.
If the cache's condenseRowsFlag is set, then the maxNumberOfRowsPerIndex limit is
applied to the cache's history_condensed table. If the cache's
condenseRowsCombineHistoryFlag is also set, then the maxNumberOfRowsPerIndex
limit is also applied to the cache's history_combo table.
To reduce overhead, a cache's maxNumberOfRowsPerIndex is checked only once per
minute or, in the case of the history_condensed table, at the condense interval,
whichever is less frequent. This means that the maxNumberOfRowsPerIndex may be
exceeded until the next time the limit is checked.
By default the value of maxNumberOfRowsPerIndex is blank, meaning that no
per-index limit is applied to the cache's history tables.
With the addition of the maxNumberOfRowsPerIndex property the cache history table
size is now controlled by 3 properties:
1. If the historyTimeSpan property is set, the cache trims its history table by
removing rows with timestamps that are older than the limit,
2. Next, if the cache's history table exceeds the maxNumberOfHistoryRows limit
(which must be > 0 for the cache to store any history), then the oldest rows are
removed from the history table to satisfy the limit.
3. Next, if the cache's maxNumberOfRowsPerIndex limit is set then it is applied
as described above.
Distribution
19692: Core version removed from derivative releases
Due to changes in the build procedures for Enterprise Monitor, BW Monitor, EMS
Monitor, and OC Monitor, there is no longer a separate Core version number. The
console and About dialogs have been updated to reflect this change. A Build
Number has been added to the configuration information in order to identify the
build from which a release was generated.
The RTView Info function has been modified to reflect this change. Previously,
the RTView Version Info argument returned a table with EM version information and
the Product Version Info argument returned a table with Core version information.
Since there is now only one version, both arguments now return the same thing
which is the table previously returned by the Product Version Info argument.
Functions
19150: Warning if subst string arg to SetSub function contains spaces
An error message will now be logged if the Substitution String argument to the
Set Substitution function contains spaces. Spaces are not permitted in
substitution strings and will likely cause parsing problems elsewhere in RTView,
particularly in the thin client.
If a function named F has its Substitution String argument set to "$A B" the
following error message will be generated:
ERROR: function <F>, substitution string $A B contains space
To avoid breaking existing configurations that may already define substitution
strings with spaces and are working in spite of the potential parsing problems,
the function will still define the substitution including any space characters,
but will generate the error message.
Note that spaces are allowed in the Value argument of the Set Substitution
function. That has always been the case and is not affected by this task.
19331: Pivot on Unique Values function upgraded to accept multiple index columns
The Pivot On Unique Values function has been enhanced so that it accepts multiple
column names as the Key Column parameter. When multiple column names are used,
separated by semicolon, it groups the results by unique occurrences of the
combined values of all columns. When only one column is specified, the behavior
is the same as before.
19557: Ensure Columns now allows a single value with semi-colons if only one column
The Ensure Columns function has been enhanced to support semi-colons as literals
in the Value(s) argument under the following circumstances:
1. There is only one value in the Column(s) argument.
2. The Value(s) argument is enclosed in single quotes.
If those conditions are not met, the semi-colon is assumed to be a delimiter for
multiple values.
Object Library
15035: Image property added to Button Control
The button control (ob_c1button) now supports an Image property.
A button can display an image, a label, or both. If both the image and label are
set, the image will be to the left of the label. (This order is not
configurable).
This feature is supported in the viewer and thin client. However the appearance
can vary slightly between the viewer and the various supported browsers. When
displayed in the viewer and different browsers, you may notice differences in the
following:
1. Alignment of the image inside the button: The image may be somewhat closer to
the top or bottom edge of the button
2. Vertical alignment of the image with the button's label, if any: The center of
the image may be somewhat lower or higher than the center of the label
3. Appearance of the image and label if they don't fit inside the button: In some
cases the label may be clipped with a "..." replacing the clipped text, or the
label may be clipped with no indication, or the label may wrap and may extend
below the button.
It is best to leave several pixels of padding between the image and/or label of a
button to avoid wrapping or clipping of text in all browsers. Also, check the
button appearance in all browsers you intend to support.
In Firefox, a button with an image will not depress when it is clicked. However
the button's command will still be invoked.
In iOS Safari, if the image property is set on a small button (32 pixels or less
in width) the button will have square corners rather than rounded corners.
18167: FX Graphs traceNVisFlag now work even if there is no data
Previously there was a bug with FX Graphs where un-checking the traceNVisFlag did
not have an affect unless it was attached to data. This has been fixed.
18873: Corrected behavior of listValues property of a ComboBox or a ListBox
A problem has been fixed that prevented the items listed in a combo box or list
box control from updating when a new string was assigned to the control's
listValues property.
19454: HTML5 chart basic support
BASICS:
The html5 trend chart is a pure HTML implementation of an RTView trend graph
object. In the RTView thin client, the html5 trend chart provides an interactive,
high performance trend chart without requiring the Flash player or other browser
plugin.
There is no html5 trend chart in the Builder palette. Instead, a new property
named webChartFlag has been added to the flex (obj_fxtrend) and swing
(obj_trendgraph02) trend graphs. To enable the html5 trend chart the user simply
sets the webChartFlag property to true (checked) on a flex or swing trend graph
instance. Then, when the display is opened in the thin client in an HTML5
compatible browser, the html5 trend chart will appear in place of the flex or
swing trend graph.
REQUIREMENTS:
Firefox, iOS Safari, and Internet Explorer version 9 or newer support HTML5 and
will display the html5 trend chart on displays where enabled. Internet Explorer
version 8 and older do not support HTML5 so in those browsers the flex or swing
trend chart will be used regardless of the value of the webChartFlag property.
PROPERTIES:
The html5 trend chart supports all of the major properties available in the flex
and swing trend graphs.
However several minor properties are not supported or have limited support in the
html5 trend chart, as follows:
- background styles: Not supported. Except for the bgColor property, none of the
background style properties are supported. This includes the properties whose
names begin with bg, traceBg, and border.
- gradients: Gradient fill is not supported, so none of the properties named
*GradientStyle, *GradientMode, or *GradientFlag are supported.
- markDefaultSize, markScale: Not supported. These default to 6 and No Scale. The
markers for each trace can be configured with the traceNMarkStyle/Color
properties.
- traceNMarkStyle: The markers for trace N can be enabled by setting
traceNMarkStyle > 0 but the shape of the markers (circle, square, triangle, etc)
is selected automatically.
- traceNType: Supported types are Line and Bar. Event type is not supported.
- legendWidthPercent, legendValueMinSpace: Not supported. The legend (if visible)
is sized automatically.
- scrollbarMode/Size, zoomEnabledFlag: Not configurable. The scroll and zoom
features are always enabled and the scrollbar size is fixed.
- traceFillStyle: Supported values are None and Transparent. All other values
(Solid, Gradient, Transparent Gradient) are converted to Transparent
- x/yAxisMajor/MinorDivisions: Not supported. The number of ticks on the x & y
axis are selected automatically according to the size of the chart.
- yAxisPostion: Not configurable. The y axis position is always outer-left.
- yAxisAutoScaleVisTracesOnlyFlag: Not configurable, always true.
- x/yAxisFlag, x/yAxisThickness: Not configurable. The x and y axes are always
visible with a thickness of 1 and 2 pixels, resp.
- traceGroupNBandedFlag: Not supported. Trace groups are supported but banding
within groups is not.
- alert properties (valueHighAlarm*, valueLowAlarm*, valueHighWarning*,
valueLowWarning*): The html5 chart supports one alert threshold per chart. If
more than one alert threshold is enabled, the html5 chart will not be used. Also,
the alert TraceColor is used only if the traceFillStyle is None. For any other
traceFillStlye the alert TraceColor is ignored. The alert TraceStyle, Mark, and
MarkColor are ignored. The alarmGlowFlag is not supported.
The properties marked as Not supported or Not configurable in the list above will
not appear in the Builder's property sheet when a trendgraph object is selected
and webChartFlag is checked.
In some cases if the properties listed above have been configured on a flex or
swing trendgraph instance, then the webChartFlag property will be automatically
set to false and hidden in the property sheet, because the html5 trend chart does
not support those features. This occurs if any traceGroupNBandedFlag is checked,
if more than one alarm threshold is enabled, or if the alarmGlowFlag is checked.
Are any new properties supported?
The html5 trend chart supports two additional properties that are only visible in
the property sheet if webChartFlag = true.
- webChartNavigatorTrace: If this property is set to a trace number (a value
between 1 and the traceCount value) the html5 chart will display a "time
navigator" at the bottom of the chart, just below the x (time) axis. The
navigator plots the data for the indicated trace, and highlights the time range
that is currently visible in the chart. The highlighted section can be resized or
dragged to perform a time zoom or scroll. The navigator is intended to show the
user the entire data set and let the user zoom/pan to the time range of interest.
By default webChartNavigatorTrace = 0 so the navigator is disabled.
- yAxisAutoScaleVisDataOnlyFlag: If this property is checked the chart will
compute the y axis scale according to the min & max y values of the visible data
points only. This means that the y axis scale may change as the user changes the
visible time range by scrolling or zooming. By default the property is unchecked
and the y axis is scaled according to the y values of all of the data points,
visible or not, which matches the behavior of the swing and flex trendgraphs.
The Builder does not allow the webChartFlag property to be attached to data. This
is by design, since the flag's value is expected to be constant.
BEHAVIOR:
In addition to the properties listed above, there are some behavioral differences
between the html5 trend chart and the flex/swing trend graph as follows.
- Legend: The legend does not show trace point data (y) values. Data values are
only shown in the mouseover tooltips (if cursorFlag = 1). The cursor always snaps
to the nearest data point, it does not show interpolated values between data
points. Trace labels longer than 200 pixels are wrapped in the legend, and labels
longer than 150 pixels are clipped in the tooltip.
- Y axis autoscaling: Given the same y data values, the html5 trend chart may
choose a different value range for the y axes in autoscale mode as compared to
the other trendgraphs, because somewhat different algorithms are used.
- Reset button: If the user changes the chart's visible time range, via the
scrollbar or navigator or by dragging the cursor to perform a zoom, then a button
labeled Reset will appear in the upper left corner of the plot area. A click on
this button will reset the time axis to its original settings. The chart will
also resume shifting to show the newest trace points, unless the
timeRangeBegin/End properties are set.
- Data point grouping: The html5 trend chart makes use of a feature known as data
grouping to enhance performance when a trace has many data points. With data
grouping, the chart plots a single point using the average y value in cases where
otherwise multiple points would be plotted on the same x pixel coordinate. When
data grouping is in effect, the chart's tooltip will display a start time and end
time (rather than the usual single time value) to indicate the time range of the
averaged data points, for example:
05-Mar 12:35:00 ~ 05-Mar 12:45:00
[Notes: The data point grouping feature is enabled automatically and is not
configurable. Also data gropuing is performed independently of (and possibly in
addition to) any data condensing or compaction that has already been applied by
the RTVuew cache data source or the historian. Also the maxPointsPerTrace
property (3200 in the test1 display) is applied to the raw data, before any data
grouping is applied.}
The legendTimeFormat is used to format the date/time strings in the tooltip. If
that property is blank then the timeFormat property is used instead, but if the
string contains a newline it is replaced with a space character to avoid making
the tooltip overly tall.
- timeShift: The html5 trend chart does not attempt to keep the tick marks on the
time axis aligned on even multiples of the timeShift value, in the case where
timeShift > 1.
ENABLING / DISABLING:
The html5 trend chart can be enabled for all obj_fxtrend (flex) instances by
adding the following rule to an rtview stylesheet (.rts) file loaded by the
display server:
obj_fxtrend {
webChartFlag : 1
}
Similarly, the html5 trend chart can be enabled for all obj_trendgraph02 (Swing)
instances by the following rule:
obj_trendgraph02 {
webChartFlag : 1
}
See the documentation for more information on using RTView stylesheets.
If a stylesheet is used note that the webChartFlag value can still be overridden
and set to zero (false) on individual instances. Also, even if webCharFlag is set
on all instances, the flex or Swing trendgraph will still be used if a display is
opened in Internet Explorer 8 or older, or if certain properties not supported by
the html5 chart (as listed above) are configured on a specific trendgraph.
To disable the html5 trend chart globally, regardless of the webChartFlag value
on individual objects, specify the -nohtml5 argument on the display server
command line, or use the equivalent property. Alternatively, add the following
line to the rtvdisplay.properties file then rebuild and deploy the rtvdisplay.war
file:
HTML5Enabled=false
Finally, the html5 chart can be disabled in a specific browser window by
appending nohtml5=true to the URL, for example:
http://myserver/rtvdisplay/getdisplay.jsp?display=test1&nohtml5
http://myserver/rtvdisplay/panels.jsp?file=myapanels.xml&nohtml5
KNOWN ISSUES/LIMITATIONS:
- After zooming or scrolling, the time axis labels may briefly be misaligned or
overlap. They should be drawn correctly on the next refresh.
- The chart's tooltip may overlap the Reset button making it difficult to click
the button. Moving the mouse a bit will correct this problem.
- Like the flex chart, the web chart will display all timestamps using the local
time zone. This may cause user confusion if the display server is in a different
time zone.
- Performance is affected by the number of traces, trace points, use of trace
line shadows, trace line thickness, trace markers, trace fill, and other
properties. Performance is also affected by the browser and version, and the CPU
speed of the client host system.
- If any of the chart's graphical properties are changed while the chart is
displayed (eg. the traceFillStyle is toggled via a checkbox control) the chart is
rebuilt in the thin client, which in turn resets the chart's time range (as
though the Reset button was clicked).
- Scrolling: If the mouse is moved below the bottom of the chart while dragging
the scrollbar, the scrolling will stop. This is unlike the behavior of other
rtview objects, which will continue to scroll until the mouse button is released.
- Drilldown from trace points: If traceFillStyle is not "None" (i.e. trace fill
is enabled) and multiple traces share the same Y axis, then it is not possible to
click on a point belonging to trace N if the fill area of a higher numbered trace
is drawn over that point.
- When yAxisLogFlag = 1 and the chart has multiple y axes and traces, some y axis
labels may show ??? rather than numeric values. This is rare.
- Since the html5 trend chart does not support legendWidthPercent, the width of
each chart's legend will vary according to the trace labels. This makes it
difficult to create multiple trend chart instances on the same display whose time
axes are all the same length, even if the charts all have the same width. (A
single chart in stripchart mode may be more appropriate in those cases).
- On a touch interface, a swipe will scroll the chart left or right. To move the
cursor without scrolling, tap the location to which you want the cursor to move.
- On a touch interface, a pinch-open gesture in the plot area, scrollbar, or
navigator will zoom the chart's range in to the pinched range. A pinch-close
gesture will zoom out to the pinched range. The pinch-close operation may be
difficult to use. A tap on the Reset button gives a better zoom-out experience.
MISC:
Here is a complete list of the obj_fxtrend properties that are hidden if
webChartFlag is checked:
legendBgGradientFlag
legendWidthPercent
markDefaultSize
traceBgColor
traceBgGradientFlag
traceGroupNBandedFlag (for each trace N)
yAxisAutoScaleVisTracesOnlyFlag
yAxisThickness
yAxisPosition
yAxisFlag
xAxisFlag
yAxisMajor/MinorDivisions
xAxisMajor/MinorDivisions
xAxisThickness
Here is complete list of the obj_trendgraph02 properties that are hidden if
webChartFlag is checked:
borderPixels
labelMinTabWidth
legendWidthPercent
legendBgGradientMode
legendBgGradientColor2
legendValueMinSpace
markDefaultSize
markScaleMode
outlineColor
scrollbarMode
scrollbarSize
zoomEnabledFlag
timeRangeOfHistory
traceBgColor
traceBgGradientMode
traceBgGradientColor2
traceBgImage
yAxisAutoScaleVisTracesOnlyFlag
yAxisFormat
yAxisFlag
yAxisPosition
yAxisValueLabels
yAxisMajor/MinorDivisions
xAxisFlag
xAxisMajorDivisions
For each trace N:
traceNValueAlarmStatus
traceNValueAlarmStatusTable
traceNValueHistoryFlag
traceGroupNBandedFlag
traceNYAxisGridVisFlag
traceNYAxisMinLabelWidth
traceNYAxisValueLabels
traceNYAxisVisFlag
traceNYAxisAutoScaleMode
traceNYAxisValueMin
traceNYAxisValueMax
19503: Fixed builder crash on save when display contains composite with tabular local vars
A problem has been fixed that caused the Builder to throw a ClassCastException if
a display contains a composite whose subdisplay creates a tabular local variable.
Platform Support
19592: Support Chrome as a broswer for the thin client
The thin client is now supported in Chrome, on Windows. The version tested was
Chrome 35.0.
Chrome was not tested on iOS or Android.
Viewer - Applet
19308: Support applets in Java 1.7 with all permissions.
In previous releases, the Registration and Viewer Applets failed to run using
Java 1.7 due to a security error. This has been fixed.
The Registration and Viewer jars have been enhanced to include the
Application-Name and Permissions parameters in their meta-data in order to pass
the Applet security check. Note that the Viewer applet Permissions parameter is
set to all-permissions. The Registration applet Permissions parameter is set to
sandbox.
Scripts
19203: Windows service scripts provided for em apps
EM servers, dataservers, display servers, etc. may now be installed as Windows
services using the new install_service.bat script (in RTVAPM_USER_HOME/bin) as
follows:
install_service appName -service:serviceName
where "appName" is ConfigServer, AlertServer, DisplayServer1, AlertHistorian, or
dataserver
The current directory will be used for the server startup directory.
For example:
To install the ConfigServer as a service named myConfigServer:
First ensure it is not running, then cd to its startup directory (e.g.
RTVAPM_USER_HOME/servers/central) and issue the command
install_service ConfigServer -service:myConfigServer
To install the emsmon dataserver as "myEmsServer" you would cd to servers/smsmon
and issue the command
install_service dataserver -service:myEmsServer
You may append arguments such as -properties and -propfilter as needed by the
given server, e.g.
install_service dataserver -service:myEmsServer -properties:myproject
-propfilter:sender
The service is started when it is installed and amy subsequently be started and
stopped via the Windows service manager.
The service may be uninstalled with just its service name, e.g.
uninstall_service dataserver -service:myEmsServer
It will be stopped before it is uninstalled.
Solution Package
19355: Corrections to various discrete alert definitions
Discrete alert types in the db2mon, oramon, tbemon, and vmwmon solution packages
previously set the alert severity incorrectly. This error caused a number of
screens to malfunction when displaying severity for either a CI Type or
aggregated across components of a service. (These alerts display an odd
"infinity" symbol in the Warning Level column.)
Host Infrastructure
18440: New extension - RTView EM Host Agent (HOSTMON)
A new extension, RTView EM Host Agent (HOSTMON), has been added.
The Host Agent for RTView Enterprise Monitor collects CPU, network, storage, and
process metrics for Linux, Solaris, Mac, and Windows hosts. The agent may also be
configured to tail log files and forward selected entries to EM. The agent is not
polled by EM; instead, the agent collects and pushes metrics at a rate specified
in the agent.properties file.
See the README.txt file included with the hostmon package for more details.
IBM DB2 Database
19375: Column names shortened in DB2_SNAPDB table
Two columns in the Db2SnapDb cache (db2mon) had columns longer than 30 characters
in length. Attempts by the historian to persist this cache to an oracle history
database resulted in SQL errors. This problem was resolved by shortening the
column names in Db2SnapDb.
Customers with existing database tables should rename the following two columns
in the DB2_SNAPDBM table:
DEADLOCKSANDLOCKTIMEOUTSPERKTRANSACTION is now DEADLOCKSLOCKTIMEOUTSPERKTRAN
DIRTYSTEALTRIGGERSPERKTRANSACTION is now DIRTYSTEALTRIGGERSPERKTRANS
Oracle Coherence
19448: Single Cache Summary trends now displayed correctly
In previous versions, under certain circumstances, data for the Trend Graphs were
not displayed correctly. This is no longer the case.
19610: Fixed Proxy/Extend Connections trend
The Proxy Services -> Proxy / Extend Connections display has been improved to
prevent some errors in the trend graphs. Alert Level has been also added to the
two tables that show Proxy and Remote End Point information.
Alert Level has been also added to the two tables shown in Proxy Services ->
Proxy / Extend Detail display.
19611: Enhanced Proxy/Extend Client Heatmap
The Proxy Services -> Proxy / Extend Overview has been enhanced to be driven
through four more metrics: Alert Severity, Alert Count, Bytes Backlog, and Proxy
Bytes Backlog. Total metrics have been removed from the Metric drop down. Now
from the heatmap one can drill down to the Proxy Services -> Proxy / Extend
Connections display.
19623: Updated all displays with new resizing behavior
Six OCM displays were modified so that when they are stretched vertically the
upper and lower data display elements (heatmaps, bar charts, etc) resize equally.
Prior to this change only one of those elements would resize, with the other
remaining at the initial height.
The six displays are:
Cluster Views -> All Services History
Cluster Views -> All Nodes History
Cache Services -> Service Metric Heatmap
Cache Services -> Single Service History
All Caches -> Current Activity Chart
All Nodes -> Communication Issues
19625: Modified trend colors
The colors of certain displays have been modified to improve their readability.
19689: Two new alerts for proxy/extend backlog
Two new limits alerts OcExtendConnectionByteBacklogHigh and
OcProxyNodeByteBacklogHigh have been added to the OCMON alerts set. These alerts
are associated to Extend Connections and Proxy Node respectively.
Oracle Database
19282: ORAMON can now be configured to accept data from OEM
Oracle Database Monitor (oramon) can now be configured to accept data from Oracle
Enterprise Manager (OEM) by way of the new Oracle Enterprise Monitor Connector
(OEMCON). See the README.txt files for oramon and oemcon for more information
Oracle Enterprise Manager
19289: New extension - Oracle Enterprise Monitor Connector
A new extension, Oracle Enterprise Monitor (OEM) Connector (OEMCON), has been
added.
The connector package OEMCON listens for data exported from OEM via JMS. OEMCON
parses each JMS message and stores the data into the OemMetricsData intermediate
cache.
From there, it is reformatted and stored in caches for the Oracle Database
Monitor (ORAMON) and HOSTBASE solution packages, which handle basic display and
alerting functions for hosts and databases. See the README.txt file included with
the oemcon package for configuration details.
19421: Integrate Coherence Network Information With Hostmon Network Information
A new display ( Network/TCMP History Heatmap /
oc_host_nic_tcmp_history_heatmap.rtv ) has been made available so that related
Host Data and Coherence data can be provided on the same display to facilitate
recognition of correlations between the two sets of data
Different metrics can be selected for display in each data set, displayed as a
history heatmap, for a user selected time range. In this display the data is
Network Card Data, and aggregated Coherence network statistics from nodes,
displayed by host.
Selecting a Host for a data set will drill down to a more detailed display for
the selected entity.
CONFIGURATION
The display requires a configured EM system that collects metrics about a
Coherence Cluster, via an OCM data server, and hosts metrics from the
corresponding hosts via a hostmon data server.
These data servers are identified by the named data server connections, using the
substitution variables $OC_HOST_DS for the OCM data server, and $OC_HOST_DS for
the hostmon dataserver.
The substitution variables are initialized to the default ?out of the box? values
for the named dataserver connections used in the default emsample EM project,
thus:
$OC_HOST_DS=MISCMON-LOCAL
$OC_OCM_DS=OCMON-LOCAL
If non default values have been used for the named data servers, then the
substitution variables will need to be set to the correct non-default values for
the display to function correctly.
The display is commented out by default in the sample em navtree file
(servers/central/rtv_appmon_navtree.xml), under the commented out ?Coherence
Hosts? section so it will need to be uncommented if is required to be displayed
in the nav tree.
USAGE
The display has two history heatmaps.
The upper history heatmap, labeled ?Host Network?, displays Network (Rate)
Metrics over a user selected time range. Each row in the history heatmap
represents a host on which coherence nodes for the cluster are present. The
?Network Metric:? Dropdown allows the selection of a given metric to be used as
the value plotted in the history heatmap (higher values of the metric are
displayed as darker colors in the heatmap) The Values of the metrics, together
with the timestamp for the selected host are displayed in the pop-up mouse over,
when a cell in the heat map is moused-over.
The lower history heatmap, labeled ?Host Nodes?, displays Network (Rate) Metrics
over a user selected time range. Each row in the history heatmap represents a
host on which coherence nodes for the cluster are present. The ?Node Metric:?
Dropdown allows the selection of a given metric to be used as the value plotted
in the history heatmap (higher values of the metric are displayed as darker
colors in the heatmap) The values of the metrics, together with the timestamp for
the selected host are displayed in the pop-up mouse over, when a cell in the heat
map is moused-over. The values represent the average metric rates for all nodes
on the given host, for the timer period represented by the cell.
The ?Enable MouseOver? Check Box can be used to enable or disable the display of
pop-up mouse overs
The ?Log Scale? Check Box can be used to display the metrics in a Log scale or a
linear Scale.
The ?Range? Drop Down can be used to select the time range over which values are
plotted in the history heatmaps. The [?] Button can be used to select a
non-current date and time for the rightmost values displayed in the history
heatmap
The Labels at the base of the display show the start and end timestamps of the
data displayed in the heatmaps.
19423: Integrate Coherence Service Metrics With Hostmon CPU Information
A new display ( Coherence Host/Service History Heatmap /
oc_host_task_history_heatmap.rtv ) has been made available so that related Host
Data and Coherence data can be provided on the same display to facilitate
recognition of correlations between the two sets of data
Different metrics can be selected for display in each data set, displayed as a
history heatmap, for a user selected time range. In this display the data is Host
Performance data and aggregated Coherence Cache Service statistics from nodes,
displayed by host.
Selecting a Host for a data set will drill down to a more detailed display for
the selected entity.
CONFIGURATION
The display requires a configured EM system that collects metrics about a
Coherence Cluster, via an OCM data server, and hosts metrics from the
corresponding hosts via a hostmon data server.
These data servers are identified by the named data server connections, using the
substitution variables $OC_HOST_DS for the OCM data server, and $OC_HOST_DS for
the hostmon dataserver.
The substitution variables are initialized to the default ?out of the box? values
for the named dataserver connections used in the default emsample EM project,
thus:
$OC_HOST_DS=MISCMON-LOCAL
$OC_OCM_DS=OCMON-LOCAL
If non default values have been used for the named data servers, then the
substitution variables will need to be set to the correct non-default values for
the display to function correctly.
The display is commented out by default in the sample em navtree file
(servers/central/rtv_appmon_navtree.xml), under the commented out ?Coherence
Hosts? section so it will need to be uncommented if is required to be displayed
in the nav tree.
USAGE
The display has two history heatmaps.
The upper history heatmap, labeled ?Coherence Hosts?, displays Host Performance
Metrics over a user selected time range. Each row in the history heatmap
represents a host on which which coherence cache services for the cluster are
present. The ?Host Metric:? Dropdown allows the selection of a given metric to be
used as the value plotted in the history heatmap (higher values of the metric are
displayed as darker colors in the heatmap) The Values of the metrics, together
with the timestamp for the selected host are displayed in the pop-up mouse over,
when a cell in the heat map is moused-over.
The lower history heatmap, labeled ?Coherence Service?, displays (Coherence
Cache) Service (Rate) Performance Metrics over a user selected time range. Each
row in the history heatmap represents a host on which coherence cache services
for the cluster are present. The ?Service Metric:? Dropdown allows the selection
of a given metric to be used as the value plotted in the history heatmap (higher
values of the metric are displayed as darker colors in the heatmap) The values of
the metrics, together with the timestamp for the selected host are displayed in
the pop-up mouse over, when a cell in the heat map is moused-over. The values
represent the average metric rates for all (cache service, node) combinations on
the given host, for the timer period represented by the cell.
The ?Enable MouseOver? Check Box can be used to enable or disable the display of
pop-up mouse overs
The ?Log Scale? Check Box can be used to display the metrics in a Log scale or a
linear Scale.
The ?Range? Drop Down can be used to select the time range over which values are
plotted in the history heatmaps. The [?] Button can be used to select a
non-current date and time for the rightmost values displayed in the history
heatmap
The Labels at the base of the display show the start and end timestamps of the
data displayed in the heatmaps.
19424: Integrate Coherence Service Metrics With Hostmon Network Information
A new display ( Network/Service History Heatmap /
oc_host_nic_service_history_heatmap.rtv ) has been made available so that related
Host Data and Coherence data can be provided on the same display to facilitate
recognition of correlations between the two sets of data.
Different metrics can be selected for display in each data set, displayed as a
history heatmap, for a user selected time range. In this display the data is Host
Network data and aggregated Coherence service statistics from nodes, displayed by
host.
Selecting a Host for a data set will drill down to a more detailed display for
the selected entity.
CONFIGURATION
The display requires a configured EM system that collects metrics about a
Coherence Cluster, via an OCM data server, and hosts metrics from the
corresponding hosts via a hostmon data server.
These data servers are identified by the named data server connections, using the
substitution variables $OC_HOST_DS for the OCM data server, and $OC_HOST_DS for
the hostmon dataserver.
The substitution variables are initialized to the default ?out of the box? values
for the named dataserver connections used in the default emsample EM project,
thus:
$OC_HOST_DS=MISCMON-LOCAL
$OC_OCM_DS=OCMON-LOCAL
If non default values have been used for the named data servers, then the
substitution variables will need to be set to the correct non-default values for
the display to function correctly.
The display is commented out by default in the sample em navtree file
(servers/central/rtv_appmon_navtree.xml), under the commented out ?Coherence
Hosts? section so it will need to be uncommented if is required to be displayed
in the nav tree.
USAGE
The display has two history heatmaps.
The upper history heatmap, labeled ?Host Network?, displays Network (Rate)
Metrics over a user selected time range. Each row in the history heatmap
represents a host on which nodes with coherence cache services for the cluster
are present. The ?Network Metric:? Dropdown allows the selection of a given
metric to be used as the value plotted in the history heatmap (higher values of
the metric are displayed as darker colors in the heatmap) The Values of the
metrics, together with the timestamp for the selected host are displayed in the
pop-up mouse over, when a cell in the heat map is moused-over.
The lower history heatmap, labeled ?Host Service?, displays (Coherence Cache)
Service (Rate) Performance Metrics over a user selected time range. Each row in
the history heatmap represents a host on which nodes with coherence cache
services for the cluster are present. The ?Service Metric:? Dropdown allows the
selection of a given metric to be used as the value plotted in the history
heatmap (higher values of the metric are displayed as darker colors in the
heatmap) The values of the metrics, together with the timestamp for the selected
host are displayed in the pop-up mouse over, when a cell in the heat map is
moused-over. The values represent the average metric rates for all (cache
service, node) combinations on the given host, for the timer period represented
by the cell.
The ?Enable MouseOver? Check Box can be used to enable or disable the display of
pop-up mouse overs
The ?Log Scale? Check Box can be used to display the metrics in a Log scale or a
linear Scale.
The ?Range? Drop Down can be used to select the time range over which values are
plotted in the history heatmaps. The [?] Button can be used to select a
non-current date and time for the rightmost values displayed in the history
heatmap
The Labels at the base of the display show the start and end timestamps of the
data displayed in the heatmaps.
TIBCO EMS
19614: Button typo fixed in All Topics for Server
A typo has been fixed. The button for navigating to EMS Destinations -> All
Topics Heatmap display has been changed from Table to Heatmap.
19784: All EMS Servers bug with multiple collectors fixed
All EMS Servers is now correct when TIBCO EMS Monitor has been configured to
collect data from multiple data servers.
UX Monitor
18913: New Extension - User eXperience Monitor (UXMON)
A new extension, the User eXperience Monitor (UXMON), has been added.
The UX Monitor Solution Package provides End User Monitoring for web
applications. It does so by performing simulated transactions as if a real user
is accessing a URL. When these simulated transactions are performed, information
about the transaction such as the performance of the transaction, whether any
errors were produced by the transaction or if the transaction produces invalid
data are captured.
Version 1.4.5 Release Notes
19327: Sybase schemas updated to conform to Sybase requirements
All historian database schemas for Sybase have been updated with the following
syntax changes:
- All non-index columns now set the "NULL" parameter
- The use of the BIT type for boolean columns has been changed to SMALLINT, to
allow the use of boolean columns in indexes.
If you have existing database tables for storing historical data, you should not
need to make any changes to them, unless you have seen errors EM server logs that
suggest that one of the above changes would resolve the problem..
Deployment
19400: fixperms.sh updated to fix files from any location.
The installation and setup of the RTView EM framework and projects has been
streamlined as follows:
(1) The script file fixperms.sh has been moved to the bin directory so it can be
used from multiple locations.
(2) fixperms.sh will automatically be made executable and executed the first time
rtvapm_init.sh is run so the user no longer need perform these steps.
For example here are the steps to install the framework and a project named
myproject:
* unzip -a ...rtvapm...zip
* unzip -a rtvapm_projects.zip (contains myproject)
* cd rtvapm
* . ./rtvapm_init.sh
* cd ../rtvapm_projects/myproject
* . ./rtvapm_user_init.sh
* fixperms.sh
Note the following:
(1) fixperms.sh will be made executable and executed when rtvapm_init.sh is
invoked.
(2) when fixperms.sh is subsequently executed in the project, it is invoked as
"fixperms.sh" not "./fixperms.sh".
19490: Linux/unix version of make_all.sh for emsample
In the emsample project there is a Windows script named make_all.bat, which
executes make scripts in various subdirectories. There is now also a unix
version, make_all.sh.
Drill Down
19440: Implement dataserver selection in default dir page under EM
The default directory display has been enhanced to provide a drop down to select
from when there are CIs from the corresponding Solution Package across multiple
Data Servers. This drop down will be hidden when there is only one deployed Data
Server.
WLM is the exception to this behavior as this Solution Package supports data
collection from multiple Data Servers.
RTView Core
Data Historian
16720: Table creation for Sybase now declares NULL for non-index columns
Two problems in the Historian have been fixed related to Sybase:
1) The following exception was sometimes thrown when the historian was storing or
compacting data:
SQLException: The column <abc> in table <xyz> does not allow null values.
2) The following exception was sometimes thrown when the historian was compacting
data:
SybSQLException: The 'CREATE TABLE' command is not allowed within a
multi-statement transaction in the <xyz> database.
Both problems are fixed.
19312: Sybase integer conversion error fixed
A problem has been fixed that caused the Historian to throw an exception when
compaction of an integer column by averaging produced a floating point result,
when used with Sybase. The exception was reported as "Scale error during implicit
conversion of NUMERIC value".
This has been fixed by setting "arithabort numeric_truncation off" in the active
session between the Historian and the Sybase database.
Data Server
19477: Data Server NPE when DS is busy and pushing data to a disconnecting client
A problem has been fixed that in rare circumstances caused the data server to
throw a NullPointerException and become unresponsive after a client disconnected.
Data Sources
18738: Data type handling improvements for Extend by SQL option
Three problems affecting the Extend By SQL option in cache data source
attachments have been fixed.
The first problem caused the following SQL error in some conditions when a cache
attachment was configured with the Extend By SQL option and a filter on a string
column, and the database in use was Sybase:
"Implicit conversion from datatype 'VARCHAR' to 'INT' is not allowed. Use the
CONVERT function to run this query."
The second problem caused SQL errors when a cache attachment was configured with
the Extend By SQL option and a filter on a Boolean column, and the database in
use was Sybase, Oracle, DB2, or MySQL.
The third problem caused the Extend By SQL query result to use integer columns
for columns that were Boolean in the cache, if the database was Oracle or DB2.
All three problems are fixed.
19204: Improved support for mbeans that serialize (Tabular/Composite)DataSupport
The JMX adapter was updated to handle mbeans that serialize TabularDataSupport
and CompositeDataSupport objects, as used in some Tibco BusinessEvent mbeans. The
previous adapter would return a text blob for BE methods that returned these
types. Now, these objects are properly deserialized into an RTView table.
Object Library
19504: listbox selection no longer clears when list changes
A problem has been fixed in the viewer which caused the selected item in a list
box control (obj_c1tlb) to be deselected when the control's listValues property
was updated.
19511: Listbox validation bug fixed
A problem in the listbox control (obj_c1tlb) has been fixed which caused it to
ignore changes to the listValues property in some cases.
Scripts
19491: New custom script for adding solution package environment info
There are certain environment variables required for RTView servers, for example
those pertaining to a TIBCO installation, as documented in the installation
guides. These variables may now be set in an emsample project by editing the
supplied file rtvapm_user_env.bat(sh). This file will be called by
rtvapm_user_init.bat(sh) whenever it is executed.
Solution Package
IBM DB2 Database
18967: Improvements for navigation and layout consistency
Previously the "Back" and "Up" controls may have been positioned differently from
one screen to the next. The buttons are now precisely positioned and will not
"move" as you cycle thru DB2 displays.
Also, the "All Members" display has been added to the emsample example for
navigation consistency; previously, the "Up" navigation from Member Summary
linked to a display not shown in the navigation tree.
Oracle Coherence
18736: Sybase support for OCM history tables
Two support issues for Sybase have been addressed:
1) When auto-creating a database table for Sybase, the Historian will now declare
a column of type SMALLINT rather than BIT for a boolean column in a cache table.
This is necessary because Sybase does not allow a BIT column to be used in an
index, and some EM caches use boolean columns as index columns.
This change has also been made to the database schema file for Sybase found under
rtvapm\ocmon\dbconfig.
2) The following error that was seen with some Sybase drivers should be fixed:
WARNING: unrecognized database product name "sql server". A lost connection to
__RTVHISTORY will be undetected.
18863: Notify when the hit Percentage drops below a percentage
A new alert - OcCacheHitPercentageLow- has been added. This alert will trigger
when the current Hit % (total current hits/total current gets) drops below the
specified threshold for a sampling period and the specified cache(s).
This alert has a service/cache override.
18864: New alert for average read Millis
A new alert - OcStoreReadMillisHigh - has been added. This alert will trigger
when the current average read millis (total current StoreReadMillis/total current
StoreReads) drops below the specified threshold for a sampling period and the
specified cache(s).
This alert has a service/cache override.
18865: GC Duty Cycle in Node History Heatmap
A new display has been added to show the GC Duty Cycle for all the nodes in a
cluster. The display can be accessed from the existing All Nodes History Heatmap,
from a newly added "GC Metrics" button.
18866: Time Range Comparison Cache
A new display has been added that allows for analysis of cache data between two
sets of time ranges.
19180: All trends now show 7 days of data
All trend graphs have been enhanced to allow the display of up to 7 days of data.
19449: All Nodes Heatmap now shows departed nodes correctly
In prior versions, under certain circumstances, various All Nodes Heatmaps showed
departed nodes incorrectly. This is no longer the case.
19555: Log Scale fixed for the All Nodes History Heatmap
The Log Scale functionality of the All Nodes History heatmap has been restored. A
bug in the previous version left the Log Scale setting ineffective.
Also, resizing of this display will now result in both heatmaps equally sharing
the available display space.
Oracle Database
19137: Non-responding DBs are now visible in All Oracle Databases
All configured database connections are now listed in the "All Databases Table".
In previous versions of the Oracle database solution package, if a database did
not respond, it was not listed in the table when EM started. If a database goes
down while EM is monitoring the connection, the database will continue to appear
in the "All Databases Table" along with the last sampled metrics. This data will
eventually be deleted from cache and display as nulls or zeroes after the
$oraRowExpirationTimeForDelete interval in rtvapm.oramon.properties.
Oracle Weblogic
19516: WlsServerStateNotRunning is now working reliably
Previously inactive servers did not always trigger the alert
WlsServerStateNotRunning. Also, it was not always possible to create per-server
alert overrides for this alert.
Both problems have been fixed.
19562: Database schema changes for WlsSessionStats table
In EM 1.4.1, a correction to the WlsSessionStats cache resulted in a change in
the order of columns in the cache table. The columns "Connection" and
"OpenSessionsCurrentCount" switched location.
This change has now been reflected in the database schema files under
wlm\dbconfig.
Users with existing database tables will need to update WLS_SESSIONSTATS table to
change the order of these columns. The correct order is listed below, with the
two columns that have switched locations marked with arrows.
time_stamp
Connection <---
Location
ApplicationRuntime
OpenSessionsCurrentCount <---
DeltaSessionsOpenedTotalCount
RateSessionsOpenedTotalCount
TIBCO BusinessEvents
18789: Cluster filter added to all displays
The "All Clusters" tabular display used cluster name to filter the size of the
list. For consistency, filtering by cluster name has been added to all of the
displays for the Tibco Business Events Monitor. Also, the terms "Connection" and
"Node" were used to mean the same thing in several displays. "Node" now
consistently refers to a named member of the cluster. The term "Connection" is
used to indicate the connection string (host:port or url) for the source of the
JMX data. Other minor display improvements include consistency in field width and
positioning for similar display elements on different screens, consistent display
format for timestamps, and the addition of the count of outstanding alerts for
each node in the cluster.
19370: Corrected timing anomalies in history charts for summary displays
This bug fix corrects chart errors in the TIBCO Business Events summary displays
for Inference Nodes and Storage Nodes. The erroneous points appear in the most
recent data plotted (ie, the last one minute of data). Although the default
sample rate is one sample every 10 seconds, the bug occasionally resulted in
erroneous points spaced less than 5 seconds apart.
19408: Bug in rules/sec trend data on summary display fixed
Previously there was a bug when the historian generated tables in an Oracle
database. This problem does not affect users who created tables in Oracle
manually using rtvapm\tbemon\create_tbemon_history_tables_oracle.sql
This bug caused the "Inference Node Summary" screen to not display history for
the "Rules / second" chart. The cause was an incorrectly set flag (to quote sql
column names) on the TbeInferenceAgent cache, and this resulted in sql errors
when the TBE_INFERENCE_AGENTS table was queried.
Customers who are affected by this bug will need to apply the following
correction to their Oracle history database.
If loss of previous agent history is not a concern, simply drop the old
TBE_INFERENCE_AGENTS table, then let the historian re-create it with the quoted
column names. Otherwise, you can avoid data loss by stopping the historian,
renaming the old table, restarting the historian, then doing a "select into" to
copy data from the old table after the historian creates the new table, and
finally deleting the old table.
TIBCO BusinessWorks
19296: Enhance discovery of BWSE engines
The BW Monitor can be configured to discover BW Engines running as BWSE
components of an AMX service implementation. The engines must be configured with
HawkEnabled=true.
To enable the discovery of BWSE engines you may edit rtview.properties and
uncomment two lines, or copy those lines to your own properties file. The lines
are:
collector.sl.rtview.hawk.enablematable true
collector.sl.rtview.cache.config=bw_engine_microagents.rtv
TIBCO Hawk
19135: Optional collection parameters for hawkmon added to rtview.properties
The following lines have been added for this release in
rtvapm\projects\emsample\servers\hostmon\rtview.properties and
rtvapm\projects\emsample\servers\miscmon\rtview.properties:
# Uncomment following to optionally enable collection for process, storage, and
network data.
#collector.sl.rtview.cache.config=hawk_host_process_cache_source.rtv
#collector.sl.rtview.cache.config=hawk_host_storage_cache_source.rtv
#collector.sl.rtview.cache.config=hawk_host_network_cache_source.rtv
These properties are for collecting optional process, network, and storage data
for hawkmon. Customer can optionally uncomment these properties to enable
collection.
Version 1.4.4 Release Notes
Configuration
19367: Fixed inactive buttons in the CMDB Admin
A bug that prevented some buttons in the CMDB Admin display from enabling when
appropriate has been fixed.
Logging
19415: Adjustments to log4j default behavior
Log4j default properties file have been enhanced to mimic the previous default
properties of RTView CORE logging mechanism. Additionally, two examples about how
to configure log4j using file and daily appenders have been included.
The recommended way to change the default properties is to copy from
rtvapm/common/conf the sl.log4j.properties file into your projects directory and
then reference it in your custom.properties file by including a new property as
follows:
# Specify default configuration
sl.rtview.cmd_line=-log4jprops:mycustom.log4j.properties
You should invoke all processes including this custom.properties file.
Monitor
18788: Improvements to navigation tree
Several improvements have been made to the navigation pane:
- The RTView Servers parent node now shows a summary of the server child
displays.
- The TIBCO Hawk Monitor category has been split into two areas: TIBCO Hawk Views
and Host Views. The Hawk Agents Table view has been added to TIBCO Hawk Views.
CMDB Editor
19381: Button layout improved
A bug that prevented the buttons of the CMDB Admin display from displaying
correctly has been fixed.
RTView Classic
Data Server
19420: Exception in data server if attachment has bogus column name
A problem has been fixed that could cause the data server to become unresponsive.
The problem occurres if a client makes a cache data attachment with no row filter
and a column filter that specifies one or more nonexistent columns. In those
conditions, the data server would occasionally throw the following exception:
Exception in thread "GmsTimer-DataServer"
java.lang.ArrayIndexOutOfBoundsException
at com.sl.gmsjrt.GmsTabularData.gg$1(SourceFile:5925)
at com.sl.gmsjrt.GmsTabularData.writeObject(SourceFile:5849)
at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
...
at
com.sl.gmsjrtvhistorian.GmsRtViewDataServerDs.sendDataToClients(SourceFile:860)
at com.sl.gmsjrtvhistorian.GmsRtViewDataServerDs.gmsTimerFired(SourceFile:899)
at com.sl.gmsjrt.GmsTimer.run(SourceFile:106)
Solution Package
Host Infrastructure
19388: Host Summary trends now all display gaps
A bug that prevented Host Summary trend graphs from showing gaps when data is not
available for longer than 5 minutes has been fixed. Now CPU % Used, Mem Used, and
Mem Total display gaps when data is not available for that period of time.
19411: All Host Heatmap corrected for CpuPercent and MemoryUsed
Previously the color legend of the heatmap displayed an incorrect alarm level for
some of the metrics. It should display the alarm level of the alerts associated
with HostCpuPercent and MemUsed metrics. This has been fixed.
TIBCO BusinessWorks
19215: All Engines table Clear button fixed
The BW Monitor All BW Engines Table has a text field for filtering on the Engine
Name and an associated Clear button to clear the text field and return to the
full display. In the thin client this button did not correctly clear the text
field. This has been fixed.
Also a checkbox labeled "Regex" has been added. This will select whether the
string entered in the text box is interpreted as a simple wildcard expression or
a full Regular Expression.
19306: Provide process data subset; add all engines all processes display
BW Monitor has been enhanced with an alternative All BW Processes table, which
can be enabled to replace the default table (or be used in addition to it) by
editing the bwmon_navtree.xml file. This table has the option to display all BW
Processes across all BW Engines and BW Servers but with a subset of table
columns. The column subset used in the table is specified by the
$bwprocessColumnSubset property in rtview.properties, e.g.
sl.rtview.sub=$bwprocessColumnSubset:'Active;Created;Completed;AverageExecution;'
19403: Display title changes
The titles of the BW Monitor "single summary" displays did not include the word
"BW". This has been corrected.
19404: Count, Active Count, and Show Active toggle added to engine displays.
The BW Monitor All Engines displays (Heatmap, Table, Grid) have been enhanced so
that they all have text fields showing the counts of engines currently displayed
and engines active, and a checkbox to cause the display to show active engines
only.
TIBCO Hawk
19407: Hawk Alert table clear button fixed
The Hawk Alerts Table has two text fields for filtering on the Alert Text or the
Rulebase fields. Each text field has an associated Clear button to clear the text
field and return to the full display. In the thin client these buttons did not
correctly clear the text field. This has been fixed.
Version 1.4.3 Release Notes
Logging
19183: Log4j set as default logging mechanism
Log4j has been confirmed as the default logging engine. In the previous releases
there were some cases in which the property "useLog4j" was set to false.
RTView Classic
Data Server
19365: REST output generation breaks with special characters
In previous releases, the output of the rtvquery (REST) servlet was truncated if
a query result contained a non-ascii character. This is fixed
Data Sources
19363: Fixed memory leak for cache attachment with column filter
A memory leak has been fixed in the cache data source. The leak occurs if there
is a data attachment to the current table of a cache, and the data attachment
specifies a column filter but no row filter, and rows are never or only very
rarely removed from the cache. If there is such a data attachment the data server
will leak memory each time the cache is updated. The size of the leak depends on
the number of columns specified in the filter. The leak was introduced by changes
in RTView version 6.2.
Logging
19256: Log4J on Linux platforms
Log4J functionality was restored on Linux platforms.
Service Model
19119: Corrected CI count and removed PROD, DEV, DR, UAT from service summary
The following Service Summary Views displays have been enhanced to filter the CI
Count to the CI's shown based on the selected filters:
Service By CI Type (rtv_service_citype_summary.rtv)
Service Summary (rtv_service_summary.rtv)
Service Browser (rtv_service_browser.rtv)
The Service By CI Type and Service Summary displays have also been modified to
remove the DEV, UAT, DR and PROD labels.
Solution Package
Host Infrastructure
19354: Timestamps now from local receiver rather than remote sender
Host data from hostbase agents now uses a timestamp indicating when the receiving
dataserver added the data to cache. Previously, the timestamp came from the
monitored host. This caused host data to display as expired when the monitored
host's system clock lags the dataserver system clock by the expiration interval
or more.
IBM Websphere MQ
19315: New column "Oldest message age" in history table MQM_QUEUESTATS
In EM 1.4.2 the cache for storing queue stats gained a new column, but this
column was not added to the database schemas. This has been addressed.
Users with existing database tables will need to add the following integer (or
NUMBER for oracle) column to the end of the MQM_QUEUESTATS table:
"Oldest message age"
TIBCO BusinessWorks
19313: Add Active Processes to engine table and heatmap.
The BW Monitor All Engines table and heatmap have been enhanced with the addition
of the metric Active Processes. This per-engine value is distinct from Running
Processes in that it is calculated by BW Monitor each update using data returned
by the Hawk GetProcesses method.
19324: Reduce amount of process data sent by the sender data server
BW Monitor has been enhanced with the ability to limit the amount of BW Process
data sent by the BW Monitor data server in sender mode. The user may specify a
subset of the available Process table columns to be sent via a new property in
rtview.properties, e.g.
sl.rtview.sub=$bwprocessColumnSubset:'Active;Created;Completed;'
In addition an alternative sender file must be selected as per the instructions
in rtview;properties:
#
# Sender functions
#
sender.sl.rtview.cache.config=bw_rtvagent_sender.rtv
#
# Sender functions for process table subset
# (Comment out the line above and uncomment the one below)
#
#sender.sl.rtview.cache.config=bw_rtvagent_sender_subset.rtv
19368: 'Active' column in bw_process cache reverted back to type long
In EM 1.4.2 the data type for the ?Active? field in the bw_process cache changed
from a type of long to integer. This may have caused problems reading from
database tables defined with a column type of BIGINT for ?Active?. This change
has been reverted so that ?Active? is again a type of long.
TIBCO EMS
19309: Create new displays for queue/topic clients for producers and consumers
Two new displays to show producers and consumers from one single Queue or Topic
have been added.
These displays are reachable from the Clients button located in the upper side of
the Single EMS Queue/Topic for Server Summary displays.
19314: Split all producers and all consumers displays
The All EMS Consumers and All EMS Producers displays have been enhanced. These
enhancements are the following:
- addition of filtering options by ClientID and Destination Name
- addition of a check box to toggle the visualization of non-expired
Consumers/Producers from the table
- addition of two drill-down mechanisms: going to the Consumer/Producers Summary
by left-mouse double click and going to the Destination Details. This will send
you to the Single EMS Queue/Topic Summary Display depending on the Destination
Type. By default Destination Types that are different from Topic will be
redirected to the Single EMS Queue Summary display
Version 1.4.2 Release Notes
Configuration
19264: Historian backlog feature now enabled by default
The backlog property has been set as the default option for the historian. For
further information, see RN of TN19131.
Deployment
19265: projects/emsample/webapps/make_all_wars.sh fixed
The Unix shell script make_all_wars.sh in RTVAPM_HOME/projects/emsample/webapps
did not make any wars. This has been corrected.
RTVMGR
19214: Autodiscover now disabled by default for sender
JMX autodiscover for RTVMGR has been fixed to be disabled.
RTView Classic
Alerts
19175: Fixed memory leak when no "new data only" alert table listeners
In previous releases, the Alert data source leaked memory if there were no data
attachments to the AlertTable with either the New Data Only option selected or a
row filter. This has been fixed.
Data Historian
18655: Historian smoothing and compaction on non-US date strings
Historian smoothing and compaction no longer fail on non-US date strings in
non_US timezones.
19100: Extraneous debug message removed from Advanced Compaction
A leftover debug message was in the Historian code at the highest
-compactionverbose:2 level. This message was benign and has been removed.
19101: Improved multi-thread support for Advanced Compaction
A better method for multi-thread support for Advanced Compaction was implemented.
Messages like ?database connection busy, skip? should not appear.
Data Sources
18796: Support Hawk 5.0
The Hawk data source has been enhanced to support Hawk 5.0. In order to use Hawk
5.0, you must run with java 1.7+.
If Hawk 5.0 is configured for log4j logging, you will need to add your log4j jar
to the RTV_USERPATH.
RTView does not support AS (DataGrid) transports. Only RVD and EMS transports are
supported for Hawk 5.0.
The Hawkspot sample microagent application does not work with Hawk 5.0.
19176: Synchronization bug fixed
In previous releases, the JMS data source had a synchronization bug that could
cause occasional data updates to be missed. This would only happen in the case
where multiple updates for the same listener came in almost simultaneously.
This bug has been fixed.
19177: Synchronization bug fixed
In previous releases, the RV data source had a synchronization bug that could
cause occasional data updates to be missed. This would only happen in the case
where multiple updates for the same listener came in almost simultaneously.
This bug has been fixed.
19257: Gather Consumer Details information
The TIBCO EMS Administration data source Consumers table has been enhanced to
include 12 new columns with information from the
com.tibco.tibjms.admin.ConsumerInfo.Details class methods:
curMsgSentCount (long) - getCurrentMsgCountSentByServer() or -1 if unavailable
totalMsgSentCount (long) - getTotalMsgCountSentByServer() or -1 if unavailable
curMsgSentSize (long) - getCurrentMsgSizeSentByServer() or -1 if unavailable
destinationPrefetch (int) - getDestinationPrefetch() or -1 if unavailable
prefetchDeliveredCount (int) - getPrefetchDelivered() or -1 if unavailable
elapsedSinceLastAck (long) - getElapsedSinceLastAcknowledged() or -1 if
unavailable
elapsedSinceLastSent (long) - getElapsedSinceLastSent() or -1 if unavailable
routeName (String) - getRouteName() or blank if unavailable
sessionAckMode (String) - getSessionAcknowledgeMode() or Unknown if unavailable
**
totalMsgAckCount(long) - getTotalAcknowledgedCount() or -1 if unavailable
isActive (Boolean) - isActive() or false if unavailable
isSystem (Boolean) - isSystem() or false if unavailable
** The sessionAckMode column contains a String created from the value returned by
getSessionAcknowledgeMode() as follows:
TibjmsAdmin.SESSION_UNKNOWN_ACKNOWLEDGE: "Unknown Ack"
TibjmsAdmin.SESSION_XA: "XA"
TibjmsAdmin.SESSION_TRANSACTED: "Transacted"
TibjmsAdmin.SESSION_NO_ACKNOWLEDGE: "No Ack"
TibjmsAdmin.SESSION_AUTO_ACKNOWLEDGE: "Auto Ack"
TibjmsAdmin.SESSION_DUPS_OK_ACKNOWLEDGE: "Dups OK Ack"
TibjmsAdmin.SESSION_CLIENT_ACKNOWLEDGE: "Client Ack"
If getSessionAcknowledgedMode() returns a value not listed here, the
sessionAckMode will be "Unrecognized Type(x)" where x is the value returned by
getSessionAcknowledgedMode().
19263: New option to disable FT discovery
The TIBCO EMS Administration data source has been enhanced with a new command
line option:
-disableFTDiscovery
This option is not used by default.
When this option is NOT used, for each server that is defined in the servers.xml
or discovered using Hawk or Routes, RTView queries the EMS Server for its fault
tolerant URL. The URL returned by the EMS Server is the value used in the
ft_active setting in the EMS Server configuration. If RTView does not already
have this URL in the ServerTable, it will be added and a connection to it will be
made. This can cause duplicate entries in the ServerTable in the case where the
server was specified in servers.xml using a different URL than was used in the
ft_active field. For example, the URL in ft_active uses a host name but the
servers.xml entry for the same server uses an IP address. Or, the servers.xml
uses a DNS alias, but the ft_active uses a host name or ip address.
When this option IS used, RTView will not query each EMS Server for its fault
tolerant URL. Instead, it expects that all fault tolerant EMS Server pairs are
added to servers.xml as compound urls (ex. tcp://myhost:7222,tcp://myhost2:7224).
For each server in the compound url, the fault tolerant url will be set to the
other server in the compound url. No error checking is done to confirm that the 2
urls listed are actually a fault tolerant pair. It is up to the user to be sure
that the servers.xml information is correct.
In addition to the command line option, you can also use the following property
to enable this feature:
sl.rtview.jmsadm.disableFTDiscovery=true
19297: ConsumerInfo.Details metrics made optional (now disabled by default)
Task 19257 added 12 new columns with information from the
com.tibco.tibjms.admin.ConsumerInfo.Details class methods to the TIBCO EMS
Administration data source Consumer table.The query for this data can be slow,
and so by default these columns have been removed from the table. To include
these columns in the Consumer table, use the following command line argument:
-queryCIDetails
Or the following property:
sl.rtview.jmsadm.queryCIDetails=true
Note that enabling this option will slow down the EMS metrics queries on servers
with a large number of consumers.
Reporting
19178: Report generator now available for EM
In previous releases, the report generator could not be used in EM. This has been
fixed.
Service Model
19102: EM-SERVICE CI can now be used by more than one environment
Previously, the the index for the EM-SERVICE CI type and
RtvEmServiceAlert/RtvEmServiceAlertImpactHigh alerts did not use the Environment.
This caused problems when adding multiple services where the only difference was
the Environment. This has been fixed.
Upgrade Notes
============
When upgrading from a version previous to 1.4.2, users will need to update the
RTVCMDB database entries for all EM-SERVICE CI's and also their ALERTDEFS
database entries for all RtvEmServiceAlert/RtvEmServiceAlertImpactHigh alert
overrides.
RTVCMDB:
For all rows where the CIType=EM-SERVICE, modify the CIName to append a ;
followed by the value in the Environment field. For example, if the CIType is
EM-SERVICE, the CIName is Owner 1;Area 1;Group 1;My Service, and the Environment
is PRODUCTION, you should change the CIName to Owner 1;Area 1;Group 1;My
Service;PRODUCTION.
ALERTLEVELS:
For all rows where the ALERTNAME is RtvEmServiceAlert or
RtvEmServiceAlertImpactHigh and the INDEXTYPE does NOT equal Default, modify the
ALERTINDEX to append a ; followed by the correct Environment value. You can
determine the correct Environment value by looking up the corresponding CIName in
the RTVCMDB table. For example, if your ALERTINDEX is Owner 1~Area 1~Group 1~My
Service and the correct environment for that service is PRODUCTION, you should
change the ALERTINDEX to Owner 1~Area 1~Group 1~My Service~PRODUCTION.
19140: Enhanced environment setting in auto-created Infastructure CI's
The automatically generated Infrastructure CMDB entries have been enhanced with a
couple of options for setting the Environment for each CI:
- If a matching CI is found in the SQL CMDB table, the Environment from the SQL
CMDB table is used for the Infrastructure CI. If the CI is found in the SQL CMDB
table multiple times with multiple Environments, it will be added multiple times
to the Infrastructure CMDB, once for each Environment in the SQL CMDB for that
CI.
- If no matching CI is found in the SQL CMDB table, the Environment in the
Infrastructure CMDB is set to PRODUCTION by default. You can override the default
Environment but specifying a different environment in the
rtv_cmdb_source_default.rtv line in your properties file. For example, the
following will set the default Environment to DR:
ConfigCollector.sl.rtview.cache.config=rtv_cmdb_source_default.rtv
$rtvDefaultCIEnvironment:DR
A matching CI is a row where the CIType and CIName match.
Solution Package
IBM Websphere MQ
19213: Queue Summary table enhanced
The Queue Summary page has been enhanced with additional fields in the list of
queues to choose from. This allows the user to sort by and easily identify the
queues of interest.
19246: Implemented sender/receiver agents on MQMON
Agent sender/receiver capabilities have been added to MQMON package.
TIBCO BusinessWorks
19207: Correct filter for Hawk Alert Table
The Hawk Alerts table may now be filtered by Rulebase as well as Alert Text, by
entering a regular expression of rulebase names into the new Rulebase Filter text
field in the display. The Rulebase and Alert Text filters are applied in
sequence.
19221: Process Summary trend graph no longer including incorrect 0 points
Under some circumstances the process data trends on the Process Summary page
would show a sawtooth appearance caused by multiple rows of data with the same
timestamp, one of which has a zero value. This has been corrected.
19222: Added more selectors to All Engines Heatmap
Added Created and RateCreated to the metrics available to the All Engines heatmap
display.
19223: Elapsed Time metrics added to Processes Heatmap
Added two new metrics on the processes heatmap: Averaged Elapsed Time and Most
Recent Elapsed Time.
19279: Hawk Server expiration corrections
Hawkmon, which is used by itself or inside of BW Monitor, will sometimes indicate
servers as expired, when they should not be marked that way. The cache source
processing was changed to use full outer joins for joining certain intermediate
caches, so that missing data in any of these caches will not block final server
row update and cause rows in final display caches to expire. Also, dataserver CPU
utilization should be improved by clearing the updateListenersImmedFlag property
on all intermediate hawk caches.
TIBCO EMS
19094: Pending messages on all servers display now correct
A bug on EMS Servers Heatmap has been fixed. Previously if the number of Pending
Msgs was above the threshold for the maximum value of the color legend, it would
not show the correct color.
19209: Implement Drilldown to Destination from Consumers / Producer
The Producers For Server and Consumers For Server tables have been enhanced with
drilldowns that correctly identify the type of each row as Topic or Queue and
drill down to the corresponding Topic or Queue Summary page. Also the ID text
fields (Producer/Consumer ID, Conn ID, Session ID) on both those pages were not
always correctly formatted as integers; this has been fixed.
19210: Improvements to All Topics and All Queues display
The All Queues and All Topics displays have been improved as follows:
- Timestamp column widened
- Expired column added
- Drilldown to corresponding heatmap display added
19211: Improved table placement and resize in Queue and Topic Summary pages
The Queue and Topic summary pages have been enhanced by improving the placement
and resize behavior of the tables on those pages.
19212: Implement All Queues and Topics Heatmaps
Two new displays have been created to visualize, on a heatmap, the main metrics
for queues and topics: Severity, Alert Count, Consumers, Receivers/Subscribers,
Pending Messages, In/Outbound Msgs Rate, In/Outbound Total Msgs.
19220: EMS Metrics Administration display supports named dataservers
A bug that prevented RTView EM from showing valid data in the EMS Metrics
Administration display has been fixed.
19247: Routes page now shows correct bytes/sec & totals for in/out msgs
An error that prevented several metrics from being displayed correctly has been
fixed. These metrics were: Message In Bytes/sec, Message In Total, Message Out:
Bytes/sec, and Message Out: Total.
19266: Additional details available for EMS Consumers
An enhancement has been added to show consumer details in the Consumers Table of
the EMS Consumers for Server display.
In order of collecting the consumer detail info, you should first enable the
collection of these columns in the Consumer table by using the following command
line argument:
-queryCIDetails
Or the following property:
sl.rtview.jmsadm.queryCIDetails=true
Note that enabling this option will slow down the EMS metrics queries on servers
with a large number of consumers.
19267: New alert for Consumer Stalled
A new alert, EmsConsumerStalled, has been added to indicate when there are
stalled consumers. This alert does not allow overrides.
To collect the consumer detail info that this alert uses, you should first enable
the collection of these columns in the Consumer table by using the following
command line argument:
-queryCIDetails
Or the following property:
sl.rtview.jmsadm.queryCIDetails=true
Note that enabling this option will slow down the EMS metrics queries on servers
with a large number of consumers.
This alert filters all consumers from the following initial conditions:
(elapsedSinceLastAckInSec > AlertThreshold) || (totalMsgAckCount == 0) && (uptime
> minUptime) && (totalMsgSentCount > totalMsgAckCount),
where minUptime in the minimum running time of the server (default of 5, set
using $emsServerMinUptime).
This set of conditions is equivalent to:
(elapsedSinceLastAckInSec > AlertThreshold) && (uptime > minUptime) &&
(totalMsgSentCount > totalMsgAckCount)) || ((totalMsgAckCount == 0) && (uptime >
minUptime) && (totalMsgSentCount > totalMsgAckCount)
which equals to:
(elapsedSinceLastAckInSec > AlertThreshold) && (uptime > minUptime) &&
(totalMsgSentCount > totalMsgAckCount)) || ((uptime > minUptime) &&
(totalMsgSentCount > 0)
And provided that:
(uptime > minUptime) && (totalMsgSentCount > totalMsgAckCount)
contains the condition:
(uptime > minUptime) && (totalMsgSentCount > 0)
we can eliminate the second part of the or without any loss of data.
Therefore, the implemented alert filters out consumer rows that satisfies each of
these three conditions sequentially:
First, by filtering by Condition (totalMsgSentCount > totalMsgAckCount).
Second, by filtering from the rows that satisfied Step 1 by Condition (uptime >
minUptime) .
And third, by issuing an alert from the rows that satisfied the previous step
those that fulfilled Condition (elapsedSinceLastAckInSec > AlertThreshold), where
AlertThreshold is set in the alert definition.
TIBCO Hawk
19206: File renamed to remove extraneous space
An include filename used by the hawk solution package had an embedded space.
Although this caused no problems, it could lead to future problems and is
inconsistent with solution package programming standards. Hence, the space was
removed. No change in behavior of the package should be observable.
Version 1.4.1 Release Notes
Alerts
18802: Time tracing added to alert notifier
Time tracing has been added to EM alert notifications. This information is useful
when debugging notification issues. It let's you know how many notifications are
being generated and how long it takes to execute them.
To enable tracing, add this to your properties file:
sl.rtview.alert.notifiertimetrace=1
A value of 1 will output trace similar to the following for all notifications:
notify: 14 alerts, queue time=1, processing time=0, cmd process time=6, cmd
execute time=179, total time=186
And output similar to the following for timer renotifications:
renotify: 14 alerts, processing time=0, query time=0, cmd process time=0, cmd
execute time=159, total time=159
A value of 2 will output additional information for renotifications:
renotify: 14 alerts, processing time=0, query time=1, cmd process
time=0(subTime=0, alertStrTime=0, setupTime=0, attachRowTime=0), cmd execute
time=143, total time=144
18853: Timer re-notifications implemented for new alert notifier
In release 1.3.0, task 18357 implemented a new alert notifier that supported
notifying centrally or on the backend data server. This new notifier did not
support timer renotifications.
The notifier has been enhanced to support timer renotifications. If the following
properties are set, EM will renotify on all open and unacknowledged alerts:
sl.rtview.alert.notifierrenottime - Sets the rate (in seconds) to renotify. This
must be set to a value greater than 30. If it is set to a value greater than 0
and less than 30, the value of 30 will be used.
sl.rtview.alert.notifiercommandrenot - Set the command to execute for
renotifications. If sl.rtview.alert.notifierrenottime is set to a value greater
than 0 and this property is blank, the command specified in
sl.rtview.alert.notifiercommandnew will be used instead.
Commented out examples of these properties have been added to
common\conf\rtvapm.properties and common\conf\custom_handler.properties and to
the custom command handler.
18898: Alert group value no longer reset to default when navigating
In the previous release, the thin client had a limitation when the default Alert
Group filter was set by the login. In this case, if the user set the Alert Group
to another value using the Alert Group filter combo and then selected a different
node in the navigation tree, the Alert Group filter was reset to the default.
This problem has been fixed.
18908: AlertIndex parsing in notifications improved
The standard my_alert_actions.sh script has been improved to eliminate echoing
extraneous characters in the ALERTINDEX field.
Configuration
18907: Added $alertActionScript sub property incl. unix example
The alert script substitution properties in RTVAPM_HOME\common\conf
\rtvapm.properties have been modified. Previously, the $alertActionScript and
$scriptEnding properties were set via cmd_line properties. They have been
modified to be set via sub properties in order to make it easier to override
these properties:
# Substitutions to define the script executed by the above command
# Use these values if running on windows:
sl.rtview.sub=$scriptEnding:bat
sl.rtview.sub=$alertActionScript:my_alert_actions
The RTVAPM_HOME\common\conf \rtvapm.properties has also been enhanced to include
commented out versions of these properties for unix users:
# Uncomment the following if running on unix:
#sl.rtview.sub=$scriptEnding:sh
#sl.rtview.sub=$alertActionScript:./my_alert_actions
19118: Historian performance optimized with batch insert statements
In order to improve the performance of the historian especially in cases of
higher than average load, the default configuration settings have been enhanced
to enable the historian to make database inserts in batches. The size and
frequency of the batch inserts are controlled by two properties:
historian.sl.rtview.historian.cache_size=200
historian.sl.rtview.historian.cache_time=30
This says that the historian will insert a batch when either it reaches 200
records or 30 seconds has passed since the last insert.
19158: EM updated with more displays from standalone monitors
The EM navtree configuration file now contains all available displays for wlm,
ocmon, bwmon, and emsmon. Previously they only showed a subset of available
displays.
19170: Updates to central.properties for bwmon integration
When bwmon was run in an EM project, under some circumstances it would fail to
display data. This has been corrected.
Monitor
CMDB Editor
19181: Fixed bug preventing addition of CIs in CMDB Admin display
A bug that prevented the CMDB editing has been fixed. This bug was introduced
when enhancing the display to allow for insertion of multiple CIs at once.
RTView Classic
Alerts
19032: Fixed synch bug in alert ds for new data only listeners
In previous releases, a synchronization bug caused some updates from alert
commands not to be applied to the new data only listeners in the case where
several command updates were executed at the same time. This has been fixed.
Data Historian
19131: Data Historian Backlog property
The historian now supports a property named local_backlog. This property can be
used to help avoid loss of data during busy periods when the historian is
receiving data from a data server at a higher rate than it can be stored in the
database. If the local_backlog property is set, the historian will use its local
heap space to keep the backlog of data rows to be stored in the database. If the
local_backlog property is not set then the row backlog is kept in the data
server, where it may be discarded after a relatively brief time if the historian
is unable to process it. By default the local_backlog property is not set.
The property can be set as follows on the command line:
run_dataserver -local_backlog
or in a properties file:
sl.rtview.historian.local_backlog=true
The local backlog will keep a minimum of 50,000 rows of data. If the Oracle
server jvm is used, the backlog will grow as large as the available heap space
allows.
The following message appear in the historian log each time the backlog is
increased by 1000 rows:
backlog: increased to N rows
or decreased by 1000 rows:
backlog: decreased to N rows
where N is the current number of rows in the backlog. If the incoming rate of
data exceeds the rate at which data can be stored in the database for an extended
period of time, the backlog may need to be trimmed in order to avoid an
OutOfMemory exception in the historian. If that occurs, the following message
appear in the historian log:
backlog: discarded N rows
If this message is seen frequently, then it may be necessary to adjust the data
server, historian, and/or database configuration to reduce the incoming data
volume or increase database throughput. (That topic is beyond the scope of this
note).
Data Sources
19130: Hawk data synchronization improvement
In previous releases, a synchronization bug in the hawk data source occasionally
resulted in some data being missed. This has been fixed.
Display Server
18825: Display server memory leak fixed
A memory leak has been fixed in the display server that caused memory to grow at
a small rate for each new session.
18893: Global subs set in login no longer reset after navigation
The following problem in the thin client has been fixed: If a global variable $x
is initialized to a value of (say) 100 via a login sub defined in users.xml or
roles.xml, and then $x is set to a value of 200 by user interaction with a
display, the value of $x will incorrectly revert to 100 when the user later
navigates to a new display.
Functions
19143: GroupBy result now correct when possible index combos > 2 ^ 31
A bug in the GroupByTimeAndUniqueValues function has been fixed which caused rows
to be missing from the result in the case where the input table has multiple
index columns and the union of all possible combinations of the index values
present in the table exceeds 2^31
Solution Package
Host Infrastructure
18912: Fixed compaction rule bug in HostStorage
The compactions rules for HostStorage cache history data referenced a
non-existent history column. This caused a SQL error in the historian.log file,
and compaction to fail. Removing the column reference from the compaction rules
corrected this problem.
Oracle Weblogic
18750: WlsServerStateNotRunning alert now accepts per-server overrides
WlsServerStateNotRunning alert has been fixed to allow overrides of individual
servers.
18829: Sessions created for app servlets are now included
Sessions per Application has been fixed to account for the existence of multiple
servlets with independent number of sessions.
18843: New CI Types for JMS Servers and JMS Destinations
Two new CI Types have been added to the CMDB to account for the JMS Servers and
JMS Destinations under WebLogic.
18844: WLS Server drop down now lists all servers
All WLS Servers are now shown even when no applications have been deployed in
them.
18845: Data server validation fixed on Cluster Apps Table display
On the clustered application table display, the data server validation has been
fixed.
18846: Alert improvements
The following alerts have been improved: WlsJmsDestinationsCurrentLow,
WlsServerPendingUserRequestsHigh, WlsLockedUserCurrentHigh, and
WlsServerReloadsHigh.
To enable WlsJmsDestinationsCurrentLow and WlsLockedUserCurrentHigh you should
first uncomment on rtvapm\wlm\projects\sample\rtview.properties the section:
"Collect all other metrics".
18855: Corrected for missing data in JDBC trends
The JDBC filtering function for the trends has been fixed to account for an
update problem of the last history points in the trend graphs. With this fix,
when selecting among JDBC modules to change the shown trends, there will not be
any loss of data points at any time between update periods.
TIBCO BusinessEvents
18766: BEMon unable to get metrics from only inference agents
Configuration instructions in Readme.txt were updated with the following
pre-requisite for tbemon use.
Tbemon requires that your Business Events project use Cache memory management.
The "In Memory" memory management setting will not expose the mbeans queried by
tbemon. In other words, the project must use a cluster of both inference and
cache agents. Inference-only configurations are not supportable, since the JMX
Mbean data is not available.
18896: Rules fired per second calculation no longer fails with BE 5.1.x
The "Rules Fired per Second" calculation was producing results higher than
expected when monitoring BE 5.1.x systems. BE 4.0 and 5.0 results were correct.
TIBCO BusinessWorks
17315: Support for BWSE (ActiveMatrix)
BW Monitor can now display BW Engines running as BWSE components in an
ActiveMatrix environment. See the documentation for instructions on configuring
BW Monitor appropriately.
Limitations:
(1) JVM memory metrics will be available for BWSE components running in AMX 3.x
environments only.
(2) The BW Version column in the Engines table will be blank for BWSE components.
(3) The Deployment column in the Engines table will be UNKNOWN for BWSE
components. The AMX environment controls in which node or nodes a BWSE component
is running so the concept of "deployment" in traditional BusinessWorks does not
apply.
(4) Likewise, BWSE components will only appear in the Engines table when they are
running in a node.
18821: Deployed Engines and Active Engines added to All Servers pages
The columns Deployed Engines and Active Engines have been added to the All
Servers Table and Heatmap displays. In the Heatmap these metrics may be selected
in the dropdown list and seen in the mouseover tooltip.
19073: Periodic update now disabled by default
In the BWAgentPlugin.hma file the argument -update is now commented out. This
allows it to take its default value of 0, which disables the periodic update of
the deployment data by the BWAgentPlugin microagent. If the argument is
uncommented and given a nonzero value (seconds) the microagent wil update its
deployment data on that interval.
19120: Server process summary pages disabled by default
The BW Monitor Server Processes and Server Process Summary pages are not enabled
by default, because (due to limitations in Tibco Hawk) the data they display is
not available from IBM AIX or HP-UX servers.
To enable these displays, edit bwmon_navtree.xml in the project directory and
uncomment the following two lines, then restart BW Monitor.
<!-- <node label="Server Processes" display="bw_server_processes"/> -->
<!-- <node label="Server Process Summary" display="bw_server_process_summary"/>
-->
19169: BWM will show duplicates of Hawk alerts
BW Monitor Solution Package (1.4.0) was showing duplicate entries for in the
alerts table for Hawk alerts. This has been corrected.
TIBCO EMS
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.
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.
18814: Password column removed from server table
The Password column in the Server Table section of EMS Single Server Tables
display has been removed.
19160: Additions to projects/sample folder
The emsmon/projects/sample folder was missing some useful files. This has been
corrected.
Version 1.4.0 Release Notes
18696: SQL definitions updated for Central alert tables
Table and index definitions for ALERT_PERSIST_TABLE_RTVRULES and
ALERT_PERSIST_TABLE_CENTRAL have been added to the SQL schemas in the
rtvapm/common/dbconfig directory.
Alerts
18268: Support defining and filtering by Alert Groups
EM has been enhanced to support defining and filtering by Alert Groups. This
allows users to filter out alerts that are not relevant to them.
Alert Groups are defined in the CITYPE_ALERTMAP table in the rtvconfig database.
In order to define an alert group, add a row to this table where the CITYPE value
is GROUP-AlertGroupName and the ALERTNAME value is the name of an alert you want
to include in that group. For example, to define an Alert Group named
Availability and add the JvmNotConnected alerts to it, you would add a row like
this:
GROUP-Availability -- JvmNotConnected
A single alert name may belong to multiple Alert Groups and an alert group may
contain as many alert names as necessary. Any alert names that are not associated
with an Alert Group are added to the "None" Alert Group. Note that you may not
define an Alert Group named None.
Add the following property to the properties file used by your Central
Configuration server:
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_db.rtv
This property is included in
projects\emsample\servers\central\central.properties, but is commented out.
Uncomment this line in order to use Alert Groups.
When you have one or more Alert Groups defined, you will see an Alert Group combo
box at the top of all displays in all of the following sections of the navigation
tree:
All Management Areas
Multi Area Service Views
Service Summary Views
Component Views
The Alert Group combo box was also added to the RTView Alerts Table (Alert
Views->RTView Alerts Table) and the Alerts History Table (Alert Views->Alerts
History Table).
The navigation tree when you run in the alert-viewer mode also has the Alert
Group combo box.
Select an Alert Group from the Alert Group combo box to filter the alerts in the
display by the selected Alert Group. This will filter out all alerts that are not
part of the selected group from the display. The Alert Group filter is an
application wide filter, so changing the selected Alert Group will also change it
on all other displays in the application.
You can also set the default Alert Group filter for your application, either in
the properties files or per user or role. To do this, set the
$rtvAlertGroupFilter to the name of the Alert Group you would like to filter by.
For example, to set it to the Availability Alert Group in your properties file:
sl.rtview.sub=$rtvAlertGroupFilter:Availability
Or add it to your users.xml or roles.xml to define a per-user or per-role
default:
sub name="$rtvAlertGroupFilter" value="Availability" />
The thin client deployment has a limitation with the per-user or per-role
default. When the user's log in sets the default Alert Group filter and then the
user changes the Alert Group filter by selecting another from the Alert Group
filter combo box on a display, this value is reset to the default value if the
user selects another node in the navigation tree.
Note that the Alert Group combo box will only show up in your displays if you
have defined at least one Alert Group in the CITYPE_ALERTMAP.
To see the defined Alert Groups, navigate to Architecture->RTView Cache Tables
and select CONFIG-SERVER in the DataServer combo box at the top of the display.
Then, select the RtvAlertGroupMap cache from the top table. This will show you
all of the Alert Groups and the associated alert names. Note that this cache
includes the None Alert Group which RTView defined for all alerts that are not
included in a user defined Alert Group.
5 new caches were added to the central alert server to support this feature:
RtvAlertStatsByCIAndAlertGroup, RtvAlertStatsByAreaAndAlertGroup,
RtvAlertStatsByServiceAndAlertGroup, RtvAlertStatsByServiceRegionAndAlertGroup.,
and RtvCmdbAlertStatsByAlertGroup. The RtvCmdbAlertStatsByAlertGroup is
configured to be stored in history when you run the Historian. It is stored in a
new database table named RTV_SERVICESTATSBYAG in the RTVHISTORY database. The
schema for this table is included in
common\dbconfig\create_common_history_tables_*.sql.
Custom displays using data from the following caches can be enhanced to include
the Alert Group filter:
RtvAlertStatsByCI
RtvAlertStatsByArea
RtvAlertStatsByService
RtvAlertStatsByServiceRegion
RtvCmdbAlertStats
The technique for adding the Alert Group filter depends on the content of your
custom display.
If your display uses one of the following include files to feed data to your
display, do the following:
1. Add a function named getAlertGroupsSupported to your display. This function
doesn't need to do anything - it can just be an Add function with both arguments
set to 0.
2. Save and reopen your display and see that the Alert Group combo box is now
included at the top left of the display. Selecting a value from this combo box
should filter the data in your display.
Include Files:
rtv_alerts_table_include.rtv
rtv_cistats_current_include.rtv
rtv_cmdb_area_current_include.rtv
rtv_cmdb_citable_current1s_include.rtv
rtv_cmdb_citable_current_include.rtv
rtv_cmdb_service_current1a_include.rtv
rtv_cmdb_service_current1o_include.rtv
rtv_servicestats_current1a_include.rtv
rtv_citypes_include.rtv
If your display does not use one of the following include files, do the
following:
1. Tools->Include - add rtv_alertgroups_include.rtv (this file is in the
rtvapm\appmon\lib\rtvapm_appmon.jar)
2. Add a function named getAlertGroupsSupported to your display. This function
doesn't need to do anything - it can just be an Add function with both arguments
set to 0.
3. Find the function in your display that is directly attached to one of the
caches listed above. Copy the data attachment to this cache.
4. Add a new Conditional Function.
- Paste the data attachment you copied in step 3 into the Table1 argument.
- Paste the data attachment you copied in step 3 into the Table2 argument.
- Double-click on the Table2 argument to edit it. Change the cache name to append
"AndAlertGroup" to the end of it. For example, if your data attachment was to
RtvAlertStatsByCI, modify it to RtvAlertStatsByCIAndAlertGroup. Also, modify the
filter to include the ALERTGROUP column filtered by $rtvAlertGroupFilter. Click
OK.
- Attach the ReturnTable2 argument to the getFilterByAlertGroup function
- Give the new function a name and click OK to save the function.
5. Edit the function from step 3 that is directly attached to the cache. Modify
it to attach to the function you created in step 4 instead.
6. Save and reload your display. You should now see the Alert Group combo box at
the top left of the display. Selecting a value from this combo box should filter
the data in your display.
18677: Filter added to alert administration
The Alert Administration screen has been enhanced to include an Alert Filter. To
filter the alerts listed in the table, enter a string into the Alert Filter and
press <enter> or click elsewhere in the display. No wildcard characters are
needed for partial strings. For example, you have 3 alerts:
BlueAlert
GreenAlert
BlueGreenAlert
If you enter Blue in the Alert Filter field and press enter, the Alert Table will
be filtered to only show the BlueAlert and BlueGreenAlert rows.
Click the Clear button to clear the filter.
18678: Alert Index checkbox added to alert table to toggle visiblity
The Alert Table display (Alert Views->RTView Alerts Table) has been enhanced with
a checkbox to toggle the visiblity of the Alert Index column. By default, this
column is hidden and can be shown by selecting the Alert Index checkbox at the
bottom of the display. To make this column visible by default, add the following
property to the properties file used by your viewer application:
# Show the Alert Index column in the alert tables
sl.rtview.sub=$rtvUserShowAlertIndex:1
The position of the Alert Index column in the table depends on the configuration
of the $rtvUserAlertTableColumns substitution property. The
$rtvUserAlertTableColumns allows the user to configure which columns are included
in the table, along with the column widths and order. The Alert Index column is
always included in the table regardless of the $rtvUserAlertTableColumns value.
If the $rtvUserAlertTableColumns value is not specified, the Alert Index column
will be positioned after the Alert Name column. If $rtvUserAlertTableColumns is
specified and it includes the Alert Index column, it will use the size and
posisiton specified. If $rtvUserAlertTableColumns is specified and it does not
include the Alert Index column, it will be positioned at the end of the table.
The Field Filter list will always contain the Alert Index column regardless of
whether or not that column is visible.
The following displays will also hide or show the Alert Index column in the alert
table based on these settings:
rtv_service_citype_summary.rtv (Service Summary Views->Service By CI Type)
rtv_service_summary.rtv (Service Summary Views->Service Summary)
rtv_allareas_allservices_citype_summary.rtv (Multi Area Service Views->Services
CI Type Summary)
rtv_area_allservices_citype_summary.rtv (Single Area Service Views->Services CI
Type Summary - not included in the default navigation tree)
Examples of these properties are included in the emsample demo in
%RTVAPM_HOME%\projects\emsample\servers\central\rtview.properties.
All of the above substitutions can be set on a per-user or per-role basis if the
RTView login is enabled and custom users or roles are defined. See the
documentation for information on how to define substitution values for custom
users and roles.
18852: Corrections to alert historian database schema defintions
The database schema definitions for history tables under common\dbconfig have
been updated. Users with existing tables in production should not need to make
changes to their tables, unless they have been experiencing problems and suspect
that one of the following is the cause of a problem.
1) The "AlertCount" column of RTV_SERVICESTATS has been corrected to have an
integer data type instead of string data type.
2) The per-database syntax was not consistent with other database schema
definitions. SQL Server in particular has changed dramatically.
3) The naming convention has been changed. The previous files were:
create_rtvhistory_tables_db2.sql
create_rtvhistory_tables_mysql.sql
create_rtvhistory_tables_oracle.sql
create_rtvhistory_tables_sqlserver.sql
create_rtvhistory_tables_sybase.sql
The new files are:
create_common_history_tables_db2.sql
create_common_history_tables_mysql.sql
create_common_history_tables_oracle.sql
create_common_history_tables_sqlserver.sql
create_common_history_tables_sybase.sql
4) Other tasks in this release have affected the contents of these database
definitions. You can read their release notes for more details.
18868 changed the length of varchar strings used as indices to 100
18268 added a new table RTV_SERVICESTATSBYAG
Configuration
18604: Allow multi-selecting of CI's in CMDB admin
The CMDB Admin display now allows users to select multiple CIs and add them to a
Service in a single step. This new behavior applies to both the 'Add CI' and 'Add
CI to...' buttons.
18688: Optimization of history database table schema definitions
Several changes have been made to the history table SQL schemas.
1) The max length for all non-index VARCHAR columns has been set to 255, and the
max length for all index VARCHAR columns has been set to 100. Users should not
need to modify existing tables.
3) Index names for Sybase and Oracle that may have otherwise been more than 30
characters have been renamed to a unique index name less than 30 characters.
Users should not need to modify existing indexes.
4) A few database table definitions still contained an unnecessary "RTVHISTORY".
table prefix. These have all been removed. Users should not need to modify
existing tables.
18793: New property defines the default character limit for index cols
A new property that defines the default character limit to 100 characters for the
size of index columns has been added. To modify this default add the following
property to your chosen properties file:
# Define the size of varchar index columns in RTVHISTORY database
historian.sl.rtview.historian.charlimitindex=[newSize]
This new property solves the issue on Sybase of failures with index limits while
increasing performance on the other supported databases.
18810: Default value for compaction interval increased to 60 seconds
To allow the historian to perform compaction without missing data, the historian
property compactiontimerinterval has been increased from 5s to 60s.
18857: New property to skip history/history_s check
The following property has been added to rtvapm\common\conf\rtvapm.properties to
prevent the Historian from attempting to create or modify the HISTORY and
HISTORY_S tables
sl.rtview.historian.historyTableName=__none
Deployment
18699: Support sender/receiver on same host out-of-box
The default properties for the packages bwmon, emsmon, rtvmgr, and wsm have been
modified so that if a dataserver is run as a sender (aka. "agent") it will be
given unique port assignments.
Note that for a deployed sender-receiver configuration, both the sender and
receiver dataservers must be restarted after this upgrade is installed.
Documentation
18775: Updated help links with latest documentation
The RTView help system has been updated with the latest published documentation.
General
18740: Help button enabled
Context-help system has been integrated in the RTView EM displays. To use it,
click the button ? at the upper right location of each display. A new browser
window will be shown with the html page in which the display has been described
in the documentation.
Monitor
18453: Default CI Type defs moved out of rtvconfig db and into packages
EM has been enhanced to support defining CI Types within each package in addition
to the central RTVCONFIG database. All of the standard SL packages have been
enhanced to take advantage of this.
Previously, all of the CI Type definitions for the standard RTView packages were
stored in the central RTVCONFIG database. In this release, they have been moved
out of the central RTVCONFIG database and are now defined in xml files in each
package's jar. In order to read the CI Type definitions, 2 lines are needed in
the properties file used by the central configuration server for each package
that you are using (where pkg is the name of the package):
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:pkg
For example, if you are using the Custom package, you would add the following:
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.custom.xml 0
rtvconfig.custom.xml 0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:custom
The central.properties file in projects\emsample\servers\central contains these 2
lines for each standard RTView package.
The RTVCONFIG database is now shipped without any rows. In future releases, this
will make it easier for customers with custom CI Types and/or Alert Group
definitions to upgrade to new versions of EM since the database will now only
contain user defined custom CI Type definitions.
Users that have created custom packages have 2 options for storing custom CI Type
definitions:
1. Add CI Type definitions to the RTVCONFIG database as was done in previous
versions. In this case, include this line in the properties file used by the
central configuration server:
ConfigColllector.sl.rtview.cache.config=rtv_config_cache_source_db.rtv
2. Create an xml file named rtvconfig.pkg.xml (where pkg is the name of the
package) with CITYPE_DEFS, CITYPE_CACHEMAP and CITYPE_ALERTMAP tables, pack it
into the package jar and add the following 2 lines to the properties file used by
the central configuration server:
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:pkg
Also add this line to the properties file for the custom package:
sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1
The custom package defined in projects\emsample\custom shows an example of how to
do this. In projects\emsample\custom\src\rtfiles, there is a file named
rtvconfig.custom.xml that contains the custom CI Type definitions. The
projects\emsample\custom\conf\rtvapm_custom.properties file contains the
following line:
sl.rtview.xml.xmlsource=rtvconfig.custom.xml 0 rtvconfig.custom.xml 0 1
The projects\emsample\servers\central\central.properties contains the following
lines in the CUSTOM section:
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.custom.xml 0
rtvconfig.custom.xml 0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:custom
By default, the rtvconfig.pkg.xml files are read from the central EM
installation. In the case where you have a backend data server that is a
different version than the one in the central EM installation and the backend
server is EM version 1.4.0+, you can configure EM to get the rtvconfig
information from the data server instead. To do this, modify the properties file
used by the central configuration server as follows:
1. Append $rtvDataServer:DATASERVER-CONN to the rtv_config_cache_source_xml line
for that dataserver, replacing DATASERVER-CONN with the data server connection
name.
2. If necessary, add a named data server connection for that server with the
ConfigCollector property filter.
For example, to do this for the custom package, you would replace this line:
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:custom
with the following lines:
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:custom $rtvDataServer:CUSTOM-LOCAL
ConfigCollector.sl.rtview.dataserver=name=CUSTOM-LOCAL;connect=localhost:3278
Upgrade Notes
---------------------
NOTE: If you skip these steps, you will either have no CI Type definitions or
outdated CI Type definitions. Either condition will cause EM to break.
Customers upgrading from a previous version of EM will need to do the following:
1. Clean up the RTVCONFIG database:
- If you have custom CI Types defined in the RTVCONFIG database, remove all rows
except those for your custom CI Types. Optionally, you can move your custom CI
Type definitions to an xml file in your package jar as described above. If you
opt to do this, remove all rows from the database.
- If you do NOT have custom CI Types defined in the RTVCONFIG database, remove
all rows from the RTVCONFIG database.
2. For each standard RTView package that you are using, add 2 lines to the
properties file used by your central configuration server where pkg is the
package name:
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:pkg
For example, if you are using the EMSMON package, you would add the following:
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.emsmon.xml 0
rtvconfig.emsmon.xml 0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:emsmon
The projects\emsample\servers\central\central.properties file contains these 2
lines for each of the standard RTView packages.
3. If you have custom CI Types, add a reference to them in the properties file
used by your central configuration server:
- If you opted to leave your custom CI Type definitions in the RTVCONFIG database
in step 1, add this line to the properties file used by the central configuration
server:
ConfigColllector.sl.rtview.cache.config=rtv_config_cache_source_db.rtv
- If you opted to move your custom CI Type definitions to an xml file in your
package jar, add these lines to the properties file used by the central
configuration server (where pkg is the name of your custom package):
ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1
ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv
$package:pkg
4. If you have created custom displays with data attachments to the RTVCONFIG
database, replace them with data attachments to the following caches on the
central configuration server: RtvCITypeDefs, RtvCITypeAlertMap and
RtvCITypeCacheMap.
Navigation
18705: Fixed bug causing "OK" button to not close window in thin client
The commandCloseWindowOnSuccess property now works in the thin client on a
pushbutton control with a drilldown command. In prior releases, the popup window
did not close.
RTView Classic
Alerts
18805: Bug loading alert definitions after multiple HA failovers fixed
In previous releases, a bug with HA caused some alerts not to load in the backup
server in the case where the primary server in the pair had failed multiple times
without the backup server rebooting and the servers were configured with multiple
alert definition files. This has been fixed.
Builder
18377: New mechanism to specify template for new displays
The builder supports a new property named displayTemplate. It allows the user to
specify an rtv file that should be used as the template for all new displays. The
user can make any changes (e.g. add objects) to the template, and the builder
will prompt for a new file name when the user attempts to save the changes, so
the template remains unchanged.
Command-line example:
run_builder -displayTemplate:MyTemplate.rtv
Property file example:
sl.rtview.displayTemplate=MyTemplate.rtv
Customization
18658: Support customization of user/role manager classnames
In previous releases the java class names for the custom user manager and role
manager were hard-coded to MyUserManager and MyRoleManager, respectively. In this
release, MyUserManager and MyRoleManager are still the default class names but
they can be overridden on the command line via two new options, as shown in the
following example:
run_viewer -customUserManagerClassName:com.xyz.UserMgr
-customRoleManagerClassName:com.xyz.RoleMgr
The custom classnames can also be specified in a properties file, as follows:
sl.rtview.customUserManagerClassName=com.xyz.UserMgr
sl.rtview.customRoleManagerClassName=com.xyz.RoleMgr
18700: Role substitutions now queried on login
The display server will now call GmsRoleManager.getSubstitutions(roleName) every
time a user logs in or changes roles. This will allow a custom role manager to
change the substitutions returned for a specific role without requiring a restart
of the display server. In prior releases, the method was only called once for
each unique role name.
Data Historian
18791: New property to set the character limit of text index columns
The historian supports a new property named charlimitindex to specify the length
of each text (VARCHAR) column that is an also index column in the corresponding
cache.
For example, if -charlimitindex:70 is specified on the command line when starting
the historian, then for each text column that is an index column in a cache, the
historian will add a VARCHAR(70) column to the database table it creates to
persist the cache.
If the charlimitindex property is not specified then all text columns, including
index text columns, will use the size specified by the charlimit property.
If the charlimit property is not specified, then all text columns will be created
as VARCHAR(50).
For example, if the following properties are specified on the historian command
line then all index text columns will be created as VARCHAR(70) and all non-index
text columns will be created as VARCHAR(200):
run_historian -charlimit:200 -charlimitindex:70
The charlimitindex property is useful in cases where the database limits the
total width (in characters or bytes) that can be used in an index. This includes
DB2, Sybase, and Oracle.
18854: New property to skip check for history/history_s
The following property can now be specified to prevent the Historian from
attempting to create or modify the HISTORY and HISTORY_S tables
sl.rtview.historian.historyTableName=__none
(Note that the value __none begins with two underscores).
By default the Historian will create the HISTORY and HISTORY_S tables and,
depending on other properties, may periodically attempt to delete old rows from
those two tables. Since neither table is used in EM, it is convenient to prevent
the historian from attempting to create or modify those tables.
Data Sources
18737: Corrected extra rows in history_condensed table
In prior releases the history_condensed and history_combo tables of a cache with
the condenseRowsFlag = true would contain 2 rows per condense interval per index,
instead of 1 row as expected, if the cache's condenseRowsRawDataTimeSpan <
condenseRowsInterval * 3. This is fixed.
18820: Hawk DS now requesting for retransmitted alerts properly
In previous releases, there was a bug with requesting existing alerts after an
agent expired and then came back. This has been fixed.
Display Server
18694: Tooltips now accomodate quote and bracket characters
In prior releases, if an object's mouseOverText property was assigned to a string
containing a ', ", <, or > character, the thin client would not render the
tooltips properly and sometime extraneous text characters would appear on the
display. This is fixed.
Object Library
18712: Support animated GIFs in table cells in thin client
An animated gif image will work properly in the thin client if used in a cell
value in obj_table02. In previous releases, only the first frame of an animated
gif was displayed.
To avoid excessive CPU usage in the display server, the frame delay in all
animated gif images should be 50 msec or larger.
Note that animated gifs are still not supported in the builder/viewer, where the
animation is only updated every two seconds or after a mouse click. This is a
known limitation that is not addressed by this task.
18713: Support animated GIFs in some objects in thin client
The thin client has been enhanced to support animated gif images on obj_rect_il
(simple label object), obj_ind_limits (indicator object with 4 analog alert
limits) and obj_ind_multi (indicator object with multiple discrete alert values).
In prior releases, only the first frame of an animated gif would appear on these
objects.
A new property named imageAnimatedFlag has been added to each of these objects.
This property must be checked (set to true) in order for the animation to occur
in the thin client.
To avoid excessive CPU usage in the display server, the frame delay in all
animated gif images should be 50 msec or larger.
If the object's label string overlaps with the image, then in the thin client the
string will be obscured by the image. To avoid this limitation, set the
labelTextPosY property to Outside Top/Bottom or set the labelTextPosX property to
Left or Right.
For obj_ind_limits and obj_ind_multi, if the value string overlaps with the image
then in the thin client the string will be obscured by the image. To avoid this
limitation, set the valueTextPosY property to Outside Top/Bottom or set the
valueTextPosX property to Left or Right.
This feature is only supported in the thin client. In the builder/viewer, the
animation will only update once every two seconds or after a mouse event.
RTView Display Panel
18722: Panel can now be minimized by default in thin client
The rtvDisplayPanel tag in a PANELS.ini file now supports an attribute named
minimized. If this attribute is set to true, as in the north panel in the
following example, then the panel will initially be hidden in the thin client:
<?xml version="1.0" ?>
<panels xmlns="www.sl.com" version="1.0">
<rtvLayout title="Panel Example" dividers="true">
<rtvDisplayPanel region="north" minimized="true" display="title.rtv"/>
<rtvDisplayPanel region="center" name="main" display="test1.rtv"/>
</rtvLayout>
</panels>
The minimized attribute is only effective if dividers="true" is specified in the
rtvLayout tag, as in the above example. The minimized attribute only works in the
thin client, it is ignored in the Viewer.
A minimized panel can be made visible by clicking in the dark area in the center
of its divider bar.
Solution Package
GlassFish Application Server
18834: Corrections to database schema definitions for Server Info table
Two of the columns in the GFS_SERVERINFO table have been adjusted in the database
schemas under gfmon\dbconfig\*sql
"Server" - This column was removed, as there is no such column in the
GfsServerInfo cache that reads/writes to GFS_SERVERINFO
"uptime" - The datatype was incorrectly set as a VARCHAR. It has been changed to
BIGINT for all databases except for Oracle, which now has it set to NUMBER.
If your existing GFS_SERVERINFO table is functioning correctly there is no need
to make changes to it. The above changes were corrections, and do not reflect a
change in the structure of the data being stored.
IBM Websphere Application Server
18827: New database schema definitions
Previously the database schema definitions under wsm\dbconfig contained errors
that made them unuseable. These old files have been deprecated, and new files
have been provided.
Limitation:
The WAS_SERVERSTATS table contains two columns, freeMemory and FreeMemory, that
are not supported by the databases SQL Server and MySQL, due to case
insensitivity.
Oracle Coherence
18790: Cluster Selection display user experience improvements
The Oracle Coherence Cluster Selection display has been enhanced to provide a
more intuitive default sort order for each table.
18797: Readability enhancements to Cluster Views / Overview display
To provide a less cluttered appearance, some data fields on the Cluster Overview
display have been re-positioned.
Oracle Database
18702: More results now returned for table space utilization
Queries for table space utilization in oracle were limited to 100 rows (tables).
The limit has been raised to 1000.
18703: Corrected calculations in the RAC DB TableSpace Utilizations
The Database Summary screen displays a scrollable list of graphic objects
depicting oracle tablespace utilization. The "used tablespace", "free
tablespace", and allocated tablespace metrics were previously calculated from
different oracle admin views, and occasionally the results were inconsistent (ie,
total tablespace did not equal used plus free tablespace). The calculation
technique has been changed to yield consistent results.
Oracle Weblogic
18701: Fixed incorrect heap calculations
WlsServerMemoryUsageHigh alert has been fixed to calculate the heap used
percentage based on the heap free percentage.
18826: SQL definitions added for optional history tables
Database table schema definitions have been added for those history tables that
are disabled in the default configuration. Those tables are:
WLS_JMSCONNECTION
WLS_JMSCONSUMER
WLS_JMSDESTINATION
WLS_JMSDESTINATIONTOTALS
WLS_JMSDURABLESUBSCRIBER
TIBCO BusinessEvents
18606: Addition of CPU and memory metrics
%cpu used and heap memory used were added to the node summary displays for caches
and inference nodes, and to the node records displayed in the cluster table.
These metrics are supplied by the JVM data collected by the rtvmgr solution
package; hence rtvmgr should be enabled in your EM project is if isn't already .
(Look for the line "rtvapm_package=rtvmgr" in your rtview. properties.)
18676: TbeNodeConnectionLoss consistency between Windows and Linux
On Windows, the TbeNodeConnectionLoss alert triggers around one minute after a
JMX connection to a Tibco Business Events agent is lost. However, when running EM
on linux systems, the same alert triggers anywhere from 3.5 to 5 minutes after
the connection goes down.
This problem occurs because of the different TCP stack implementations for
Windows and Linux. By default, the Windows tcp stack sends out (at most) 3 SYN
packets when attempting to connect to a remote jmx port, with a delay of 3
seconds for the second SYN, and 6 for the third. But Linux sends out 6 SYN's per
attempt, with exponential backoff so that SYNs are separated by 1, 2, 4, 8, and
16 seconds. So, you can see that the time that windows will spend failing to
reconnect per attempt is 3+6=9 seconds, while for linux it is 1+2+4+8+16=31
seconds. Setting the following TCP tuning parameter will eliminate the behavioral
difference between Windows and Linux, so that alert timing is similar.
sysctl net.ipv4.tcp_syn_retries=2
TIBCO BusinessWorks
18622: Fixed incorrect engine data with two domains on same server
Previously BW Monitor would return an incorrect list of deployments if a user was
querying multiple domains on the same server. The list returned would show each
domain as having the deployments of both domains. This problem did not occur if
the user queried each domain separately.
This has been fixed, so that now the list returned will show the correct
deployments for each domain.
18717: Engines that are deployed but not active are now shown
If a BW server had engines deployed but none were active, BW Monitor would show
no engines at all for that server. This has been corrected.
TIBCO EMS
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).
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.
TIBCO Hawk
18649: New solution package TIBCO Hawk monitor (hawkmon)
The new hawkmon solution package displays cpu, process, disk, and network metrics
and alerts for hosts running Tibco Hawk, versions 4.8 and 4.9. When used with
Tibco Business Works monitoring (bwmon), hawkmon can supply metrics to enhance
bwmon displays. The datasource configuration used to specify hosts for bwmon will
work for hawkmon, so no additional configuration will be necessary for existing
bwmon customers.
By default, hawkmon collects CPU and memory statistics. Uncomment the following
lines in rtview.properties to collect disk, network, and/or process data. See
hawkmon's readme.txt for additional details.
#collector.sl.rtview.cache.config=hawk_host_process_cache_source.rtv
#collector.sl.rtview.cache.config=hawk_host_storage_cache_source.rtv
#collector.sl.rtview.cache.config=hawk_host_network_cache_source.rtv
VMWare vSphere
18666: EM Service Summary now drills down to correct VM host.
Double-clicking a virtual machine (VM) listed on the Service Summary Views ->
Service Summary screen should cause the VmWare Virtual Machine Summary screen to
show the metrics for the selected VM. This failed in the previous EM version
because a necessary index was not sent to the VmWare Virtual Machine Summary
screen. This was corrected by adding the index to the CITYPE_DEFS table in the
CMDB. Customers who manage their CMDB in Oracle or other third-party databases
will need to apply this correction manually.
SQL to correct CMDB:
DELETE FROM CITYPE_DEFS WHERE CITYPE = 'VMWARE-VM';
INSERT INTO CITYPE_DEFS
VALUES('VMWARE-VM','1;2;3;4','connName;name;managedObjectId;hostId','vmw_vm_summary','$vmwConnName;$vmwName;$vmwVmManagedObjectId;$vmwHostManagedObjectId',1,'Infrastructure','Servers','Hosts')
Version 1.3.1 Release Notes
Alerts
18583: RTView alert table displays enhanced
The alerts table displays have been enhanced.
Alert Views->RTView Alerts Table has been enhanced as follows:
1. An additional count has been added to Totals, Critical and Warning. The
previous count is the number to the left of the /. This number shows the number
of alerts in the table which is the number of alerts after all of the filters
have been applied. The new count is the number to the right. This shows the count
of alerts with only the CMDB and cleared filters applied. None of the other
filters are applied to these counts.
2. The popup menu has a new Alerts submenu that contains all of the actions that
can be performed on the currently selected alerts.
3. A new menu item, Set Filter Field, has been added to the Alerts submenu in the
popup menu. This will set the Field Filter and Search Text fields based on the
selected cell in the table. To clear the Field Filter and Search Text fields,
click on the Clear button to the right of the Field Filter field.
The alert table at the bottom of the following displays has also been enhanced:
Service Summary Views->Service By CI Type
Service Summary Views->Service Summary
Single Area Service Views->Services CI Type Summary
Multi Area Service Views->Services CI Type Summary
1. The popup menu has a new Alerts submenu that contains all of the actions that
can be performed on the currently selected alerts.
2. The popup menu has 3 new menu items in the Alerts submenu, Details, Options
and Annotate. These menu items do the same thing as the corresponding menu items
in the RTView Alerts Table.
3. Double-clicking on a row in the alert table will bring up the details display
for that alert.
4. The substitution set by the table for the ID columns has changed from
$multiplealertId to $multipleAlertIds. The substitution set by the table for the
Source column has changed from $multipleAlertSource to $multiplAlertSources. The
substitution set by the table for the CompID column has changed from
$multipleAlertCompIDs to $multipleCompIDs. This was done so that the
rtv_alerts_menu_include.rtv could be shared between rtv_alerts_table_common.rtv
and rtv_alerts_table.rtv. This change only impacts users who have customized
either rtv_alerts_table_common.rtv or rtv_alerts_table_menus_include.rtv. Users
who have customized rtv_alerts_table_common.rtv should use these new
substitutions when merging in their changes. Users who have customized the
rtv_alerts_table_menus_include.rtv should use these new substitutions in their
actionCommand definitions.
18687: Selected index now set correctly for multiple index types
The Tabular Alert Administration display's Index assignment functionality now
works as designed. A bug in the prior version made it occasionally difficult to
set certain Unassigned Indexes as overrides.
Enterprise RTView
Data Sources
18670: Gaps in extend-by-sql cache data attachment fixed
A bug has been fixed that caused time gaps to appear in data supplied a cache
attachment configured as follows:
Cache : MyCache
Table : history, or history_combo
Time Range : <any value larger than the time range of data available in the cache
table above>
Extend with SQL : on
Begin Time: <blank>
End Time: <blank>
Update Once: off (if Table = history)
Update : On Condense or Always (if Table = history_combo)
A cache attachment with that configuration will periodically update its
listeners, as new data is added to the cache history table. In prior releases, a
time gap would eventually appear between the most recent data retrieved by the
Extend with SQL query and the oldest data in the cache history table. This is
fixed.
18707: Enhance rowExpiredIndexColumns behavior in Mark+Delete mode
The row expiration feature of the cache data source has been enhanced to allow
the rowExpiredIndexColumns and the rowExpirationTimeForDelete properties to be
used in combination. If a cache is configured as follows ...
rowExpirationMode = 3 (Mark + Delete)
rowExpirationTime = -1
rowExpirationTimeForDelete = any value > 0
rowExpiredIndexColumns = any subset of the cache's index columns
... then if a row X exists in the cache's current table and that row's values in
the columns specified by the rowExpiredIndexColumns are not matched in the data
table applied to the cache's valueTable property, the row will be marked as
Expired. Subsequently, if row X is not updated again before the time specified by
the rowExpirationTimeForDelete property has elapsed then row X will be deleted
from the cache's current table.
Display Server
18689: Support updates to drillDownColumnSubs on table
The drillDownColumnSubs property of the table object (obj_table02) can be
attached to data. However, in previous releases the thin client only read that
property when the display was opened and ignored subsequent updates from the data
attachment. This has been fixed.
Platform Support
18746: Table index names shortened for Oracle and Sybase
The historian will now keep index names to 30 characters or less on Oracle and
Sybase to avoid "identifier is too long" errors from those databases.
Monitor
18610: Clear no longer removes all content from Alert History Table
In previous releases, the Clear button on the Alert History Table display removed
all rows from the Alert History Table when run in the thin client. This has been
fixed.
Solution Package
Oracle Coherence
17946: Single Service Summary Display now showing all data
The Cache Services > Single Service Summary display now correctly displays
historical data.
18434: Expiration now indicated for Nodes, Caches and Services
Previously, under certain circumstances the All Caches - Current Size Chart
display would display incorrect cache totals. This is no longer the case.
(Expired Cache nodes are not counted)
This has been achieved by implementing Expiry for Nodes, Caches and Services.
Expiry affects data elements, UI elements and configuration properties.
Expired Data items are represented by the addition of an Expired column in the
current table of a cache, where a row in the cache represents the entity in
question. For Expired entities Expired will be true. For currently active
entities (i.e. non expired) Expired will be false. Expired entities contain the
last known data for that entity.
Expired entities are indicated in the UI by a dark red color.
Expired entities may be shown in aggregates (Tables, Heatmaps) along with non
expired entities and individual Expired entities may be displayed on their own
displays that represent that entity.
Cells in heatmaps that indicate an expired entity will have this dark red color
and rows in data tables that represent an expired entity will have a dark red
background. Often the last column in the table will be the Expired column,
allowing for sorting/grouping of expired and non expired entities
Displays that represent an expired entity typically have a drop down selector
that selects a particular entity. Expired entities are represented by an appended
[X] at the end of the selector dropdown.
When an expired entity is selected the display background will be set to dark red
to reinforce that this is an expired entity. The display shows the last known
values for the entity where available.
Typically trend graphs will only show data up the point of expiry of the entity.
Expiry currently relies on the absence of previously available data during an
update. Some data is required for the update to succeed. Total absence of data
means there is no data to update.
Expiry behavior is controlled by properties. Previously the user could control
time base expiry. Expiry is now event based and must be configured correctly.
For new installs the defaults are set correctly and the user need not be
concerned.
Users migrating from a previous version, or using a properties file from a
previous version, need to take care that the following properties are not
redefined (so as to take the correct default values) or are explicitly set using
the the following values.
# Configure to detect expired entities in caches on update, and delete expired
entities after a finite time. By Default
# Expiry Mode
# 3 = Mark + Delete
# Mark Expired Entities. Delete Expired Entities.
#
# Known entities are Nodes, Caches and Cache Services at this point. Consider
what Entity a row in a configured cache represents
#
sl.rtview.sub=$ocmRowExpirationMode:3
#
# Detect Expired Entities, by absence, on update, rather than by (implicit
assumed) absence after minimum time-out since last updated.
# expiration time of -1 means use update mechanism rather than time mechanism.
#
sl.rtview.sub=$ocmRowExpirationTime:-1
Failure to do so may result in undesired behavior.
The user can still control when expired entities are deleted, and thus no longer
appear in displays, or are available for selection. By default expired entities
are deleted after 24 hours.
Users can override this setting if desired: thus
# Delete expired entities from caches a finite time after they expire.
# Can be used to limit the grown of configured current caches based on the rate
of growth/churn
# (Creation + Expiry of new entities with unique identifiers)
# By default set to 24 hours - ocmRowExpirationTimeForDelete (86400 = 24 hrs)
#
sl.rtview.sub=$ocmRowExpirationTimeForDelete:86400
18537: Alert indicators added to the overview screen.
A set of six alert indicator lights has been added to the Cluster Views /
Overview display. The lights indicate the aggregated status for Memory, Network,
Stability, Tasks, Data Quality and "Other" alerts. Green signifies no alert,
yellow signifies at least one warning, and red signifies at least one alarm level
alert.
Clicking within this area will display the Alert Detail Table for more specific
information on the alerts.
18651: SQL definitions added for optional history tables
Several changes have been made to the history table SQL schemas.
1) SQL table schema definitions have been added for those history tables that are
disabled in the default configuration. Those tables are:
OCMCACHESERVICESTATS_TABLE
OCMINVOCATIONSERVICESTATS_TABLE
OCMCACHESTATS_TABLE
OCMSTORAGESTATS_TABLE
OCMPROXYSERVICESTATS_TABLE
OCMPROXYSERVICETOTALS_TABLE
OCMEXTENDCONNECTIONS_TABLE
OCMJVMGCINFO_TABLE
OCMJVMMEMORYPOOL_TABLE
OCMJMXMGMTDATA_TABLE
Definitions have also been added for two legacy tables. These tables do not store
historical data, but errors may be thrown to the console if they are not found.
HISTORY
HISTORY_S
2) The max length for VARCHAR columns has been increased across all history
tables to 255. Users should not need to modify existing tables.
Version 1.3.0 Release Notes
Alerts
18357: Central and backend notifications implemented
Alert notifications in EM have been enhanced to support notifying in the central
alert server. In previous releases, alert notifications were executed in the
solution package data servers, but now notifications are done centrally. 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.notifiercommandfirstsevchange - 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\projects\emsample\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\projects\emsample\custom\make_classes.bat. This will build the
custom handlers and output them in
RTVAPM_HOME\projects\emsample\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%/projects/emsample/custom/lib/rtvapm_custom.jar. You can optionally
uncomment the sl.rtview.alert.notifiercommandfirstsevchange,
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 central alert server, add the following to the command line:
-properties:%RTVAPM_HOME%/common/conf/custom_handlers
Persistence
=========
In the previous release, notifications were executed on the backend server and
the standard alert persistence prevented duplicate notifications from executing
after restart or failover. Now that notifications occur in the central alert
server, you must enable persistence in the central alert server and also setup a
standard alert persistence table named ALERT_PERSIST_TABLE_CENTRAL and a
notification persistence table named ALERT_NOTIF_PERSIST_TABLE in your ALERTDEFS
database. The schema for the ALERT_NOTIF_PERSIST_TABLE is in
%RTVAPM_HOME%\common\dbconfig. To enable persistence, override this property in
projects\emsample\conf\emcommon.properties:
AlertAggregator.sl.rtview.alert.persistAlerts=true
The notifiercommandfirstsevchange notification is not persisted and will execute
the first time the severity changes on an unacknowledged alert each time the
alert server runs. This means you will get notification a notification the first
time it changes on a new alert, and again the first time it changes after the
central alert server is restarted or fails over.
Note that notification information is persisted to the ALERT_NOTIF_PERSIST_TABLE
for each notification that is executed. In order to optimize performance of the
central alert server, users should limit the number of columns specified in the
sl.rtview.alert.notifiercolumns property to the minimum number of necessary
columns, preferably less than 5. The more columns you notify on, the more
notifications will need to be written to the database.
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.notifiercommandfirstsevchange to the same value as
sl.rtview.notifiercommandnew and set the sl.rtview.alert.notifiercolumns property
to Severity<remove>. With this configuration, you will get a notification the
first time the Severity changes. If you want to be notified every time the
Severity changes, use the sl.rtview.alert.notifiercommandchanged property and set
sl.rtview.alert.notifiercolumns to Severity.
sl.rtview.alert.renotificationcommand - This property is no longer supported.
sl.rtview.alert.renotficationtime - 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.
18450: Alert Detail Table display has been refactored
The Alert Detail Table display has been refactored for optimization. Instead of
querying the alerts directly from the central alert server, those alerts are now
cached locally. This means a new cache needs to be loaded into the Viewer and
Thin Client applications:
rtv_alerts_cache_local.rtv
This is included in appmon\conf\appmon.properties for all applications that use
the AlertClient or AlertCollector property filters:
# Local cache of RtvAlertTable
AlertClient.sl.rtview.cache.config=rtv_alert_cache_local.rtv
# This is needed to support appmon1 mode
AlertAggregator.sl.rtview.cache.config=rtv_alert_cache_local.rtv
If your Viewer or Thin Client application uses the RTView Alerts Table display
and does not use one of those property filters, you will need to add this cache
in your properties file.
Also, some of the columns in the alert table have been modified. The Last
Occurrence column is now named Last Update Time and the Source2 column has been
removed. This will have no impact on the built-in displays, but users that have
customized the rtv_alerts_table display from previous versions will need to apply
their changes to the new version of the rtv_alerts_table instead of using the
customized version from a previous release.
18555: rtv_alert_manage.rtv buttons incorrect for number of alerts
In previous releases, the rtv_alerts_manage display that comes up from the
Annotate button in the Alert Detail Table showed the buttons for a single
selected alert, even when multiple alerts were selected. This has been fixed.
18564: Dual alerts display
The RTView Alerts Table display has been enhanced to include an optional second
table. This table shows all of the open (not cleared) alerts owned by the logged
in user. The filters selected in the display will not apply to this table. By
default, this table is hidden. To show this table, add the following line to the
rtview.properties file in the directory where you run the Viewer or Display
Server:
sl.rtview.sub=$rtvUserShowDualTables:1
This property was added to emsample\servers\central\rtview.properties, but
commented out.
This can be set on a per-user or per-role basis if the RTView login is enabled
and custom users or roles have been defined. See the documentation for
information on how to define substitution values for custom users and roles
18565: On tabular alert administration page, move back to alerts button
To afford quicker access, the "Back to Alerts" button has been moved from the
Tabular Alert display's upper left corner to its lower right corner.
18599: Alert engine status indicator added to alert table
The alert tables in EM have been enhanced to show the state of the alert engine
that is hosting the alert. If the alert engine that is hosting the alert is not
connected, not enabled or not initialized, the background of the row will turn
gray. The Own, Suppress, Unsuppress, Close, Annotate, Options and Details buttons
will also become disabled when this row is selected.
Customization
18465: Allow custom filters to be added to the Alert table
EM has been enhanced to support custom alert filters. This new feature allows
users to setup named filters with values for each of the filters that are
supported in the RTView Alert Table display (rtv_alerts_table.rtv). These filters
are defined in a new table named CUSTOM_ALERT_FILTERS in the ALERTDEFS database
which contains the following columns, all of type String:
User
Key
rtvAlertDynFilter
rtvAlertDynTextFilter
rtvAlertDynTextFilterRegEx
rtvClearedFilter
rtvAckFilter
ownerFilter
rtvWarningFilter
rtvCriticalFilter
rtvOwnerLoc
rtvAreaLoc
rtvGroupLoc
rtvServiceLoc
rtvEnvironmentLoc
Users upgrading from previous versions must add this table to their ALERTDEFS
database. See the schemas in RTVAPM_HOME\common\dbconfig for the correct schema
to use for your database. This table has also been added to the database in
emsample.
The custom filters are defined per user. To add custom filters, add rows to the
database with the following values:
User - The name of the user who can use this filter. This must correspond to the
value specified for the User in the RTView login.
Key - The name of the filter. This value will be used in the Custom Filters combo
box.
rtvAlertDynFilter - The name of a column in the Alert Table to filter on. This
corresponds to the value in the Field Filter combo box in the display. This must
be the actual column name, which is sometimes different than the displayed column
name. Valid values are blank, Time, Last Update Time, Count, ID, Cleared,
Acknowledged, Owner, Alert Name, Primary Service, CIName, CIType, Alert Index,
Alert Text, Severity, Source, Cleared Reason, AlertClass, CompID, TicketID,
TicketGroup and any other custom columns you have added to the alert table. A
blank value indicates this filter should not be used. Note that if you specified
a column list as described in task 18467, the list of valid values is limited to
the values in the specified column list.
rtvAlertDynTextFilter - The value that the column in the rtvAlertDynFilter must
equal. This corresponds to the Search Text field in the display.
rtvAlertDynTextFilterRegEx: 1 to use Regex for the
rtvAlertDynFilter/rtvAlertDynTextFilter filter, 0 otherwise. This corresponds to
the RegEx checkbox in the display.
rtvClearedFilter - Filter on the Cleared column. This corresponds to the
All/Open/Closed radio buttons in the display. Valid values are *, which will show
both, false which will show only open alerts and true which will show only closed
alerts.
rtvAckFilter - Filter on the Suppressed column. This corresponds to the
Suppressed checkbox in the display. Valid values are *, which will show both, and
false which will show only unsuppressed alerts.
ownerFilter - Filter on the Owner column. This corresponds to the Owner Filter
combo box in the display. Valid values are *, which will show all, blank which
will show alerts that are not owned, and the logged in user name which
corresponds to the Owned by Me combo box item.
rtvWarningFilter - Filter on Severity = 1 (warning alerts). Valid values are
blank, which doesn't show warning alerts or 1 which does show warning alerts.
rtvCriticalFilter - Filter on Severity = 2 or 3 (critical alerts). Valid values
are blank, which doesn't show critical alerts or 2,3 which does show critical
alerts.
rtvOwnerLoc - Filter on the CMDB owner. This corresponds to the Owner value in
the CMDB Filter field. Valid values are any owner in your CMDB or * if you do not
want to filter by CMDB owner.
rtvAreaLoc - Filter on the CMDB area. This corresponds to the Area value in the
CMDB Filter field. Valid values are any owner in your CMDB or * if you do not
want to filter by CMDB area.
rtvGroupLoc - Filter on the CMDB group. This corresponds to the Group value in
the CMDB Filter field. Valid values are any owner in your CMDB or * if you do not
want to filter by CMDB group.
rtvServiceLoc - Filter on the CMDB servic. This corresponds to the Service value
in the CMDB Filter field. Valid values are any owner in your CMDB or * if you do
not want to filter by CMDB service.
rtvEnvironmentLoc - Filter on the CMDB environment. This corresponds to the
Environment value in the CMDB Filter field. Valid values are any owner in your
CMDB or * if you do not want to filter by CMDB environment.
The Custom Filters combo box will only show up in the Alert Detail Table display
if there are custom alerts defined for the logged in user. This combo box will
contain all of the Key values specified for that user. When a value is selected
from the combo box, that filter will be applied to the display. The corresponding
filter fields will show the applied value and the filter will be applied to the
table. If any of the filter fields is then changed such that the filter no longer
matches the selected custom filter, the Custom Filter value will be cleared.
18467: Allow users to specify alert table columns
RTView EM has been enhanced to allow you to specify which columns will be
displayed in the RTView Alerts tables. This impacts the tables in the following
displays and any custom displays that include rtv_alerts_table_common.rtv:
rtv_alerts_table.rtv (Alert Views->RTView Alerts Table)
rtv_service_citype_summary.rtv (Service Summary Views->Service By CI Type)
rtv_service_summary.rtv (Service Summary Views->Service Summary)
rtv_allareas_allservices_citype_summary.rtv (Multi Area Service Views->Services
CI Type Summary)
rtv_area_allservices_citype_summary.rtv (Single Area Service Views->Services CI
Type Summary - not included in the default navigation tree)
By default, the alert table includes the following columns in the following
order:
Time (Column Label = First Occ)
Last Update Time (Column Label = Last Occ)
Count
ID (hidden by default)
Cleared (Column Label=Closed, hidden by default)
Cleared Reason (Column Label=Closed Reason, hidden by default)
Acknowledged (Column Label=Sup)
Owner
Alert Name
PrimaryService (Column Label=Primary Service)
CIName (Column Label=CI)
Alert Text
AlertClass
CompID
TicketID
TicketGroup
You can override the default columns by adding the following property to the
properties file used by your viewer application:
sl.rtview.sub=$rtvUserAlertTableColumns:'Time:94 Last Update Time:93 Count:50
ID:50 Cleared:40 Cleared Reason:85 Acknowledged:40 Owner:70 Alert Name:134
PrimaryService:150 CIName:117 Alert Text:1000 AlertClass:83 CompID:75 TicketID:69
TicketGroup:86'
Replace everything after the "$rtvUserAlertTableColumns:" with the column names
and column widths in the order that you want to see the columns. The above
example will configure the tables to display the default columns. The value after
"$rtvUserAlertTableColumns:" must be enclosed in single quotes and use the
following syntax:
'colName:colWidth colName2:colWidth2'
Valid column names are Time, Last Update Time, Count, ID, Cleared, Cleared
Reason, Acknowledged, Owner, Alert Name, PrimaryService, CIName, CIType, Alert
Index, Alert Text, Severity, Source, AlertClass, CompID, TicketID, TicketGroup
and any other custom columns you have added to the alert table.
The ID, Cleared and Cleared Reason columns are always included, but are hidden by
default. To show them, add the following properties to the properties file used
by your viewer application:
# Show the Closed column in the alert table if set to 1, hide it if set to 0
sl.rtview.sub=$rtvUserShowCleared:1
# Show the Closed Reason column in the alert table if set to 1, hide it if set to
0
sl.rtview.sub=$rtvUserShowClearedReason:1
# Show the ID column in the alert table if set to 1, hide it if set to 0
sl.rtview.sub=$rtvUserShowId:1
If they are included in the $rtvUserAlertTableColumns, they will be shown in the
table in the position specified. Otherwise they will be shown after the columns
specified in $rtvUserAlertTableColumns. In rtv_alerts_table.rtv ((Alert
Views->RTView Alerts Table), you can also toggle the visibility of these columns
using the checkboxes at the bottom of the display.
The values in $rtvUserAlertTableColumns are also used to populate the Field
Filter combo box in the rtv_alerts_table.rtv (Alert Views->RTView Alerts Table).
The Field Filter also always contains the ID, Closed and Closed Reason columns
whether or not those columns are visible.
By default, the alert tables are sorted by the Time column in descending order to
show new alerts first. You can override the sort column and whether to sort
ascending or descending by including the following in the properties file used by
your viewer application:
# Set this to the name of the column on which to sort.
sl.rtview.sub=$rtvUserAlertTableSortColumn:Time
# Set this to 1 to sort ascending or 0 to sort descending
sl.rtview.sub=$rtvUserAlertTableSortAsc:0
You can also change the sort column in the display by clicking on the header of
the column you want to sort on.
Examples of all of these properties are included in the emsample demo in
%RTVAPM_HOME%\projects\emsample\servers\central\rtview.properties.
All of the above substitutions can be set on a per-user or per-role basis if the
RTView login is enabled and custom users or roles are defined. See the
documentation for information on how to define substitution values for custom
users and roles
Deployment
18468: Support Dual write in Distributed Alert Server deployments
The Own, Suppress, Unsuppress, and Close buttons on the EM alerts displays have
been enhanced to support dual write. It is disabled by default. To enable dual
write, include the following property in the properties file for the Viewer or
Display Server (in projects\emsample, this is the
emsample\servers\central\rtview.properties file):
sl.rtview.sub=$rtvUserEnableAlertDualWrite:1
When one of these buttons is clicked, it executes the associated command on the
selected alerts in the data server(s) that are hosting the selected alerts. There
is sometimes a delay in seeing the result of the action in the alert table. This
is because the command goes to the data server hosting the alert, that server
updates the alert then pushes the updated alert data to the central alert server,
then the central alert server pushes the updated alert data to the client hosting
the display. This may be slow in deployments where the data server hosting the
alerts are not on the same system where the central alert server and client are
running.
When dual write is disabled (default), the display updates as described above.
When dual write is enabled, the action is applied directly to the alert cache in
the central alert server before the action is executed on the data server that is
hosting the alert. This reduces the delay between executing the action and seeing
the result in the alert table, however it will cause the data in the alert table
to be temporarily out of sync with the real alert data. There are several
limitations to this feature which must be considered before using it.
The following limitations apply when dual write is enabled:
1. If an alert is cleared, clicking on Suppress or Unsuppress will update the
central alert server cache, but not the actual alert. The suppressed state of an
alert cannot change after the alert is cleared.
2. Clicking on the Close button will immediately update the Cleared value in the
alert table, but the Cleared Reason value will not update until the server
hosting the alert closes the alert and sends an update.
3. If the server hosting the alert sends an update between the time you click on
one of the buttons listed and the time that server processes the associated
action, the value in the table will toggle between the new value, and the old
value. For example, you select an alert and Suppress it. At the same time, the
alert severity changes in the backend server. The table will initially update
with old severity with Sup set to true, then it will update with the new severity
with Sup set to false, then it will update with the new severity with Sup set to
true. If you have configured the central alert server to notify when the Sup
column changes, you will receive notifications for all 3 of these changes (true,
false, true).
4. If the server hosting the selected alert is not connected or not enabled when
you click Own, Suppress, Unsuppress or Close, the value in the alert table will
update, but this value will not be applied to the real alert. When the server
hosting the alert connects again, the value will revert to the previous value.
This is not likely to occur because the Own, Suppress, Unsuppress and Close
buttons are disabled with the server hosting the selected alert is not connected
or is not enabled. However, it is possible that you perform the action just as
the server hosting the alert is exiting before the buttons are disabled.
18631: EM .sql files out of sync
Reviewed
Enterprise RTView
Builder
18513: Icon Properties dialog requires Apply or you lose data
A problem has been fixed in the Builder which required the user to click Apply
before closing the Icon Properties dialog after configuring a object grid with
Icon Class Name = obj_composite and changing the rtvName property value. If the
user simply clicked OK in that case, the changes were lost.
18514: Cannot display data for attachment with blank data server sub
A bug has been fixed in the Builder which caused the Display Data dialog to show
no data, when a data attachment was selected whose Data Server field was assigned
to a substitution whose value was an empty string.
Data Sources
18535: add option to not try ODBC connection for undefined database
In all prior releases, if an sql query or command is executed that references a
database name XYZ and there is no definition of XYZ in OPTIONS.ini then RTView
attempts to establish an ODBC connection to XYZ. In this release a new
coomand-line option has been added to change this behavior:
-sqltryodbc:false
The option can also be specified in OPTIONS.ini:
sqltryodbc false
or in a properties file:
sl.rtview.sql.sqltryodbc=false
If this option is specified and an sql query or command is executed that uses
database XYZ and there is no definition of XYZ in OPTIONS.ini, then no ODBC
connection attempt will be made and instead the following error message will
appear in the console:
Undefined SQL database XYZ
This option is useful in cases where ODBC connection attempts cause a JVM crash,
which has been reported in some JVM versions.
Note that RTView will still make an ODBC connection if a database has the "Use
ODBC Driver" option checked in the SQL tab of the options dialog, even if the
-sqltryodbc:false is specified.
18563: improve perf when incoming data not in time order
The performance of the cache data source has been improved in the case where a
cache is configured to keep a history table and the cache's timestamp column is
contained in the data tables that are applied to the cache (rather than being
added by the cache itself) but the values in that timestamp column are not always
in ascending time order in the incoming data tables. The performance improvement
is most noticeable when the history table is large, the cache's
allowDuplicatesInHistoryFlag property is set to false, and new data is applied to
the cache frequently.
18616: synchronization bug when multi-threading is enabled
In the previous release, if the JMX option to Use Multile Threads for Commands
and Polled Queries was enabled, a synchronization problem caused data attachments
to multiple connections to miss some updates and duplicate others. This has been
fixed.
Drill Down
18516: Cannot edit drilldowns with data attachments to functions/vars
A bug in the Builder's Drill Down Properties dialog has been fixed that prevented
changes made to existing data attachments from being saved when the user clicked
OK.
Functions
18540: Replace function should allow replace with empty string
The eval function replace function should allow an empty string as the second
argument, to permit the removal of a character, but in fact this caused an error:
Evaluating expression "replace(%str, " ", "")": One string argument and two
character arguments are required.
This has been corrected.
18569: enhance Set Subs By Lookup to add $ to column names
The Set Substitutions by Lookup function has been enhanced with a new argument,
Add Dollar To Column Names. By default, the value is 0 and the function behaves
as it did before.
If Add Dollar To Column Names is set to 1, each column after the Key column is
used to set a substitution regardless of whether or not it starts with $. For
columns that do not start with $, a $ is added to the beginning of the column
name when it is used as a substitution name.
18589: Combine Multi-Server Tables now keep data after server restart
In previous releases, the table returned by the "Combine Multi-Server Tables"
function was cleared when it received the first update from a reconnecting data
server, so the table was missing the rows from all the other servers until each
of those servers sent another update. This problem has been fixed.
General
18581: cache history query not run if no cache props attached to data
A bug has been fixed that prevented the initial sql query from being run to fill
cache history tables in some configurations. The problem occurred if a cache was
configured with constant values for all of its properties and either the cache
had no current data or the current data was provided indirectly by a Store Table
in Cache function rather than a data attachment on the cache's valueTable
property.
Object Library
18545: New drilldown select mode to update ddColumnSubs at data update
The drillDownSelectMode property on obj_table02 now supports a new mode of 2
(Element Only + Auto Update) in addition to the existing modes of 0 (Anywhere)
and 1 (Element Only). When drillDownSelectMode is set to 2 the table's command is
performed automatically when the row selection changes after a data update.
The new mode is available only if the table's command property is configured to
perform a drilldown to the current display in the current window, and if the
table's indexColumns property is set to a nonempty string.
The new mode is useful in cases where the substitutions set by the table's
drilldown command need to be updated if some of the selected rows in the table
are removed by a subsequent data update.
18546: Support deselecting all rows in a table
The table object (obj_table02) now supports a property named clearSelection. When
the property is set to a value of 1, all rows in the table are deselected. When
the property is set to a value of 2, all rows are deselected and the table's
action or its drillDownTarget are invoked.
Typically, a table's clearSelection property would be attached to a local
variable that is set by a control object on the same display.
For example, say you want a to add a Clear Selection button to a display that
contains a table that supports multiple row selection. This could be configured
as follows:
1. Add a local variable named $clearSelection with an initial value of 0.
2. Create a button object, with these property values:
label : "Clear Selection"
valueToSet : 1
varToSet : <attached to the $clearSelection variable>
3. Set these table object's properties:
clearSelection : <attached to the $clearSelection variable>
4. If the table object has a drilldown command, or a drillDownTarget, add this to
its Drill Down Substitutions:
$clearSelection : 0
The last step is required to reset value of the $clearSelection variable to zero
when the user selects a row in the table.
18554: New option to not display newlines in row data
The table object (obj_table02) has been enhanced to support removing line breaks
from the text displayed in the table cells. To enable this feature, turn on the
removeLineBreaksFlag property in the Data Format category.
This option will only remove line breaks from the table cell, not from the drill
down values. For example, if you have your drillDownColumnSubs setup to set a
substitution from a cell with a line break, the substitution value will contain
the line break regardless of the removeLineBreaksFlag. This works correctly in
the Viewer Application.
In the Thin Client, the drill down substitution will not contain the line break
if the removeLineBreaksFlag is set. See the PAL for 18582 for more information.
Logging
18379: Change the default configuration for EM to use log4j
A new enhancement has been added to easily set log4j as the default log engine.
To set log4j as the default log engine:
1. Edit rtvapm/common/conf/rtvapm.properties and
rtvapm/projects/emsample/servers/central/central.properties files and uncomment
the following lines in both files:
#sl.rtview.cmd_line=-logfile:
#sl.rtview.cmd_line=-logdir:
#sl.rtview.jvm=-Dcom.sl.rtview.useLog4j=true
2. On Unix, comment out the command line for Windows:
#sl.rtview.cmd_line=-log4jprops:%RTVAPM_HOME%/common/conf/sl.log4j.properties
and uncomment the command line for Unix:
sl.rtview.cmd_line=-log4jprops:$RTVAPM_HOME/common/conf/sl.log4j.properties
Monitor
18044: Add one more level to heatmap label depth
A Service Names checkbox has been added to the Group/Region Heatmap display to
allow the Service labels to be shown.
18566: Services CI Summary displays duplicate rows if CI's are not sort
A bug has been fixed where the Service Health By CI Type display was creating
multiple rows for the same Service under certain conditions. Now it groups all
data into Services correctly, generating just one row per Service.
18592: Add "All CI Types" button to Services CI Type Summary display
An "All CIs" button has been added to permit drilldown to Service Summary display
with all CITypes selected.
Previously the only way to drill down to Services Summary was by selecting one
CIType.
In practical usage, you often want to drill down and have all CITypes shown -
this button provides that pathway.
CMDB Editor
18446: CI name of a component of a Service shouldn't be * never
Fixed error of allowing the creation of a Service with * as the CI Name.
Solution Package
Amazon CloudWatch
18387: acwmon heatmap needs anchoring
This task fixes a cosmetic display defect. The log and label controls for the
acwmon heatmap were not anchored to the upper left corner of the window, so they
moved around and obscured other display elements when the page was resized. These
controls now remain stationary as display is resized.
IBM Websphere MQ
18520: MQ-BROKER and MQ-QUEUE CI Types added
Two new CI Types have been defined for the MQMON package: MQ-BROKER and MQ-QUEUE.
Now MQ Brokers and Queues can be added to the CMDB database and alerts associated
to MQ Queues will be propagated into the EM heatmaps. Currently there are no
default alerts related to QM Brokers.
Oracle Coherence
18297: New alert CacheQueueSize
The alert OcCacheQueueSizeHigh has been added to trigger when the CacheQueueSize
for ALL nodes exceeds a threshold.
18298: New alert OcSendQueueSize
The OcSendQueueSize alert has been added to inform the user when a Send Queue
exceeds a given threshold.
18322: Add Days of Data on startup..
The new substitution variable $ocmHistoryTimeSpan has been added to
rtview.properties to allow the user to set the number of days of history data
that is loaded at startup. The value to be set is based in seconds with the
default being 1296000 (15 days).
18407: Support new EM alert notifier
Alert notifications in OC 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\ocmon\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\ocmon\sample\custom\make_classes.bat. This will build the
custom handlers and output them in
RTVAPM_HOME\ocmon\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%/ocmon/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.
18426: Provide Cluster selection in EM deployments
Cluster Selection display added to Oracle Coherence section of EM Nav tree.
A new Cluster Selection display has been added to Oracle Coherence section of EM
Nav tree. This allows the user to browse between multiple coherence clusters when
EM has been configured to use multiple OCM dataservers.
18435: Values in 'Delta' column missing commas
Delta columns in All Caches - Current Activity Table display are now formatted
with "," thousands separator
The Delta Columns in the "Totals For Each Cache over all Storage Nodes" table in
the "All Caches - Current Activity Table" display are now formatted with ","
thousands separator like the non delta numeric columns.
Additional Delta Columns that are now formatted with "," thousands separator like
the non delta numeric columns, can be found in the following displays:
"Single Cache - Cache Detail Tables" display
Bottom Table labeled "Statistics By Node for Selected Cache"
"Proxy / Extend Detail" display
Bottom Table labeled "Extend Client Connections"
18436: Proxy Service CPU % now displayed correctly
Previously, the Proxy Service CPU % may have been displayed incorrectly in
various Proxy Services displays. This is no longer the case.
18475: Add Nacks to History and the Node History Heatmap.
To aid in troubleshooting communication errors, the data points "Delta Nacks
Sent" and "Rates Nacks Sent" have been added to the Node History heatmap display.
Both appear in the Metric drop-down list, and both have been added to the
tooltips for both heatmaps (Process and Storage Nodes) on that display.
18476: TCMP additional Data.
New Columns added to the OcNodeStats Cache and Database Table
New columns that reflect the state of TCMP traffic on a per node basis have been
added to the the OcNodeStats Cache and persisted to the corresponding Database
Table (OCM_NODESTATS) to enable historical analysis. The Columns contain Delta
and Rate information obtained from the raw (incrementing) count value. The new
columns are DeltaNackSent, DeltaPacketsResentEarly, DeltaPacketsResentExcess,
RateNackSent, RatePacketsResentEarly, RatePacketsResentExcess.
18490: Departed Nodes not correctly being displayed
The Departed Nodes indicator on the Cluster Overview display, and the Departed
Nodes table on the Cluster Stability Metrics display, were inaccurate in their
reporting of departed nodes. This has now been fixed, and required a change to
the ocmRowExpirationTimeForDelete property in the rtview.properties file. This
property is now set to 86400, which allows the OCMonitor to wait 24 hours before
removing records of expired nodes.
18492: New alerts for Cache status
Two new alerts, OcEndangeredCache and OcNodeSafeCacheTwo, have been added to
allow for notification when StatusHA values become NODE-SAFE and ENDANGERED.
18541: Add new alerts to show the # of nodes falling below a threshold
Three new alerts have been added to trigger when node counts dip below their
respective thresholds: OcLowTotalNodeCount, OcLowStorageNodeCount,
OcLowClientNodeCount. The three alerts are disabled by default.
Oracle Database
18456: History now displayed correctly for all trend charts
The "read-thru" cache access to historical data was misconfigured for oramon
historical data, with the result that history displays were limited to data
currently residing in the cache. This has been corrected so that history plots
now scroll smoothly back in time to show all available data.
Oracle Weblogic
18568: Missing table: WLS_SERVERTOTALSBYCLUSTER
See RN of TN18570.
18570: Database schema updates
The sql schemae for table creation have been updated to account for the latest
changes on cache configuration. All strings have been expanded to 255 chars size.
TIBCO BusinessEvents
18495: BE process not showing up properly
The BE Clusters Table now shows all configured BE connections, even when the BE
node (process) is not running. The previous display behavior was no entries in
the table for nodes that were down when EM starts. This change ensures that you
see problems independently of when EM starts.
TIBCO BusinessWorks
18406: Integrate new EM alert notifier
Alert notifications in BW 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\bwmon\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\bwmon\sample\custom\make_classes.bat. This will build the
custom handlers and output them in
RTVAPM_HOME\bwmon\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%/bwmon/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.
TIBCO EMS
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.
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
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.
Version 1.2.5 Release Notes
Enterprise RTView
Alerts
18553: Custom object properties and event attributes are now restored
In previous releases, persisted custom event attributes and alert object
properties were not restored correctly. This has been fixed.
18577: Timing problem with persisting disabled state during terminate
After the addition of task 18308, the alert engine sometimes incorrectly
persisted the alert engine state as disabled during terminate or fail-over. This
has been fixed.
Functions
18591: Last table rows function returns incorrect value, may deadlock
In 6.2.0 the Last Table Rows function returned an extra row if the Index Column
Names argument was blank. If the function was used in certain cache
configurations, it could also deadlock. Both problems are fixed.
18602: Mark Time Gaps func throws array bounds exception.
A bug in 6.2.0 has been fixed that caused the Mark Time Gaps function to throw an
ArrayOutOfBoundsException if a time gap was found in an integer data column.
Platform Support
18587: Support for Solaris 10
On Solaris 10, certain executable scripts need to be modified to use the bash
shell. This will now be done automatically by fixperms.sh. In this case the
script will print:
fixperms.sh: modify the following scripts to use 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
fixperms.sh: done.
Version 1.2.4 Release Notes
Configuration
18471: Clarify database configuration
Updated dbconfig schemas to minimize the need to edit the files.
Distribution
18209: Enhance fixperms.sh to avoid dos2unix issues
The script fixperms.sh would fail if dos2unix was not found or if it was found
but expected more than one argument. This has been fixed.
RTView Core
Data Sources
18441: Queue browser fix when msgs have inconsistent props or fields
In previous releases, data attachments to the Queue Browser would throw an
exception and fail to return data if all of the messages in the queue did not use
the exact same properties and fields. This has been fixed.
Layouts
18409: Enhanced anchor property to support anchor objects
The anchor property has been enhanced to support anchoring to anchor objects and
also to supporting floating within the extent of anchor objects.
The anchor property is applied when the window containing the display is resized
only if the Resize Mode is set to Layout. The Resize Mode is set in the
Background Properties dialog. It is also applied to objects in the composite
display when a composite is resized and its resizeMode is set to Layout.
Otherwise, this property is ignored.
By default, objects are not anchored and they float within the extent of the
display. For example, if the display is 100 pixels wide and objX is 50, when you
resize the display to be 200 pixels wide, the object's objX will move to 100. You
can also select an anchor object to float inside. In this case, the object will
float within the specified anchor object maintaining its relative position within
the anchor object's extent. The object's center must be inside the anchor
object's extent and the list of available anchor objects in the Float Inside list
in the Anchor Property Dialog is limited to the anchor objects with extents that
contain this object's center point.
When an object is anchored, you may select an anchor for the top, bottom, left
and right sides of the object. If you select Display, that side of the object
will be anchored to the corresponding side of the display. When the display
resizes, the number of pixels between the specified side of the object and that
side of the display remain constant. If an object is anchored on opposite sides
(ie. Top and Bottom or Left and Right), the object will be stretched to fill the
available space. If you select an anchor object, that side of the object will be
anchored to the center of the specified anchor object. When the display resizes,
the number of pixels between the specified side of the object and the center of
the anchor object remain constant.
Only objects that support the objWidth and objHeight properties support anchoring
on opposite sides. If an object has the dock property set, the anchor property is
ignored.
Circular anchor references are not allowed. An object cannot anchor to itself
directly or indirectly.
To make an object available for use as an anchor object, select the
isAnchorObject property for that object. When Anchor Property Dialog is open, all
of the available anchor objects in the display will show a tooltip displaying
their name.
Since an anchor object is referenced by name when anchoring to an object or
floating inside an anchor object, you must not have multiple anchor objects with
the same name. This could potentially happen when using include files. This can
be avoided by assigning a unique value to the objName property of objects in an
include file. For example, you might append "_Header" to the name of each object
when
building an include file named Header.rtv.
Solution Package
TIBCO BusinessWorks
17735: Show Business Works Version in Engine Display
The All BW Servers table and All BW Engines table have been enhanced with the
addition of a column showing the version of TIBCO BusinessWorks in use on each BW
server.
18130: 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:
bwmon ./bwmon dataserver rundata
bwmon ./bwmon historian runhist -ds
bwmon ./bwmon displayserver rundisp -ds
bwmon2 ./bwmon2 dataserver rundata
bwmon2 ./bwmon2 historian runhist -ds
bwmon2 ./bwmon2 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 ./bwmon dataserver rundata
desktop ./bwmon historian runhist -ds
desktop ./bwmon viewer runv -ds
browser ./bwmon dataserver rundata
browser ./bwmon historian runhist -ds
browser ./bwmon 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.
18460: UPTIME value mismatch in displays
The values for BW Engine Uptime displayed in the All Engines table were
incorrectly formatted, and were inconsistent with the (correct) values on the
Engine Summary page. This has been fixed.
18473: 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
TIBCO EMS
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
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.
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.
18369: EmsServerStaleData alert fixed
The EmsServerStaleData alert now works as intended; it fires for active servers
but does not trigger for fault-tolerant servers
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
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.
VMWare vSphere
18458: drill-down to VM summary from All VMs table is broken
In previous release, some upgrades to the All VM's tabular display broke
drill-down from a selected table row to the summary description for the selected
VM. This has been fixed, so that it is no longer necessary to re-select the VM
via the combo control.
Version 1.2.3 Release Notes
Configuration
18415: OCMON added as dataserver to emsample
OCMON has been added as a dataserver to the emsample directory.
The example OCMON dataserver is defined as a dataserver named OCMON-LOCAL as
configured in the emsample/servers/central/central.properties file
The example OCMON dataserver is not enabled by default .
The example OCMON dataserver is not configured (to connect to a coherence
cluster) by default .
To configure the OCMON dataserver (to connect to a coherence cluster) you will
have to edit the emsample/servers/ocmon/rtview.properties file
The example OCMON dataserver has the config "ocmon" as defined in the
emsample/servers/rtvservers.dat file
To enable the example OCMON dataserver (for use with start_rtv) you will have to
uncomment the ocmon dataserver line in the emsample/servers/rtvservers.dat file
e.g.
before:
#ocmon ./ocmon dataserver rundata -propfilter:maincollector
after:
ocmon ./ocmon dataserver rundata -propfilter:maincollector
You will then be able to start the ocmon dataserver in emsample,
implicitly , by using the "all" config
e.g.
start_rtv all
or explicitly
e.g
start_rtv ocmon dataserver
Monitor
18392: Added WLS-CLUSTER and WLS-CLUSTAPP to emsample
Two new CI Types, WLS-CLUSTER and WLS-CLUSTERAPP
have been added to the rtvapm\projects\emsample RTVCONFIG database
(DATA/rtvconfig.script).
Now WebLogic Clusters and WebLogic clustered applications will be selectable from
the CI table of the CMDB Admin display under their CI Type selector.
Solution Package
Oracle Coherence
17248: ObjectCountDelta*Cache now only triggers for back of near-cache
Both the ObjectCountDeltaUpCache and ObjectCountDeltaDownCache alerts have been
modified to ensure that no alerts are generated due to object count changes in
the front of the near cache. Alerts will only reflect activity in the back
portion of a near cache.
17399: History Heatmap for Extend Connections
A History Heatmap has been added that allows for the selection of a proxy node
and exposes the Extend Client information. It can be navigated to via Proxy
Services / Extend Connections History
17931: Supress unwanted error messages in dataserver logs
Spurious ERROR message no longer occurs
Previously, under certain circumstances the
proxyServiceConnectionManagerData3_RTDelta function would generate ERROR messages
regarding invalid columns. This is no longer the case.
17968: Provide new metrics for the All Node History heatmap
Two new metrics have been added to the All Nodes History Heatmap display. These
are: DeltaPacketsSent and DeltaPacketsReceived.
17969: Provide new metrics in the All Caches History display
Five new metrics have been added to the All Caches History Heatmap display. These
are:
StoreFailures (Delta)
StoreReads (Delta)
StoreReadMillis (Delta)
StoreWrites (Delta)
StoreWritesMillis (Delta)
17988: Integrate OCM alerts into the EM framework
The existing set of OCM alerts has been updated to work within the new EM
framework.
18014: Integrate OCM custom functions into RTView EM
OCM custom functions are available in EM CSP ocmon.
The OCM custom functions are available in the EM CSP ocm by use of the package
ocmon and the jar file rtvapm_ocmon.jar
18051: All Caches current size display obscures conn OK light
An indicator light was obscured by a button on the Current Size display. The
button has been moved so that the indicator light is now visible.
18165: Cache Summary - Add Delta/Rate Selection
Delta/Rate Selection added to the "Single Cache - Summary" Display
A new "Use Rates" Checkbox has been added to the "Single Cache - Summary" display
that allows the user to select either Delta values or Rate Values to be used in
the display for Trend Graphs and "Activity - Current" Values.
Delta/Rate Selection added to the "Single Service - Summary" Display
A new "Use Rates" Checkbox has been added to the "Single Service - Summary"
display that allows the user to select either Delta values or Rate Values to be
used in the display for Requests And Messages Trend Graphs and "Current" Value
displays.
18182: Support global alert notification definitions
The alert notification functionality has been enhanced. The changes include:
- The alert command is my_alert_script.bat.
- The alert command executes for new alerts and on the first severity change.
Alert notification is now setup through property files, rather than by editing
.rtv files.
- 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.
- 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. 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 can now be set:
sl.rtview.alert.renotificationmode
sl.rtview.alert.renotificationtime
sl.rtview.alert.renotifyonsevchangedmode
sl.rtview.alert.renotficationcommand
sl.rtview.alert.commentcommand
sl.rtview.alert.alertclearedcommand
Further information can be found in the alert documentation.
18201: Rename cache names to be consistent with EM naming conventions
All Cache names have changed and been given an OC prefix.
18219: Alert when JMX connections drop
The alert OcNoJmxConnection has been added which will execute after sensing that
JMX connection has been disconnected for a set amount of time. By default the
alert is set to ON and the default time value is 60 seconds..
18220: OCM Processing Time Alert.
A new alert - OcJmxProcessingTime - will trigger when the sum of the data
collection tIme (sum of the JMX Queries) and the data processing Time (sum of all
the functions) is greater than the JMX Period * the threshold.
The threshold defaults are 80% for warning, 90% alarm. The alert duration default
is 0 and the alert is disabled by default.
18221: StoreFailures alert.
An OcStoreFailure alert has been added which can trigger when the
DeltaStoreFailures on the CacheTotals Stats exceeds a specified threshold.
18238: Create a Proxy Node History heatmap.
A History Heatmap has been added that displays the sent and received statistics
for each of the Proxy nodes.
It can be navigated to via Proxy Services / Proxy Nodes History
18416: Update database schemas
The database schema files have been updated, and are now under
rtvapm\ocmon\dbconfig.
18421: OcEndangeredAllCaches alert only triggers now for ENDANGERED
OcEndangeredAllCaches alert now only triggers when StatusHA is ENDANGERED. It no
longer triggers when StatusHA is NODE-SAFE.
Oracle Database
18438: Update dbconfig files
Dbconfig files for oramon have been updated with table indexes and type columns
for all tables.
Oracle Weblogic
18390: Enhance WLM to collect, cache, and display Cluster configuration
A new display "All Clusters Table" has been added to the WebLogic Servers
section. This display presents a table of all WebLogic clusters discovered by WLM
in all Domains being monitored. Servers that are not defined in a cluster will
have a blank cluster name.
Additionally, the All Servers Table and Heatmap displays have been enhanced to
provide a drop-down selector to filter the servers shown by the cluster to which
they belong. Also these two displays now show the Cluster name to which each
server belongs and group and sort the servers by Domain and Cluster.
18391: Define WLS Cluster alert for Percent Servers Not Running
A new alert type has been added to WLM: WlsClusterServersPercentNotRunningHigh.
This alert will fire whenever the percentage of not-RUNNING servers
that are in any cluster exceeds the specified threshold values.
18404: Reworked WLM caches for granularity and performance options
The WLM default data collection behavior has been modifed for performance
reasons. Now, by default, the WLM will collect only Server-related metrics, such
as Server JVM statistics, Thread Pool statistics, and JDBC statistics. In the
sample project supplied with the WLM solution package either stand-alone or under
EM, the rtview.properties contains a section of commented out properties that can
be selectively configured. These provide granular control over other metrics
related to WebLogic applications.
Application Servlet and Session statistics can be selectively collected on a
per-application or per-server basis. It is typical in applications that use
WebLogic for clustered applications to be
deployed on a cluster of servers often with a standard naming pattern. The
following property may be included multiple times to specify a number of
different applications and servers using
a wildcard JMX pattern. It is important that the query be as specific as possible
to minimize data collection overhead on the Admin Server. The following is an
example pattern:
sl.rtview.cache.config=wls_servlet_cache_source.rtv
$wlsServletPattern:ApplicationRuntime=estore,ServerRuntime=estore*
This will collect data for an application named "estore" running on all servers
whose name begins with "estore". Multiple entries can be provided for the wls_
servlet_cache_source property.
Also in the sample rtview.properties are several additional lines that enable the
collection of other metrics. They can be commented out as needed:
wls_workmgr_cache.rtv - WorkManager metrics for all apps
wls_auxilary_cache.rtv - Miscellaneous data, like JTA stats
wls_jmsserver_cache.rtv - JMS Server and Destination stats
wls_jmsbridge_cache.rtv - JMS Bridge stats
wls_jmspstore_cache.rtv - JMS Persistent Store stats
Note: Some of these data sets could be large, and will consume a lot of cpu in
collection. Verify performance in your environment.
18427: Provided Clustered App caches and displays
The WLM has been enhanced to provide two new data caches and
two new displays for showing Clustered Application data.
WebLogic applications that are deployed in a cluster will have a
servlet running on each of the servers in the cluster. The Cluster Apps Table
display shows a list of all Applications
organized by the cluster they are contained in and the aggregate
metrics for the entire cluster (total sessions, e.g.)
Drilling into one of the Cluster Applications will take you to
the Cluster App Summary page, showing a breakdown of
activity on the app across each server in the cluster as well as
a trend of the aggregate metrics.
The two new caches behind these displays are
WlsServletTotalsByClusterApp and WlsSessionStatsByClusterApp
containing, respectively, servlet totals and session statistics
across the entire cluster
18432: Auto-creation of WLS and WLS-APP CI entries
Server and Application data from WebLogic can be now automatically populated to
the CMDB. To do so, one first should add the following line to the
central.properties file under emsample\servers\central directory:
ConfigCollector.sl.rtview.cache.config=rtv_cmdb_source_wls_autocreate.rtv
and then enable the collection of application data by commenting out the
following line in the rtview.properties file under emsample\servers\wlm
directory:
sl.rtview.cache.config=wls_servlet_cache_source.rtv
$wlsServletPattern:ApplicationRuntime=*,ServerRuntime=*
Version 1.2.2 Release Notes
Enterprise RTView
Data Server
18366: Speed improvement for row delta calculation in data server
The performance of the Data Server and its clients has been improved when
tracking and applying changes to large data tables.
Data Sources
18367: Property updateListenersImmedFlag added to cache object
A property named updateListenersImmedFlag has been added to the cache table
object (obj_cache table). The property is in the Cache category and is checked by
default. In very specific conditions, the property can be unchecked to improve
the performance of the Data Server.
If updateListenersImmedFlag is checked, then each time new data is stored in the
cache the updated contents of the cache's tables are immediately applied to any
listeners attached to those tables. This is the default behavior and is
appropriate for most caches.
If updateListenersImmedFlag is unchecked, the updated contents of the cache's
tables are not applied to the listeners immediately after new data is stored in
the cache. Instead the listeners are updated on the next RTView update cycle.
(The default rtview update interval is 2 seconds). This is more efficient in the
case where raw event-driven data is frequently stored in the cache (for example
high-frequency event data from a JMS, RV, or RtvAgent data attachment) and the
cache's current table or history table can grow large (more than 25k rows) and
the cache is maintained in a data server.
18375: Improved row expiration performance
The performance of the cache data source and data server have been improved when
rows with random timestamps expire and are removed from the current table of a
cache.
Functions
18368: Buffer Rows function no longer loses rows
A bug in the Buffer Rows function has been fixed which made it possible for some
rows in the buffer to be lost before the downstream function was updated with
those rows.
Version 1.2.1 Release Notes
Solution Package
Oracle Database
18332: Support for Oracle RAC
The caches and top-level drill-down screens for the Oracle db solution package
have been re-organized to support RAC databases. The top level screen is a list
of databases. Clicking on a database leads to a summary screen, which includes
space utilization and a list of instances which host the database. Non-RAC
databases are handled the same as RAC databases; the difference is that non-RAC
databases have a single instance. A click in the summary screen takes you to a
table of instances, which in turn leads to an instance summary.
The Reports display is now customizable to include user SQL for additional
reports. Customers may add SQL and associated formatting for display columns to
the ora_reports.xml file, which can be found in the oramon/projects/sample
directory. For use in EM, copy this file to the customized EM project folder for
your installation (which should be something like emsample/servers/central). It
is not necessary to restart EM after adding new reports to this file. Simply
navigate to the Reports screen, and new entries should be immediately available.
Oracle Weblogic
18324: Accomodated for more than one ComponentName per application
Previously, Server Summary trends behaved erratically when there was more than
one ComponentName per application. This has been fixed.
18325: Improve metrics going to the all apps summary display
A new metric, New Sessions, has been added to the table. Also time stamp has been
formatted to European format.
18326: Add new alert for New Sessions Low
A new alert WlsServerNewSessionsLow has been added to the set of WLM alerts.
18333: wls_allapps_summary trends now always shows history data
Trend graphs have been fixed to plot the whole range of data, which was not the
case previously.
18334: Display state of WebLogic server as UNKNOWN if no connection
Expired server state is now shown as UNKNOWN.
18343: Added standard color in All Servers table for expired rows
Expired or inactive servers will appear with gray background to discriminate them
easily from the active ones.
18350: Show correct state of all servers, even if not RUNNING
All WLS servers now are displayed in the All Servers Heatmap and Table whether or
not they are RUNNING. If the server changes state, the correct state will be
reflected in these displays.
18356: Show CPU metric for all WebLogic Servers
The CPU metric now shows up properly for WebLogic servers
that use the Oracle SUN JVM. Previously, these servers would
always show a value of 0 for the cpu metric.
18360: Add new alert WlsAppNewSessionsRateLow
A new alert has been added to the WLM package, WlsAppNewSessionsrateLow. This
alert will fire whenever the rate of new sessions is below the specified warning
and alarm thresholds. Overrides may be specified for specific named Applications.
18365: Provide Domain Filter for All Servers Heatmap/Table
A Domain filter has been added to the All Servers Heatmap and Table displays, as
well as a checkbox to control whether Inactive servers are shown in the display.
TIBCO BusinessWorks
18327: Server Free Memory MB no longer reported as 0 for linux servers
The BW Monitor metric Server Free Memory MB would be reported as 0 if the Hawk
Agent was running on UNIX. This has been corrected.
TIBCO EMS
18330: Alerts fired for standby servers
FT standby servers on EMSMON don't trigger alerts now.
VMWare vSphere
18355: Added sql schemae of history
Example database schemae for our supported databases have been added.
Version 1.2.0 Release Notes
18101: Modify Service Summary to add CI Type filter drop down
A drop-down menu was added to the service summary page, to allow the users to
filter the table of CI's by CI type.
When drilling down from the Service Summary By CIType display, the CI type filter
will be set to the selected CI type
Alerts
18047: Line breaks removed from the Alert Text column
Alerts Table now removes all line breaks from the Alert Text column before
displaying it, so all rows in the table use the same space.
18065: Enable user to extend alert enrichment
EM now supports user alert enrichment which allows users to add their own
information to RTView alerts in the central alert server. To add a new column to
the alert table, add a Custom Alert Definition property to your properties file
using the following syntax:
sl.rtview.alert.custom_alertdef_prop=name=MyColumnName dataType=string
Valid dateTypes are string, boolean, integer and double. To set the value for any
column in the alert table, extract rtv_alerts_source_user_include.rtv from
RTVAPM_HOME\appmon\lib\rtvapm_appmon.jar. The stdAlertTableEnriched function
contains the alert table with the standard alert enrichment applied. Modify the
userAlertEnrichedTable function to return your enriched table. To create your
enriched table, apply one or more functions to the stdAlertTableEnriched. The
last table in the function chain must be userAlertEnriched
Note that you are responsible for persisting the information you apply in the
userAlertEnrichedTable so that when the central alert server restarts, that
information is available.
18066: Allow alert filtering by Owner, Area, and Group
The EM Alerts Table has been enhanced to support filtering alerts based on all of
the selected CMDB values. Previously, alerts were filtered by the selected CMDB
Service and Environment only. This enhancement adds support for also filtering on
the selected CMDB Owner, Area and Group.
The Alerts Table view has been enhanced to show the applied CMDB filters. The
Service Filter and Env fields and the All button have been replaced by the CMDB
Filter field and Clear CMDB Filter button. The CMDB Filter field shows the
selected Owner, Area, Service, Group and Environment filters. To clear all CMDB
filters, click on the Clear CMDB Filter button. This will only clear the filter
on the Alert Table view and will not affect any other displays.
To apply CMDB filters to the Alert Table view, open the Alert Table from any of
the Views under Multi Area Service View (click on the ! in the yellow triangle).
Selecting elements from the heatmaps and tables in these views will set the CMDB
filter on the Alert Table view. The displays under All Management Areas will also
set the CMDB filters on the Alert Table view.
Note that the Alert Table view opened from the navigation panel will only have
the Environment filter applied.
Users that have made custom displays using the following global variables may
need to modify their displays: $rtvOwner, $rtvArea, $rtvGroup, $rtvService.
Previously, these variables were initialized to - and now they are initialized to
*. Displays that contained logic depending on the - value to mean no filter
should change that logic to look for a value of * instead.
The behavior when only an Environment filter is applied has changed. Previously,
the Environment filter was only applied if there was also a Service filter. The
had the effect of showing rows with an empty Primary Service when there was an
Environment filter and no Service filter. Now, the Environment filter is applied
if the Environment filter is not * regardless of whether or not there is a Owner,
Area, Group or Service filter. Since the Environment filter is always applied if
it is not *, rows with no Primary Service will not show if there is a non-star
Environment filter and no Owner, Area, Group or Service filter.
18109: Custom user alert fields no longer removed during enrichment
In previous releases, user defined custom alert event attributes and custom alert
definition properties values were lost during the alert enrichment process. This
has been fixed.
To prevent the custom alert event attribute values from being lost, you must add
a substitution named $rtvAlertCustomEventAttrs to your properties file and it
must contain a semi-colon delimited list of your custom alert event names in the
order they were specified. To prevent custom alert definition property values
from being lost, you must add a substitution named $rtvAlertCustomAlertDefs to
your properties file and it must contain a semi-colon delimited list of your
custom alert definition property names in the order they were specified. For
example:
# Add custom alert definition properties and custom alert event attributes to the
alert table
sl.rtview.alert.custom_alertdef_prop=name=MyNewColumn dataType=string
sl.rtview.alert.custom_event_attr=name=TicketRequested dataType=boolean
sl.rtview.alert.custom_alertdef_prop=name=TicketStatus dataType=String
# This must contain all of the custom_alert_def_prop names in the order
# specified above.
sl.rtview.sub=$rtvAlertCustomAlertDefs:'MyNewColumn;TicketStatus'
# This must contain all of the custom_alert_def_prop names in the order
# specified above.
sl.rtview.sub=$rtvAlertCustomEventAttrs:'TicketRequested'
18154: Need to filter out the alerts of unwanted packages
A substitution $rtvAlertPackageMask has been added to filter out alerts from
unwanted packages in the alert admin display. The default value is blank, to
allow all alerts to be managed. The value shuld be a regular expression, for
example, the following line will allow alerts whose names start with "Wls" or
"Jvm":
sl.rtview.sub=$rtvAlertPackageMask:^Wls|^Jvm
18175: Go To CI button is not disabled when multiple alerts selected
A bug has been fixed in the alert table, where if multiple alerts were selected,
the Go To CI button remained enabled. It should be disabled.
18215: Provide Aggregate Service alert which fires once for sub-alerts
This task is connected with TN18216. Here we describe the mechanism needed for
these special alerts.
RTVRULES is the package that needs to be run for this feature. Otherwise, the
alerts wouldn't be triggered. It's located under
rtvapm\projects\emsample\servers\rtvrules.
The alerts are defined in the rtv_emservice_alertdefs.rtv file under
appmon\src\rtfiles and are two: RtvEmServiceAlert (A Service has one or more
alerts on any of its CIs) and RtvEmServiceAlertImpactHigh (A Service has an Alert
Impact higher than the specified threshold on any of its CIs).
Let's assume you already have a relationship among services, otherwise, use the
RBT on TN18216 to do so. Next, one needs to execute all the needed servers from
an initialized command window.
1. Initialize a command window:
cd rtvapm
rtv_init.bat
cd rtvapm\projects\emsample\servers
rtvapm_user_init.bat
2. copy under rtvapm\emsample\servers\emsmon and rtvapm\emsample\servers\wlm the
corresponding sl.properties located in rtvapm\emsmon\src\rtfiles and
rtvapm\wlm\src\rtfiles respectively.
3. modify rtvapm\projects\emsample\servers\rtvservers.dat by adding the text
-properties:sl
to the end of the line that starts emsmon and wlm dataservers.
4. start the em servers
cd to rtvapm\projects\emsample\servers and type start_rtv all
this will start the databases the config server, display server, and alert and
directory servers
5. in the same directory as before, start the back-end data servers
start_rtv [pckg] dataserver, where pckg={emsmon, wlm}
6. start rtvrules
start_rtv rtvrules
you'll see in the Architecture->System Overview the rtvrules, emsmon, and wlm
dataservers in green
7. Perform the RBT of TN18216.
18216: New SERVICE CIType allows references to other services
A new CI Type to associate services has been created. This new CI Type would
allow alerts triggered in the associated services to be seen in the belonging
service.
18217: Implement Alert Impact aggregation by Component Criticality
An improved formula to compute the Alert Impact of a Service has been developed.
It also takes into account the Alert Impact of dependent services.
18227: Service filter on alerts now applied and cleared correctly
Previously, the Service filter was not applied consistently to the Alert Table
display and clearing the Service filter on the Alert Table also incorrectly
cleared it on other displays. This has been fixed. The new behavior is as
follows:
- When the alert table is opened by clicking on the ! in a triangle button from
any display, the service filter is applied to that window. If the service filter
is changed in the main window, that filter will be applied to the open alert
window.
- When the alert table is opened in the main window or by click on the ^ button
in the alert table in the main window, the service filter will not be applied to
that display.
- When the All button is clicked in any alert table display, it will only clear
the service filter on itself. This clear will not apply to other displays.
18242: Provide a view of Alert History
A new display to track alert history has been added. Alerts can be filtered by
Alert Name using regular expressions optionally. There is the possibility to
chose the time range to inspect. Alerts are indexed by ID and Alert Name. The ID
is a unique value provided by the back-end data server. Thus, multiple IDs can
exist for different data servers.
In this display, on the rightmost side of the table, the Cleared Reason is shown,
which can be a DATA UPDATE (the metric has returned to normal thresholds) or
MANUAL (one user has cleared/closed the alert manually)
18251: Support for alert notifications in EM
EM has been enhanced to support alert notifications. Notifications are supported
in the rtvrules server and in the data collector servers. By default, alerts are
configured to execute my_alert_actions.bat whenever a new alert is generated and
the first time the severity changes. This script (and a .sh version) is located
in RTVAPM_HOME\common\bin. The script contains a commented out line to print
alert information to the console. To use this script, do the following:
1. copy my_alert_actions.bat (for windows) or my_alert_actions.sh (for unix) to
the directory where you are running the rtvrules or data collector.
2. uncomment the echo line at the bottom of the script
3. if you are on unix, add this line to your rtview.properties file:
sl.rtview.cmd_line=-sub:$scriptEnding:sh
Run the rtvrules or data collector server. When an alert fires, you should see
the echo from the my_alert_actions script in the console or log file for that
server. You may modify this script as necessary to execute your custom action or
specify a different script to execute by adding this property to
rtview.properties:
sl.rtview.cmd_line=-sub:$alertActionScript:my_script_name
You may alternatively execute a custom java command instead of a script for alert
notifications. An example of this is provided under
RTVAPM_HOME\projects\emsample\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\projects\emsample\custom\make_classes.bat. This will build the
custom handlers and output them in
RTVAPM_HOME\projects\emsample\custom\lib\rtvapm_custom.jar.
2. Modify common\conf\custom_handlers.properties to uncomment the
sl.rtview.alert.alertcommand line. Also, modify the sl.rtview.cp line to
%RTVAPM_HOME%/projects/emsample/custom/lib.rtvapm_custom.jar.
3. When you run the rtvrules or data collector server, add the following to the
command line:
-properties:%RTVAPM_HOME%/common/conf/custom_handlers
When an alert fires, you will see something like this in the console or log file:
Custom alert command executed: DOMAINNAME=SLDOMAIN ALERTNAME=JvmNotConnected
ALERTINDEX=localhost~SOME_DATASERVER ALERTID=1000 ALERTSEVERITY=2
ALERTTEXT=Server disconnected
You may modify this custom command to implement your custom action. The source
code is in
RTVAPM_HOME\projects\emsample\custom\src\com\sl\rtvapm\custom\RtvApmCommandHandler.java.
Modify or replace the outputAlertString function with your custom action. The
custom command handler api is described in the RTView Classic documentation under
Customization->Custom Functions and Customization->Customization API.
18273: Filters no longer apply to Service Summary views
In previous releases, the alert table in the following views were filtered based
on the filters selected in the Alert Table view:
Service Summary Views->Service By CI Type
Service Summary Views->Service Summary
Single Area Service Views->Services CI Type Summary
Multi Area Service Views->Services CI Type Summary
This has been fixed so that the alert table in the Service Summary views always
shows all open, unsuppressed alerts regardless of the filter on the Alert Detail
view.
18274: CMDB-driven Alert Viewer added
EM has been enhanced to support an Alert Viewer. This shows the CMDB hierarchy in
a tree view in the left panel and the Alerts Table in the main panel. The Alerts
Table is filtered to show only the alerts related to the selected node in the
CMBD hierarchy tree. For example, when you click on an Area, the alerts are
filtered to only show alerts related to the Services in the selected area. To
clear the filter on the Alerts Table, click Clear CMDB Filter.
The CMDB hierarchy tree is filtered by the Owner, Area, Group and Environment
combo boxes at the top of the panel. Each node in the tree has an indicator that
is green to indicate no associated alerts or red to indicate one or more
associated alerts. The labels for the Services in the tree have the Environment
and number of alerts appended to the service name.
To run it in the viewer, use the -panelconfig:rtv_alert_panels.xml command line
argument. It is already pre-configured for you in the projects\emsample\servers.
In that directory, run
start_rtv alert-viewer
The emsample contains a webapps directory for deploying in the thin client. To
run the Alert Viewer, modify webapps\index.html to replace rtv_appmon_panels.xml
with rtv_alert_panels.xml, then rebuild and redeploy the war file as usual. When
you view this page, the Alert Viewer will be used instead of the regular viewer.
18294: delay sync of central server alerts after backend server restart
The central alert server has been enhanced to delay the synchronization of alerts
after a backend server restart until after the backend server has finished
initializing its alerts. When a backend alert server exits, its alerts remain in
the central alert server table. After it starts back up, the alerts in the
central alert server table are synchronized with those in the backend server.
Previously, this synchronization occurred before the backend alert server
finished initializing the alert table. This resulted in all of the alerts for
that server being removed from the central alert server and added back in again.
Now, the synchronization is delayed until after the backend server's alert table
is initialized.
Configuration
18169: Add option to do indexing for the historian and varchar max
Two new options have been added to control how the Historian creates the database
tables: -charlimit:NNN and -index_history_tables:true
-charlimit defines the max string length to use in VARCHAR column types. Default
is 50 in RTView but it has been set to 255 on rtvapm applications.
#
# Define the default size of varchar columns in RTVHISTORY database
#
historian.sl.rtview.historian.charlimit=255
-index_history_tables defines whether indices should be created for new tables,
to improve time response when displays are trying to access historical data. It
creates one index by the TimeStamp column, and another index for the cache index
columns, followed by the TimeStamp column. Default is false in RTView, but it has
been set to true for rtvapm applications.
#
# Add indices when creating tables in RTVHISTORY database
#
historian.sl.rtview.historian.index_history_tables=true
18173: Implement expiration behavior for the CMDB caches
The Enterprise Monitor CMDB behavior has been improved so that Owner, Area,
Group, or Service entries that are deleted will be immediately reflected in the
heatmaps and tables that are driven by the CMDB contents. Previously it was
necessary to stop the Config Server and restart before these changes would take
effect.
NOTE:if a custom "CMDB Source" is used, a small modification will be required to
append one additional column to the RtvCmdbCITable. This additional column must
be named "Source" and contain an entry that uniquely identifies each separate
source of CMDB data. This column value must not start with "RTV_"
18189: Provide dos to unix conversion utility for Unix users
RTView APM packages now include a utility to convert text files from DOS to unix
format for systems that don't provide "dos2unix" or "d2u" in the form of a script
file named "dos2unix.sh" in $RTVAPM_HOME/common/bin. It takes one argument, a
filename, and will convert that file and replace it with the converted version.
18299: Provided unix version of make scripts for wars
In emsample/webapps are shell scripts to remake the war files for the rtvagent,
rtvdata, rtvdisplay, and rtvquery servlets.
Deployment
18246: Modify CIMap collector to query one DataServer
The rtv_cimap_source.rtv file is used in the EM central.properties file to create
a CIMap by searching for CIs of a specified type in a specified DataServer.
The previous version was mistakenly configured to query from ALL DataServer,
resulting in some performance degradation.
The default version of rtv_cimap_source.rt vhas been changed to query from only
one DataServer, identified with a $rtvDataServer substitution in its config line.
A copy of the older version, which queries all DataServers, has been provided
with the name rtv_cimap_source_all.rtv, to be used in case a customer deployment
was dependent on this capability.
General
18228: Criticality Level can be 6 when Criticality is empty
A bug has been fixed where when the criticality was blank it was assigned a value
of six for purposes of calculating alert impact.
18265: Provided an example of HA in emsample
To avoid loss of data, High Availability (HA) has been implemented. There are
three steps involved on configuring HA:
1. Use of the Config Server to reference ALERTDEFS and enable Alert Persistence
2. Take into account the use the newly added ha.properties file in the back-end
data servers
3. use two machines to be configured as the PRIMARYHOST and the BACKUPHOST by
setting these environment variables.
An example of this has been provided in projects\emsample:
Properties are contained in a separate properties file. servers/center includes
central-ha.properties. For each individual data server there is a separate
ha.properties in each dataserver (SP) directory.
Also in emsample/server there is a version of rtvservers.dat called
rtvservers-ha.dat. This contains all the properties and filter settings for HA
support. If you want to use this dat file you have to rename rtvserver-ha.dat to
rtvservers.dat.
If you use rtvserver-ha.dat, you can start primaries as normal (start all
supported). For the backup servers you have to start each server individually.
Backup servers are started with start_rtv central-backup.
Each individual SP backup dataserver needs wlm-backup, emsmon-backup, etc.
18315: $rtvOwnerMask and $rtvAreaMask now applied to all views
Previously, the $rtvOwnerMask and $rtvAreaMask were not applied correctly to all
displays. This has been fixed.
Monitor
18043: Selection of alert in Service Summary remainswhen filters change
There used to be an error where the alert action buttons remained functional
after the selected alerts disappeared from the table (for instance, because the
user changed the filters). Now buttons will get disabled when selected alerts are
not in the table.
18046: Drill down to specific area from CDR heatmap
When drilling down from the Area Table or Heatmap, the Area where the user has
clicked will be selected in the next display. In previous versions of the
product, only the Owner was selected, but the display showed all Areas.
Now the context menu has two new options: Drill Down to Area and Drill Down to
All Areas, allowing the user to choose between the old and the new behaviors.
18048: Custom alert detail screens now resize properly in thin client
Custom alert detail drill downs now resize properly in the thin client.
18069: Option to hide data server column on the Service Summary Page
A substitution $rtvShowDataServerColumn has been added to control visibility of
DataServerName column in Service Summary display. Set it to 1 or true in your
properties or command-line options to show that column. Set it to 0 or false to
hide it. Default is 1.
18084: CDR Heatmap - Only shows all environments
The Environment drop-down in Area Table and Heatmap displays used to show the
"All" option only. It now shows all Environments like the other CMDB displays.
18099: Add Service Health State heatmap
A new display Service Heatlh Heatmap has been added to the Service Summary Views
of EM applications. This display shows a heatmap of different metrics for each CI
of a selected Service.
18100: Add Service Summary by CIType table
A new display Service By CI Type has been added to the Service Summary Views of
EM applications. This display shows a table with summary alert metrics by CI
type.
18102: Enhance Multi/Single Area Service/Group tables
Cosmetic changes to displays:
rtv_allareas_allservices_table.rtv
rtv_area_serviceinfo_table.rtv
rtv_area_table.rtv
18115: Corrected assignment of Crit Level and Criticality
An error has been corrected where the Criticality shown in the heatmap tooltip of
the All Areas By Owner heatmap was not always correct.
Now the All Areas By Owner table has a Criticality column instead of Criticality
Level.
18141: Change Default Area / Service drilldowns to goto CIType Summary
Also, a new substitution has been defined to control the drill-down behavior of
heatmaps and tables in the CMDB displays. Set $rtvNavAppRightClickActionFlag to 0
allow drilldown with a single-click. Set it to 1 to enable drilldown on
double-click and to prevent drilldown on single click and just set subs. Default
is 0.
As before, the substitution $rtvNavAppDisplayName defines where to drill down
from the area heatmaps and table displays. The default has been changed to
rtv_service_citype_summary.rtv
18171: Enhanced Data Server summary under Architecture
The Data Server Summary display has now two additional columns in table: Runtime
and Status
18174: Add all services by CI type summary display
A new display Service Health By CI Type has been added to EM. It shows a
two-dimensional table of light icons. Columns are CI Types and rows are Services.
For each Service in the selected Group, a light icon will describe the maximum
alert severity for each CI Type. If there are no CIs for the CI Type, the cell
will remain blank; otherwise, the light will be green, yellow, or red depending
on the maximum alert severity of all alerts in CI's of that type. The background
color of the cells denote the alert impact for that service and CI Type.
The lower alert table shows all alerts for the selected combination of Service
and CI Type selected.
18193: Improve performance of drop down menus in CMDB displays
Previously, in a browser deployment, the drop down menus in all CMDB displays
would take a noticeable time to refresh when the owner dropdown was changed by
the user. The times should now have improved significantly.
18243: New Service Status History Heatmap display
A new display to track the history of alerts has been added. Go to the Alert
Views->Alerts History Table to track alerts back in time by selecting the
appropriate time range and date. Multiple IDs of a given alert in the table
indicates that the same alert occurred several times.
18290: Commands in Alert Table work for alerts from multiple servers
In previous releases, the Own, Suppress and Unsuppress buttons on the Alerts
Table view did not apply the command correctly when alerts from multiple backend
servers were selected. This has been fixed.
CMDB Editor
18104: Allow users to add new services in the CMDB editor
A new display to manage CIs under a hierarchical CMDB structure has been
included.
18105: Improve CMDB Admin page so updates/deletes don't require restart
The CMDB Admin page has been enhanced so that updates or deletes to any entry no
longer require the Config Server to be restarted. The change will be immediately
reflected in the heatmaps and tables affected by the CMDB (the EM Area and
Service views)
Scripts
18259: Enhanced EM start\stop\status scripts
The scripts used to start and stop and get status of EM servers have been
enhanced as follows:
(1) Each command may now take optional arguments such as additional property
files or propfilters.
*NOTE: To use additional arguments you must either specify a specific server or
'all' to apply the additional arguments to all servers in a given configuration
(or all configurations)
(2) The usage message has been enhanced to list the servers within each config
(as well as to reflect enhancement 1). For example:
Usage: start_rtv config or 'all' [server or 'all'] [args...]
Available configs:
default
dataserver
historian
displayserver
database
.
18260: Start/stop/status scripts now work on Solaris 11
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
Solution Package
18225: CUSTOM: 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. 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
18247: RTVMGR: 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. 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
Amazon CloudWatch
17919: Not all Amazon instances are displayed in acwmon
Amazon made a change in the way data is collected and returned by the CloudWatch
interface, and this change broke acwmon collection. In addition to the usual data
(%cpu, disk reads, etc), CloudWatch returns metadata for each instance
(StatusCheckFailed). The data and metadata are individually timestamped, but the
timestamps for the metadata do not match the data timestamps. The datasource
adapter attempts to create a row of tabular data for each instance by matching
timestamps. Since the metadata timestamps did not correlate, the adapter could
not build a complete row, so no data was returned. The adapter now discards
metadata, and only the data is returned.
18118: Incorrect table column names
The column names in the All Amazon Instances display have been fixed to match the
data in the column.
18119: Accordian nav tree broken
Issues that resulted in "cannot open file ..." popups when clicking on the Alert
Views, and Administration nodes of the ACWMon navigation tree have been fixed.
18120: Update Heatmap and summary screen to common EM
To conform with solution pack standards, some cosmetic changes were made to
acwmon display screens. When data expires, the background color will change on
the Instance Summary screen to reflect a data quality issue. The Instance Heatmap
now includes a "labels" switch to optionally label the heat map boxes with the
instance ID.
18121: Integration of alerts with EM
Amazon CloudWatch alerts are now disabled by default when the solution pack is
first installed. They can be enabled using the Alert Administration display.
18176: 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. 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
18197: Provide a property for poll rates
This enhancement allows you to set the CloudWatch polling rate as a property in
conf\rtvapm.acwmon.properties file; the substitution $acwQueryInterval sets the
rate at which CloudWatch is queried for metrics. By default, we set this rate so
that displays will update within 30 seconds of a change in CloudWatch's Basic or
Detailed Monitoring metrics. Decreasing $acwQueryInterval will decrease display
latency at the cost of increased RTView server and network utilization.
GlassFish Application Server
18180: 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. 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
IBM DB2 Database
18122: Adjusted connections to conform to EM standards
The file names for configuring caches in rtview.properties were changed to
conform with best practices. In order to configure a connection to a new
database, add the following lines to your rtview.properties:
# include following line once for each db2 instance (any database connection
defined on
# collector.sl.rtview.sql.sqldb line) Using a distinct database name is
recommended,
# as for example <connectionName> = vhost.db2inst1.sample
#collector.sl.rtview.cache.config=db2_cache_source_instance.rtv
$dbconn:<connectionName>
# include following lines for each db2 database. One connection per database is
required.
#collector.sl.rtview.cache.config=db2_cache_source_database.rtv
$dbconn:<connectionName>
#collector.sl.rtview.sql.sqldb=<connectionName> <user> <password>
jdbc:db2://<host-or-IP>:50001/<database> com.ibm.db2.jcc.DB2Driver - false false
18123: Updated heatmaps to EM conventions
The size controls have been removed from the All Instances and Database
Partitions heatmap displays. Previously, a "Size Metric" combo allowed the user
to select a metric from a list to determine the relative size of boxes on these
displays. This proved awkward in practice, especially when some metric values
were zero (resulting in no box displayed). Hence, the size is now defaulted to a
metric that changes rarely (so that boxes are not repositioned on every update)
and intuitively reflects physical database size.
18124: Integration of alerts with EM
The following changes were made to conform with solution pack standards for
alerts:
Names of alert definitions now start with Db2 instead of "db2".
Alerts are now disabled by default.
Package name has been changed from db2mon to DB2.
Displays now use the alert cache from the dataserver to show alert status.
18125: Navigation to displays sometimes not populated with data
Previously the DB2 displays would sometimes fail to load data. This problem has
been corrected.
18126: Accidental test query error removed
A test query that was used during development has been removed. This query was in
a cache config file used to populate caches, and was found when a data connection
to a database was deleted and the connection name used in the data attachment was
no longer valid. The invalid connection name caused sql errors to appear in the
console window, but did not result in any display failures because the query
output was not bound to a cache or any displays.
18127: Changed "Connected" LED to a checkbox on summary display
In conformance with solution pack standards, the "Connected" status on the
database summary page is now a checkbox instead of an LED.
18178: 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. 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
IBM Websphere Application Server
18187: 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. 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
IBM Websphere MQ
18181: 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. 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
Oracle Database
18142: History plots now show gaps when there is a connection outage
The plots in the Oracle Database Summary screen did not correctly depict
intervals in which monitoring data was not collected. When data is missing in a
historic time sequence, the solution pack standard behavior is to use the Mark
Time Gaps function to insert marker rows in the sequence which causes the plot to
show a gap. The previous incorrect behavior was to draw a line to bridge the
range of missing data points.
18143: Heatmap display added
Heatmaps are a standard display for EM Solution Packages. The first version of EM
shipped without this feature. A heatmap for all Oracle databases has been added
for this version of EM.
18144: Integration with EM
ORAMON was updated by this task to conform with evolving best practices for
solution pack development. Most of the work involved code refactoring with no
changes to the displays. Hence, oramon should function as before with no apparent
visual changes. However, a file-level substitution variable name was changed;
this will impact datasource declarations in rtview.properties. When updating your
configuration, please note the rename of a substitution variable: $databaseName
to $oraDatabaseName.
18145: Changed "Connected" LED to a checkbox on summary display
In conformance with solution pack standards, the "Connected" status on the
database summary page is now a checkbox instead of an LED.
18146: Corrected port for HSQLDB
The TCP port used by hsqldb was set to the wrong port number in
server.properties. This was changed so that hsqldb runs on the standard port for
stand-alone solution packs, port 9102.
18183: 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
Oracle Weblogic
18078: Compaction added to all WLM caches with history
JMS caches now have compaction configured. By default, the names of the tables
storing historical data of JMS caches are disabled. To enable them, go to
rtview.properties file and comment out the following lines:
sl.rtview.sub=$WLS_JMSCONSUMER_TABLE:''
sl.rtview.sub=$WLS_JMSPRODUCER_TABLE:''
sl.rtview.sub=$WLS_JMSCONNECTION_TABLE:''
sl.rtview.sub=$WLS_JMSDESTINATION_TABLE:''
sl.rtview.sub=$WLS_JMSDESTINATIONTOTALS_TABLE:''
sl.rtview.sub=$WLS_JMSDURABLESUBSCRIBER_TABLE:''
18080: Update trend graphs with advanced filtering
WLM trend graphs now show historical data properly.
18186: 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. 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
TIBCO BusinessEvents
18147: New TIBCO BusinessEvents Solution package
This is the initial release of the VMWMON solution package for monitoring VMWare
hosts and virtual machines via connections to vSphere vCenter and ESXi servers.
Limitations:
1. This release of TBEMON was developed and tested using Tibco Business Events
4.x and 5.x. Earlier versions have not been tested, so compatibility is not known
at this time.
2, When configuring connections to monitored BE processes, you must explicitly
configure for either BE version (4.x or 5.x). If the versions that are deployed
are upgraded, you must update the connection configuration (see rtview.properties
file).
3. TBEMON uses JMX to collect all BE metrics. In general, applications that use
JMX to monitor java processes on a server with the server's firewall enabled may
experience connection problems. The JMX protocol allows initial contact on a
known port, but subsequent communications may occur over a second randomly chosen
port. Version 5 of Tibco Business Events has a fix that allows the follow-on
communications to occur over the same port. However, BE version 4.0 does not have
this fix. BE 4.0 installations should use a local agent to push the necessary
mbean data to the central RTView dataserver, or use a "premain agent" as
described in
https://blogs.oracle.com/jmxetc/entry/connecting_through_firewall_using_jmx
Requirements:
1. Java 1.6
18185: 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_tbemon.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
VMWare vSphere
18148: New VMWare vSphere solution package
This is the initial release of the VMWMON solution package for monitoring VMWare
hosts and virtual machines via connections to vSphere vCenter and ESXi servers.
Limitations:
1. This release of VMWMON was developed and tested using vSphere 4.1. Other
versions have not been tested, so compatibility is not known at this time.
2, Only hosts and virtual machines are supported. Storage, interfaces, and other
resources are not supported.
3. vSphere alerts are not supported. RTView alerts may be enabled for collected
host and VM metrics.
Requirements:
1. For best performance, the system clocks of the rtview dataserver and all
monitored resources should be synchronized to the same NTP source.
2. Java 1.6
18188: 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_vmwmon.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
18196: Provide a property for poll rates
This enhancement allows you to set the polling rate as a property in
conf\rtvapm.vmwmon.properties file; the substitutions $vmwQueryInterval and
$vmwQueryIntervalSlow set the rate at which vSphere servers are queried for host
and virtual machine metrics. The default rate of 20 seconds matches the default
rate at which vSphere servers update "real-time" metrics. Hence, these
substitutions should not be changed unless the rate is changed for your vSphere
configuration.
Version 1.1.1 Release Notes
Alerts
18006: Alert action audits do not capture the user login
An error occurred where the user credential were not passed to the alert action
audit table, leaving the User column blank. This error has been corrected.
Deployment
18004: New 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:
bwmon ./bwmon dataserver rundata
bwmon ./bwmon historian runhist -ds
bwmon ./bwmon displayserver rundisp -ds
emsmon ./emsmon dataserver rundata
emsmon ./emsmon historian runhist -ds
emsmon ./emsmon 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 ./bwmon dataserver rundata
desktop ./bwmon historian runhist -ds
desktop ./bwmon viewer runv -ds
browser ./bwmon dataserver rundata
browser ./bwmon historian runhist -ds
browser ./bwmon 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.
Note about project settings directories:
The project settings directories are created during installation by taking a copy
of a sample directory from the distribution. They contain the properties files
that specify the configuration and are located outside the distribution directory
tree (i.e. rtvapm?) so that they are not overwritten when the distribution is
updated.
In the case of a standalone monitor (BW, EMS, ...) there will be a single
directory copied from the projects/sample directory in the distribution. This
will include the example rtvservers.dat file described above. In the case of
Enterprise Monitor with multiple Solution Packs, there will be several
directories, including one for each solution pack and one named ?central? for the
EM servers. In this case the project setings directory may be created by taking a
copy of the directory projects/emsample/servers, which might contain the
following:
bwmon (folder)
central (folder)
emsmon (folder)
rtvmgr (folder)
rtvservers.dat (file)
In the case the rtvservers.dat file will refer to the subdirectories, for
example:
### CENTRAL
#
# Central Database
central ./central database rundb
# Central Servers with Config and Alert Servers
central ./central ConfigServer rundata_configserver
central ./central AlertServer rundata_alertserver
central ./central DisplayServer1 rundisp_appmon
#central ./central AlertHistorian runhist_appmon
### RTVMGR
#
rtvmgr ./rtvmgr dataserver rundata
#rtvmgr ./rtvmgr historian runhist -ds
### EMSMON
#
emsmon ./emsmon dataserver rundata
#emsmon ./emsmon historian runhist -ds
### BWMON
#
bwmon ./bwmon dataserver rundata -propfilter:receiver
#bwmon ./bwmon historian runhist -ds
In the case the command start_rtv all would start the all the configurations,
whereas start_rtv bwmon would start only BW Monitor, etc.
Monitor
18042: Drilldown on the Regional Heatmap incorrect
Drilling down from the Regional heatmap has been corrected to take into account
the area of the selected service
Solution Package
Oracle Weblogic
18077: Enhance JDBC display to include history trends
The JDBC Summary dashboard has been enhanced with a set of trend graphs that show
the main metrics of the selected JDBC module.
Version 1.1.0 Release Notes
Alerts
17321: Alerts added to RTVMGR
A few alerts about JVM metrics have been added:
JvmCpuPercentHigh
JvmStaleData
JvmNotConnected
JvmGcDutyCycleHigh
JvmMemoryUsedHigh
17626: DBCONFIG schemas updated and moved to common\dbconfig
In previous releases, the schemas in dbconfig were out of date. This has been
fixed. They are now located in common\dbconfig.
17818: Multiple index types now populate unassigned indexes correctly
A bug in the Tabular Alert Administration display has been fixed. Previously, if
an alert had multiple index types defined, selecting anything other than the
first item from the Index Types list would not populate the Unassigned Indexes
table properly. This has been fixed.
17898: Added context menu items to alert table displays
The Alerts Table view has been enhanced so that the following menu items are
available in the context menu when you right-click on a row in the alert table:
Details
Own
Suppress
UnSuppress
Close
Annotate
Go To CI
Options
The Single Host Summary display has been enhanced so that the following menu
items are available in the context menu when you right-click on a row in the
alert table:
Own
Suppress
Close
Details
These items do the same action as the corresponding buttons.
17934: Common/dbconfig alert schemas updated
In previous releases, the alert database schemas did not use a large enough field
size for text fields. This has been fixed.
17967: Go To CI button on alert displays fixed
In previous releases, the Go To CI button on the alert views sometimes brought up
a blank display. This has been fixed.
Customization
18031: New format available for custom commands
APM packages can now use the newer format for custom commands. The function
signature now supported is:
public GmsRtViewCommandStatus invokeCommand (GmsRtViewCommand cmd)
This provides access to the GmsRtViewCommand object, applications should get the
information they need through this object, rather than relying on global data.
General
17352: Enhance common custom handler to work with multiple packages
Custom function, command, and RTView handlers for multiple packages are available
in the same project
17470: DisplayDerver default PNG compression factor set to 3
The default Display Server png image compression factor has been set to "3"
instead of "9". This reduces the time taken to generate many common displays by a
factor of at least 2.
This value can be controlled in the rtvapm/common/conf/rtvapm.properties file:
displayserver.sl.rtview.cmd_line:-pngcompress:3
17622: Enhance rtvmgr to support Tomcat 7.0
The RTVMGR package has been enhanced to support the modified MBean names in
Tomcat version 7.0
17715: Change Common date format for international usage
The format of date in the header of all diaplays has changed to avoid ambiguity
in an international context. months are represented with three letters and year
is shown with four digits.
18020: Updated rtvmgr project under emsample
The rtvmgr project under emsample has been configured to monitor the central EM
servers (config server, alert server, and display server)
It references the central.properties to get the JMX connections for the central
servers. This is done by adding a reference to central.properties files in
custom_setup.bat and .sh. The user can specify additional servers by adding JMX
connections to the rtview.properties file
18022: Rename EMS CI Type to EMS-SERVER
The CIType EMS has been renamed to EMS-SERVER
Navigation
17314: RTVMGR navtree now hasTomcat in its own section
A Tomcat section has been added to the default navtree for RTVMGR.
Four displays are provided showing a heatmap and table of all servers as well as
a heatmap of all applications and an application summary page
Scripts
18009: Provide separate log files for EM data servers
The emsample application has been set up so that the config dataserver and the
alert dataserver output to different files (config_dataserver.log and
alert_dataserver.log respectively). Previously the dataservers were trying to
write to the same file.
Solution Package
Amazon CloudWatch
17864: Network Out field on acwmon's Instance Summary fixed
The network out variable name for the EC2 datasource binding had an extra
character appended. Correct value is displayed after fixing the name spelling.
IBM DB2 Database
17701: Modify Summary page to use Db2Summary cache instead of snap
If the login account used for monitoring a DB2 database server does not have
adequate privileges, the sql queries used by db2mon will fail. This can be
demonstrated by installing DB2, creating a new user for the sample database, and
setting up an RTView datasource connection to the sample database using the new
user. The default privileges will not be sufficient for all sql queries to
succeed, although the Connected flag will be true for the datasource. Perform the
following steps to add the privileges necessary for the user. Note that under
linux, db2 uses linux accounts and passwords for login.
1. create a linux group "rtv_monitor", and add the user ids that should get
monitoring privilege; then in a bash shell,
$ db2 update dbm cfg using sysmon_group rtv_monitor
$ db2cc
2. expand "All Databases", expand database to be monitored, expand "User and
Group Objects", click on "DB Users" folder, click the "Add New User" link, and
add a new user with "Connect to database" authority.
3. right click on user name used for monitoring and select "Change...", click
Function tab, and set execute permission for the following table functions:
SYSPROC.MON_GET_CONNECTION
SYSPROC.MON_GET_INDEX
SYSPROC.MON_GET_PKG_CACHE_STMT
SYSPROC.MON_GET_TABLE
SYSPROC.MON_GET_UNIT_OF_WORK
4. restart db2
$ db2stop
$ db2start
17702: Modified to use filtered current data
Db2mon was modified to use filtered current data. Instead of transferring the
entire contents of a cache from dataserver to client, the dataserver now applies
the filter and sends the reduced table to the client, thereby improving
performance.
A minor cosmetic change was made on "Database Status" screen. The opaque-fill
rectangles for "Memory" and "Connections" portlets were deleted; this allows the
Data Quality fill color to be seen as background color in these areas. Also, the
Start Time and Up Time fields on the Database Summary screen are blanked when a
datasource does not connect (previous behavior was to display "zero" time in
seconds since 1970, 12/31/1969 23:59:59)
17809: Updated db2mon to support partitioned databases.
The first version of db2mon supported non-partitioned databases. This release
supports databases with up to 1000 partitions spread across potentially as many
virtual or physical hosts, called members. Each named "instance" of a DB2 server
can support any number of databases. If partitions are created for the instance,
then the "create database" statement will create a database that spans all
available partitions by default, or the partitions specified in a named partition
group. Db2mon will display status of instances, members, databases, and
partitions, using tabular views, grids, heatmaps, and a new reports module.
Report module is user extensible by simply adding queries and formatting details
to an XML file.
Oracle Weblogic
17866: Enhance alerts for Server and App categories
Alert WlsMemoryUsageHigh has changed its name to WlsServerMemoryUsageHigh. It
also has been added a new alert category to capture misbehavior at the
application level. There has been added one alert on that level:
WlsAppOpenSessionsHigh.
17867: Added Application indicator alert in the server summary display
A new category indicator for Application Alerts has been added to the Server
Summary display.
|