Closed sebastien-rosset closed 1 month ago
- In process:
state
,direction
,type
.
I created PR #3431 to explore what namespaced metric attributes could look like for process metrics
I wonder if there's a way for us to preserve the short attribute names we have and add an attribute-namespace concept to be determined at the instrument-level, for example. A hardware metric can use "state" and we'll know that it's a hardware "state" because of perhaps a scope-level attribute ("attribute.namespace=hardware").
Attribute names are indeed namespaced now. If you have any examples not yet converted please open issues for them in the semconv repo.
What are you trying to achieve?
Fix the names of the attributes in the semantic guidelines to make them hierarchical. Some names are not hierarchical in hardware, system.
What did you expect to see?
Under the hardware semantic guidelines, the names of the attributes should be hierarchical.
Elsewhere, HTTP, RPC, Database, System, Process, Runtime Environment, FaaS are consistently using hierarchical names, with
state
noted as an exception. However, in the Hardware guidelines, many names have a flat structure, which is not compliant with the naming guidelines.If exceptions to the naming hierarchy requirement are allowed, IMO that should be explicit in the spec.
Additional context.
The spec states:
Defining lots of attributes with no name hierarchy has the side effect of preventing any future use of that word as a namespace. These attributes are declared with a flat naming structure:
direction
,vendor
,model
,serial_number
,vendor
,firmware_version
,bios_version
,driver_version
,firmware_version
,id
,name
,parent
,chemistry
,capacity
,limit_type
,state
,sensor_location
,type
,task
,raid_level
,logical_addresses
,physical_addresses
,smart_attribute
.state
,type
,direction
,device
,cpu
,mode
,mountpoint
,protocol
,status
.state
,direction
,type
.state
,pool
,type
,daemon
,gc
,action
.capacity
is defined as the capacity in Watts-hours or Amper-hours, which is highly specific to batteries. However, the word capacity is contextual, it could mean something entirely different in another namespace. It seems that by allowing names to be flat, more flat-names will be created in short order, which inevitably will lead to collisions or other naming problems. At some point, shouldn't there be a registry of namespaces, similar to what was done at the IETF or IEEE?Device
device
attribute is defined under disk controller metricsdevice.id
attribute is defined in device attributesThis means the word
device
is both a namespace and attribute name. This breaks this attribute naming rule:State
Out of curiosity, I looked at all the possible values for
state
: