|
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. |
|
