OC Exporter - send start_timestamp, resource labels, and convert labels to strings

[aabmass]

Fixes #940, fixes #951.

1. Pass start_timestamp for stateful metrics
2. Export resources as well. For resource type, copied logic from the Collector in Infer OpenCensus resource type based on OpenTelemetry's semantic conventions opentelemetry-collector#1462
3. Convert any labels to str when setting it in proto. The labels should all be strings, but this is currently only type-checked.

Previously, start_timestamp wasn't being passed at all. For metrics that are cumulative over the life of the process, the exporter should be sending a start time since startup. The docstring for this start_timestamp:

// Must be present for cumulative metrics. The time when the cumulative value
// was reset to zero. Exclusive. The cumulative value is over the time interval
// (start_timestamp, timestamp]. If not specified, the backend can use the
// previous recorded value.
google.protobuf.Timestamp start_timestamp = 1;

The OpenCensus to OpenCensus Agent exporter sends the start_timestamp that is attached to each series, but OT doesn't store the start time in the aggregator or batcher AFAIK. I feel like this should be added, but we are waiting for the SDK specification still.

Questions

• Should we also send the start_timestamp for non-stateful instruments? There is no nice way to get the interval's start time AFAIK; the Google cloud monitoring exporter is just caching the previous end time and using that as the start_timestamp of the next collection window: https://github.com/GoogleCloudPlatform/opentelemetry-operations-python/blob/a3f35dab9bf9e90fde5ab6acd274f6ec7b2567b4/opentelemetry-exporter-cloud-monitoring/src/opentelemetry/exporter/cloud_monitoring/__init__.py#L253-L255
• Is there a way to specify which resource keys should be sent? Right now I am sending all of them, which is added to each metric in the request. I don't see any sanctioned way to do this in the spec.

[lzchen]

The OpenCensus to OpenCensus Agent exporter sends the start_timestamp that is attached to each series, but OT doesn't store the start time in the aggregator or batcher AFAIK. I feel like this should be added, but we are waiting for the SDK specification still.

What does "start time" mean? When the metric is recorded or exported? Does it only make sense for non-stateful instruments?

EDIT: From the specs: "The time when the cumulative valuewas reset to zero." So this leads me to believe that it is upon export time. Wouldn't the exporter be responsible for this value then instead of the metric/aggregator/batcher?

Should we also send the start_timestamp for non-stateful instruments

What would start_timestamp mean for non-stateful instruments? If following the specs, when their value was reset to zero would be upon every export right?

[aabmass]

So this leads me to believe that it is upon export time. Wouldn't the exporter be responsible for this value then instead of the metric/aggregator/batcher?

By "upon export time" do you mean from whenever the exporter started up? That's what I'm sending for stateful metrics

What would start_timestamp mean for non-stateful instruments? If following the specs, when their value was reset to zero would be upon every export right?

That is my understanding, although the docstring in the proto file makes it sound likes this is done automatically: "If not specified, the backend can use the previous recorded value."

[lzchen]

@aabmass

By "upon export time" do you mean from whenever the exporter started up?

Ahh sorry I misunderstood what you meant by start time. Forget this question.

but OT doesn't store the start time in the aggregator or batcher AFAIK

I asked this originally to address this. I'm not sure if starttime should be part of the aggregator/batcher? Wouldn't it make sense for it to be just part of the exporter when it is instantiated/first exported?

[aabmass]

Wouldn't it make sense for it to be just part of the exporter when it is instantiated/first exported

@lzchen, I am going with when the exporter was instantiated for now. I think this is as accurate as we can get without adding a start_time to the SDK.

[ocelotl]

Just minor comments