add User-agent OS attributes

[rogercoll]

Fixes #1433

Changes

Please provide a brief description of the changes here.

Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[rogercoll]

The PR is mostly a copy and paste from the OS attributes current definition to the user_agent's attributes, is there a way to reference them but applying the "user_agent" prefix?

[github-actions]

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

[github-actions]

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

[github-actions]

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

[trask]

this looks like a straightforward embedding of os.name and os.version under the user_agent.* namespace 👍

[trisch-me]

I think we might revisit these attributes when embediing will be there to re-use os.* attributes

[trask]

I think we might revisit these attributes when embediing will be there to re-use os.* attributes

that will just be a mechanical change? or do you think that would change (break) the semantics of these new attributes?

[trisch-me]

from my POV one of the goals of embedding - not to break semantics of fields itself, but adding additional meaning.
In this particular case os.* attributes will be attached to the user agent hence additional meaning. But this is what we are already having while introducing these fields so I don’t see any problems

[trask]

@rogercoll sorry, one more thing, can you describe how you are using these attributes? e.g. are you enriching existing spans that already have user_agent.original? or emitting events, or other spans using them? thanks!

based on how you're using them, we can consider if we would like to add them to one of those signals in semconv, e.g. as an opt-in attribute on http spans

[rogercoll]

@rogercoll sorry, one more thing, can you describe how you are using these attributes? e.g. are you enriching existing spans that already have user_agent.original? or emitting events, or other spans using them? thanks!

based on how you're using them, we can consider if we would like to add them to one of those signals in semconv, e.g. as an opt-in attribute on http spans

Not enriching spans at the moment, but enriching logs that contain an unparsed user_agent. Specifically, the Nginx Ingress Controller structured logs in which we extract the corresponding fields using OpenTelemetry Collector's processors (OTTL). Although the Nginx Ingress Controlled Log Event PR is in a draft state, we would like to include the log attributes containing this user_agent.os* values.