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

Add _ViewInstrumentMatch #2400

Merged
merged 4 commits into from
Feb 17, 2022
Merged

Add _ViewInstrumentMatch #2400

merged 4 commits into from
Feb 17, 2022

Conversation

ocelotl
Copy link
Contributor

@ocelotl ocelotl commented Jan 22, 2022

Fixes #2300

This class is intentionally named ViewInstrumentMatch because it represents a match between a View and an Instrument. There will be as many instances of ViewInstrumentMatch as there will be matches between Views and Instruments. I think this is a more descriptive name than ViewStorage considering the fact that instances of this class do no store any Views.

@ocelotl ocelotl added metrics Skip Changelog PRs that do not require a CHANGELOG.md entry labels Jan 22, 2022
@ocelotl ocelotl self-assigned this Jan 22, 2022
@ocelotl ocelotl requested a review from a team January 22, 2022 00:28
@ocelotl ocelotl added the Approve Public API check This label shows that the public symbols added or changed in a PR are strictly necessary label Jan 24, 2022
@aabmass
Copy link
Member

aabmass commented Jan 24, 2022

because it represents a match between a View and an Instrument.

I think this is a more descriptive name than ViewStorage considering the fact that instances of this class do no store any Views.

It doesn't store views, it is the storage for a view. To me, ViewStorage is more descriptive of what the class does and ViewInstrumentMatch is just descriptive of how it gets created. Also, we have MetricReaderStorage so "storage" is consistent.

Also curious what folks besides me and Diego think–here's the section of the design doc for this

@codeboten
Copy link
Contributor

For what it's worth, I think other implementations are going with ViewsRegistry here (at least java/js are).

Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

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

@codeboten
Copy link
Contributor

codeboten commented Feb 11, 2022

It doesn't store views, it is the storage for a view

But it's also not the storage for a view, as a single view may be associated with many of these objects (one per instrument) correct? In which case the relationship between ViewInstrument described in ViewInstrumentMatch makes more sense to me.

I don't know that Match is descriptive enough to make it clear as to what this thing is though, I don't know what I'm supposed to do with a Match.

@ocelotl ocelotl changed the title Add ViewInstrumentMatch Add _ViewInstrumentMatch Feb 11, 2022
@ocelotl
Copy link
Contributor Author

ocelotl commented Feb 12, 2022

I don't know that Match is descriptive enough to make it clear as to what this thing is though, I don't know what I'm supposed to do with a Match.

Actually, the user does not do anything with a view and instrument match. They are an implementation detail, I have updated the class name and the PR title to reflect this. Implementation details should still have descriptive names.

It is hard to describe what this class does, it has a consume_measurement and a collect method as MetricReaderStorage and MeasurementConsumer do. Instances of this class will be used like this.

A measurement that follows the consume_measurement process is handled by the following methods:

  1. Instrument.add/record
  2. MeasurementConsumer.consume_measurement
  3. MetricReader.consume_measurement
  4. MetricReaderStorage.consume_measurement
  5. ViewInstrumentMatch.consume_measurement
  6. ...

From point 1 to point 4 the measurement is handled sequentially by only one object. In step 5 the measurement is handled by several objects (instances of ViewInstrumentMatch) because it can go in several metric streams, one per match between a view and an instrument.

Because it is hard to describe what this class does or is, I believe it is better to stick to the facts, view and instruments can match and every time they match we get an instance of this class. It would be perfect if we could find a noun or adjective that describes it exactly, but I don't know one and I don't think either storage or registry describe them either.

Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

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

ViewInstrumentJoin? ViewInstrumentUnion? I'm just throwing more ideas to see if any stick 😄

I'm ok with calling this a Match as well, tbh since this is an implementation detail I don't have a strong preference here.

@lzchen
Copy link
Contributor

lzchen commented Feb 14, 2022

implementation detail I don't have a strong preference here.

Same here. _ViewInstrumentMatch is fine with m.

@aabmass
Copy link
Member

aabmass commented Feb 15, 2022

I agree with @codeboten's point about "match"

I don't know that Match is descriptive enough to make it clear as to what this thing is though, I don't know what I'm supposed to do with a Match.

but i'm fine to move on with the this name 👍

@ocelotl ocelotl requested a review from codeboten February 15, 2022 22:40
@lzchen lzchen merged commit a07e039 into open-telemetry:main Feb 17, 2022
@ocelotl ocelotl deleted the issue_2300 branch February 17, 2022 18:36
name: str,
unit: str,
description: str,
aggregation: type,
Copy link
Member

Choose a reason for hiding this comment

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

What does type mean here?

class _ViewInstrumentMatch:
def __init__(
self,
name: str,
Copy link
Member

Choose a reason for hiding this comment

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

Why not just pass in the view here to get all of these properties? They are well defined there and then if more fields are added to the view, you don't need to update this constructor

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These attributes don't necessarily come from the view, they may come from the instrument, like this.

if key in self._attribute_keys:
attributes[key] = value
else:
attributes = measurement.attributes
Copy link
Member

Choose a reason for hiding this comment

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

this can be None

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right, @codeboten fixed this in #2469. ✌️


attributes = frozenset(attributes.items())

if attributes not in self._attributes_aggregation.keys():
Copy link
Member

Choose a reason for hiding this comment

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

.keys() is unnecessary here

This was referenced Feb 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Approve Public API check This label shows that the public symbols added or changed in a PR are strictly necessary metrics Skip Changelog PRs that do not require a CHANGELOG.md entry
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add ViewStorage
4 participants