Mapping service and migration impact report 🔗
The mapping service lets you migrate from Smart Agent to OpenTelemetry deployments without significantly disrupting the form or content of your existing dashboards, charts, and detectors. It automatically translates collectd (Smart Agent) conventions into the syntax used by the Collector as a background operation.
Mapping supports multiple observers, deployment types, and kinds of metadata.
How does the mapping service work? 🔗
The mapping service is a transition tool that defines equivalencies between legacy SignalFx Smart Agent metric naming and semantic conventions and the OpenTelemetry names and formats:
It applies to metrics and metric time series (MTS), dimensions, and properties.
Mapping logic treats any of the names for a metric or property as referring to that same metric or property in OpenTelemetry, without tracking versions.
For example, if you track CPU utilization for your Kubernetes pod, your
analytics can use the kubernetes.container_cpu_limit value. In that
case, the mapping service updates your existing queries to include both
legacy semantics and new semantics (such as k8s.container.cpu_limit)
joined by an OR clause.
Obtain the migration impact report 🔗
The OpenTelemetry Migration Impact Report explains how the transition from Smart Agent to OpenTelemetry affects some of the variables and saved filters in the following dashboards, charts, and detectors.
The migration impact report also tells you where to find whatever subset of your content calls functions with Smart Agent names, so that you can update that content either by hand or programmatically to complete your transition to open telemetry.
Access the migration impact report 🔗
To access the migration impact report, follow these steps:
Log in to Splunk Observability Cloud.
In the navigation menu, select Settings and then select Subscription Usage.
Select the Usage Reports link on the Infrastructure Monitoring tab.
Navigate to View detailed usage reports.
Select the OpenTelemetry Migration tab.
Select Download to open the report as a comma-separated values file.
What is flagged for update in translation 🔗
The report is specific to your computing environment. It flags the following items and tells you where to find and update them in your collection of plots, filters, and functions:
Wildcards
Direct references to Smart Agent metrics
Filters that use Smart Agent dimensions
Aggregates that use Smart Agent dimensions
The migration impact report also shows which OpenTelemetry metrics and dimensions work well as replacements for specific Smart Agent metrics and dimensions, with the important exception of wildcards not supported by OpenTelemetry.
Interpret the migration impact report 🔗
The OpenTelemetry Migration Impact Report summarizes the scope of component name change associated with your migration to open telemetry. It assesses your dataset to list the tokens currently used as metric, dimension, property or tag names, and highlights migration rules that can generate conflict between old and new equivalence groups.
The report explains when migration from an old MTS to a new MTS will trigger detectors, and which detectors those are. For example, heartbeat detectors working with un-aggregated MTS are affected by design, but if a heartbeat detector is working with a dimension that continues across the transition to OTel, then the mapping service ensures continuity so that you do not have to restart that detector.
The migration impact report assesses migration effects across three categories:
Data object types
Team responsibilities
Migration mitigation steps you should take
Avoid unexpected results 🔗
Because the mapping service only renames existing MTS when filtering or grouping requires renaming to conform to OpenTelemetry Collector conventions, correlation across different datasets yields unexpected results when a mapped MTS is correlated with an unmapped MTS. This can happen, for example, when an MTS attempts to correlate with a time-shifted or transformed version of itself.
If you have charts and detectors built from formulas whose terms use different agents, you won’t get the alerts you expect.
To resolve this issue, explicitly filter or group by dimensions so that Mapping Service renames the fields in all the MTS in the job to match the name you specified in the filter or grouping.
Data object type information 🔗
The migration impact report explains migration impacts within your organization to the following object types:
Dashboards
Charts
Detectors
The report shows how many objects of each type are affected, and includes tables that show where to find the affected objects. You can read the report to see, for example, a list of all affected charts on a given dashboard or within a dashboard group.
Team information 🔗
The migration impact report extracts information from your dataset about stakeholders, meaning the people who created object types or are affected by changes to them because they’re on email lists of employees to be notified in the event of, for example, a detector being triggered by a critical alert condition.
When applicable, the report shows the names of teams linked to particular detectors. The report also identifies people or teams linked to particular dashboard groups.
Migration mitigation steps 🔗
The migration impact report explains what effect migration will have on the content highlighted in it, so that you can modify that content as needed to ensure a smoother transition.
Flagged items that need to be modified include the following (as listed in the report):
Wildcards used in a plot, filter, or function.
Direct references to Smart Agent metrics.
Filters that use Smart Agent dimensions.
Aggregates that use Smart Agent dimensions.
While the migration impact report highlights items that need revising because they use legacy syntax or conventions, it also pairs those items with the OTel-based metrics and dimensions that you can use as substitutes for them.
Conflicting semantics 🔗
If you emit 2 or more metrics which could be mapped to one another, the system won’t be able to distinguish them and it might cause various side-effects such as duplicated alerts or inconsistent dimensions in results.
This can happen:
If you have both the Smart Agent and OpenTelemetry Collector running on the same host.
If you included 2 equivalent dimensions on the same metric, like
hostandhost.name. Because of the mapping you are expected to only provide the OpenTelemetry semantics or the legacy semantics during the transition.
Semantics collission on ingested data apply only per MTS. This means you
can send OpenTelemetry metrics from host A, and legacy metrics from host
B. You also can send the metrics container_fs_usage_bytes and
k8s.container.name from the same host, since these will be different
MTSs.
The same rule applies to querying in charts and detectors, where you are
expected to only query by the OpenTelemetry semantics or by legacy
semantics within the same data() invocation, regardless of the
metrics you’re querying are aligned with legacy or OpenTelemetry
semantics. In this situation Splunk Observability Cloud might produce
duplicated MTSs from non-duplicated ingested data. For example, this
might happen if you write a query such as
data("container.image.name", filter=(filter("host", "<host-id>") OR filter("host.name", "<host-id>"))).
OpenTelemetry values and their legacy equivalents 🔗
See the following table for OpenTelemetry values and their legacy equivalents:
Legacy semantics |
OpenTelemetry semantics |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You can find a table outlining OpenTelemetry values and their legacy equivalents in GitHub at Legacy to OTel semantics mapping table.