Instana

 View Only

Reducing GB Ingested Trace Data to Instana for Java Applications

By Domenico Schettini Filho posted 8 days ago

  

To reduce data volume to Instana we are providing different ways of configuration on the Instana Agent.

We have different ways to control data ingestion:

  • Disabling all calls coming from a specific library.
  • Filtering calls coming from a library based on configuration.
Disabling all calls coming from a specific technology
Disabling based on a specific library

This is the old way of disabling a specific library. Disabling those libraries make sure that all the spans that could be created for that particular instrumentation won't be created at all. For example we can disable the library Spring Couchbase. 

Bellow is the configuration that shows the list of disable plugins for Spring Couchbase. Plugins are the name of configurations that we use at Instana java Tracing. This configuration is located in the Agent configuration.yaml file. The exact names of the configuration can be obtained by reaching customer support.

com.instana.plugin.javatrace:
  instrumentation:
    plugins:
      CouchbaseExit: false
      RequireCouchbase2: false
      Couchbase3Exit: false
      RequireCouchbase3: false

We can check that before the above configuration be inserted in the configuration.yaml the instrumentation happened successfully and the spans were created as a result.

After the configuration be changed the UpsertRequest database span wasn't created as result. As we can check bellow:


Disabling based on technology

The instrumentation can be disabled based on technology.  Bellow the configuration to disable each of this technologies will be shown.

com.instana.plugin.javatrace:
  instrumentation:
    plugins:
      Redis: false
      DynamoDB: false
      Logging: false

Bellow we can check before disabling Redis.

After disabling Redis we can check that no spans were created.

Filtering calls coming from a library based on configuration

When filtering the calls from a library the customer would control better the granularity of spans creation.

The current supported technologies are:

  • Redis
  • DynamoDB
Endpoints (Actions/Commands) based

We can filter the calls in a lower granularity, based in commands. Bellow we will show the configuration to filter calls for some Redis and DynamoDB commands.

com.instana.tracing:
  ignore-endpoints:
    redis: type|get
    dynamoDB: get|query

We can also use environment variables.

export INSTANA_IGNORE_ENDPOINTS_REDIS="HGET|HDEL"
export INSTANA_IGNORE_ENDPOINTS_DYNAMODB="get|query"

Bellow is an example after disabling Redis commands HGET and HDEL. As we can check only the HSET command was maintained as expected.

Side Effects
Loosing the correlation

When a specific library is disabled, if it has downstream calls, then the correlation will be lost.

Not loosing correlation

When we disable leaf spans (they usually are exit spans) we don't have the risk of disabling the correlation between the race hierarchy. In the bellow example we can see the Redis endpoints as leafs in the call hierarchy when we disable the Redis instrumentation just the corresponding calls won't be shown and spans won't be created.

Before disabling Redis

After disabling Redis entirely


Summary

The main points to about the configurations presented in this blog are:

  • Disabling all calls coming from a specific library:
    • The customer can go to the specific instrumentation he wants to disable.
    • As a disadvantage for plugin based configuration, the customer needs to contact the Instana support team to be able to know the configuration for disabling it.
  • Filtering calls coming from a library based on configuration:
    • Allow our customer to filter calls based on commands.

#community-stories3
1 comment
21 views

Permalink

Comments

7 days ago

Well, if you use the first approach, it is actually very awkward because customers cannot choose by themselves. All plugin names are Instana's Internal Name. Customers cannot know the complete list. They must contact Instana Support for any configuration. This has always been a complaint from many customers that we are not flexible enough compared to Dynatrace/AppDynamic. The ideal approach is that customers can filter based on class name matching.
The second method has some enhancements, but it seems that we still don't have a public list of configurable items, right?