Application Management (AM) includes project management, development, testing, quality assurance, release management, application monitoring, and responding to the information supplied by monitors. Application Performance Monitoring(APM) is application monitoring that is focused on performance rather than security, availability, planning, or some other matter.This article is part three of a primer for those who have never heard about APM. It is helpful to read part one and part two first.Part Two of this article ended by saying:
“This allows the development team to effectively implement end-user experience monitoring; user-defined transaction profiling; application component discovery and monitoring; and application component deep-dive monitoring, all with just one tool.”
Part Three continues by describing how to use Paid Monitor cloud-based monitoring to accomplish user-defined transaction profiling, and application component discovery and modeling.
User-Defined Transaction Profiling How-To
User-Defined Transaction Profiling watches a transaction as it works its way through the application stack and infrastructure services. It measures how long it spends within each layer or service. These data help identify the layer or service that is slowing the application down.
If your programming language of choice allows you to send an HTTP request to a web server (which describes all the major languages), then the Paid Monitor Open API lets you send any data to any Paid Monitor monitor. This simple tool is ideal for monitoring the time spent within each layer or service.
To implement user-defined transaction profiling, first record the timestamp just before entering an application layer or invoking a service. Then invoke the layer or service. Then subtract the previously-saved timestamp from the current timestamp. This tells you how long your code was in the layer or service. Finally, use the addResult action to send the time differential to your monitor.
The code is the easy part. Identifying the layers or services you want to monitor is not so cut-and-dried. However, this is a necessary step that any monitoring system will require. Of course, you will focus on those that have proven to be troublesome in the past. You will likely want to keep track of recent modifications, too, even if you do not expect trouble from them.
You need to create the monitors before you start adding results to them. You can use the API’s addMonitor action to create a monitor, but IMHO it’s easier from the web interface.
The addResult action requires the api key, the authorization token, and the monitor id. These data are also available through the web interface. You can write code to retrieve them, but you don’t have to.
And that’s all there is to it. You can use a stable product with a simple interface to profile invocations of any (or all) layers/services.
Application Component Discovery and Modeling How-To
Application Component Discovery and Modeling records what software and hardware components are exercised as application transactions are executed.
The same Paid Monitor API that is described above can work for you here, too. Just use the addResult action from the point at which the software/hardware components are used. If you want to record the amount of time spent using them, code it as described above. If you are only interested in a count of the number of accesses, forget the timestamps and send the value 1 to the monitor.
Again, the monitor needs to be pre-created and you need to get the api key, the authorization token and the monitor id. These things only need to be done once.
References
The Application Performance Monitoring Primerby Warren Gaebel.
