-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
docs(dev-docs): Add metrics telemetry specs #15178
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
base: master
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Co-authored-by: David Herberth <[email protected]>
| : **Number, required**. The numeric value of the metric. The interpretation depends on the metric `type`: | ||
|
|
||
| - For `counter` metrics: the count to increment by (should default to 1) | ||
| - For `gauge` metrics: the current value | ||
| - For `distribution` metrics: a single measured value | ||
|
|
||
| Integers should be a 64-bit signed integer, while doubles should be a 64-bit floating point number. |
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 you supply both an integer and a float to a metric? So call increment(3) and then increment(4.5)?
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 suggest we stick to integers for counters. @k-fish I assume the value eventually ends up in an EAP attribute where integers and floats go into separate columns. Mixing both types might then make queries tricky, plus you'd have to deal with precision loss for very large numbers.
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.
Tagging on to the discussion, is the SDK expected to truncate large integers? If so, how do we truncate, or do we just reject integers that are beyond 64 bits.
In particular, 64-bit floats are natural in Python, but integers are arbitrary precision (under the hood more memory is allocated if the user provides a large integer).
| - `name` **String, required**: The name of the metric | ||
| - `value` **Number, required**: The value of the metric | ||
| - `options` **Object, optional**: An object containing the following properties: | ||
| - `unit` **String, optional**: The unit of measurement (distribution and gauge only) |
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.
Why can't we put units on counts?
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.
Isn't count the unit itself?
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.
No, you can count 🥔 for example 😄
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.
Yeah but that would be determined by the name right? metrics.count('🥔', 2)?
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.
Thanks for this @chargome 👍
A couple notes:
- This api might change before a beta takes place, so we may want to leave it up in PR for a while
- Metrics may have different limits than logs (eg. metric size limit is 2kib currently, might lower it) so may want to make note of that when it comes to adding attributes. We also probably need indicate what the failure mode should be if you have too much attribute data on the scope that you're trying to add to each metric
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!
| : **Number, required**. The numeric value of the metric. The interpretation depends on the metric `type`: | ||
|
|
||
| - For `counter` metrics: the count to increment by (should default to 1) | ||
| - For `gauge` metrics: the current value | ||
| - For `distribution` metrics: a single measured value | ||
|
|
||
| Integers should be a 64-bit signed integer, while doubles should be a 64-bit floating point number. |
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.
Tagging on to the discussion, is the SDK expected to truncate large integers? If so, how do we truncate, or do we just reject integers that are beyond 64 bits.
In particular, 64-bit floats are natural in Python, but integers are arbitrary precision (under the hood more memory is allocated if the user provides a large integer).
Co-authored-by: Alex Krawiec <[email protected]>
Co-authored-by: Alex Alderman Webb <[email protected]>
Co-authored-by: Alex Alderman Webb <[email protected]>
Bundle ReportChanges will decrease total bundle size by 58.13kB (-0.25%) ⬇️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: sentry-docs-server-cjsAssets Changed:
view changes for bundle: sentry-docs-client-array-pushAssets Changed:
|
sdk/telemetryformetrics./sdk/data-model/envelope-items/for the trace metric itemTook the logs specs as a template.
ref getsentry/sentry-javascript#17883