Skip to content
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(metrics): Allow ingestion of custom metric units [INGEST-1131] #1256

Merged
merged 7 commits into from
May 4, 2022

Conversation

jan-auer
Copy link
Member

@jan-auer jan-auer commented May 3, 2022

Introduces MetricUnit in measurements[].unit on the event protocol. This allows SDKs to submit units for custom measurements, as well as override units on well-known measurements defined in the past. Metric extraction uses these units when supplied, falling back to the predefined units in their absence.

Follow-ups:

  • Move breakdown computation to use Duration for type safety
  • Support for custom unit conversion during breakdown computation

This connects to:

@jan-auer jan-auer self-assigned this May 3, 2022
@jan-auer jan-auer requested a review from a team May 3, 2022 14:59
@jan-auer
Copy link
Member Author

jan-auer commented May 3, 2022

I'm not going to fix up breakdown computation with support for custom units in this PR. To do this in a type-safe fashion, I want to consistently pass Duration around. Then, it's much more straight forward to introduce support for custom units. This will be part of a follow-up PR. The TODO remains until then.

@jan-auer
Copy link
Member Author

jan-auer commented May 3, 2022

We agreed in acceptance criteria that violations of the well-known units should be logged. This still needs to be added along with a test case before merging.

"ratio" => Self::Fraction(FractionUnit::Ratio),
"percent" => Self::Fraction(FractionUnit::Percent),

"" | "unit" | "none" => Self::None,
Copy link
Member

@AbhiPrasad AbhiPrasad May 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had a discussion offline about if "unit" should pattern matched to Self::None. The reasoning that this was put in place was to track the unit type () that exists in different languages. Does this still make sense? I would rather remove it.

Also worthwhile syncing to see if we can better match OpenTelemetry in general here, particularly around defining dimensionless units, and opting into custom units (like recording X number of Y - for ex with a counter for network packets, 100 (measure) packets (unit)).

https://opentelemetry.io/docs/reference/specification/metrics/semantic_conventions/#instrument-units

Units should follow the Unified Code for Units of Measure (need more clarification in #705).

  • Instruments for utilization metrics (that measure the fraction out of a total) are dimensionless and SHOULD use the default unit 1 (the unity).
  • Instruments that measure an integer count of something SHOULD only use annotations with curly braces to give additional meaning without the leading default unit (1). For example, use {packets}, {errors}, {faults}, etc.

Copy link
Member Author

@jan-auer jan-auer May 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, agreed to remove "unit" from here. This has not been used actively, so we can safely remove it.

Other than that, this PR merely moves the existing unit definition and derives new traits. We can ideally discuss units in a new DACI or GitHub issue. Units are definitely not ideal yet, and we're also not able to support X per Y units (e.g. frames per second). Note that this is different from fractions.

let default_unit = get_metric_measurement_unit(name);
if let (Some(default), Some(stated)) = (default_unit, stated_unit) {
if default != stated {
relay_log::error!("unit mismatch on measurements.{}: {}", name, stated);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can bring the SDK name into the error message, so we immediately know where this came from.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The SDK is already on the context since we're in envelope processing.

|scope| {
scope.set_tag("project", project_id);
if let Some(client) = client {
scope.set_tag("sdk", client);
}
if let Some(user_agent) = user_agent {
scope.set_extra("user_agent", user_agent.into());
}
},

Generally, we should aim for central configuration rather than overloading code with error reporting boilerplate.

@jan-auer jan-auer merged commit bff235e into master May 4, 2022
@jan-auer jan-auer deleted the feat/custom-measurement-units branch May 4, 2022 07:38
@github-actions
Copy link

github-actions bot commented May 4, 2022

Fails
🚫 Please consider adding a changelog entry for the next release.
Instructions and example for changelog

For changes exposed to the Python package, please add an entry to py/CHANGELOG.md. This includes, but is not limited to event normalization, PII scrubbing, and the protocol.

For changes to the Relay server, please add an entry to CHANGELOG.md under the following heading:

  1. Features: For new user-visible functionality.
  2. Bug Fixes: For user-visible bug fixes.
  3. Internal: For features and bug fixes in internal operation, especially processing mode.

To the changelog entry, please add a link to this PR (consider a more descriptive message):

- Allow ingestion of custom metric units. ([#1256](https://github.com/getsentry/relay/pull/1256))

If none of the above apply, you can opt out by adding #skip-changelog to the PR description.

Generated by 🚫 dangerJS against ca84ecd

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants