Add unique identifier to Cloud Monitoring exporter #841
Conversation
...ntelemetry-exporter-cloud-monitoring/src/opentelemetry/exporter/cloud_monitoring/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-exporter-cloud-monitoring/tests/test_cloud_monitoring.py
Outdated
Show resolved
Hide resolved
...ntelemetry-exporter-cloud-monitoring/src/opentelemetry/exporter/cloud_monitoring/__init__.py
Outdated
Show resolved
Hide resolved
|
Correct me if I'm wrong, but it seems like |
|
It seems kind of strange that |
|
If the uniqueness depends only on the name and labels, what about instruments with the same name but different other properties (desc, unit, value_type, metric_type)? Would a |
You Are able to auto create MetricDescriptor https://cloud.google.com/monitoring/custom-metrics/creating-metrics#auto-creation. But theres a lot of information that you lose, e.g. the metric can't have a description, labels can't have descriptions, you can't choose the unit or displayname. That's why I opt to create my own. The other fields (labels, metric_kind) do get used, just not by me. By adding the MetricDescriptor type to my Metric, its telling the backend that the label keys + metric_kind should match, and if they don't it'll complain. |
MetricDescriptor stores only label keys, while record.labels has both. When creating the MetricDescriptor you only need to pass it label keys, but when creating Metric (that's associated with a MetricDescriptor) you need to populate all the label keys passed to the associated MetricDescriptor with a valid label value (or None). I'm not sure what you mean with the GUID, we store a UUID with label key opentelemetry_uuid. |
Nice. |
Resolved offline. Users can't have multiple metric instruments in the same meter with same name. |
...ntelemetry-exporter-cloud-monitoring/src/opentelemetry/exporter/cloud_monitoring/__init__.py
Outdated
Show resolved
Hide resolved
c62b646 to
cca8d63
Compare
...ntelemetry-exporter-cloud-monitoring/src/opentelemetry/exporter/cloud_monitoring/__init__.py
Outdated
Show resolved
Hide resolved
...ntelemetry-exporter-cloud-monitoring/src/opentelemetry/exporter/cloud_monitoring/__init__.py
Outdated
Show resolved
Hide resolved
ext/opentelemetry-exporter-cloud-trace/src/opentelemetry/exporter/cloud_trace/__init__.py
Outdated
Show resolved
Hide resolved
cca8d63 to
1f9a247
Compare
|
🚀 |
...ntelemetry-exporter-cloud-monitoring/src/opentelemetry/exporter/cloud_monitoring/__init__.py
Outdated
Show resolved
Hide resolved
| @@ -33,6 +50,11 @@ def __init__(self, project_id=None, client=None): | |||
| self.project_name = self.client.project_path(self.project_id) | |||
| self._metric_descriptors = {} | |||
| self._last_updated = {} | |||
| self.unique_identifier = None | |||
| if add_unique_identifier: | |||
| self.unique_identifier = "{:08x}".format( | |||
There was a problem hiding this comment.
If the process using the exporter restarts, the ID could change, which means the exported time series will be different from those before the restart for time series that have monitored resource / metric labels that are otherwise the same. Is that a concern?
| self.unique_identifier = None | ||
| if add_unique_identifier: | ||
| self.unique_identifier = "{:08x}".format( | ||
| random.randint(0, 16 ** 8) |
There was a problem hiding this comment.
Just checking, this will generate different values on different instantiations after process restarts without seeding? (not very familiar with Python random module)
Cloud Monitoring allows one update every 10 seconds for a unique tuple (metric_name, metric_label_value_1, metric_label_value_2 ...). To respect this, the exporter has an in memory map of when it last exported each tuple. There are two ways this can be broken.
For both cases, a fix has been suggested in the troubleshooting docs. For the second, the ability to add a unique identifier as a label_value has been added. Thanks to @cnnradams for bringing up this issue :)