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 timestamps to aggregators and OTLP metrics exporter #1199

Merged
merged 6 commits into from
Oct 12, 2020

Conversation

ocelotl
Copy link
Contributor

@ocelotl ocelotl commented Oct 5, 2020

Description

Add timestamps to aggregators and OTLP metrics exporter.

Fixes #1008

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Refactored aggregator and OTLP metric exporter tests.

Checklist:

  • Followed the style guidelines of this project
  • Changelogs have been updated
  • Unit tests have been added
  • Documentation has been updated

@ocelotl ocelotl force-pushed the issue_1008 branch 4 times, most recently from 31c3d71 to 55625d7 Compare October 7, 2020 05:47
@ocelotl ocelotl marked this pull request as ready for review October 7, 2020 05:52
@ocelotl ocelotl requested a review from a team October 7, 2020 05:52
@ocelotl ocelotl self-assigned this Oct 7, 2020
@ocelotl ocelotl changed the title Issue 1008 Add timestamps to aggregators and OTLP metrics exporter. Oct 7, 2020
@ocelotl ocelotl changed the title Add timestamps to aggregators and OTLP metrics exporter. Add timestamps to aggregators and OTLP metrics exporter Oct 7, 2020
self.current = None
self.checkpoint = None
if config:
self._lock = threading.Lock()
Copy link
Contributor

Choose a reason for hiding this comment

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

Technically, all classes that extend from this would want this implementation, but design-wise, what are we deciding for having implementation within ABCs? This applies to merge and verify_type as well. See this comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it is the right thing to have implementation in the base class if that implementation can be used by the concrete classes. There are 2 different things happening here, first, abstractmethod makes it mandatory for the concrete class to implement a specific method. Second, having implementation in the parent class. The second thing does not go against the first one, it is independent and it fulfills a separate need, the one of having common code in one single place. We can move the lock instantiation to the concrete classes if that is the project consensus, but I think that would just mean more repeated code 🤷‍♂️

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah personally I don't mind having implementation in the base class. Just something I'd thought I'd bring up.


@abc.abstractmethod
def merge(self, other):
"""Combines two aggregator values."""
self.last_update_timestamp = max(
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 safely assume that all aggregators want this behaviour as the default? LastValueAggregator already doesn't follow this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, this is not the default behavior, it is just common code that all (or most) aggregators can use if they decide so, by calling super themselves.

@lzchen lzchen merged commit 04792d5 into open-telemetry:master Oct 12, 2020
srikanthccv pushed a commit to srikanthccv/opentelemetry-python that referenced this pull request Nov 1, 2020
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.

Send start_time_unix_nano and time_unix_nano in OTLP MetricExporter
4 participants