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

Implement metric identity specification #4222

Merged
merged 6 commits into from
Mar 15, 2022

Conversation

jack-berg
Copy link
Member

Implements changes merged in spec PR #2317.

In summary:

  • Each instrument is identified by its name, description, unit, type, and value type.
  • If you ask a meter for an instrument with the same identity as one previously registered, you'll record to the same instrument.
  • If you ask a meter for an instrument the same name as one previously registered but some difference in description, unit, type, or value type, you've created an identity conflict. Multiple metrics with the same name will be exported, and we'll log a diagnostic error message.
  • Views also play a role in identity. Since you can use views to change the name, description, and aggregation, its fairly easy to create an identity conflict when you register multiple views that select the same instrument(s).

public abstract String getDescription();

public abstract String getUnit();
Copy link
Member Author

Choose a reason for hiding this comment

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

No reason for getUnit() to be a top level field since views can't modify it.


/** The view that lead to the creation of this metric, if applicable. */
public abstract Optional<View> getSourceView();
Copy link
Member Author

Choose a reason for hiding this comment

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

No reason for getSourceView() to be optional. Getting rid of optional simplifies code.

"Failed to register metric.")
.getThrowable())
.hasMessageContaining("Metric with same name and different descriptor already created.");
logs.assertContains("Found duplicate metric definition");
Copy link
Member Author

Choose a reason for hiding this comment

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

A lot of the tests in this code duplicate the test cases in IdentityTest, but with less complete validation. I think I should remove the duplicate scenarios to reduce maintenance burden.

@codecov
Copy link

codecov bot commented Feb 28, 2022

Codecov Report

Merging #4222 (3e9e384) into main (26c0429) will decrease coverage by 0.11%.
The diff coverage is 91.98%.

Impacted file tree graph

@@             Coverage Diff              @@
##               main    #4222      +/-   ##
============================================
- Coverage     90.32%   90.21%   -0.11%     
- Complexity     4752     4762      +10     
============================================
  Files           553      555       +2     
  Lines         14611    14692      +81     
  Branches       1402     1413      +11     
============================================
+ Hits          13197    13254      +57     
- Misses          954      982      +28     
+ Partials        460      456       -4     
Impacted Files Coverage Δ
...lemetry/sdk/common/InstrumentationLibraryInfo.java 100.00% <ø> (ø)
.../java/io/opentelemetry/sdk/logs/SdkLogEmitter.java 100.00% <ø> (ø)
...n/java/io/opentelemetry/sdk/logs/data/LogData.java 0.00% <0.00%> (ø)
...va/io/opentelemetry/sdk/logs/data/LogDataImpl.java 100.00% <ø> (ø)
.../io/opentelemetry/sdk/metrics/data/MetricData.java 85.00% <0.00%> (-4.48%) ⬇️
...ry/sdk/metrics/internal/aggregator/Aggregator.java 100.00% <ø> (ø)
...dk/metrics/internal/aggregator/DropAggregator.java 36.36% <ø> (ø)
...k/metrics/internal/aggregator/EmptyMetricData.java 100.00% <ø> (ø)
...rics/internal/state/AsynchronousMetricStorage.java 97.87% <ø> (ø)
...nternal/state/DefaultSynchronousMetricStorage.java 82.50% <ø> (ø)
... and 52 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 59a6061...3e9e384. Read the comment docs.

class InstrumentDescriptorTest {

@Test
void equals() {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it possible to use equalsverifier?

Copy link
Member Author

Choose a reason for hiding this comment

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

I can't figure out how to make it work with an abstract class implemented by autovalue.

/** The instrument which lead to the creation of this metric. */
public abstract InstrumentDescriptor getSourceInstrument();

/** The FQCN of the view aggregation. */
Copy link
Contributor

Choose a reason for hiding this comment

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

How about using Class directly instead of String?

Copy link
Contributor

Choose a reason for hiding this comment

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

Though otherwise if we already have the concept of a human-readable aggregation name for viewconfig, we should try to use that too

"Unrecognized aggregation " + aggregation.getClass().getName());
}
return name;
}
Copy link
Member Author

Choose a reason for hiding this comment

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

@anuraaga this is my solution for being able to translate aggregations to / from human readable names. Its in an internal class so we're not obligated to support it, but it provides a central place for the conversion that both the view file config and MetricDescriptor#getAggregationName() can depend on.

"Unrecognized aggregation " + aggregation.getClass().getName());
}
return name;
}
Copy link
Member Author

Choose a reason for hiding this comment

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

@anuraaga this is my solution for being able to translate aggregations to / from human readable names. Its in an internal class so we're not obligated to support it, but it provides a central place for the conversion that both the view file config and MetricDescriptor#getAggregationName() can depend on.

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

2 participants