Adds in more generic hw attributes #2417

[thompson-tomo]

Fixes #2417

Changes

Adds in vendor. serial & model as generic hw attributes given that they are used for most of the hardware definitions and are applicable in all cases.

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.

[bertysentry]

I think it's a great idea to define common vendor, model, and serial number attributes!

However, I'd say KISS principle applies here:

• hw.vendor for indicating the vendor
• hw.model for indicating the model
• hw.serial_number for the serial number

I see very few modern hardware instrumentations (Dell, HPE, Cisco, Huawei, NetApp, Pure, etc.) providing separate fields for vendor ID and vendor name (like we have in PnP or in IANA enterprise number). Even Redfish's detailed ComputerSystem resource doesn't expose separate vendor ID and name, model ID and name.

Edit: broken link to Redfish spec

[thompson-tomo]

I originally had it like u suggested but then I noticed what was done in host.cpu.* hence I went more verbose. Note My intention is to consolidate those to be in the hw namespace hence to avoid that confusion.

[bertysentry]

Thank you, James, we're on the same page! @thompson-tomo

[bertysentry]

Also, we need to remove host.cpu.vendor.id in favor of host.cpu.vendor:

• It says "id" but stores the values in EBX, EDX and ECX registers returned by CPUID, like "GenuineIntel" or "AuthenticAMD". That’s not an ID, that’s just a quirky vendor branding string.
• Other fields in our semconv (e.g., cloud.provider, container.image.name, etc.) are plain English strings, not weird hardware-returned mnemonics. Why suddenly diverge for CPUs? It's confusing to everyone.
• "GenuineIntel" vs "Intel" — this doesn’t help anyone doing aggregation, dashboarding, or alerting. If our goal is consistent, readable observability data, this CPUID value is garbage. It’s like using "msft" instead of "Microsoft".
• CPUID is x86-only. What about ARM? What about RISC-V? We’re baking x86 assumptions into a supposedly architecture-agnostic semantic layer.

[thompson-tomo]

I disagree, as cpuid is not a name but rather an id with a fixed length. "SIS SIS SIS " is an is with the name being sis.

[bertysentry]

We're trying specify the attributes of a physical entity here, as in DMTF's CIM_PhysicalElement class.

My suggestion:

• hw.entity.vendor
• hw.entity.model
• hw.entity.serial_number
• hw.entity.family
• hw.entity.type
• hw.entity.part_number
• hw.entity.vendor_code (if really someone needs it 😅)
• etc.

This can be easily extended later and clearly identify these attributes' intention.

We could use another word that entity, like element, component, etc. But in OpenTelemetry, I think we prefer entity.

And the best part: it avoids namespace collisions!

@thompson-tomo What do you think?

[thompson-tomo]

I am not a fan as it is not consistent with anything else or the naming guidance. The entity part is redundant. And the ambiguity is being introduced as a vendor could have a name, address, phone number etc.

Also entity, if not already blocked it should be to avoid confusion.

[bertysentry]

You're probably right, @thompson-tomo, so we will keep it simple:

• hw.vendor
• hw.model
• hw.serial_number

This is what past standards like DMTF CIM, Redfish, and others have been using over the past 3 decades.

[thompson-tomo]

Forget serial number.

Under your suggestion how can we model a cpu model which has the below while still being compliant with naming:

• Id
• Name
• Family
• Description

With 3 of those currently in use in the host.cpu namespace?

[bertysentry]

Most often, CPU information comes from SMBIOS type 4, as defined by the DMTF. I'm referring to page 42 of this specification.

• Processor Version will be mapped to hw.model and/or host.cpu.model
• Processor Manufacturer will be mapped to hw.vendor and/or host.cpu.vendor
• Processor Family does not need to be mapped either as it can be deduced from Processor Version, but could be mapped to hw.family and/or host.cpu.family
• Processor ID does not need to be mapped as it's just raw identification data, which can be transformed into vendor, family, and version.

Let's take a real example.

This is the SMBIOS Type 4 information from my own laptop:

See how it's reported by WMI with the Win32_Processor class:

How it's reported in LibreHardwareMonitor:

How it's reported in Task Manager:

How it's going to be reported in OpenTelemetry attributes:

• hw.vendor: GenuineIntel
• hw.model: 12th Gen Intel(R) Core(TM) i7-1280P

I've been in this field for 20+ years (infrastructure monitoring). Not a single of the 500+ customers I worked with (Fortune500, large data centers, etc.) ever requested more detailed information.

[thompson-tomo]

Thanks for that detailed response, I think part of the difference is for me is looking at it from an app users experience vs an infrastructure monitoring perspective.

Howabout we introduce hw.family rather than hw.model and use that for the hw metrics. I want to avoid blocking the usage of the namespace hw.model.* as In the future i would like to see a device feed up that device xyz is an ups and has model 123. That data is enriched using a registry at which point you have access to a wide range of data about including links to support sites, release dates hence the namespacing. I know it would take alot to get there but it is good to dream.

For vendor that could avoid namespacing for the attributes if everyone else is inboard.