Q: What is JTSMon?
JTSMon is an internal, unsupported tool that will help you make more sense out of Jazz server traffic patterns based on web service reports. It takes a series of snapshots then turns them into time trend spreadsheets so you can sort, filter, recombine, and graph the data to actually see what sort of traffic is hitting your server day by day and week by week. For more details see JTSMon - Seeing what your server is up to
Q: Can I use JTSMon in production systems?
No. JTSMon is provided as-is, without support. It uses private interfaces to CLM servers which may change between releases. It may stop working in future releases without notice. JTSMon should not be used to maintain production systems.
Q: Where do I get JTSMon?
JTSMon can be downloaded at the bottom of this page
. The package includes all you need to get started including documentation and release notes.
The latest is JTSMon 6.0.
Older versions are available at JTSMonOlderDistributions
Q: Where do I ask questions about JTSMon?
Use the questions and comments box at the bottom of this page or the Jazz.net forums with the tag "jtsmon" to ask questions about how to use JTSMon and interpret the data it provides.
Q: Is there a quick, easy way to get up and running?
There is a one-page JTSMon Quick Start guide inside the JTSMon package. It will summarize all you need to know to install, configure, run, and analyze your results.
A 60-second practical hands on demonstration video
of the basics of configuring and running JTSMon is attached below. (This is a demo for an older version, but it still presents the basics and is valid.)
A 10-minute demonstration video
attached below provides a brief walk-through from the QuickStart to Visualization. (This is a demo for an older version, but it still presents the basics and is valid.)
Q: What is preferred for sample intervals and run durations?
- PREFERRED: Experiment with JTSMon for a few hours but it's preferable that you run it for a week (SEQ_RUN_LENGTH_ARG=7d) at hourly intervals (default PARM_COUNTER_RATE_MINS value). It works best to record a full week Monday - Monday because that will be the most obvious to everyone - Friday through Monday will tell you very little. A week can give you some idea what is happening day to day and over nights and weekends and will help you identify what seems like an "average" day to use for a baseline. From a separate command line window you can run the gather and analyze commands at any time so you can see initial data after a few hours even while running.
- SHORT TERM: If you are going to run it for just a day or two you might want to set PARM_COUNTER_RATE_MINS for 15-minute intervals but analyze it initially at 60 minutes (default for ANALYSIS_SAMPLE_TIME). This lets you drill in for more detail if needed. But 15 minutes will collect a lot of data over a longer period running into weeks or months, so if it's more than a few days use 60-minute data collection intervals.
- LONGER TERM: Longer-term monitoring of a month makes sense to keep gathering data and seeing longer-term patterns. It helps to track when there are user complaints to identify "sore points" for closer investigation. If hourly data is too much over a month, you can change the analyzer to output results in 4-hour or 24-hour periods if needed. It's probably best to do one month segments at a time; too much more and the data gets to be pretty large and time-consuming to analyze.
- DON'T DO SNIPPETS: Don't run it in segments and then try to make sense of disjointed pieces if you can avoid it. It's easier to delete excess files than to join segments with gaps between them. Baselines can be taken from any isolated stretch of time (i.e. last Tuesday 9-5).
- ANALYZE ANY TIME: The commands are separated. So, while you have an ongoing monitoring session running for days in one command shell, you can run the gather/analyze commands at any time from another command shell to look at results at any time you want. There will be a warning if you try to copy data over an existing "gather" directory: you can either agree to overwrite it or just stop and adjust the RUN_ID to write to another directory.
- LET IT KEEP RUNNING: As long as the server is up when you start the run, it will continue even if the server is down or restarted. It will mark time by copying the last good period as placeholders and then flag those time columns as suspect ("?") in the analysis output so the number spike when the server comes back up makes sense. It is best to get long continuous stretches so you can see the ebb and flow of users and types of activities and keep the data on a regular hourly clock than to deal with gaps.
Q: Where can I find workload samples from IBM internal deployments like Jazz.net?
After extracting the JTSMon package, look for the directory named Data. This directory has sample workloads collected from Jazz.net. It looks like the following example:
The 200 users in the file names represent a rough estimate of the number of concurrent users that are active on average.
Q: Is there any quick way to convert the JTSMon CSV file output into charts and tables?
The JTSMon Visualizer Excel macro automatically converts nearly all the CSV output into Microsoft Excel workbooks that contain data, charts. and a table of contents for easy navigation.
Q: What do all those web service components mean?
This is a short summary of what the different system components (com.ibm.team..) do:
(Extracted from the JTSMon.pdf in the JTSMon distribution.)
- apt - Agile Planning and Tracking
- build - Support for Build Engines to access and process build requests
- calm - Collaborative Application Lifecycle Management (C/ALM) specific operations
- com.ibm.debug.team - internal debugging
- com.ibm.teami - I-System specific operations
- com.ibm.teamz - Z-System specific operations
- dashboard - Support for web browser dashboard presentations showing mix of reports and queries
- datawarehouse - Services unique to managing meta-data about the repository
- enterprise - Enterprise extensions
- filesystem - Manage versioned file artifacts between local workspaces and repository
- fulltext - Full text search capabilities
- interop - SCM integrations between Jazz and external systems, including work item synchronization with ClearQuest
- jfs – Jazz Foundation Services - Resource based storage and query services providing access to the JFS repository and user information, also used by JFS-based fronting applications
- links - Access and manage links between different types of artifacts such as work items and change sets
- process - Process definition controlling activity flow, roles, and permissions with customization
- reports - Reports provide data about activities and artifacts over time in the repository
- repository - User, license, and server administration services along with modeled storage services for persistent and query
- rtc – Rational Team Concert (one lone operation)
- scm – Source Code Management - basic change set management operations – check ins, accept/deliver, suspend/discard/resume, workspace management
- social - Support for Open Social integration
- vs - Visual Studio client platform support
- workitem – Work item operations - define/create/edit/delete/query work items
Q: How do I find out what's in my repository?
JTSMon offers a repository report tool. Repository reports use an internal API to collect data about the contents of the Jazz repository itself, providing insight into the distribution of different types of artifacts in the repository, based either on the component level (
repoReport.n.txt) or, in the more detailed report, by individual types of artifacts in the component namespace (
repoReport.n.itemized.txt). Data is returned in columnar format. The columns of greatest interest are the number of items (unique artifacts) and states (changes to those artifacts). Other columns show what percentage a namespace is compared to the overall total or additional information about storage size.
For more information see the JTSMon.pdf in the JTSMon distribution.
Q: While running the command "java -jar JTSMon monitor", I see the following error during execution:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target)
JTSMon uses the JAVA_HOME variable set for the current session. Many a times customers prefer to run the JTSMon utility on a different machine, and the newer JAVA_HOME might not be configured with the certificate provided by CLM. To fix this issue, one needs to following the steps mentioned below:
- ) Open the ikeyman in the local Java env set for JTSMon, (server\jre\bin\ikeyman.exe)
- ) Click open -> Browse to cacerts file -> click open Use password as "changeit")
- ) Change the scope of certificates to personal, and click on Export/Import
- ) Select Import option and browse to the Certificate provided in CLM:
- For default Liberty Profile in 601, this would be located in: server\liberty\servers\clm\resources\security\cacerts
- For Tomcat Setups in previous versions, this would be located in: \server\jre\lib\security\cacerts Close iKeyMan and rerun the monitor Command.
NOTE: The latest version of JTSMon is the 6.0 release which is required for working with CLM 6.0 because of changes in the data output. This will work with CLM 4.0.2 and CLM 5.x systems. However, the behavior of the floating license counters has changed as of the 4.0.6 release; the counters are now reset hourly as part of the License ETL job.