The ask: Can Instana do method-level tracing?

This is a common question from customers who want to replace their APM/observability vendor but must cover monolith applications and come in with a method-level-tracing requirement.

Why do customers want it?

Customers will use this analysis of every method call inside the monolith to look for the longest-running methods. They can point their performance engineers at these methods to make the monolith run faster. With IBM Instana Observability, we would like to look at a better way to make the monolith run faster, rather than copy other approaches.

This is a discussion we had with several customers, and they like the modern approach to modernizing the monolith, mainly because of the focus on improving the performance of the monolith. Customers using the traditional tooling do not know if those improvements will impact critical end-user experiences or less-performance-critical backend jobs that really don’t need to run faster.

Looking at a better approach with Instana

Let’s go to the pain point—a customer wants to make the monolith run faster. We measure the specific cases where real users were impacted (e.g., a latency was exceeded, a high error rate was observed, etc.) and then look at those specific cases to improve. We can then be sure that the performance engineers are focused on improving the parts of the monolith that impact end users and not on improving performance on things that do not matter to the business, such as overnight batch processing jobs. We can even measure the impact of the performance engineer’s work if we set up service level objectives (SLOs) against the monolith and track our improvements.

The set up

First, we need to describe the various functions the monolith performs for our end users. For example, a single monolith Java application for banking may perform checking account functions, money transfer functions and nightly reporting functions for audit purposes:

Application perspectives

In this example, we would want to set up Instana application perspectives for each of our key services—one for the monolith entry point for checking account functions, another for money transfer functions and a third for nightly reporting functions.


Now we can set up SmartAlerts for each of our application perspectives—this will set boundaries and provide alerts when we exceed them. Let’s say latency for any checking account function should happen in 500 milliseconds, money transfers should happen in 2 seconds, and nightly reporting functions should happen in less than 1 hour. Since Instana captures 100% of our real-user traffic, we will get an alert for every instance when our real traffic exceeds the boundaries we have set. We also will avoid working on performance improvements where we do not impact the end-user experience with this approach:

Improve the experience

Now, after some time letting Instana observe your monolith, we can look at each application perspective where we are getting alerts and focus on the specific user experiences that had the slowest latency.

Clicking into the trace, we will see the stack trace where the monolith was slow, including the exact time it took and the timings of any external calls, which could be to databases or other services. Many times, this alone will point to the cause if a database is performing badly or another service is the cause. If the problem is within the monolith itself, we can use our “always-on” Java profiler to see where the time was spent. You will see a stack trace of all the method-level calls to see any hot spots. This is where a performance engineer can improve the experience for just the outliers that actually impact the end-user experience. We expect this method to work for most of the performance problems in a monolith.

Need to dig deeper?

In the rare cases where we need more observability into the monolith, the Java performance engineer can use Instana’s configuration-based Java Trace SDK to instrument the code in areas that aren’t performing well, and we can get that deeper visibility directly into the traces and SmartAlerts we have set up.

Maintenance over time with IBM Instana

Once the monolith is performing how you would like it to, you can set up a service level objective (SLO) for each of your key services the monolith provides and track for compliance over time. Request a demo to get the most out of your applications.

Learn more about IBM Instana


More from IBM Instana

Observing Camunda environments with IBM Instana Business Monitoring

3 min read - Organizations today struggle to detect, identify and act on business operations incidents. The gap between business and IT continues to grow, leaving orgs unable to link IT outages to business impact.  Site reliability engineers (SREs) want to understand business impact to better prioritize their work but don’t have a way of monitoring business KPIs. They struggle to link IT outages to business impacts because data is often siloed and knowledge is tribal. It forces teams into a highly reactive mode…

Buying APM was a good decision (so is getting rid of it)

4 min read - For a long time, there wasn’t a good standard definition of observability that encompassed organizational needs while keeping the spirit of IT monitoring intact. Eventually, the concept of “Observability = Metrics + Traces + Logs” became the de facto definition. That’s nice, but to understand what observability should be, you must consider the characteristics of modern applications: Changes in how they’re developed, deployed and operated The blurring of lines between application code and infrastructure New architectures and technologies like Docker,…

Debunking observability myths – Part 5: You can create an observable system without observability-driven automation

3 min read - In our blog series, we’ve debunked the following observability myths so far: Part 1: You can skip monitoring and rely solely on logs Part 2: Observability is built exclusively for SREs Part 3: Observability is only relevant and beneficial for large-scale systems or complex architectures Part 4: Observability is always expensive In this post, we'll tackle another fallacy that limits the potential of observability—that you can create an observable system without observability driven by automation. Why is this a myth? The notion that…

Top 8 APM metrics that IT teams use to monitor their apps

5 min read - A superior customer experience (CX) is built on accurate and timely application performance monitoring (APM) metrics. You can’t fine-tune your apps or system to improve CX until you know what the problem is or where the opportunities are. APM solutions typically provide a centralized dashboard to aggregate real-time performance metrics and insights to be analyzed and compared. They also establish baselines to alert system administrators to deviations that indicate actual or potential performance issues. IT teams, DevOps and site reliability…