Production debugging is one of the most difficult parts of the job for any software engineer and one of the most underrated problems faced by IT. Developers usually rely on logs to troubleshoot production issues. They go through hundreds of lines of logs, sorting through complex logic as their stress levels rise, acutely aware that the bug they are looking for could be crippling the business. It’s painstaking, laborious work at best, and all too often the relevant logs are not available.
Developers need better tools to debug production issues faster. At stake is not only lost revenue but often something even more valuable: The trust of their customers.
I’ve spent many late nights staring at my computer trying to find the root cause of an issue in production environments. The general lack of insights into what is happening in the production environment makes this hard enough, but if the code has been inherited (legacy code) or involves timed elements such as background processes or cron jobs, things get even more difficult to track down. Engineers (myself included) often don’t have a clear understanding of the entire application, so it’s hard to know if the issues we’re tracking down are related to a change we made, or something that changed in another part of the codebase. We look for answers in the logs, but it feels like we are hunting for a needle in a haystack. Adding additional logs in search of more relevant data only increases the amount of proverbial straw and is probably not an option if the issue we are dealing with is time-sensitive.
During these late nights, I used to wish that production environments were more like a local developer environment where debugging is relatively easy, thanks to tools like the debugger in my local IDE or browser. Wouldn’t it be nice to have a debugger or a dynamic logging device in production? Developers need a magic wand (or magnet) to get all the needles from the haystack of production logs! Well, it turns out that the Information Points feature of AppDynamics was the magic wand I was looking for.
What are information points?
If you are not familiar with AppDynamics, consider an information point as a tool that allows you to inspect the input parameters or return value of any invocation of a method along with additional metrics about the execution time of the method for each invocation. If you are familiar with AppDynamics, information points are similar to data collectors in business transactions. However, while data collectors show application data in the context of a business transaction, information points reflect data state across all invocations of a method, independently of business transactions. They also let you apply computations to the values, for example, representing the sum or average for a method return value or input parameter.
Below is an example of how I have used information points as a production debugging tool. You will notice the debug flow is very similar to the way developers find and fix issues using an IDE.
One of our customers was reaching the data limits for one of the metadata items we collect, and the customer was adamant that the stale/old data was not getting purged. Our operations engineers increased the limits a couple of times, and the issue got escalated to my engineering team. The system was designed in a way where the stale/old data was deleted by a background cron task. The same background task was used for all similar data, so it was hard to diagnose what was going on and whether the background task to clean old data was being invoked for that particular account and metadata records. There were no relevant logs available to debug this issue further.
To resolve the issue I created a new information point on the Information Point Page with a few clicks as shown in Figure 1 (below). The information point was created on the delete method of the background task for that particular account and metadata record. I also created a custom metric for the return value which returned the number of deleted entities.
Code block for the delete background task:
DeleteBackgroundTask {
public int deleteStaleEntries(int accountId, String entityType) {
Delete code…
}
}
Figure 1: Information points created with custom metric.
Within the next few minutes, I was able to confirm that the background job to delete stale entries was triggered every 10 minutes and was working as per design. I also was able to see how many records were deleted.
Next, I created another information point for this particular account on the method that was creating the stale entries. This information point had a custom metric that collected the number of records being created. From this information, I was able to determine that the customer was creating these records at a rate higher than the documented limits, and our delete task could not keep up. This information was then conveyed to the customer, they were able to adjust their usage, and the entire issue was solved within less than hour.
The Information Points feature in AppDynamics has truly changed my life. Information points help me understand what is going on in real time, and I use them regularly to debug production issues. They are also used by our quality engineers to test complex background tasks. With information points, problems can be easily isolated to a particular method or segment of code.
I have just one word of caution: There is a limit on the number of information points that can be added to the system as collecting too many can impact your own application performance. Please make sure you delete the information points that you create during your debugging session so you are prepared for the next one. Happy debugging!
For more details on information points, check out the docs here. You can also learn more about AppDynamics with our guided tour or by scheduling a demo today.
