-
Notifications
You must be signed in to change notification settings - Fork 194
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
Breakdown metrics #564
Breakdown metrics #564
Conversation
Codecov Report
@@ Coverage Diff @@
## master #564 +/- ##
==========================================
+ Coverage 84.16% 84.64% +0.48%
==========================================
Files 116 120 +4
Lines 6894 7190 +296
==========================================
+ Hits 5802 6086 +284
- Misses 783 789 +6
- Partials 309 315 +6
Continue to review full report at Codecov.
|
Here's a description/explanation of some of the more interesting parts.
Due to the last two points, we do not have long-lived timer objects: we still limit the breakdown metrics to 1000 The locking involved in (4) concerns me. Under the "happy path" where transactions get enqueued to the tracer there will be no contention between transactions, but when the load is high enough that the tracer cannot process transactions quickly enough, we'll introduce contention between transaction goroutines. |
The idea was to limit the number of unique metricsets to 1000.
Maybe you should consider the writer-reader phaser the Java agent uses as well. It does not block writers at any time. |
The important thing is to have a bound on agent memory? Does it matter if it's 1000 unique metrics for the process's lifetime vs. at any one time?
Indeed. I misunderstood the guarantees of the phaser. I'll take a closer look at that. |
5e1d0cc
to
5c067d7
Compare
Implementation of agent breakdown metrics (elastic/apm#78)
Checklist/TL;DR version of the design:
span.type
app
transaction.name
,transaction.type
,span.type
andspan.subtype
transaction.breakdown.count
counter every time the metrics are reportedCloses #528