[ASM] Remove warnings and fix flake#3338
Conversation
This comment has been minimized.
This comment has been minimized.
c045fb6 to
aef887f
Compare
| if (!transport.Blocked) | ||
| { | ||
| LastChanceToWriteTags?.Invoke(this, new InstrumentationGatewayEventArgs(transport, relatedSpan)); | ||
| } |
There was a problem hiding this comment.
In the end, I think this change is not necessary, though seems a fairly sensible protection against unnecessary calls to the WAF.
| { | ||
| LogAddressIfDebugEnabled(eventData); | ||
| eventHandler?.Invoke(this, new InstrumentationGatewaySecurityEventArgs(eventData, transport, relatedSpan, eraseExistingAddress)); | ||
| } |
There was a problem hiding this comment.
This skips the debug log too though, is that correct?
There was a problem hiding this comment.
I would say yes, we only really want to know what the input data is if it's going to be analyzed by the waf.
This comment has been minimized.
This comment has been minimized.
| var ea = new InstrumentationGatewayBlockingEventArgs(context, scope, tracerSettings, doBeforeActualBlocking); | ||
| BlockingOpportunity?.Invoke(this, ea); |
There was a problem hiding this comment.
This now creates the InstrumentationGatewayBlockingEventArgs object even if BlockingOpportunity is null, that looks worse for allocations to me? 🤔
This comment has been minimized.
This comment has been minimized.
Benchmarks Report 🐌Benchmarks for #3338 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 #3338 into master will not change line coverage
View the full report for further details: Datadog.Trace Breakdown ✔️
The following classes have significant coverage changes.
View the full reports for further details: |
Summary of changes
We are seeing flake in the ASM blocking tests, where the status code and resource name disappeared from the span:
Reason for change
Flake is bad.
Implementation details
Before this change we dispose systematically disposed a scope / span in the
TracingHttpModule.OnBeginRequestin the case of an exception, the logic being we won't be able to retrieve it from the http contextTracingHttpModule.OnEndRequest.However, this is not always true, if the exception occurs late
TracingHttpModule.OnBeginRequest, then the span will be in the http context and we'll attempt to update theTracingHttpModule.OnEndRequest. This creates a race between data being written to the span object and the span being written to theAgentWriter.In the case where we blocked the request from the call to the WAF in
TracingHttpModule.OnBeginRequest, we were also calling the WAF again inTracingHttpModule.OnEndRequest, which seems unnecessary.