Update support for semconv versions up to semconv 1.27.0 #440
Conversation
elastic-observability-automation
bot
added
the
safe-to-test
| }, map[string]interface{}{ | ||
| "http.scheme": "https", | ||
| "http.server_name": "testing.invalid", | ||
| "server.port": 80, |
There was a problem hiding this comment.
QQ: When I was working with the user fields mapping, I wondered if the unit tests file should be using constants for these. Previously, they were defined privately in otlp package while the tests were in otlp_test, so I couldn't just import it and use the constants. Moving forward, should we use semconv constants where possible even in tests?
There was a problem hiding this comment.
No strong opinion, but using hardcoded values instead of updating the tests to the same constants as the actual business logic, allows to more easily spot if any previously supported key is dropped or e.g. accidentally renamed.
Overall, I do not expect us to put a lot of effort into this going forward. We should keep up-to-date with semconv, but the update PRs should hopefully be small as semconv stabilizes more and when we upgrade more regularly (this time we upgraded from 1.5 to 1.27.
The goal of this PR is to support the latest semantic conventions for already mapped otel attributes, without introducing any breaking changes. This is desirable so that users can upgrade their agent SDKs to newer versions without losing semantics when data are mapped with this library.
Backwards compatibility is achieved by keeping the deprecated field names in the mapping. Where possible, the new field names were added. In cases where no new field names are defined by otel, the fields would be stored as labels instead of concrete mappings, however this would be a breaking change in the semantic conventions itself, rather than in the apm-data mapping logic.
The mapping logic is taken from https://opentelemetry.io/schemas/1.27.0 as much as possible, and otherwise where possible from the deprecation notes in the semconv version implementations.
This PR does not introduce support for additional, previously unmapped otel fields.