Add an internal metric build_info

[gillg]

Is your feature request related to a problem? Please describe.
Add a metric exposing the build_info somewhere around https://github.com/open-telemetry/opentelemetry-collector/tree/main/internal/obsreportconfig/obsmetrics
This could be very useful to monitor deployed collector and track version drifs, missing updates and so on...

[Ashmita152]

Can I pick this task if no one has picked it yet.

[bogdandrutu]

We already have the version in all the metrics, but not enabled by default https://github.com/open-telemetry/opentelemetry-collector/blob/main/service/telemetry.go#L48

[gillg]

Thanks @bogdandrutu ! But I don't unsertand, by default this var is true, I don't see any way to update it, but I don't have it either in timeseries, either in metrics labels. 🤔
Moreover, this seems higly related to OpenCensus, but I know there is a lot of efforts made around Prometheus receiver to get rid of dependancies in OpenCencus, does this telemetry.go file is always in use ?

[bogdanov1609]

+1 on this one.
And i dont think that adding version in all the metrics is a good idea, because every time series database(like prometheus, victoria metrics or InfluxDB) doesn't like too many uniq time series.

[gillg]

@dashpole don't you think it duplicates the new "target" metric ? In this case the version, go version, etc will be resources attributes of all internal otel collector data.
What would be the plan to avoid conflicts with external receivers from multiple sources ?
There is also a conceptual question around the otel collector metric endpoint in Prometheus format. Does it should expose the "target" metric and Prometheus receiver just carry it without transformation?

[dashpole]

don't you think it duplicates the new "target" metric ?

Yes, this is a special-case of passing resource information through prometheus.

What would be the plan to avoid conflicts with external receivers from multiple sources?

I'm not sure I understand the question.

Does it should expose the "target" metric and Prometheus receiver just carry it without transformation?

The prometheus receiver will transform target info back into resource information. That is specified in https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/datamodel.md#resource-attributes, and is tracked in open-telemetry/opentelemetry-collector-contrib#8265.

[jmcarp]

Was there a decision about this? A metric like otelcol_build_info metric would be really useful. My team runs a large number of otel collector instances, and it would be great to be able to count collectors by version with a single query.

[codeboten]

This is currently exposed in the target_info metric and additionally applied to each metric as attribute

otelcol_processor_batch_metadata_cardinality{processor="batch",service_instance_id="5ba8d547-4742-4bf1-9c49-fa18b7ec142b",service_name="otelcorecol",service_version="0.105.0-dev"} 2

target_info{service_instance_id="5ba8d547-4742-4bf1-9c49-fa18b7ec142b",service_name="otelcorecol",service_version="0.105.0-dev"} 1

I believe this can be closed. Please re-open if that's not the case