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.

Figure 1: Extensive filtering capabilities enable deep analysis of the complete data set.

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.

Figure 2: Charting capability within Analyze for both traces and calls.

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.

Figure 3: Filters applied within Analyze to find database queries that require optimization.

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.

Sign up for a free, two-week trial


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…