Skip to Main Content
Cloud Management and AIOps


This is an IBM Automation portal for Cloud Management, Technology Cost Management, Network Automation and AIOps products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Under review
Workspace Instana
Categories Tracing
Created by Guest
Created on Sep 15, 2025

Reducing data load by optimazing JVM StackTrace storage

Data load is ending into high costs for Instana customers, and probably for Instana itself. Analyzing the root cause of these big ammounts of data sent to the backend, we have realized that JVM's stack-traces are big chunks of data, which are mainly identic copies ones from the others. In our concrete case, a few of our applications are handling kafka topics, at the rate of millions per hour, and each topic is handled at the same point of the code, generating the same and identical stack trace, which is sent to the Instana backend, increasing our budget.


Once the problem is stated, the proposal is to analyze from this point of view, and check if there is any way to optimize the storage, in the sense that stack traces could be identified in a let-say master table, and stored once (or a few times, but not always), reducing the whole size of the stored data. Let me add up that the technique for performing this optimization is up to you, and my intention is to mere expose the current problem and the benefit of aproving this idea. My calculations lead to a reduction of 75% or 80% in data size, in case of this to be performed.


Thanks for reading and analyzing.

Idea priority High
  • Admin
    Prashant Raj Singh
    Nov 7, 2025

    Hi @Guest

    We have a feature where we only collect stack trace for erroneous call. It is a opt in feature where we do not send stack traces for non-error spans reducing the ingestion.

    I am attaching the configuration below:

    Agent via configuration.yaml that doesn’t needs application restart:

    com.instana.tracing:
    stack.filter.error.enabled: true

    Environment Variable

    1. export INSTANA_TRACING_STACK_FILTER_ERROR_ENABLED=true

    2. It needs application restart

    3. The variable should be created where the application is running

    System property

    -Dcom.instana.tracing.stack.filter.error.enabled=true

    To use system property the customer must add this argument when he starts the application, like $ java -Dcom.instana.tracing.stack.filter.error.enabled=true -jar application.jar

    Needs restart the application to add the new property as argument

    I want to know if this will help you guys?


    Also we have a improvement on this feature coming up where we do not create stack tracers for non-error spans. But I think the feature we have now will already help you guys.