tracer: Report stats on errorstack#3752
Conversation
BenchmarksBenchmark execution time: 2025-07-16 14:39:44 Comparing candidate commit b28c891 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 24 metrics, 0 unstable metrics. |
|
|
||
| // Wrap takes in an error and records the stack trace at the moment that it was thrown. | ||
| func Wrap(err error, n uint, skip uint) *TracerError { | ||
| telemetry.Count(telemetry.NamespaceTracers, "errorstack.source", []string{"source:TracerError"}).Submit(1) |
There was a problem hiding this comment.
My only question here: Would there be situation where we actually wrap an error but it doesn't end up in the spans? (setTagError never call for this error)
Technically, this doesn't change anything for this PR. However, it worths keeping in mind.
There was a problem hiding this comment.
I can maybe see this happening if we were to wrap an error somewhere and not explicitly set it on the span somehow. For the sake of keeping existing functionality around, I'm not wrapping built-in error types as they pass through setTagError (also that wouldn't solve the issue of incorrect stack traces, I think). But yeah, it's worth thinking about!
As we start migrating to errortrace internally, we can keep this in mind. I'm sure there are edge cases that we might need to investigate in the future...
kakkoyun
changed the title
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
dd-devflow
Bot
added
mergequeue-status: queued
mergequeue-status: in_progress
and removed
mergequeue-status: queued
labels
dd-devflow
Bot
added
mergequeue-status: done
and removed
mergequeue-status: in_progress
labels
2 participants
What does this PR do?
Creates two new telemetry metrics:
errorstack.source: a count representing the number of stacks calculated for an error. Includes a tag (source) indicating where this calculation happened. This tag can either beerrortraceortakeStacktrace.errorstack.duration: a distribution representing how long (in milliseconds) it took for the stacks to be calculated. This also includes the samesourcetag as above.Motivation
Following the work in #3709, we want to keep track of how and where error stacks are being calculated. Our main points of comparison are in the new
errortracepackage vs the existingtakeStacktracefunction. This can help us determine how customers pick up on the package and if we need to made any modifications.Reviewer's Checklist
golangci-lint runlocally.Unsure? Have a question? Request a review!