Open dmitryax opened 1 month ago
@codeboten, please let me know if it makes sense
100% i would like to move in that direction for all internal telemetry as well
Just to confirm with the assignment, I'll work on this 👍
Started working on this, just want to bring up a limitation of the upstream go.opentelemetry.io/otel/attribute
package. As described in this issue's description, attributes are added to a telemetry metric using the go.opentelemetry.io/otel/attribute
package's functionality of attribute.NewSet
, passing in the correct KeyValue information.
However, KeyValue
only supports a subset of valid attribute types that our metadaya.yaml
supports.
From mdatagen's metadata schema: https://github.com/open-telemetry/opentelemetry-collector/blob/505819e63ae2b615d7c57c9cfe2b4325ae82dc4c/cmd/mdatagen/metadata-schema.yaml#L72
Types supported by KeyValue
can be seen here.
The missing types are as follows: bytes
, slice
, and map
. I believe this is an existing limitation, unrelated to this change. However, it may be good to document this limitation in the metadata schema file.
Edit: I've submitted #10997 to clearly state this limitation in the schema.
I've got most of the functionality working, but I'd like to make sure it's tested more thoroughly before going forward. My current plan is as follows:
metadata.yaml
.My goal is to be able to have tests that ensure existing behavior of recording telemetry metrics and their attributes doesn't change as a result of this.
Define all the attributes for internal metrics in the metadata.yaml similar to what we do for the scraper metrics.
Those attribute definitions should be used to generate documentation and helpers that replace the directly exposed counters with
Record...
functions.For example:
Instead of
we would generate