OCS: Prototyping ARM with RootCause
The normal process for adding ARM instrumentation to an application is as follows:
- Select the transactions to measure.
- Determine the appropriate ARM points for transaction and subtransaction measurements.
- Modify the application to include calls to the ARM API.
- Add ARM agents to collect the data and configure a management system to manage the information.
In theory, the process is straightforward. In reality, it is rarely that simple.
Simplify ARM with RootCause
Now OC Systems offers a method for prototyping the ARM instrumentation that makes ARMing your application faster, much easier, and significantly less expensive.
We use our software instrumentation tool, RootCause, to insert ARM calls at runtime, as the application executes.
With RootCause, you can insert, delete or change ARM calls easily, without making any changes to application files. This lets you prototype your ARM calls—you can iterate quickly, load test and finalize the ARM code in a fraction of the time it would normally take.
Prototyping ARM instrumentation in this way resolves many of the issues you would otherwise encounter when implementing ARM.
ARM implementations involve many groups within IT
An ARM implementation effort crosses many different groups within the IT department:
- Operations will be collecting the ARM data and will receive alerts based upon the information.
- Tech support will be notified when slownesses are detected and will be required to perform triage.
- Development will modify the system to incorporate ARM instrumentation.
- Performance teams will use the data for analyses such as capacity planning.
- Architecture groups will have specific areas that they desire to monitor.
Without prototyping:
Prototyping with RootCause:
This complexity makes managing the ARM implementation challenging. It can be difficult to balance the needs and concerns of each group, which can become so difficult that the project stalls.
Each group needs to be consulted, but minimal effort is required on their part. You can quickly show useful ARM data from the actual system, making it a lot easier to get cooperation from IT staff and buy-in from management.
ARM calls take several iterations to get right
There are many decisions involved in defining the ARM calls:
- Where do the ARM points go?
- How much ARM data should be aggregated?
- What context data should be included with ARM calls?
- Should additional data be collected after a slowness has been identified?
Without prototyping:
Prototyping with RootCause:
With research and effort, estimates can be made. But it almost always takes several iterations to get useful data at acceptable overhead. In a large system this effort can take many months.
With RootCause, ARM calls can be inserted, removed and modified without changing any application files, so it is easy to iterate rapidly. The prototype can exist on the same testing platform as the current build, eliminating the need for a separate CM build that would need to be modified and maintained in parallel with the current system. Being able to prove that the ARM calls hold up to load testing makes it easier to get buy-in as well.
Read more:
- ARM with RootCause (PDF, 265KB)