[dashpole]

Description

This PR aligns the prometheusremotewritereceiver with the standard pull-based prometheusreceiver, ensuring that the job label is consistently mapped directly to service.name without splitting in both receivers. This prevents us from having to codify divergent receiver behaviors in the OpenTelemetry specification.

To ensure a safe migration path for existing users who rely on the legacy splitting behavior, this PR introduces an alpha feature gate receiver.prometheus_remote_write.disableJobSplit.

When this feature gate is enabled, the receiver preserves the job label as-is and maps the entire string directly to service.name, omitting service.namespace. Because it starts in the alpha stage, the gate is disabled by default, completely preserving the legacy splitting behavior. This provides a safe transition path to eventually deprecate the splitting logic.

Testing

• Added TestParseJobAndInstanceFeatureGate to verify that when the feature gate is enabled, the job string is preserved exactly as service.name.
• Confirmed that all existing module tests pass out-of-the-box with the feature gate disabled (the default behavior).

Documentation

Updated metadata.yaml to include the new feature gate description.

Authorship

• I, a human, wrote this pull request description myself.

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on reviewers · refreshed 2026-11-09 09:54 UTC

Review the latest changes.

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Anything look wrong? Report it with what you expected; it helps us improve the dashboard.

[himanshu130700]

LGTM

[singhvibhanshu]

Needs rebase.

[ArthurSens]

Isn't this doing the exact opposite of what is being described in open-telemetry/opentelemetry-specification#5356?

[dashpole]

Needs rebase.

Rebased onto main.

Isn't this doing the exact opposite of what is being described in open-telemetry/opentelemetry-specification#5356?

@ArthurSens In open-telemetry/opentelemetry-specification#5356 (comment) (and #52626 (comment)), @krajorama and I agreed to treat the job / split in prometheusremotewritereceiver as an implementation bug rather than codifying it in the spec, since a valid service.name can itself contain /. open-telemetry/opentelemetry-specification#5356 just hasn't been updated yet to reflect that discussion.

[ArthurSens]

Would it be ok to proceed with this PR only once we make the appropriate change in the spec? I'd love to avoid the possibility of us making a change here and eventually disagreeing on the spec change

[dashpole]

Would it be ok to proceed with this PR only once we make the appropriate change in the spec? I'd love to avoid the possibility of us making a change here and eventually disagreeing on the spec change

@ArthurSens Since the existing spec on main doesn't specify splitting job on / (that text was only drafted in open-telemetry/opentelemetry-specification#5356 to document current receiver behavior, and @krajorama agreed above to drop it), and this PR is gated behind a default-off alpha feature gate (receiver.prometheus_remote_write.disableJobSplit), landing it now wouldn't change default behavior or lock us in if the spec discussion changes. That said, I'm also fine holding off on merging until #5356 is updated if you prefer.

[krajorama]

LGTM