Almost no one writes all their own code. Whether you are an engineer in IT operations or a developer, you are most likely working with code written by someone outside your organization. As a result, one question we hear repeatedly is how do you monitor third-party code?
The answer is that it depends whether you have access to the runtime, the runtime and the source code, or neither. The good news is that in every case monitoring the code you didn’t write is easier than you might think.
Standalone Software
Commercial off-the-shelf software (COTS) provides a complete, self-contained solution running in the equivalent of its own box in your environment. While you generally have access to the runtime, it can be difficult to instrument because you don’t know what business transactions are most meaningful. With AppDynamics, the challenge of figuring out what to monitor is made easier with pre-built support for many popular COTS solutions such as SAP, Atlassian Confluence, or IBM Integration Bus.
For products where we do not provide out-of-the-box visibility, you can write an extension that will provide insight into what is going on inside the software. For example, by ingesting metrics such as the number of requests per minute or the associated disk usage provided by the COTS software, you can correlate unexpected changes to baseline behavior to the corresponding business transactions.
Remote Services
In contrast to COTS software, third-party remote services can only be accessed via the network and offer no access to runtime whatsoever. By monitoring the endpoints—calls to and responses from a service—AppDynamics will give you a clear indication whether or not a particular service is responsible for slowness in an application. And we also have additional capabilities that help you monitor the health of these endpoints through Service Availability Monitoring or Synthetic Monitoring. If your third-party service offers visibility metrics, we can integrate those into your AppDynamics dashboard. We can also set up alerts that trigger when the average response time rises above a certain level, so you can easily ensure compliance with SLAs.
Libraries
Third-party libraries are another common scenario. What is the best way to troubleshoot issues with a threading library, a logging library, or a client library for a cache? If a library is integrated with your code, your business transactions will flow through it. If there are any performance issues with your application, the third-party code will, in most cases, show up in a snapshot and you will be able to see if it is to blame. In some more advanced cases, however, additional instrumentation may be necessary. Please see documentation on how to Configure Instrumentation for more information.
Conclusion
Third-party software may seem like a black box, but extracting performance insights from someone else’s code can be surprisingly simple. AppDynamics offers pre-built support for standalone software and provides visibility into the behavior of third-party services by observing the health of their endpoints. Many third-party libraries are automatically incorporated into AppDynamics’ snapshots. Our belief is that it shouldn’t matter who wrote the code, business and application performance should be transparent all across your networked environment.
