If you’re involved in troubleshooting or optimizing application performance, your life just got much easier with the IBM Instana™ platform’s newly released analyze capabilities. And the best part—you don’t have to pay any extra fees to use our analytics capabilities, so you can benefit from them immediately if you’re already an IBM Instana client.

Troubleshooting and optimizing all the microservices

In our last significant release, we introduced Application Perspectives—the ability to create dynamic application definitions that continuously update as you release new software and scale your environment. Along with this functionality, we delivered a set of curated dashboards that are used to quickly identify any requests that are slow or throwing errors.

In this release, you have two primary ways of getting to the Analyze screens:

1. You can drill down from an Application Perspectives dashboard to analyze traces or calls. Benefit: The Analyze screen is already prefiltered using the context of the Application Perspectives, service, service endpoint, trace, call, error message, database call and so on.
2. You can select the top-level Analyze menu item to begin your analysis with the complete data set contained within the IBM Instana platform. Benefit: It’s the perfect place to search for optimization opportunities without being limited to any given portion of the data set.

What are traces and calls?

You need to understand the concept of traces and calls to take full advantage of the data within the IBM Instana platform and solve difficult performance problems.

Quoting the IBM Instana Observability documentation:

• “A trace is the sequence of synchronous and asynchronous calls between service endpoints. Services talk to each other and deliver a result for a user request. Transforming data in a data flow can involve many services.”
• “A call describes an activity within a monitored process, typically a request between two services.”

A trace is composed of one or more calls. A call is composed of either one or two spans:

• Entry span: For example, an HTTP request from an uninstrumented process to an instrumented process.
• Exit span: For example, a database call from an instrumented process to a database. Databases aren’t instrumented.
• Exit plus entry span pair: For example, an HTTP request from an instrumented process to another instrumented process. There will be an exit span for the client process and an entry span for the process serving the response.
• Intermediate span: For example, custom spans are added through the software development kit (SDK), instrumented in-process caching or instrumented view technologies.

Troubleshooting performance problems—from Application Perspectives to Analyze

Application Perspectives offers a set of curated dashboards that make it easy for anyone to identify problematic services, endpoint traces, or calls. When you’ve identified a problem, you can immediately jump to Analyze to explore the traces and calls in the exact context you drilled down from.

Application and service performance optimization through Analyze

Site reliability engineers (SREs), developers and DevOps are all interested in finding opportunities to optimize the services they write or support. Historically, the hard part has been identifying opportunities to make improvements in an easy and focused manner. Most monitoring tools have so much data contained within them that it’s hard to filter out the noise to find the interesting signal contained inside them.

If you’re responsible for identifying opportunities for performance optimization, meet your new best friend.

As you can see in Figure 1, exploring the performance of every application, service, endpoint, request type and so on is as simple as finding a place to stay on Airbnb. You’ll find an extensive selection of filters located above the Results section of the Analyze screen. From there you can filter by application, service, endpoint, type, technology, latency, erroneous and more—which gives you access to every tag available within the IBM Instana platform.

This powerful set of filters allows you to identify traces or calls in whatever manner you need to accomplish your goal. For example, I can set my filters to:

        call.type = Database
        call.latency > 1000 ms
        Grouped By = call.database.statement

The result is that I see a grouped list of every unique database query that takes longer than 1,000 ms to execute across all my services. This list is linked to the underlying data so you can click each query to drill down and explore each statement in context of the associated trace.

If I’m interested in finding slow HTTP requests, I can set my filters for the following:

        call.type = Http
        call.latency > 5000
        Grouped By = trace.endpoint.name

To learn more, check out the IBM Instana site and give the free trial a shot.