-
Notifications
You must be signed in to change notification settings - Fork 140
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
Refactor the exclude list for assembly instrumentation #3137
Conversation
{ | ||
Logger::Debug("ModuleLoadFinished matched module by pattern: ", module_id, " ", module_info.assembly.name, | ||
"but assembly is explicitly included"); | ||
goto inject; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😲 😲 😲 😲 😲
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can leave it like this or or or use a break;
to prevent my eyes from bleeding. 😂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't use a break
because we're two for-loops deep at this point 😛 We want to break out of both loops (because we've already matched the pattern, so don't want to check the others)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's ways of removing the break
if it's too offensive 😉
We could check if the assembly is in the include_assembly
list first. Only check the skip_assembly_prefixes
if it's not in that list.
Given that most assemblies won't be on the list, the approach approach I used should have less overhead I think, by avoiding the extra loop for every assembly? It's a tiny difference though 😉 Happy to change it if you think that's preferable! 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤦🏻 true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or add the typical bool "found" and if (found) {break}
once again... 🙄🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or add the typical bool "found" and if (found) {break} once again...
Yeah, I think this is preferable. Too much of a coincidence that I add a goto
and all our builds suddenly fail 🙈 . They say it's DNS, but I dunno, seems sus 🤫
This comment has been minimized.
This comment has been minimized.
692d69b
to
3c3c6b4
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
In #1663 we switched from excluding the Microsoft.Extensions prefix to excluding each of the non-logging assemblies individually. This is not future proof (as new libraries could be added), and increases the number of assemblies we need to match against. As a workaround, list adds an explicit "include" list for assemblies which match the "exclude" prefix, but which should be included anyway.
3c3c6b4
to
b5c00bd
Compare
Benchmarks Report 🐌Benchmarks for #3137 compared to master:
The following thresholds were used for comparing the benchmark speeds:
Allocation changes below 0.5% are ignored. Benchmark detailsBenchmarks.Trace.AgentWriterBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AppSecBodyBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.AspNetCoreBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.DbCommandBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ElasticsearchBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.GraphQLBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.HttpClientBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.ILoggerBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.Log4netBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.NLogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.RedisBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SerilogBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.SpanBenchmark - Same speed ✔️ Same allocations ✔️Raw results
Benchmarks.Trace.TraceAnnotationsBenchmark - Same speed ✔️ Same allocations ✔️Raw results
|
Code Coverage Report 📊✔️ Merging #3137 into master will not change line coverage
View the full report for further details: Datadog.Trace Breakdown ✔️
The following classes have significant coverage changes.
The following classes were added in #3137:
View the full reports for further details: |
Summary of changes
Refactor the "exclude by pattern" list to allow specific inclusions.
Reason for change
In #1663 we switched from excluding the Microsoft.Extensions prefix to excluding each of the non-logging assemblies individually.
This is not future proof (as new Microsoft.Extensions libraries could (will) be added, that we don't want to instrument), and increases the number of assemblies we need to match against.
Implementation details
As a workaround, adds an explicit "include" list for assemblies which match the "exclude" prefix, but which should be included anyway.
I used a
goto
. I understand if I'm not allowed to touch C++ again.Test coverage
Should be covered by existing
Other details
Should make it easier for @NachoEchevarria's work on
System.Diagnostics.Process
.