This article discusses transaction monitoring and the 4 approaches of network appliances, Java/.NET deep dive, end-user measurements, and agent based monitoring.
You know that your enterprise is in dire need of a transaction monitoring solution. Transaction latencies are in the sky, some transactions do not even make it through, mysterious bottlenecks pop up during peak use, and users call in with complaints. Implementing a transaction monitoring solution is unavoidable.
The problem is, when you look at all of the transaction monitoring solutions out there they all look the same. Every vendor seems to make the same claims: end-to-end transaction monitoring, full visibility into transactions, link IT to business processes, low overhead, perform root cause analyses, find application performance problems before they impact your clients, and so on.
So, how can you make sense of all the claims and find the transaction monitoring solution that is right for you? This article reviews the various transaction monitoring approches and presents the advantages and disadvantages of each.
1. Transaction Monitoring: Four Solution Types
- Network Appliances: Includes all solutions that collect data by non-intrusively listening to network traffic.
- Deep Dive Profilers: J2EE/.NET code instrumentation. Includes all solutions that use bytecode instrumentation (or Java/.NET Hooks) in order to collect thorough code-level metrics.
- End-User Monitoring: This approach utilized end-user latencies either by connecting an appliance to the network at the Web server or by installing agents on the client side.
- Agent-based Transaction Tracing: Solutions where agents are installed on all relevant tiers and all transactions are traced everywhere.
- Transaction Monitoring with Network Appliances
- What they do: perform transaction monitoring by network sniffing in order to identify application events (or transaction segments), and then reconstruct the entire transaction by fuzzy matching.
- How they do it: network appliance solutions usually connect to a port mirror in order to collect the traffic, and then try to reconstruct the entire transaction. Information needs to be collected directly from every node that is of interest.
- Main advantage: transaction monitoring by connection to the network means that no overhead is added and it is simple to install.
- Main drawback: transaction monitoring has to be done by an algorithmic approach since they cannot collect data directly from the servers, which leads to inaccurate transaction metrics and topology.
Correlsense SharePath vs. Network Appliance Solutions
SharePath can provide data from within the servers, enabling resource consumption and all of the actual parameters of the transaction segment to be collected without requiring fuzzy matching, which can be inaccurate. SharePath is much more flexible, is very non-invasive, and simply records what goes in and out of the server, and it can dive-in to collect metrics from encrypted data packets.
2. Transaction Monitoring with Deep Dive into the Java/.NET Code
- What they do: these transaction monitoring tools provide deep diagnostics into Java applications to the code level. They are used by J2EE/.NET experts in order to locate problems before deployment.
- How they do it: transaction monitoring is done by bytecode instrumentation (or Java hooks) that retrieve data from the nodes that are running J2EE/.NET applications. This is done by utilizing the class loading mechanism of the interpreter (JVM for J2EE or CLR for .NET) that, in order to intercept specific classes or methods, calls within the application.
- Main advantage: provides a lot of rich information for developers. This type of transaction monitoring brings up the specific line of code that is the cause of the problem.
- Main drawback: transaction monitoring cannot be done for all of the transactions running on the system (up to 10% for short periods of time), implementations are lengthy and invasive, and the person ultimately responsible for application performance may be completely overwhelmed and/or clueless by how to utilize the massive amounts of information retrieved.
SharePath vs. Deep Dive
Transaction monitoring by deep dive cannot load test at full capacity during development or monitor all transactions during production like SharePath can with its very low overhead. SharePath can be used with one of the many J2EE and .NET profilers that are available on the market today (some are for free) in order to aid application development before deployment. Because of its ease of use and high-level view, SharePath can be used by IT operations and infrastructure teams to trace transactions at all tiers, providing a full topology of the transaction flow. Conversely, deep dive solutions provide metrics only at the application server, and they have limited horizontal visibility. Lastly, SharePath’s architecture is environment-independent and can be deployed on any server, not just the .NET or J2EE server. The product’s technology is based on process wrapping and, therefore, is non-invasive, which enables fast and clean implementation.
3. Transaction Monitoring with the Help of End-User Measurements
- What they do: this transaction monitoring approach is based on managing the application by monitoring the end-user response times and then performing customer analytics and system heuristics from the Web server outward.
- How they do it: there are two general strategies to implement transaction monitoring with this approach. The first is by installing an agent on the user’s computer, either on the desktop or in the browser with the help of a Java script. The second is by installing a network appliance on the Web server. Some solutions have servers around the world that test performance from different regions.
- Main advantage: provides valuable metrics about what your customers are experiencing. Transaction monitoring with this approach puts customers first.
- Main drawback: transaction monitoring stops at the Web server. The few solutions that let you peek beyond that can only provide very limited metrics. You will know that there is a problem, but you will have no idea where to find it.
SharePath vs. End-User Monitoring
SharePath can be extended with an end-user monitoring solution in order to cover all bases. The product finds the specific location of problems versus only alerting about them, providing important insight and saving time. Real end-user monitoring products do not provide much information in the development phase. However, with SharePath, you can test your application pre-deployment.
4. Agent-based Transaction Monitoring
- What they do: software agents are deployed along the application path across the different tiers so that a unified view of the entire application is provided. What characterizes these solutions is that the full flow of every single one of the transactions running on the system is recorded in real time, at thousands of transactions a second. This solution is just as valuable to IT management as it is for the application development team.
- How they do it: agents installed at each tier send data collected to a central repository for processing. Agents may be installed with the help of JVM/CLR instrumentations at the application server (one technical execution approach), or they may be installed as kernel modules (drivers), shared objects (Unix), or DLL files (Windows) at the operating system level. Agents may also be installed at databases, MQ middleware servers and legacy mainframe computers. Every event or transaction segment is recorded along with all of its real parameters and then accurately re-constructed.
- Main advantage: transaction monitoring is done all the time for every single transaction. This is the only true end-to-end solution that includes the middle and all of the important data that is to be collected from the servers in a way that does not weigh down the system.
- Main disadvantage: by themselves, these transaction monitoring solutions cannot get deep into the code or see what is happening at the browser level.
SharePath vs. Other BTM Solutions
SharePath’s deployment is faster and is not as labor intensive as other BTM solutions that need to perform code instrumentations—for example, SharePath installs drivers, DLL files, objects, etc. SharePath can be easily used by anyone, and it works at the operating system level (wraps processes as opposed to bytecode instrumentation) and is therefore environment independent. Residing at the OS level means that SharePath can better monitor resource consumption beyond CPU consumption (IO, network, and can be customized to collect anything). View videos.