David Ashpole

I think we are probably doing the right thing in the prometheus receiver... The `labels` config is supposed to add a label to every metric series. If there was an...

> increase the cardinality of all senders' timeseries 2x when senders are redeployed Is that actually the case? Won't it only increase the cardinality of the target_info series? I wouldn't...

Job and instance are converted to `service.name` and `service.instance.id` in the prometheus receiver, and are converted back (and added as metric labels) in the PRW exporter, so they should be...

> however, will add that the string "target_info" does not appear in the spec today? Yes, I even managed to confuse myself on that front: https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/12079#issuecomment-1183189066. I'll update the spec...

@mrblonde91 No, this shouldn't impact any other metrics.

The "short_name" attribute is intended to be used for the prometheus namespace, but is currently a work-in-progress: * https://github.com/open-telemetry/opentelemetry-specification/pull/2702 * https://github.com/open-telemetry/opentelemetry-specification/pull/2703 Also, I'm working on a migration OTel for OC...

I'm fine prefixing everything we use the OTel API for with `otel` for now. I'm not sure its worth the effort, but if people actually want to use otel instrumentation...

I'd prefer waiting. I don't see the urgency in changing the OTel metric names while the OTel metric SDK is being rewritten.

To clarify what I was trying to get across at the SIG meeting today: * Combining prometheus metrics from both OC and OTel **requires** a given metric to only be...

I think there is a difference between `EnsureCapacity` + `Append` vs `SetLen` + `SetAt` if we need to not add an item, right? It seems better to encourage EnsureCapacity +...