See the System Requirements pagefor the most current information.
Yes! There is an RTI cartridge for JBoss running in OpenShift currently in alpha testing. Contact OC Systemsfor the download details.
Yes! We do most of our testing there. There are no special considerations necessary, so if you're having trouble please ask.
See the System Requirements pagefor the most current information.
We’re constantly expanding our capabilities so contact us if you need RTI for additional applications and/or middleware such as WebLogic and WebSphere. We're all software people at heart and occasionally the documentation lags behind the development. Your best bet is to ask if you don’t see what you need: email@example.com.
No. It means, "Start logging detailed per-call information on the methods already being monitored."
Yes. The RTI Enterprise collector automatically handles either 32- or 64-bit Java applications. The RTI Browser collector only supports 32-bit applications, but the default Windows Chrome, Firefox and Internet Explorer programs are 32-bit, so they should just work. However, the RTI IE collector won't work on 64-bit Internet Explorer. Contact usif you need that.
Yes. RTI automatically recognizes whether 32- or 64-bit Java is starting up and uses the appropriate libraries.
Not at this time (Version 3.4.2, September 2013); we're focusing on JBoss Enterprise middleware for now, including JBoss, Fuse, Wildfly and Tomcat.
Application is noticing 503 errors. We need to collect the appropriate data to trouble shoot the issue and identify whether Application Issue or Infrastructure Issue or both.
RTI deep dive will mark failed transactions (503) and trace the transactions through the servlet infrastructure and application code with appropriate custom EDFs. The trace will indicate the call path of the failure. Resource shortages are indicated by collected JMX metrics. DB issues may be determined from JDBC results.
Application is seeing slow performance and we are not able to meet the SLA from a performance point of view.
RTI deep dive will trace the transactions through the server infrastructure and application code with appropriate custom EDFs. The trace will indicate the call path of the transactions and the elapsed time in each segment. Resource shortages are indicated by collected JMX metrics. DB issues may be determined from JDBC results.
Availiability of the Infrastructure is dropping for example there was high threads or low memory reported by our monitoring tools.
RTI lightweight profile gives an overview of the performance of all transactions/requests in an application. RTI deep dive traces transactions through application code and indicates where time is spent. RTI deep dive collects JMX metrics about thread count, heap usage, garbage collection cycles. RTI takes periodic thread dumps and provides a complete thread analysis perspective.
We need to identify which flow with an transaction is slow (for example if we have ecommerce application where we do have search, add to cart) and what is the root cause.
RTI lightweight profile gives an overview of the performance of all transactions/requests in an application and shows which transactiosns are slow. From the lightweight profile you can launch deep dive trace to find out where transactions are slow.
The following Event Definition Files (EDFs) are provided in version 3.4 and configurable in the Events Editor. Those in bold are enabled by default.
Independent of the above, RTI also collects basic transaction metrics, detailed JMX metrics, and thread dumps.
A: Not built-in, but we can (and did) write a custom one that you can inject yourself. Download the SocketCount probefor RTI 3.4.2, unpack it where you run your RTI Console, and follow the directions in the README.txt. The source is included: check it out and you might get ideas of other probes you or OC Systems could write.
You can request a free trial on the download page.
These might all be the same machine. You should have gotten an e-mail with a link to a web site describing all this about the currently available version. If not, go to our Download page and fill out a form, or contact us.
It's all explained in the User's Guide.
A license key is a single line with no trailing whitespace ending in a newline. Put that single line into the file
$RTI_HOME/cfg/cookie on Linux or
%RTI_HOME%\cfg\cookie on Windows. You can verify it with the RTI command
There are four aspects of RTI to consider:
Each of these is described in the user's guide.
Run "Start→All Programs→RTI→RTI Enterprise Cmd" which opens a 'cmd' window that is set up to run rti commands. You generally won't be needing this beyond the "rti edit" command described in the user guide, but the command
rti 2>&1|moregives usage for all the commands.
In a bash-compatible shell window, do
. /opt/ocsystems/rti/ee64/setup where "/opt/ocsystems/rti/ee64" would be replaced by whatever your RTI installation directory ($RTI_HOME). You generally won't be needing this beyond the "rti edit" command described in the user guide, but the command
rti helpgives usage for all the commands.
Yes you can. Simply run the "rti edit" command on each one, naming its JBOSS_HOME value, for example:
rti edit -t jboss /opt/jboss-soa-p.4.3.0/jboss-as
rti edit -t jboss /opt/jboss-6.0.0.Final
No, this is currently not supported. The architecture of RTI assumes one or more collectors unique to each host machine. If this presents a problem, it may be possible to hand-edit some configuration files to get around this limitation: please contact firstname.lastname@example.org.
If you are logged in as root, "." (the current directory) isn't generally in your PATH. Precede the installer name with "./" or "sh ".
When you downloaded the installer it may have lost its execute permission. Run it as: sh rti-enterprise-3.4.1-linux-x86.installer.
The easiest way is to re-install just the RTI Enterprise component on that computer. However, if that seems like overkill or you don't have the installer any more, you can do it manually as follows:
The program that shows the "RTI" icon is an Eclipse RCP program like the RTI Console, and requires a 32-bit Java installation. It selects the path to this at installation. If you delete that Java installation it will cause the "RTISystray" application to fail. The easiest way to fix this is to download and install a new RTI Browser -- the installation process will find a new Java if one is available. However, this requires that you close your browser windows. Alternatively, you can change the Java path being used by editing the file
C:Program Files (x86)OC SystemsRTIBrowserRTISysTrayRTISysTray.inias administrator, and changing the path shown there to a similar path to a 32-bit Java executeable or jvm.dll that exists.
The given path must be the parent of the bin directory containing the "run.sh" script, for example:
rti edit -t jboss /opt/jboss-soa-p.4.3.0/jboss-as
It may be unable to locate the installation's RTI_HOME. You can explicitly tell it where RTI_HOME is as follows:
This probably means it can't find the rti installation at all. See the next question.
Enable JBoss ON agent debugging, force manual auto-discovery on the platform root node, then look in the agent log file for more information. See the next two questions for how to do this.
You can enable agent debugging by selecting the Inventory view, Resources→Platforms>→your platform)→RHQ Agent. Then right-click, choose Operations→Set Debug Mode, then choose "Yes" for both Enabled and Trace Messaging Parameters, then click Schedule button at the bottom of the Create New Operation Schedule view.
This is described in the user's guide.
Perhaps the RTI plugin in in your remote JON/RHQ agent can't find the local RTI Enterprise installation, because the magic files it looks for are missing or have incorrect contents. The quick fix is to
on each machine to create the correct file(s). Here is the explanation:
There are two magic files that point to the current RTI installation for a given host: There is a user-specific one and a global one,
/var/opt/.ocs-rti-inforespectively. In this case, the "$HOME" value is the home directory for the user who is running the JON/RHQ agent, perhaps root or jonuser. So if you installed RTI Enterprise on that machine as some other user, with a different home directory, the "wrong" $HOME/.ocs-rti-info file would have been created/updated. But there's still the global one. But again, if the user you installed as doesn't have write access to /var/opt/, then that file wouldn't have been created/updated either. Hence the command above, to cause the global one to be created.
If you think these files are right, or our explanation wasn't clear, contact us.
No. For now you have to look at each platform separately, by clicking Inventory, Resources, Platforms, then choosing the platform (host) of interest. However, the dashboard is user-customizable as described in the JBoss ON documentation..
No, the rti console is read-only with respect to JBoss ON configuration. See the user's guidefor how to create alerts in JBoss ON.
It takes a few seconds to construct the RTI Alerts dialog. Unfortunately, it presents its OK button before it other controls appear. Wait until you see a big dialog with a number of Properties before proceeding.
You have RTI Enterprise and the accompanying JBoss ON plugins successfully installed. Now you must:
See the user's guide.
See the user's guide section Configuring JBoss ON or RHQ to Allow RTI Console Access.
The Java-based enterprise collectors that are started by scripts--currently JBoss, JMeter, SoapUI?, and Tomcat--are "enabled" for RTI by edit these scripts, after which collectors are automatically created or activated as-needed whenever the script is run. Thus, the way to create a script for these is to choose a host and collector type, "edit" the script, and then (re)start the application.
So you need to:
rti edit -t tomcat $CATALINA_HOME # for example
That will edit the catalina.sh script to call rti_enable_tomcat.sh. Then you need to restart Tomcat and it should create a collector (or use the one you had previously) and you should then see processes and data:
rti get_collector_processes -t tomcator you can run the console and it will issue the same kind of commands to update the Tomcat collector node.
rti list_collector_data -t tomcat
Just to continue some more, for all the collector kinds except java and rcp, we have to do this "enable" step that consists of editing the start-up script for the tool to call the appropriate
$RTI_HOME/bin/rti_enable_*.sh/batscript. That can be done: automatically at installation on Linux (and in the future maybe Windows) if the env variables are set up and the user opts to, from the console using the Enable page in the New Collector wizard. manually from an RTI shell with the "rti edit" command,
It's spread out like this because the user must have privilege to edit the tool scripts and that may not be possible for the console user. In those cases they will have to get privilege or do it on the server manually or during installation.
After doing the enable/edit the user will have to restart any running tool processes to get data. This is another reason they may need to do the operation on the server with privilege.
There are two operations done when you create a JBoss (or other Java-based) collector: creating the collector objects within RTI, and enabling the JBoss application. This second step, enabling JBoss, requires write access to JBoss application files. That's why we recommend you enable JBoss as a separate step, from the command line, as a JBoss administrative user, as described in the user's guide.
This capability is provided for Linux by the "mod_arm4" module and is described in the text file
The mod_arm4 plugin for Apache httpd can be used to provide a white list capability:
That will allow tracing for listed IP addresses and not trace all others. Contact email@example.com help in setting this up.
Version 3.4.1 of RTI manages temporary files differently from previous versions. Older versions of RTI stored temporary working files in the default temporary directory for that platform ($TMP for Linux and %TEMP% for Windows). RTI now places (almost) all the temporary files in $RTI_DATA/tmp. A few small temporary files may still be placed in the default platform temporary directory, but the space requirements are very small.
When the RTI Console is first started, there is a shortcut created on the desktop label "RTI Drop Box" that points to the RTI Drop Box/RTI Data folder in the Workspace View at the lower left of the console window. This is an easy way to access files from both within the RTI Console and your Windows Explorer. In the absence of the RTI Drop Box link.
You can Copy out of Workspace Drop Box by copy and paste:
Copy into the Workspace Drop Box by drag and drop: Copy/paste as above will work, but this is easier. Simply select the file in the Windows Explorer, and holding the mouse down, drag it onto the folder (e.g., RTI Data) shown in the Workspace view.
Check that your DISPLAY environment variable valid is valid. If Firefox can work, then RTI Console should also.
Probably because the installed version of xulrunner is newer than that supported by the version of Eclipse SWT that RTI is built from (3.7/Indigo) See http://www.eclipse.org/swt/faq.php#browserlinux
The RTI Console is Eclipse-based, and uses the Eclipse help system. On Linux this requires a Firefox browser. If Firefox is running you will need to stop and restart it. If it's not running, delete
The RTI console performance is generally linked to the size and number of open and displayed data sets. In general you can increase performance by closing unneeded deep-dive editors which tax the Java heap. Closing all views works best, as it also disposes of data shared by multiple views.
You can track the Java heap usage by the RTI console by enabling the heap status as follows:
Windows→Preferences→General→Show heap status
This will display a heap status widget in the status line of the RTI console (along the bottom). The heap status shows the total Java heap used and the current size of the heap. The Java heap may grow in size up to the maximum specified (1GB for Windows and 32-bit Linux, 2GB for others).
You can increase the available heap by closing the RTI Console and editing the rti-console-install-path/RTIEEConsole/RTIAnalyzer.ini file to increase the size specified in the -Xmx option there. For example, if it says
you can change that to
to double the available memory.
This is a glitch in the Eclipse Windows UI with selecting items in the navigator. I open dataset A by selecting it under Saved Trace Data. Then I select on dataset B, choose 'Open'. and it re-opens A. If I double-click on B it opens correctly. We can't figure it out either, so recommend using double-click here.
Sorting is done independently at each level of the transaction tree. So all the Top-level transactions are sorted, then under each of those, it's direct children are sorted, and so forth. So if you look at an expanded tree it can look out of order. You can flatten the tree into a single linear list by doing a filter on "/".
Some "failed" (light red color) transactions are so marked because no stop event was ever seen. The stop time associated with them is the time at which the tab or window is closed, which could be a long time after it was started. The statistics associated with failed transactions are not generally reliable.
This are the load time and size of the actual .swf file. The file may then display an animation or streaming video which will not be measured by RTI, since what you see is not interacting with the browser itself in any way.
For cached, 0 means "page requested, not cached"; 1 means "page retrieved from cached, not requested"; and 304 means "request made with 'If-Modified-Since' header in request, and 304 Not Modified was returned, so the page was then retrieved from cache".
Use the RTI Console to:
innocuous characters, and
RTI allows you to export selected transactions from a transaction tree view in CSV format. When you open the exported .csv file with Microsoft Excel, you see only hours and minutes -- the date isn't visible.
Amazingly enough, Excel does not support automatically formatting a date/time with millisecond accuracy from a CSV file! You need to do a custom format in Excel to properly use the millisecond date/time exported by the Console in the CSV file, as follows:
Now column A gives the date/time with millisecond precision.
Use the Collector Configuration Editor as described in the user's guide.
If you don't see RTI-blotz.edf in the Collector Configuration Editor's "Events" tab, then the answer is probably no. But we might be able to whip something up for you, or provide guidance on how you could add it yourself. Please contact firstname.lastname@example.org ask.
No: If you really want RTI to do nothing at all in your enterprise application, you can uncheck everything and your application will still work. This is basically what "Disable RTI" does when applied to a host.
But: Do not uncheck RTI-Monitoring.edfunless you want to disable all the lightweight profiling, JMX metrics, JON metrics, and statprof.
In general, you should only disable EDFs if you're getting data about parts of the application that you don't care about.
Changes may take effect immediately, periodically, or only on restart, as follows:
To add by package, you:
If you trace too many methods you will introduce too much overhead to give you very accurate timings. Avoid low-level methods and favor API-level methods.
--## What happens if I have two wildcards whose expansion overlaps?
If you have, for example:
MONITOR EDGE METHOD OCSTX com.ocsystems.example.ecommerce.*::* and
CHILD METHOD OCSOTHER com.ocsystems.example.*::*
You will get duplicate entries for those methods that match both wildcards, with one appearing as the caller of the other.
The general mechanism for specifying where RTI collects profile and trace information is to create a custom EDF. This is generally done using the RTI console Collector Editor where you can select specific methods from your application and specify whether the method should be a trace/profile point, and whether it should be a monitoring point. For most situations this process will be quite sufficient, but the RTI EDF file support a number of features which are not accessible from the RTI Collector Editor (see the next question).
To use these features you will need to edit the EDF file manually, outside of the RTI Collector Editor. Actually, you can edit the EDF file as an ordinary text file in the RTI console by saving and opening it as such.
If you want to edit an existing EDF file, first save it to the RTI console workspace:
If you want to create a new EDF file, create it in the RTI console workspace:
The file may be opened in the default system editor which is fine, or you can choose to edit it in the embedded text editor in the RTI console:
The file will be available to edit.
The EDF file may contain blank lines, comment lines, and directives:
The most common and useful forms of directive lines are:
The first of these is for selecting application methods for monitoring, tracing, and profiling. Use the MONITOR keyword to specify that the method is a BTM: a business transaction that can produce metrics, and start profile summary trees and deep-dive traces. Use the EDGE keyword to specify that this method should start deep-dive traces unconditionally--this is not very common. Use the CHILD keyword to indicate that the method should be traced only if a caller starts the trace--this is the most common form. The quoted-id specifies the event class that appears in traces. The quoted-method-targetspecifies to which application methods these actions should be applied--these are generally method signatures but can be wildcard patterns.
The second form above is for specifying that custom probes should be applied when the target methods are executed. These are primarily used for built-in RTI probes for common frameworks. There are several useful RTI probes that you might want to use when investigating application structure:
An example of using the traceback probe is:
CUSTOM "traceback" "package.Class::method()" RtiLogTracebackProbe
The third form is for specifying custom probe beans, which contain sets of cooperating probes. These are primarily used for built-in RTI features.
The quoted-method-targetspecifications have the following form:
Note that the separator between class and method names is a double colon (::). Wildcards (*) can be used once in the class specification and once in the method signature specification and should be the rightmost character (on each side to the double colon). Be careful using wildcards because they may match many methods, and the RTI runtime limits the number that can be matched in one directive.
Yes, and it will collect data from your browsers that can be viewed by other RTI Consoles.
The .rti files are XML text, but they're not very readable. Contact us for an rti2csv tool which might help.
There are a few possible reasons:
RTI Firefox and Internet Explorer Collectors write under a sub-folder in %USERPROFILE%. You can change this behavior by editing
%PROGRAMFILES%\OC Systems\RTI\Browser\conf\config.txt and modifying the parameter RING_LOG_DIR to a safe location; for example
RING_LOG_DIR=C:tmpRTI. Restart Firefox and verify there are now .rti files contained in
Not always. On pages with sophisticated dynamic content, transactions can be initiated that are impossible to relate back to the last user-initiated transaction that caused them. However, if you have reproducible output which doesn't look right, please report a bug.
In its default configuration, the Browser collector only keeps data for seven days or up to a limit of 32MB. See the next question.
If you want to keep more data, change the parameters. Here you can change the values of TOTAL_RING_SIZE, RING_SIZE, and KEEP_DAYS, respectively.
NOTE You must restart your browser(s) to pick up the changed configuration.
By a "ring" of files, we mean a fixed-size group of files, such that each file is approximately the same size, and the oldest is deleted when creating the newest. There is always one more file than the stated ring size. For example, if ARM Ring Size is listed as 1, there's never more than 1 file in addition to the one being written to. If the Arm Ring File Size is 8388607, then when a transaction is recorded which brings the current file size at or above 8MB, that file is closed. If there's already an existing data file for the current process it is deleted, and then new file with the next sequence number is opened.
Using the RTI Console, right-click on the Localhost→Chrome, Firefox or IE collector, and choose Edit Configuration... to see the Properties page. Note that the same RTI browser configuration is shared by all three browser "brands" so changing the properties for Chrome changes them for IE and Firefox also.
The properties are are as described here.
When you re-start your browser, it deletes data files changed more than 7 days before. For each IE process, the default is to keep 2 8MB data files, or about 10,000 transactions. These settings can be changed in the Properties page for the collector.
We've built lots of support into RTI for collecting internal data to help us figure things out, so here's what to do...
Attach all data in any compressed format to an e-mail describing the problem:
Under the RTI Console, there is Help→Problem Report. Try that first, and send the file it tells you it creates.
The RTI Console's Help->Problem Report will gather data about all connected hosts and collectors, but if the problem isnt' with something you're currently connected to, then: