[component] Add namespace parameter to component.BuildInfo

[dpaasman00]

Description

Adds a new field to component.BuildInfo to facilitate support for reporting the service.namespace semantic convention in OpAMP. Includes corresponding updates to resource attributes reported by the collector. Also adds a new parameter to the builder configuration to facilitate setting this via the OCB.

Link to tracking issue

Fixes #12505

Need follow up PR to OpAMP extension making use of this value.

Testing

Relevant unit tests updated.

Running the updated otelcorecol with logging enabled in service.telemetry and the new resource attribute for service.namespace shows up. This was done sending to another collector running the otlp receiver and logging via the debug exporter.

02-26-25_monitoring-output.txt

Documentation

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.20%. Comparing base (8cf42f3) to head (146215c).
Report is 126 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12508      +/-   ##
==========================================
+ Coverage   92.18%   92.20%   +0.02%     
==========================================
  Files         469      469              
  Lines       25390    25395       +5     
==========================================
+ Hits        23405    23416      +11     
+ Misses       1574     1568       -6     
  Partials      411      411              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[evan-bradley]

Overall looks good to me.

[dpaasman00]

Contrib tests failing

[bogdandrutu]

I am not sure I understand, how this. Why do you not configure the "service.namespace" in the service::telemetry::resource?

[bogdandrutu]

The service.namespace is a runtime identification configuration and not a build time identification configuration, so I am confused why we need a change to the build info.

Need more discussion

[evan-bradley]

@dpaasman00 I've discussed this offline with other core leads and received some feedback that we may need to make some changes. Could you make the following updates to this PR?

1. Remove Namespace from component.BuildInfo. component is a stable module, so we need to be absolutely sure of anything we put in there. We will likely need to pass information from the builder down to the service through a new parameter for now, and we can consider moving it to component.BuildInfo in the future. Additionally, is there a term other than namespace that we could use to uniquely identify distributions in a way that doesn't include the binary name?
2. Clarify whether service.namespace is the correct attribute for something set at build time. My initial impression was the same as Bogdan's, that service.namespace is primarily intended to describe the runtime context of a service than describe its functionality, but reading the docs and seeing how we set service.name, I'm not so clear on this. Could you determine whether we should set this information in service.namespace, or whether service.name may be more appropriate? If we don't set service.namespace, maybe we add a distro field and make the service.name attribute something like opentelemetry.otelcol.

[evan-bradley]

A relatively minor aside: I read through the docs again and saw this:

Note: service.namespace and service.name are not intended to be concatenated for the purpose of forming a single globally unique name for the service.

I don't think this strictly impacts anything here since we can define the semantics if we concatenate the distro and binary inside service.name, but we do need to think about what it means if we put the distro into service.namespace.

[dpaasman00]

After spending some time thinking about this, I agree that service.namespace is not the correct attribute for what we're trying to accomplish. The goal is to better differentiate collectors now that the OCB enables users to create and manage their own distributions and versions of the collector. To achieve this, I think we should add 2 new attributes to the service resource semantic convention, service.description and service.distribution.

• service.description would be a long, human friendly description of what the collector is intended for. There is already a distribution.description config parameter for the builder that gets added to the BuildInfo, this would just need to get reported by the OpAMP extension once the semantic convention is established.
• service.distribution would represent who created and manages the manifest the collector was built with. Implementing this attribute would require adding a new parameter to the builder, adding a new field to BuildInfo, and updating the OpAMP extension to report this value once the semantic convention is established.

I understand this approach would take a while since we're changing the semantic conventions and BuildInfo, but I do think it is a better approach to the original problem this PR was trying to solve.

@evan-bradley @bogdandrutu What do you think of this approach?

[evan-bradley]

Thanks for your thoughts, I'm largely in agreement with everything you wrote. There is an existing proposal for something similar, but under the agent attribute namespace: open-telemetry/semantic-conventions#950. I think it would be worth checking on that PR or at the next OpAMP SIG meeting how we should proceed there.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.