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

internal/exp/metrics: identity types #31017

Merged
merged 10 commits into from
Feb 19, 2024
Merged

Conversation

sh0rez
Copy link
Contributor

@sh0rez sh0rez commented Feb 2, 2024

Adds a new internal, experimental package metrics/identity which implements identity types for resource, scope, metric and stream.

This is closely related to work being done in #30707 and #30827.

The package is specifically experimental, as it shall be treated as an internal component to above processors which may change at any moment as long as those are under active initial development.

/cc @jpkrohling @djaglowski @RichieSams

Adds new internal, _experimental_ package `metrics/identity` which
implements identity types for resource, scope, metric and stream.
@sh0rez sh0rez mentioned this pull request Feb 2, 2024
3 tasks
)

type Resource struct {
attrs [16]byte
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to include the resource SchemaURL as part of the identifier?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no idea, can someone clarify? @jpkrohling @djaglowski

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

This came up in the maintainers meeting yesterday and consensus seemed to be that most language libraries are not setting this field. Technically it is optional so I would be ok with leaving it out for now and adding later if necessary.

type Scope struct {
res Resource

name string
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to include the scope schemaURL as part of the identifier?

Copy link
Member

Choose a reason for hiding this comment

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

Leave it out IMO

@RichieSams
Copy link
Contributor

RichieSams commented Feb 5, 2024

Added some small comments. Overall, I like the approach a lot; the code design is very clean

sum.Write([]byte{byte(i.ty), mono, byte(i.temporality)})
return sum
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we add functions for each identity struct to return the "inner" ID? For example:

func (i Metric) Scope() Scope {
    return i.scope
}

So Stream has a Metric(), Metric has a Scope(), and Scope has a Resource().

Copy link
Contributor

Choose a reason for hiding this comment

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

IE: d9b3edd

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes absolutely, already got to this conclusion during local testing

@RichieSams
Copy link
Contributor

RichieSams commented Feb 12, 2024

@jpkrohling @djaglowski Any thoughts on this PR?

@sh0rez What do you think of my comments about the schemaURL and potentially allowing exposing the "inner" ID?

Can i assist in any way to help get this PR across the finish line? (And subsequently, the follow-up PR for staleness: #31089)

Copy link
Member

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

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

I'm OK with this change, but it should be discussed with other folks owning metrics components. I also feel like this should be part of core, not contrib.

cc @dmitryax, @codeboten, @mx-psi

@@ -100,7 +100,7 @@ extension/storage/filestorage/ @open-telemetry/collect

internal/aws/ @open-telemetry/collector-contrib-approvers @Aneurysm9 @mxiamxia
internal/docker/ @open-telemetry/collector-contrib-approvers @rmfitzpatrick @jamesmoessis

internal/exp/metrics/ @open-telemetry/collector-contrib-approvers @sh0rez
Copy link
Member

Choose a reason for hiding this comment

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

@RichieSams, how do you feel about being a code owner of this with @sh0rez ?

Copy link
Contributor

Choose a reason for hiding this comment

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

That's fine by me. I already was adding myself in the followup PR: #31089

Copy link
Member

Choose a reason for hiding this comment

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

@RichieSams, you'll have to become a member of the OpenTelemetry org in order to be a code owner. Requirements are here. I'm happy to be one of your sponsors.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

that would apply to me as well then. @djaglowski would you be willing to be a sponsor for me as well?

Copy link
Contributor

Choose a reason for hiding this comment

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

@jpkrohling Would you be willing to be our second sponsor?

Copy link
Member

Choose a reason for hiding this comment

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

Absolutely

Copy link
Contributor

Choose a reason for hiding this comment

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

@djaglowski
Copy link
Member

I'm OK with this change, but it should be discussed with other folks owning metrics components.

This looks pretty good to me. Having a dedicated package which handles uniqueness according to our data model will be very helpful. I've seen numerous other implementations, most of which tend to be suboptimal. As a shared package, it can evolve towards correctness and performance without otherwise being a concern of those who work on it.

I also feel like this should be part of core, not contrib.

I agree but in my opinion it makes sense to develop it in contrib and move it to core when it is proven out.

Copy link
Member

@mx-psi mx-psi left a comment

Choose a reason for hiding this comment

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

Makes sense to me to have this. Would be good to closely follow the spec, since there are some subtleties involved, and it's also a good opportunity to clarify the spec if it's unclear that a particular attribute is part of the metrics' identity.

@sh0rez sh0rez marked this pull request as ready for review February 14, 2024 11:13
@sh0rez sh0rez requested a review from a team as a code owner February 14, 2024 11:13
@jpkrohling jpkrohling added the Skip Changelog PRs that do not require a CHANGELOG.md entry label Feb 14, 2024
@RichieSams
Copy link
Contributor

@sh0rez It looks like some CI checks are failing:

Porto links are out of date, please run "make goporto" and commit the changes in this PR

@djaglowski @jpkrohling @mx-psi Once that is fixed, do you have any other comments? Is it ok to merge?

@sh0rez
Copy link
Contributor Author

sh0rez commented Feb 19, 2024

@RichieSams as a future codeowner, could you approve this PR as well? :)

@jpkrohling jpkrohling merged commit 9dc748d into open-telemetry:main Feb 19, 2024
142 checks passed
@sh0rez sh0rez deleted the expmetrics branch February 19, 2024 13:54
@github-actions github-actions bot added this to the next release milestone Feb 19, 2024
djaglowski pushed a commit to djaglowski/opentelemetry-collector-contrib that referenced this pull request Feb 19, 2024
Adds a new internal, _experimental_ package `metrics/identity` which
implements identity types for resource, scope, metric and stream.

This is closely related to work being done in open-telemetry#30707 and open-telemetry#30827.

The package is specifically experimental, as it shall be treated as an
internal component to above processors which may change at any moment as
long as those are under active initial development.

/cc @jpkrohling @djaglowski @RichieSams
djaglowski pushed a commit to djaglowski/opentelemetry-collector-contrib that referenced this pull request Feb 19, 2024
Adds a new internal, _experimental_ package `metrics/identity` which
implements identity types for resource, scope, metric and stream.

This is closely related to work being done in open-telemetry#30707 and open-telemetry#30827.

The package is specifically experimental, as it shall be treated as an
internal component to above processors which may change at any moment as
long as those are under active initial development.

/cc @jpkrohling @djaglowski @RichieSams
XinRanZhAWS pushed a commit to XinRanZhAWS/opentelemetry-collector-contrib that referenced this pull request Mar 13, 2024
Adds a new internal, _experimental_ package `metrics/identity` which
implements identity types for resource, scope, metric and stream.

This is closely related to work being done in open-telemetry#30707 and open-telemetry#30827.

The package is specifically experimental, as it shall be treated as an
internal component to above processors which may change at any moment as
long as those are under active initial development.

/cc @jpkrohling @djaglowski @RichieSams
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Skip Changelog PRs that do not require a CHANGELOG.md entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants