add User-agent OS attributes #1434
Conversation
|
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? |
|
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
|
|
||
| ## User-agent OS Attributes | ||
|
|
||
| Describes the OS user-agent attributes. |
There was a problem hiding this comment.
Could you please describe the use-case for these attributes? is there any instrumentation or semantic convention that's supposed to populate it?
We usually add attributes along with the convention (span/metric/resource/event) that uses them - this usually results in more specific attribute definition and more clarity for those who want to populate the attribute on other conventions.
So, could we define such convention and/or document the use-case in some other way?
There was a problem hiding this comment.
Could you please describe the use-case for these attributes?
For example, to understand which are the source OSes that are making requests to your system. This could be used from a Nginx Ingress Controller log, which records all requests UserAgent's.
is there any instrumentation or semantic convention that's supposed to populate it?
There is an ongoing PR in the collector: open-telemetry/opentelemetry-collector-contrib#35458
We usually add attributes along with the convention (span/metric/resource/event) that uses them - this usually results in more specific attribute definition and more clarity for those who want to populate the attribute on other conventions.
From the collector point of view, these attributes are agnostic to its location, they will be extracted from any defined context (span/metric/resource/event). I would like to use it to populate a Nginx Ingress Controller event, but it is not defined in Semconv yet (#982). Would it make sense to add a Nginx log example and explain how these attributes could be extracted?
There was a problem hiding this comment.
@lmolkova How could we proceed with this PR? In which section could I add the use-case? brief field?
If a proof of concept is needed beforehand, we could unblock open-telemetry/opentelemetry-collector-contrib#35886 (comment) by just referencing this PR for now.
model/user-agent/registry.yaml
Outdated
| brief: > | ||
| The operating system type. | ||
| stability: experimental | ||
| - id: user_agent.os.description |
There was a problem hiding this comment.
is this needed? I don't see it in ECS, and I'm not sure what you would populate it with via https://github.com/ua-parser/uap-core
There was a problem hiding this comment.
I think the equivalent in ECS would be the os.full field, ECS embeds all the os fields in the user_agent: https://www.elastic.co/guide/en/ecs/current/ecs-user_agent.html#_field_reuse_30
Given that there is no direct mapping for this field in https://github.com/ua-parser/uap-core/blob/master/docs/specification.md#os_parsers and the collector's use case does not cover this attribute at the moment, it is ok for me to remove it until the use case 1b46946
model/user-agent/registry.yaml
Outdated
| The version string of the operating system as defined in | ||
| [Version Attributes](/docs/resource/README.md#version-attributes). | ||
| examples: ['14.2.1', '18.04.1'] | ||
| - id: user_agent.os.build_id |
There was a problem hiding this comment.
same question for this attribute, thanks
There was a problem hiding this comment.
Removing it until we have a use case 1b46946
wdyt? Thanks for the review!
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
[chore]