Skip to content
This repository was archived by the owner on Sep 17, 2025. It is now read-only.

Add gauges#494

Merged
c24t merged 10 commits intocensus-instrumentation:masterfrom
c24t:gauges-init
Feb 12, 2019
Merged

Add gauges#494
c24t merged 10 commits intocensus-instrumentation:masterfrom
c24t:gauges-init

Conversation

@c24t
Copy link
Copy Markdown
Member

@c24t c24t commented Feb 7, 2019

This PR adds LongGauge and DoubleGauge metrics classes following the java implementation, and incidentally adds/changes some related classes' repr methods to help inspect gauges.

self._len_label_keys = len(label_keys)
self.descriptor = metric_descriptor.MetricDescriptor(
name, description, unit, self.descriptor_type, label_keys)
self.points = OrderedDict()
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

This is so the points appear in the converted metric's timeseries list in the order that they're added, may not be necessary.

self.value
))

def add(self, val):
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

total fly by comment as I watch the metric progress: it strikes me as odd for a gauge to have an add method instead of just set and seems like it could lead to misuse by users, do you know the rationale behind this?

Is it because the value is threadsafe with the lock private, so a user couldn't do an atomic add without the functionality baked in?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I think the motivation here is to support data sources that only expose a delta.

I'm following the java implementation for now, but we need to add a description of the gauges API (including add) to the spec.

Is it because the value is threadsafe with the lock private, so a user couldn't do an atomic add without the functionality baked in?

It's actually the other way around: we wouldn't have to lock in set if we didn't want to provide an atomic add. That said, there's nothing (besides common sense) preventing the user from acquiring the lock themselves and changing the value.

converted metrics. See that class for details.
"""

def __init__(self, name, description, unit, label_keys):
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think we should validate all input params like name, label_keys etc.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Just that they're not null or empty? We check label_keys in the MetricDescriptor constructor:

if not label_keys:
raise ValueError("label_keys must not be empty or null")
if any(key is None for key in label_keys):
raise ValueError("label_keys must not contain null keys")

self.points
))

def get_time_series(self, label_values):
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

That's true, I didn't understand the rationale for the default time series in the java client. The goal is that there's a single default point (read: time series) for each gauge that isn't associated with any label values?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Added in a2e56cf, let me know what you think.

Copy link
Copy Markdown
Member

@mayurkale22 mayurkale22 left a comment

Choose a reason for hiding this comment

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

Overall looks good to me.

@c24t c24t merged commit 24e4bc2 into census-instrumentation:master Feb 12, 2019
@c24t c24t mentioned this pull request Feb 12, 2019
@c24t c24t deleted the gauges-init branch February 12, 2019 18:08
@c24t c24t mentioned this pull request Apr 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants