move common hardware attributes and metrics to registry #1030
Conversation
| unit: "{errors}" | ||
| extends: metric.hardware.attributes | ||
| attributes: | ||
| - ref: hw.error.type |
There was a problem hiding this comment.
| - ref: hw.error.type | |
| - ref: error.type |
There was a problem hiding this comment.
I have answered in another similar comment
There was a problem hiding this comment.
Since there was no defined attribute for hw.error.type, my strong preference would be not to introduce one and instead use generic error.type.
Otherwise, we'd end up with another attribute that should be immediately deprecated.
| value: 'temperature' | ||
| brief: 'Temperature' | ||
| stability: experimental | ||
| - id: voltage |
There was a problem hiding this comment.
same here - voltage seems confusing as a type
There was a problem hiding this comment.
so the suggestion is to use voltage_sensor
There was a problem hiding this comment.
@lmolkova See my previous comment for temperature.
lmolkova
changed the title
|
cc @bertysentry |
|
@lmolkova I'm confused by your comments. I haven't created anything new. I have extracted hardware from one md file into yaml. As I stated in description I will do this in batches because there will be open questions and to make review easier, so I have extracted only first portion |
Co-authored-by: Liudmila Molkova <limolkova@microsoft.com>
trisch-me
changed the title
|
@trisch-me Thank you so much for taking the time to move the hardware semconv to YAML! (I was supposed to do it but couldn't find the time... and I was afraid the tooling wouldn't work well on some of the specificities of the hardware metrics, with common attributes, etc.). Let me know if you need any help with that! If you want to see these metrics in real life (to get a better understanding of their purpose and use), you can check these Grafana dashboards: Thanks! |
|
thanks @bertysentry for your comments. If you don't mind I will add you as reviewer to all my PRs related to the moving hw metrics to the yaml files/registry off-topic - I think we have met in the OTel booth during this Kubecon conference in Paris :) |
|
@trisch-me I confirm we met in Paris! It's funny when you realize usernames in GitHub are actual people! 😅 I'll be happy to review any PR on this topic! |
|
|
… into hardware_basic
| @@ -44,6 +44,7 @@ body: | |||
| - area:gcp | |||
| - area:gen-ai | |||
| - area:graphql | |||
| - area:hardware | |||
There was a problem hiding this comment.
could we be consistent with the root namespace?
| - area:hardware | |
| - area:hw |
(and in other places)
There was a problem hiding this comment.
hw as abbreviation seems strange to me in registry so I prefer hardware, but I haven't changed the namespace.
@bertysentry do you think we should/can change common namespace for hardware to be indeed hardware and not hw?
I created #1071 to keep track of HW naming issues. I still suggest to do a bare minimum changes to existing HW metrics so that we don't need to deprecated a bunch of things later ( |
This is the first PR out of many for hardware metrics.
The first PR is about generic attributes used by all hardware metrics. I decided to split it into multiple PRs to make review easier because it's easy to miss something with a lot of changed files (I have started doing it with 5 metrics and lost myself track on things :) ).
I delete portions of
docs/system/hardware-metrics.mdfile so that reviewers could see what has been changed now. This file will be deleted later as soon as it will be ported completely.Hardware wasn't moved to the yaml schema, so I'm doing here both introducing it to the registry and creating appropriate yaml files for each hardware metric
I need this PR merged before I will create other PRs (half of them is ready but based on this PR)
Merge requirement checklist
[chore]