Turn off capturing of DB Prepare statements

[gilgi]

Hi, 

While Database prepare statements may be beneficial, I've seen more than once situations in which the DB prepare statements (in an intensive database based application) take a huge percentage of the allowed trace ingest quota for the V3 platform. This results in a customers missing out crucial spans and having to pay for additional storage because of spans they do not want.
My question to you: did you face such situations? how did you handle that? and for the Dynatrace guys our here - do you know of any way to just turn off the prepare statements collection?

Gil.

[AravindhanV]

Hi @gilgi ,

Its Valid question, how about using the Bind Variables,

Understanding would be, Bind variables allow the database server to prepare the statement once and execute it multiple times without reparsing or reanalyzing it.

Settings > Server-side service monitoring > Deep monitoring

Under Database Capture SQL bind values.

Have a look and share your thought

Thanks

[dylan_taelemans]

If you're using Dynatrace SaaS, you could try using OpenPipeline to drop them.

Something similar to this:

[gilgi]

Hi, 

@AravindhanV this makes a lot of sense. we'll test it.

@dylan_taelemans while this will remove the spans, I suspect it will not affect the ingest & process ( as pipelines runs after this stage), hence will only solve storage but not the ingest quota.

Gil.

[luiz_portela]

@gilgi Did you figured this out?

SQL Prepare Statements are consuming right now 105% of our trace licensing. 

The option "Capture SQL Bind values" is already disabled for us.

[gilgi]

Hi, 

There was a thought that capture bind variables is causing that. it seems like its not. unfortunately we don't have any solution to that.

Seems like something Dynatrace team needs to answer or provide a way to resolve. It could be that using OTEL will reduce that but this means the OneAgent is loosing from its added value and more and more "manual" involvement, even if its  not direct code change, will be required, hence making the deployment more comlicated and slower.