Mapping service and mapping 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. The Mapping Service creates equivalencies between your Smart Agent and OTel metric names.
Obtain the transition mapping report π
If you decide as a Splunk admin to turn off the mapping service, you can still generate and download a Mapping and OTel Transition Impact Report specific to migration for your cloud computing environment.
The mapping 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 mapping 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.
To access the migration transition impact report, follow these steps:
Log in to Splunk Observability Cloud.
In the left navigation menu, select Settings > Billing and Usage.
Click the View detailed usage reports link.
Select the OpenTelemetry Migration tab.
Click 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 mapping 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.
You can view and save the mapping impact report even if you opt out of mapping.
Interpret the mapping impact report π
The Mapping and OTel Transition Impact Report summarizes the scope of component name change associated with your migration to open telemetry. It assesses your data set to list the tokens currently used as metric, dimension, property or tag names, and highlights migration rules that could 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 mapping transition impact report assesses migration effects across three categories:
Data object types
Team responsibilities
Migration mitigation steps you should take
Avoiding unexpected results π
Because 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 mapping 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 mapping impact report extracts information from your data set 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 mapping 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 mapping 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.
OpenTelemetry values and their legacy equivalents π
Refer to 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.