Closed sebastien-rosset closed 5 months ago
Semantic conventions for System, Runtime Environment and Process use these attributes without prefixes:
direction
state
cpu
type
device
mode
mountpoint
protocol
status
pool
daemon
action
gc
direction
is notably used for the following metrics:
process.disk.io
process.network.io
system.paging.operations
system.disk.io
system.disk.operation_time
system.disk.merged
system.network.dropped
system.network.packets
system.network.errors
system.network.io
Semantic conventions for hardware simply follow the same pattern and ensure consistency for this attribute and its possible values, as recommended by the general guidelines for metrics semconv.
My advice is that we must update the specification for attributes naming. While it is critical to have unique attribute names for Resources, it should not be mandatory for metric attributes.
Metric attributes are defined in the scope of a given metric (in OpenTelemetry) and there is no possible conflict of 2 attributes with identical names from 2 different metrics.
Having direction
attribute in process.disk.io
, system.network.io
and hw.network.io
is never going to be a problem.
If we can avoid prefixing everything as if it were Java class names, it will make everybody's life much easier too, and save some storage space as well ;-)
Thanks. If that's the case, then yes the specification for attributes naming should be updated. This would apply to #3131 as well.
Given that the spec explicitly states attribute names must be hierarchical, one could wrongly assume metric attributes do not have name collisions across metrics. This could be a problem when exporting metrics and their attributes to an external database. The spec could explicitly state the names of metric attributes are unique within the scope of a metric.
Presumably the spec would also have to state something about naming conventions for attributes defined in the spec itself versus attributes defined by other organizations. Someone could create metric-level attributes with common words or contractions such as com
, memory
, mtu
, buffer
, etc, which may collide with future use of the same words in the spec but with different semantics.
Thank you for the clarification.
Metric attributes are defined in the scope of a given metric (in OpenTelemetry) and there is no possible conflict of 2 attributes with identical names from 2 different metrics.
I thought the specification allowed for extensibility? I.e., a per-metric attribute can be defined in the specification, and a vendor may also define custom attributes. At least this is how I understood the recommendation to use hierarchical names. A hierarchical name such as com.myCompany.foo.bar
helps to avoid collisions, even if the spec adds new attributes in future versions of the spec.
If a vendor can create a per-metric attribute with a flat name, then I don't see how it's possible to avoid future collisions. For example, one may want to create custom attributes such as form_factor
or port_type
. In that case, maybe the vendor will be lucky, or maybe not.
Shouldn't there be a way to ensure there is no possible collision between custom attributes and standard attributes?
Looks like this issue is resolved now. direction
was recently changed to have different prefixes depending on a use case: system.paging.direction
, disk.io.direction
, network.io.direction
.
We feel that this has been addressed, if you feel differently, leave a comment and we can reopen the issue, @sebastien-rosset
What are you trying to achieve?
Either:
direction
attribute so that it's compliant with the naming guidelines.direction
.What did you expect to see?
I was expected the OpenTelemetry spec to be self-consistent with naming conventions, in particular that the
direction
name is hierarchical.Additional context.
The spec states the instrument should have attributes for direction; oddly, plural is used, which implies there could be more than one attribute for direction, but without explaining why plural makes sense. Further, that sentence is not stating the attribute should be named
direction
, but elsewhere it was interpreted as a literal requirement, i.e., the name of this attribute ISdirection
.Using the name
direction
breaks some of the semantic rules listed in the spec:One issue is that another namespace could have a different concept of "direction" such as up, down, or East, West, left, right, etc. For example a vane anemometer could have a direction attribute which reports wind direction in degrees or cardinal direction. Perhaps for I/O the attribute should be named
hw.io_direction
.In addition, the spec states:
Defining attributes with no name hierarchy has the side effect of preventing any future use of that word as a namespace.