-
Notifications
You must be signed in to change notification settings - Fork 412
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support multi-key fields from SemConv #2333
Comments
Other similar case is
|
That's interesting. I wasn't aware that we were adding all HTTP headers to the mapping. @axw did you hear of situations where this lead to mapping explosions? It seems a bit dangerous to me as anyone can just create a bunch of requests with unique HTTP headers and force the backend into a field explosion.
This would also work in case Click to expand example
This doesn't work when Click to expand example
|
I haven't.
That's a good point, I don't think anyone considered this. |
@felixbarny should I bring into next semconv meeting your thoughts about field explosion? Or if you want you can create issue here |
I'm not sure if this is an issue with semantic conventions per-se. It depends on how backends can deal with namespaces that don't have a bounded number of fields. Some may be more resilient than others when it comes to the total number of fields. For example, some vendors may only store fields of certain namespaces for retrieval but don't maintain in-memory metadata about them. What we can do when it comes to mapping Still, I think it would be interesting to get some insight into how other backends intend to deal with these multi-key fields. So if you could bring that up in the next semconv meeting, that would be highly appreciated. |
Summary
(Not sure if
multi-key fields
is the right term; if there is a better short name describing it, let's update the title.)OTel SemConv defines fields which can have multiple keys - examples are:
http.request.header.<key>
, this is alreadystable
db.query.parameter.<key>
There are 2 aspects of this:
We discussed this with @felixbarny shortly, regarding point 2:
flattened
field typeenabled
to false.labels
with similar dynamic keys, currently with this mapping:Issue with above is that this leads to field explosion.
The text was updated successfully, but these errors were encountered: