Mark,
I think this covers most of your comments above...
I agree that gathering extensive information on every transaction is very costly. However, we are not proposing that this tool be used routinely in production. I think the sensible thing to do is to gather aggregate information in such a way that has minimal impact on the running system. We seem to have this mostly covered at the moment as we can obtain, rollback, commit and in-flight transaction counters. This is great for identifying the presence of a problem, but IMO, in many cases the user would then need to turn up the logging to establish the root cause of the problem.
This is similar to how developers improve the performance of a system. Aggregate data (i.e. average throughput, average response times) is used to identify that we have a problem. The developer then attaches a profiler to identify the root cause of the performance problem.
I see this tool more as a profiling tool to be used when the aggregate data has identified an issue. In which case, the overhead of gathering this data is less of an issue, assuming it doesn't impact the system to the point where it skews the data being gathered.
The benefit of parsing the logs to get this data is that:
1) It can be done retrospectively from a user's log
2) We can automate the detection of common issues that would typically relied on a user/GSS/Transactions team person eye balling the logs.
3) We validate that the logs contain all the information required to detect these issues (assuming the right level is set).
We were planning on having a meeting with the Transactions specialists in GSS to find out there views on this tool and to target some high priority issues that Alex could focus on for his prototype.
In an ideal world, we'd like this tool to filter out more support issues at each level. I.e users discover the problem without needing to raise a support ticket; GSS discover the problem without having to contact the transactions team for help.