Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[exporter/datadog]: add ignore_resources configuration option #3245

Merged
merged 22 commits into from
Apr 30, 2021

Conversation

ericmustin
Copy link
Contributor

@ericmustin ericmustin commented Apr 26, 2021

Description:

This PR adds a configuration option ignore_resources, which matches the feature currently available in the datadog-agent, to the opentelemetry-collector datadogexporter. The configuration option allows users to supply A blocklist of regular expressions to "drop" certain traces based on their resource name. A resource name is a Datadog APM Specific concept which generally represents a specific endpoint or route in an application, such a GET /healthcheck.

This feature has been requested by a number of end users and allows users greater flexibility for "dropping" certain low value traces before they generate trace related metrics/stats or are added to trace payloads sent to datadog. It allows users to control any associated ingestion costs from sending data to the datadog backend, as well as filter out unwanted traces.

In the context of the OpenTelemetry Collector, specifically how ignore_resources functions is it will drop the entire "trace chunk" (all spans with the same traceId in a payload of ResourceSpans), when the "Root" span in that trace has a resource that is in the blocklist.

Technically, this means that in an environment with very low or zero batching within the tracing pipeline (at sdk processor/exporter or in collector pipeline processors), some child spans of the blocklisted trace may not be dropped (since they'd be contained in a separate payload). Generally speaking there's not much we can do about this limitation and I think, since the datadogexporter's suggested setup/configuration instructions include specific requirements and caveats to ensure batching, this is an acceptable limitation/tradeoff

*Note: For context, The implementation is similar to the datadog-agent blacklister, with some differences I tried to note through code comments and above. I wanted to try to use more inclusive language (blacklist -> blocklist). It does admittedly sound a little odd so if there's more appropriate terminology here i'm open to changing.

Testing: Added a unit test and tests for the blocklister functionality

Documentation: Added configuration option to the example config yaml. It may be worth adding a section to the README with usage instructions as well

@ericmustin ericmustin requested a review from a team as a code owner April 26, 2021 15:22
@codecov
Copy link

codecov bot commented Apr 26, 2021

Codecov Report

Merging #3245 (b07c6bc) into main (17399fa) will decrease coverage by 0.06%.
The diff coverage is 36.11%.

❗ Current head b07c6bc differs from pull request most recent head 08da12c. Consider uploading reports for the commit 08da12c to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##             main    #3245      +/-   ##
==========================================
- Coverage   91.91%   91.84%   -0.07%     
==========================================
  Files         494      494              
  Lines       23939    23980      +41     
==========================================
+ Hits        22003    22024      +21     
- Misses       1429     1449      +20     
  Partials      507      507              
Flag Coverage Δ
integration 63.74% <ø> (+0.05%) ⬆️
unit 90.86% <36.11%> (-0.07%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
exporter/datadogexporter/utils/trace_helpers.go 0.00% <0.00%> (ø)
exporter/datadogexporter/config/config.go 89.28% <100.00%> (+0.82%) ⬆️
exporter/datadogexporter/factory.go 82.60% <100.00%> (+0.19%) ⬆️
exporter/datadogexporter/traces_exporter.go 90.69% <100.00%> (+0.45%) ⬆️
exporter/datadogexporter/translate_traces.go 89.60% <100.00%> (+0.21%) ⬆️
exporter/signalfxexporter/config.go 83.67% <0.00%> (-2.38%) ⬇️
...porter/awsprometheusremotewriteexporter/factory.go 100.00% <0.00%> (ø)
receiver/prometheusexecreceiver/receiver.go 88.33% <0.00%> (+2.50%) ⬆️
exporter/awsprometheusremotewriteexporter/auth.go 86.66% <0.00%> (+4.05%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 84952e2...08da12c. Read the comment docs.

@ericmustin
Copy link
Contributor Author

cc @mx-psi for review from datadog

Copy link
Member

@mx-psi mx-psi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments. Since CodeCov is temporarily disabled I believe the report is not updated so you should run the Go coverage tool locally

exporter/datadogexporter/blocklister.go Outdated Show resolved Hide resolved
rootSpan := utils.GetRoot(apiTrace)

if !blk.Allows(rootSpan) {
//TODO: do we need to delete if we're skipping appending to payload?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should clarify this TODO before merging

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I worked through it and I'm nearly sure its safe to not delete, updated the pr

exporter/datadogexporter/utils/trace_helpers.go Outdated Show resolved Hide resolved
exporter/datadogexporter/utils/trace_helpers.go Outdated Show resolved Hide resolved
Comment on lines 233 to 236
if c.Traces.IgnoreResources == nil {
c.Traces.IgnoreResources = []string{}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A nil slice works pretty much like an empty slice, I think we can remove this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated

Comment on lines 54 to 57
if err != nil {
// log.Errorf("Invalid resource filter: %q", entry)
continue
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should handle this instead of just ignoring it. I think we can

  1. On the configuration, validate the regexes using regexp.Compile. Following add validatable interface to all the component config opentelemetry-collector#2898 we should do this on a Validate method from the configuration.
  2. Use regexp.MustCompile and ensure that we only pass valid regexes to the NewBlocklister.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems fine to me but I'm a bit confused on the behavior you want here.

In the Validate method should i just return an error if invalid, or should i be sanitizing the values from a slice of strings into a slice of regexs?

Where am I using MustCompile ? I don't quite follow this part.

anyway i pushed up an attempt at this but not sure how mustcompile fits in

exporter/datadogexporter/blocklister.go Outdated Show resolved Hide resolved
Comment on lines 53 to 57
rule, err := regexp.Compile(entry)
if err != nil {
// log.Errorf("Invalid resource filter: %q", entry)
continue
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I meant with the comment above is that we can now just do

Suggested change
rule, err := regexp.Compile(entry)
if err != nil {
// log.Errorf("Invalid resource filter: %q", entry)
continue
}
rule := regexp.MustCompile(entry)

since we know the regexes are valid

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kk makes sense, updated this and cleaned up the tests. i did have to remove a few tests from denylist_test.go that tested invalid regex, but moved them into the config_test section for the Validate function, which I think is where they'd belong now anyway.

Copy link
Member

@mx-psi mx-psi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, checked code coverage locally and it looks reasonable to me

@ericmustin
Copy link
Contributor Author

👋 @kbrockhoff could i get a quick review here when u have a moment?

@kbrockhoff
Copy link
Member

LGTM

@bogdandrutu bogdandrutu merged commit f853a99 into open-telemetry:main Apr 30, 2021
mstumpfx pushed a commit to mstumpfx/opentelemetry-collector-contrib that referenced this pull request Aug 31, 2021
…elemetry#3245)

* [exporter/datadog]: wip add blocklist for resources. wip test and documentation

* [exporter/datadog]: clean up ignore resources defaults

* [exporter/datadog]: remove unused helpers

* [exporter/datadog]: add yaml config details

* [exporter/datadog]: add links to datadog agent funcs

* [exporter/datadog]: seperate blocklist into its own file and tests

* [exporter/datadog]: fix copyrights

* [exporter/datadog]: pr feedback update code comments and update naming conventions, clean up code comments

* [exporter/datadog]: add validatioon block to config

* [exporter/datadog]: update config

* [exporter/datadog]: linting

* [exporter/datadog]: wip add helper tests

* [exporter/datadog]: add helper tests

* [exporter/datadog]: linting

* [exporter/datadog]: use mustcompile for denylist

* [exporter/datadog]: fix tests for new config/denylist behavior

* [exporter/datadog]: add ignore resources validation test for config
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants