-
Notifications
You must be signed in to change notification settings - Fork 193
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
feat: handle span compression with new service_target_* fields #1339
feat: handle span compression with new service_target_* fields #1339
Conversation
Update compression logic to use service target fields and stop relying on resource internally.
🌐 Coverage report
|
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.
I'm surprised that no tests have changed. Do we have any tests for "same kind" compression with target service?
@kruskall have you had time to follow up with the question regarding the tests? |
Sorry for the late reply. I'm not sure what should change. We have tests to verify "same kind" compression is working as intended (https://github.com/elastic/apm-agent-go/blob/main/span_test.go#L536-L656) but they still pass since there is no "change" in behaviour. |
It seems to me we have a (pre-existing) gap in our testing: AFAICS the "same kind" compression tests don't cover the code path where the span type and subtype are the same, but the target service name/type differ. I expected we would have a test for this, and that we should have changed the test to set service target rather than the deprecated destination fields. We can merge this as is, but it would be good to improve the tests. |
…different service target fields Add a test case that ensure spans with different service target fields are not compressed even when they are the same kind. The service target fields are inferred by the db context.
Good point! I think we can add it here since it's related to the change and it's fairly small. I've added a test case, let me know what you think! 👍 |
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.
LGTM, but I think we could simplify the test a little bit by not relying on inference.
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.
Looks great, thank you :)
Verified with 8.7.0 BC9 and the latest main (332875e): package main
import (
"fmt"
"time"
"go.elastic.co/apm/v2"
)
func main() {
tracer := apm.DefaultTracer()
tracer.SetSpanCompressionEnabled(true)
tracer.SetExitSpanMinDuration(0)
currentTime := time.Now()
tx := tracer.StartTransactionOptions("8.7.0", "testplan", apm.TransactionOptions{
Start: currentTime,
})
currentTime.Add(
newSpan(tx, currentTime, "SELECT * FROM users", "mysql", "db", "myhost"),
)
currentTime.Add(
newSpan(tx, currentTime, "SELECT * FROM users", "mysql", "db", "myhost"),
)
currentTime.Add(
newSpan(tx, currentTime, "SELECT * FROM orders", "mysql", "db", "anotherhost"),
)
tx.End()
tracer.Flush(nil)
fmt.Printf("%+v\n", tracer.Stats())
}
func newSpan(tx *apm.Transaction, start time.Time, name, t, targetType, targetName string) time.Duration {
span := tx.StartSpanOptions(name, t, apm.SpanOptions{
ExitSpan: true, Start: start,
})
span.Duration = 2 * time.Microsecond
span.Context.SetServiceTarget(apm.ServiceTargetSpanContext{
Type: targetType,
Name: targetName,
})
span.End()
return span.Duration
} |
Update compression logic to use service target fields and stop relying on resource internally.
The updated logic is compliant with the spec on span compression.
See https://github.com/elastic/apm/blob/main/specs/agents/handling-huge-traces/tracing-spans-compress.md#consecutive-same-kind-compression-strategy
Closes #1292