Skip navigation

TMART

8 posts
Share This:

Summary:

While the Tomcat vulnerability issues in TM ART are independently categorized as “Medium”, BMC understands that there are organizations that perceive the risk as “High”.   As such, BMC has developed and tested an immediate work-around and is also in the process of developing a product update to address this issue.

 

Recommended Approach

BMC is in the process of developing an update that will:

  1. Address the Tomcat vulnerability. TM ART 4.2 uses Tomcat 7.0.29 which has security vulnerabilities. Tomcat 7.0.55 or later is needed.
  2. Address the recently reported OpenSSL vulnerability. See To prevent another Heartbleed, severe OpenSSL flaw to be patched | ZDNet
  3. Bundle these fixes plus all hotfixes released since SP2 into a single, easy to install deliverable.  This will be SP3.

We intend to make this service pack generally available by June 5th and we recommend that customer use this method for remediating the issues.

 

Immediate work-around

BMC realizes that some customers will want to address these vulnerabilities immediately.  For these customers we have developed and tested a process where customers can upgrade the underlying Tomcat components without making changes to the TM ART installation.   While this work-around immediately addresses the security issue, it is also more complex and time-consuming than applying the service pack.   As such, BMC only recommends this path for customers who perceive this risk as critical and who cannot wait until the service pack that will be made available by June 5, 2015.

 

Next Steps

Customers interested in applying the workaround should reach out to support to request documentation and assistance.

Customers with questions on this process should reach out to Support or their account team for additional information

Share This:

TMART customers ,

 

In May of 2014, a letter was sent to the contact on record for all TMART customers.   This letter discussed BMC's plans to end support for TMART and offer a migration to a replacement product.  Below is a copy of that letter for additional reference to those who may not be the  contact of record with BMC.

_____________________________________________________________________________

 

Dear TMART customer,

 

You are receiving this letter because you own licenses for the BMC Transaction Monitoring Application Response Timer (also known as TMART) product. 

 

BMC is sending you this letter to:

  1. Notify you that BMC will end support for BMC TMART as of March 31, 2019
  2. Provide you the information you need to easily migrate from BMC TMART to a new replacement product between now and the planned end of support in 2019

 

BMC has a replacement offering for BMC TMART called Borland Silk Performer Synthetic Transaction Monitoring for BMC Software. This replacement solution offers additional value and a simple technical upgrade path.  Most importantly your TMART scripts can be used as-is with the new platform. Details of this replacement solution is here.

 

Next Steps

BMC recommends that you contact your Account Manager to discuss how to obtain the replacement product. While there is still plenty of time between now and the planned end of support date in 2019, it is important to begin developing your migration plans now.  Your BMC Account Manager can help you understand the impact of this change and the best timing for your migration.   Your Account Manager will also be able to provide information about license migration, product capabilities, and ongoing roadmap plans.

 

Ongoing support:

Per BMC Support Policy, TMART is now in “Limited Support” status.  Between now and the end of support date, BMC will continue to offer telephone support and provide patches and hot fixes for critical issues.  BMC will no longer be developing new features or supporting additional platforms with TMART.  You can find the full details of Limited Support by visiting the BMC website at: http://www.bmc.com/support/product-support-policy.html

 

Impacted Licenses:

The following products have been withdrawn and will no longer be supported after March 31, 2019:

 

Product Name

End Of Support Date

BMC ProactiveNet Performance Management - Synthetic Transaction Monitoring and Analytics

3/31/2019

BMC Synthetic Transaction Monitoring and Analytics - License Add-on

3/31/2019

BMC ProactiveNet Performance Management - Synthetic Transaction Analytics

3/31/2019

BMC ProactiveNet Performance Management - Synthetic Transaction Monitoring

3/31/2019

BMC Transaction Management Application Response Time - Infrastructure Edition

3/31/2019

BMC Transaction Management Application Response Time Execution Server - Infrastructure Edition

3/31/2019

BMC Transaction Management Application Response Time - Service Level Edition

3/31/2019

BMC Transaction Management Application Response Time Execution Server - Service Level Edition

3/31/2019

 

Please be assured that BMC is committed to providing you with state-of-the-art solutions. If you have any other questions, please contact your BMC Account Manager at 1-800-841-2031, BMC Customer Support at 1-800-537-1813.  You can also email TMART specific questions to:

TMART-Questions@bmc.com

 

Thank you.

Share This:

1. SilkTest 13.5 is no longer supported in TM ART.  Go to SilkTest 15. KA404663.

 

2. SP2 of TM ART 4.2 drops support of Citrix Server 4.5. And the code that supports Citrix Server 6.5 is much better in SP2 of TM ART 4.2 so if you are struggling with getting TM ART monitors to work with Citrix Server 6.5 please try SP2 of TM ART 4.2. A Technical Bulletin for this is being worked on.

 

3. SP2 of TM ART 4.2 adds more support for Remedy. TM ART Monitor Workbench 4.2 is based on SilkPerformer 9.5 but for SP2 of TM ART 4.2 all of the SilkPerformer 15 code for Remedy monitors was added to TM ART Monitor Workbench.  The Technical Bulletin for SP2 tells the new levels of Remedy that are supported.

 

Dan Egner

Share This:

Top Ten TM ART Database Tuning tips. And one to grow on.

 

People love the down-home goodness of TM ART monitoring so much they keep adding monitors to it until it pops like a ripe watermelon at a Gallagher show.

 

And the performance bottleneck of TM ART is usually the TM ART database.

 

So here are the Top Ten TM ART database tuning tips.

 

1. Rebuild the SV_TimeSeriesData indexes. This is documented in the Admin Guide. This tip is the most important one. TM ART uses the SV_TimeSeriesData table a lot.  It is usually 50 to 70 per cent of the size of the entire TM ART database and is written to constantly update with monitor results.

 

2. Give the database more virtual memory.  This tip applies to most databases.

 

3. Do not share the database server computer. I know that in kindergarten you were taught to share but you gotta unlearn that. Do not run your payroll application on the same computer as the TM ART database.

 

4. Do not share the database server software. So do not have your account receivable database use the same database server as TM ART.

 

5. Do not share the database disk space. You do not want some unrelated backup to slow down TM ART.

 

6. Enable Persistent Result Data. Information regarding Persistent Result Data is in the TM ART Administration Guide starting on page 107 here: http://documents.bmc.com/supportu/documents/13/94/441394/441394.pdf

 

I first started telling customers to turn on this feature because it would prevent the loss of data if a TM ART hang happened. But then I noticed that when customers turned on this feature the TM ART hangs decreased or disappeared.

 

7. Use the new DataDelete instead of the old one. The new one is documented in the TM ART Getting Started Guide which is here: http://documents.bmc.com/supportu/documents/25/99/442599/442599.pdf

See Chapter 7, Data Deletion utilities.

The old way is documented in the Admin Guide starting on page 109 in the section named Reducing Repository Size and Stabilizing Performance on the Database Server.

 

8. To be on the safe side, Oracle DB SGA may need 6 - 8 GB of memory allocation.

 

9. Do not put the database on a VM.  Yes, we all love VM's but since you do not want the database to share anything it is overhead for no good reason.

 

10. AppServer computer needs to be at least 6 gig. This is the OS Virtual Memory, not a database or Java parameter. Having only 2 or 4 gig of virtual memory on the computer where the AppServer runs causes performance problems.

 

11. Reduce unnecessary TrueLogs.  TrueLogs are much bigger than ordinary monitor results. Writing a lot of TrueLogs can slow down a database.

 

I’ve used the steps described here to help many customers get better performance out of TM ART by getting better performance out of its database. I hope this info helps you avoid issues.  Please rate it below to give me feedback.  To see more like it, see BMC Application Management Support Blogs

Share This:

TM ART Log Analyzer.

You can analyze TM ART log files and answer lots of TM ART questions quickly.

TMArtLogAnalyzer25pc.jpg

Caption for picture above: The original TM ART Log analyzer, now in a museum curated by Hal DeVore.

 

Major update: The older version of this blog entry had the bat file named findstr.bat. Bad! That means that the findstr.bat file will call itself instead of calling the built-in findstr utility and that means a vicious hanging loop.  I have corrected this by having you call the bat file findstx.bat instead of findstr.bat.

 

Summary:

1. Put a copy of all the TM ART logs involved in one directory. For example C:\tmp\log1

2. Put the attached findstx.bat in that directory

3. Run findstx.bat

4. Findstx.bat will read in the *.log files and create .txt files.

5. List the *.txt files.

6. All .txt files that are greater than 0 bytes are interesting.

7. Use the text in the .txt files to search the BMC support knowledge base.

 

You can re-run this as many times as you like. It does not alter the .log files and it overlays the .txt files.


Details:

After working on TM ART for a while I noticed that I was always looking at the log files for the same text.  And after TM ART started supporting the use of Oracle as the TM ART repository with TM ART 3.0 in January 2007 I noticed I searched the logs for the text "ORA" quite a bit. So I created a .bat file to do the most common log file searches.

 

Here is an example. After you run findstx.bat and it displays "dir *.txt" you get this:

log2.png

 

So since rollback.txt contains more than 0 bytes it may be interesting. So we search the knowledge base at the BMC support site and we find knowledge article KA366959. And that tells me I need to tune my database that is being used as the TM ART repository.

 

That is just one example.  In general you look at E.txt first and W.txt second since they contain Error s and Warnings.

 

Here is bit of information about each file produced:

AppServershutdown.txt - Helps establish a timeline

AppServerstartup.txt - Helps establish a timeline

complete.txt - Helps establish a timeline

DataDelete.txt - Shows internal DataDelete information

DeleteMonitorDataOrder.txt - Shows internal DataDelete information

E.txt - Shows errors. Look at this file first.

finished.txt - Tells when internal DataDelete sections finish

LowOnMemory.txt - Helps with tuning.

Memorylimitexceeded.txt - Helps with tuning.

ORA-00600.txt - Oracle error from TM ART database.

ORA-01653.txt - Oracle error from TM ART database.

ORA-01654.txt - Oracle error from TM ART database.

ORAdash.txt - Oracle error from TM ART database.

rollback.txt - Oracle rollbacks indicate database tuning is needed.

Rule37.txt - We had an issue with Rule 37 for a while.

shut.txt - Helps establish a timeline

start.txt -  Helps establish a timeline

StartAndShut.txt - Helps establish a timeline

UpdateException.txt - Specialized problem from the past.

UpdateExceptionFailed.txt - Specialized problem from the past.

W.txt - Shows warnings. Look at this file second.

writtenWithin.txt - Shows how long it takes to write results, used for tuning.

 

Note on the attached file - rename findstxbat.txt to findstx.bat. I did not want to have a .bat file just to avoid someone running it accidentally.

 

I would love to hear comments on whether you find this useful or how to possibly make it more useful.

 

Update August 23, 2015: I attached an updated bat file.  See comments in the file. (You will have to rename it to findstx.bat or whatever.)

Update October 5, 2915. I attached an updated bat file and deleted the old one from August 2015. See comments in the file. (You will have to rename it to findstx.bat or whatever.)

Update April 25, 2017. I attached an updated bat file and deleted the old ones See comments in the file. (You will have to rename it to findstx.bat or whatever.)

Update August 30, 2017. New findstx.bat file, contains one enhancement. Note that some output file names contain knowledge article numbers to make it easy to find the related knowledge article.

Share This:

Can you run twice as many TM ART monitors on your execution servers?

 

Customers love TM ART monitors so much that they keep adding more and more of them until TM ART is full. Sometimes it is the execution server that gets full first. Up until now you could put about 120 to 180 simple URL Checkers on an execution server and if you had monitors with a bigger footprint, like SilkTest monitors or Citrix monitors the number of monitors per execution server was far less.


Customers were asking for ways to put more monitors on each execution server. One savvy customer pointed out that it is the Java environment that ran out of gas first so how about using multiple Java environments on each computer, which means running multiple instances of the execution server on one computer.

 

When I mentioned that to R&D, the QA guy told me that QA already does that. But it was not officially supported. So we had this unsupported feature for a while that only one or two customers and BMC QA used.

 

Then we got more customers asking for the ability to run more TM ART monitors per execution server computer.

 

01 PressureCooker.jpg


So we had some pressure to make it official.

 

So we went through the procedures to get the feature officially supported and now it is. The Technical Bulletin for it is here:

 

http://documents.bmc.com/supportu/documents/46/33/444633/444633.pdf

 

Please make note of these caveats:

-Before using the utility to run multiple execution servers on your machine, make sure you have enough resources (CPU, processor, memory etc.) to execute more than one execution server.  If you add more execution servers and run out of resources, your server is not fit for this configuration.

-When you encounter an issue on the execution server machine, please make sure it is not related to multi-execution server install.  Shut down all the execution servers but one and see if the problem persists.  If it doesn’t persist, your server is not able to work with multiple execution servers.

- Automatic upgrade of remote execution servers (for either full packages or service packs) will not work on remote execution servers with multiple execution servers.
- The BMC TM ART Configuration Tool for changing the TM ART folder directories will not work on a multiple ES environment.


I installed it on a support computer here that runs TM ART 4.1. The install was pretty simple. Mainly I just told it that I wanted the maximum number of additional execution servers which is 5. Of course, you should make sure your execution server computer is big enough for how many execution servers you wish to run.  I recommend you start by adding only one additional execution server.
Here is what the TM ART Service Manager screen looked like for me:

02 TMARTserviceManager.png

 

And then I went to the TM ACT Locations screen and added the execution servers and here is what I got:
03 ListunderLocation.png

 

The middle section of the System Health screen looked like this:
04 SystemHealth.png

That is the middle section that you set when you turn on the SystemHealthShowExecServerDetails tag in SccFrontendBootConf.xml. There is a write-up on that in the TM ART Admin Guide http://documents.bmc.com/supportu/documents/13/94/441394/441394.pdf

Let's take a gander at it on Task Manager:05 taskMgr.png

 

Yes, it does require more memory.

If you have thoughts on this I would love to hear them.

Share This:

Is it possible to have TM ART check a URL every 10 seconds?
When a customer asked me about this back in June I was skeptical.  But instead of running the monitor every 10 seconds what you do is have the monitor loop every 10 seconds and have the monitor check the URL inside the loop.  After each URL check the script checks for errors and stops the monitor and sends the data back to TM ART Central if an error is detected.


I sent the customer a script that I thought he could use as an example and I starting running it on a test system here at BMC Software also.
The monitor that I used is attached. It is just a sample, of course.
So you add that monitor to a project. I suggest creating a new project just to keep it simple starting out.

And here are the parameters you specify when you add the monitor to the project:

01 ParametersOfTheMonitor.png

Notice that you could even set the time between URL checks to be even less than 10 seconds but you wouldn't want to do that would you?
And since I want to run the monitor every ten minutes I set the number of loops to 60.

 

Now the monitor configuration:02 UseWrtInsteadOfTrueLog.png

 

I turned off TrueLogs because the .wrt file that the script generates seems to have enough information in it. The .wrt file is way smaller than the TrueLog so it will take up a lot less room in my TM ART repository and be written faster.

 

And now the schedule:

03 RunIntervalIs10Minutes.png

 

I want it to run every 10 minutes.

 

And the execution log:


04 ExecutionLogShowsMonitorRunALongTime - Copy.png

Most TM ART monitors run in a few seconds. But notice that this monitor takes 590 seconds, just 10 seconds shy of 10 minutes, to run because of all that wait time.

 

And the result details:

05 ResultsShow60AccessesPer10Minutes.png

 

Notice the count is 60 because the monitor checked the URL 60 times during the 10 minutes that it ran.

 

The monitor produces a .wrt file when it encounters an error with the application that it is monitoring. Here is an example of the contents of that .wrt file:


2013-07-26 10:46:23 WebPageUrl : http://trex002:19120/bmc
2013-07-26 10:46:23 Error Number: 10061, Facility: 6, Severity: 3
2013-07-26 10:46:23 WinSock: 10061 - Connection refused
2013-07-26 10:46:23 host="trex002:19120", attempts=3
2013-07-26 10:46:23 In line 164 of C:\temp\SCC_ExecServer_19124_19125\PerfProjects\PerfPrj_111_1374844742009\MonitorLoop.bdf
2013-07-26 10:46:23 Loop counter = 39 of 60

 

The monitor seemed to work fine.


Does anyone else think this might be useful?

Share This:

If you've visited the ProactiveNet Performance Mgmt to keep up with TMART (discussions, docs, blogs and ideas), then you may have noticed some of the discussions are migrating to BMC TMART


To make it easier for others to join and participate in our TMART Community fun, we are creating this new BMC TMART sub-forum for BMC Application Management  under the BMC Communities Product Forums. We expect that re-locating this community will improve usability and drive greater participation.  We believe that the new forum provides a concentration point in our effort to serve our TMART community better.   Thank you for being a part of the Community!


--Hal

Filter Blog

By date:
By tag: