DataDog
[FEATURE]: Add support to filtering traces
Framework or Library Name
No response
Library Type
No response
Library Version(s)
No response
Describe the feature you'd like
In languages such as python, it's easy to filter out traces before they reach the agent. The .NET library doesn't support filtering traces: can it be added to the roadmap?
Filtering traces is crucial when you're monitoring your endpoints overall latencies and you have a /healthcheck endpoint that is screwing up your average. Such endpoint has micro-seconds lantencies, while your other endpoints are in the millis.
This is even worse while developing new services. "app" endpoints receive little traffic, while the healthcheck one gets a constant rate of calls. Anomaly monitors from the "dev" environment will trigger for the wrong reason, making it harder for the team to evaluate them.
Is your feature request related to a problem?
No response
Describe alternatives you've considered
No response
Additional context
No response
Hello @ffissore, you are correct that the .NET Tracer doesn't have a Post Processing option like Python does, but when it comes to managing which traces are sent to Datadog, you have a different option, for example the one below.
You can Configure the Agent to Ignore Specific Resources: You can set the DD_APM_IGNORE_RESOURCES environment variable or update the ignore_resources setting in the Agent's datadog.yaml configuration file. This allows the Agent to exclude traces from specified resources based on their names.
ignore_resources: ["(GET|POST) /healthcheck","API::NotesController#index"]
If your use case requires a different type of approach please respond with the details so we can look into it. Thanks!
Hi @link04, I've read about that option and it would solve our problem. The issue with it is that datadog agents are managed by an entirely different team in my org, so applying changes there takes much longer. Having a postprocessing/filtering option at the library level would give us more freedom and reduce friction.
For now, we have worked around the issue by filtering out the health check endpoints in our monitors.
Given the workaround would solve your problem, and we don't have plans to expose a programmatic way to do this filtering at the moment, I'll close this issue for now. Thanks!
