Add the ability to exclude classes from the trace

[Vladislav Zhurin]

Add the ability to exclude classes from the trace.

Is your feature request related to a problem? Please describe.
Yes, we are migrating from NewRelic to Datadog and are faced with the issue, that we can't fully migrate our functional.
We used to xml config to exclude some methods from the trace:

<?xml version="1.0" encoding="utf-8"?>
<extension xmlns="urn:newrelic-extension">
    <instrumentation>
        <tracerFactory name="NewRelic.Agent.Core.Tracer.Factories.IgnoreTransactionTracerFactory">
            <match assemblyName="Microsoft.AspNetCore.SignalR.Core" className="Microsoft.AspNetCore.SignalR.HubConnectionHandler">
                <exactMethodMatcher methodName="OnConnectedAsync"/>
            </match>
        </tracerFactory>
        <tracerFactory name="NewRelic.Agent.Core.Tracer.Factories.IgnoreTransactionTracerFactory">
            <match assemblyName="Microsoft.AspNetCore.SignalR.Core" className="Microsoft.AspNetCore.SignalR.HubConnectionContext">
                <exactMethodMatcher methodName="HandshakeAsync"/>
            </match>
        </tracerFactory>
    </instrumentation>
</extension>

And can't find Datadog alternative in the documentation (currently only excluding resources is available)

Describe the solution you'd like
But I see, that for Java implementation this was already added, let's copy it to dotnet - https://docs.datadoghq.com/tracing/trace_collection/library_config/java (DD_TRACE_CLASSES_EXCLUDE)

[Andrew Lock]

Hi @zhurinvlad, are you refering to tracing or profiling here? For tracing, we don't instrument all methods anyway, and the methods you're mentioning aren't currently traced as far as I'm aware.

That said, the support for websocket connections isn't great currently. I'm assuming that the problem you're experiencing is long continuous traces related to the signalr connection?

[Vladislav Zhurin]

Yes, you are right. But you mentioned that these methods are not traced at all. In that case, we shouldn't do anything, isn't it?

But for the future, it will be a good opportunity to skip some methods.

[Andrew Lock]

But you mentioned that these methods are not traced at all

Correct, those methods aren't traced, but they may be calling methods which are traced under-the-hood🙂 Because, for example, we trace httpclient and aspnetcore pipeline executions. Whether that causes you any problems will depend on your application - if you can post an image of the "problem" (if you have it) then we can look into it further 🙂

But for the future, it will be a good opportunity to skip some methods.

You can disable specific integrations by setting environment variables as described here. For example, you could disable the "SomeLibrary" integration by setting

DD_TRACE_SomeLibrary_ENABLED=false

We don't allow disabling specific methods in an integration. That typically isn't necessary (or desirable) and would potentially lead to instability/memory leaks if used incorrectly, so I suspect it's not something on our radar right now.

If you run into a situation where you find you do need this functionality, we'd love to hear about it to understand the use case 🙂 Thanks!

[Andrew Lock]

Hi @zhurinvlad, I'm going to close this for now, as I think your original issue is resolved. Feel free to reopen it if you think that's not the case!