stats: do not create MetricDescriptor for Stackdriver built-in metrics.

[census-ecosystem]

stats: do not create MetricDescriptor for Stackdriver built-in metrics.

[songy23]

Consider using the GetMetricType option to set a custom metric prefix, for example "custom.googleapis.com/my.org/...". I think this is a constraint on Stackdriver backend rather than the exporter.

[yanweiguo]

Consider using the GetMetricType option to set a custom metric prefix, for example "custom.googleapis.com/my.org/...". I think this is a constraint on Stackdriver backend rather than the exporter.

I'm using that. My use case is to write metrics to a Stackdriver provided metric, instead of a custom metric prefix. For example, appengine.googleapis.com/flex/cpu/reserved_cores. The MetricDescriptor is already there.

[songy23]

I see, the OC Stackdriver exporter is meant to be used to export application metrics mainly, but we should definitely allow exporting to built-in metrics. /cc @odeke-em @rghetia

[yanweiguo]

@rghetia Thanks for #77. I verified that it still doesn't work for built-in metrics. I spent some time to debug whether the cause is from my GetMonitoredResource func or from the exporter.

The error is from equalMeasureAggTagKeys func:

for _, k := range md.Labels {
	if _, ok := labels[k.Key]; !ok {
		return fmt.Errorf("stackdriver metric descriptor %q was not created with label %q", md.Type, k)
	}
	delete(labels, k.Key)
}

IIUC, GetMonitoredResource returns a resource with resource.type and resource.labels. It also returns a string map which should be filed as metric.labels. For a timeSerie, it must have all resource.labels filled, but its metric.labels are optional. The logic in the code mentioned above doesn't look right to me.

What's the reason to cache MetricDescriptor and compare the tags/labels before sending CreateTimeSeries request to Stackdriver?

If we indeed need to do the tags/labels comparison, I think we may change the logic to:

1. Check all view.tags are in metric.labels or resource.labels
2. Check all resource.labels are in view.tags.

[rghetia]

@yanweiguo the reason for caching MD is that you don't have to send it over and over again.

Are you using resource label as view tags? can you provide concrete example with your view.tags and resource.labels?

[yanweiguo]

@yanweiguo the reason for caching MD is that you don't have to send it over and over again.

I found the caching MDs are only used in createMeasure func. I wonder whether we need to call createMeasure for built-in metrics since their MD are already there.

Are you using resource label as view tags? can you provide concrete example with your view.tags and resource.labels?

Here is our func for GetMonitoredResource.