Attributes with nested data structures #3624
-
We have a use case where we want to capture complex JSON objects in span event attributes. The solution proposed is to serialize the value into a JSON string, but that can be challenging to use effectively in some back end systems. In the example I liked above we are trying to represent validation errors in span events https://graphql.org/learn/validation/: {
"errors": [
{
"message": "Field \"name\" must not have a selection since type \"String!\" has no subfields.",
"locations": [
{
"line": 4,
"column": 10
}
]
}
]
} Looking at the object I can see some direct mappings to OTel Trace SemConv attributes, while others may be a little more ambiguous: {
"events": [
{
"name": "Field \"name\" must not have a selection since type \"String!\" has no subfields.",
"attributes": {
"graphql.validation.errors": [
{
"code.lineno": 4,
"code.column": 10
}
]
}
}
]
} All that being said, what is the best way for us to represent these validation errors? Should we include them in our instrumentation at all? What are other language SIGs doing for these use cases? cc: @swalkinshaw @open-telemetry/ruby-contrib-approvers @open-telemetry/specs-semconv-approvers |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
hi @arielvalentin ! I opened an issue to discuss the GraphQL semantic convention: open-telemetry/semantic-conventions#182 would be great to join forces, feel free to add your thoughts on the proposal. |
Beta Was this translation helpful? Give feedback.
-
A related feature request: #3731 |
Beta Was this translation helpful? Give feedback.
hi @arielvalentin !
I opened an issue to discuss the GraphQL semantic convention: open-telemetry/semantic-conventions#182
would be great to join forces, feel free to add your thoughts on the proposal.