If you are affected by the OpenTelemetry HTTP semantic convention stabilization breaking changes, this guide will help you migrate your application from the old semantics to the new, stable semantics.
To identify whether you are affected, visit OpenTelemetry HTTP Semantic Conventions Compatibility.
Understand the Impact
As a part of the stabilization breaking changes, 17 attributes in the HTTP semantic conventions were renamed, such as http.status_code changing to http.request.status_code.
These changes are likely to impact several areas within Honeycomb.
We recommend to review the complete list of attribute changes in OpenTelemetry’s Summary of Changes.
With these attribute changes in mind, we also recommend to review your Honeycomb:
- SLOs
- Triggers
- Calculated Fields
- Boards and saved queries
- Refinery rule conditions and field lists
- OpenTelemetry Collector configurations
If any of these elements depend on attributes with HTTP semantic conventions, then you will be impacted by these breaking changes.
Migration Strategy
OpenTelemetry defines a special environment variable, OTEL_SEMCONV_STABILITY_OPT_IN, that should be added to language instrumentation to help users migrate.
We recommend the following migration steps:
- Set the
OTEL_SEMCONV_STABILITY_OPT_IN environment variable to http/dup so that the instrumentation library will be able to create data using both the old and stable HTTP semantic conventions.
- Update to an instrumentation library version that supports
OTEL_SEMCONV_STABILITY_OPT_IN.
- Coalesce your data to include the new, stable HTTP semantic conventions.
- Change your SLOs, Triggers, Calculated Fields, Boards, Refinery Rules, and OpenTelemetry Collector Configurations to use the new, stable HTTP semantic conventions.
- Then, set
OTEL_SEMCONV_STABILITY_OPT_IN to http so that the instrumentation library only emit the new, stable HTTP semantic conventions.
- Test that everything works as expected.
- When possible, upgrade to an instrumentation library version that only supports the new, stable HTTP semantic conventions.
Refer to our language compatibility matrix to determine important library instrumentation versions and whether the library supports http/dup.
Coalesce Your Data
Producing both sets of HTTP semantic conventions at the same time is the best way to ensure a seamless transition between the old and the new HTTP semantic conventions.
Setting the OTEL_SEMCONV_STABILITY_OPT_IN environment variable to http/dup enables this dual semantic convention ability for you.
If this is not an option, such as using a language that does not yet support the stable HTTP semantic conventions in OTel, complete these steps (as applicable) to ensure your setup can handle the transition period:
Use the OpenTelemetry Collector
The OpenTelemetry Collector allows for coalescing of data before it reaches Refinery (if applicable) or Honeycomb’s endpoint.
We highly recommend that you use an OpenTelemetry Collector to transform and forward your data, especially when dealing with this change.
If your collector includes the alpha schema processor, you can use it instead of writing the OTTL coalescing statements in this guide.
The schema processor reads each signal’s schema_url, fetches the corresponding schema file, and applies schema-defined renames automatically.
It also supports a migration mode that emits both old and new attribute names during the transition.
The OTTL approach in this guide works for collectors without the schema processor and for environments where alpha components aren’t acceptable.
Coalescing Span Attributes
Use the following OTel Collector configuration to ensure that both new and old span attributes are always present in your data before it gets sent to Refinery or Honeycomb.
Using the configuration below prevents data breakage and allows for incremental updates for other things, like SLOs and Triggers, without risking data loss:
Coalescing Metrics
Coalescing the metrics changes is more complicated, but still possible.
If you use metrics, determine whether you want the metrics to appear in Honeycomb with the old values or the new values.
Based on your decision, use one of the two examples below to modify your OTel Collector configuration for metrics.
The following OTel Collector configuration renames old metric values to new metric values:
The following OTel Collector configuration renames new metric values to old metric values:
Update Refinery Rules
Refinery, as of version 2.3, can use multiple fields in a condition, which ensures that the same sampling decisions can be made on differently-shaped data.
While not a true coalescing since the data is not modified, this feature will help to manage tail sampling when the traces contain spans with both the old and new HTTP semantic conventions.
If you use Refinery, we highly recommend updating Refinery to the latest version and use this capability.
Fields is used here instead of Field.
This configuration ensures that the rule evaluates successfully, regardless of whether data uses http.status_code or http.response.status_code as an field.
Coalesce using Calculated Fields
If the OTel Collector is not an option, you can create Calculated Fields using the COALESCE function.
Use COALESCE to make a new field name that represents two values at once.
It works by taking the value of whichever field it sees first.
To avoid name conflicts in the future, we recommend to name these Calculated Fields with a dc. prefix.
Using the status_code in an SLI requires embedding the COALESCE function anywhere the status code is tested or returned, so it can get verbose.