receiver/prometheus: Populate scope attributes from labels instead of otel_scope_info

.chloggen/prometheusreceiver_scope_attributes_spec_compliance.yaml

@@ -0,0 +1,36 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: enhancement
+
+# The name of the component, or a single word describing the area of concern, (e.g. filelogreceiver)
+component: prometheusreceiver
+
+# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: "Implement scope attributes extraction from `otel_scope_` prefixed labels to comply with updated OpenTelemetry specification"
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+issues: [40060]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext: |
+  The OpenTelemetry Prometheus specification has been updated to deprecate the `otel_scope_info` metric 
+  in favor of embedding scope attributes directly in metrics using `otel_scope_` prefixed labels.
+  This implementation always extracts scope attributes from `otel_scope_` prefixed labels on all metrics
+  and always filters these labels from datapoint attributes, regardless of the feature gate setting.
+  The feature gate `receiver.prometheusreceiver.RemoveScopeInfo` only controls `otel_scope_info` processing:
+  - When disabled: `otel_scope_info` metrics are processed for scope attributes and merged with `otel_scope_` labels.
+  - When enabled: `otel_scope_info` metrics are treated as regular metrics.
+  This change maintains backward compatibility while enabling compliance with the updated specification.
+  See: https://github.com/open-telemetry/opentelemetry-specification/pull/4505
+
+# If your change doesn't affect end users or the exported elements of any package,
+# you should instead start your pull request title with [chore] or use the "Skip Changelog" label.
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [user]

receiver/prometheusreceiver/README.md

@@ -153,10 +153,16 @@ This receiver accepts exemplars coming in Prometheus format and converts it to O
 This receiver drops the `target_info` prometheus metric, if present, and uses attributes on
 that metric to populate the OpenTelemetry Resource.
 
-It drops `otel_scope_name` and `otel_scope_version` labels, if present, from metrics, and uses them to populate
-the OpenTelemetry Instrumentation Scope name and version. It drops the `otel_scope_info` metric,
-and uses attributes (other than `otel_scope_name` and `otel_scope_version`) to populate Scope
-Attributes.
+It always extracts scope attributes from `otel_scope_` prefixed labels on metrics. Labels with the 
+`otel_scope_name`, `otel_scope_version`, and `otel_scope_schema_url` prefixes are used to populate the 
+OpenTelemetry Instrumentation Scope identity, while other `otel_scope_` prefixed labels become Scope Attributes.
+All `otel_scope_` labels are filtered from the metric datapoint attributes.
+
+The processing of `otel_scope_info` metrics is controlled by the `receiver.prometheusreceiver.RemoveScopeInfo` 
+feature gate:
+- When disabled: `otel_scope_info` metrics are processed for scope attributes and merged with 
+  any `otel_scope_` labels, with `otel_scope_` labels taking precedence in conflicts.
+- When enabled: `otel_scope_info` metrics are treated as regular metrics and not processed for scope attributes.
 
 ## Prometheus API Server
 The Prometheus API server can be enabled to host info about the Prometheus targets, config, service discovery, and metrics. The `server_config` can be specified using the OpenTelemetry confighttp package. An example configuration would be:

receiver/prometheusreceiver/internal/metricfamily.go

@@ -360,6 +360,11 @@ func populateAttributes(mType pmetric.MetricType, ls labels.Labels, dest pcommon
 		if j < len(names) && l.Name == names[j] {
 			return
 		}
+
+		if strings.HasPrefix(l.Name, "otel_scope_") {
+			return
+		}
+
 		if l.Value == "" {
 			// empty label values should be omitted
 			return

receiver/prometheusreceiver/internal/metricfamily_test.go

@@ -5,6 +5,7 @@ package internal
 
 import (
 	"math"
+	"strings"
 	"testing"
 	"time"
 
@@ -17,6 +18,8 @@ import (
 	"go.opentelemetry.io/collector/pdata/pcommon"
 	"go.opentelemetry.io/collector/pdata/pmetric"
 	"go.uber.org/zap"
+
+	"github.com/open-telemetry/opentelemetry-collector-contrib/internal/common/testutil"
 )
 
 type testMetadataStore map[string]scrape.MetricMetadata
@@ -773,6 +776,77 @@ func TestMetricGroupData_toSummaryUnitTest(t *testing.T) {
 	}
 }
 
+// TestPopulateAttributes_ScopeLabelFiltering tests the target behavior where otel_scope_
+// prefixed labels should always be filtered from datapoint attributes regardless of feature gate.
+func TestPopulateAttributes_ScopeLabelFiltering(t *testing.T) {
+	tests := []struct {
+		name           string
+		labels         labels.Labels
+		featureEnabled bool
+		wantAttrs      map[string]string
+	}{
+		{
+			name: "feature_gate_disabled",
+			labels: labels.FromStrings(
+				"__name__", "test_metric",
+				"job", "test-job",
+				"instance", "localhost:8080",
+				"method", "GET",
+				"otel_scope_name", "my-scope",
+				"otel_scope_version", "1.0.0",
+				"otel_scope_animal", "bear",
+			),
+			featureEnabled: false,
+			wantAttrs: map[string]string{
+				"method": "GET",
+				// otel_scope_* labels should always be filtered out regardless of feature gate
+			},
+		},
+		{
+			name: "feature_gate_enabled",
+			labels: labels.FromStrings(
+				"__name__", "test_metric",
+				"job", "test-job",
+				"instance", "localhost:8080",
+				"method", "GET",
+				"otel_scope_name", "my-scope",
+				"otel_scope_version", "1.0.0",
+				"otel_scope_animal", "bear",
+			),
+			featureEnabled: true,
+			wantAttrs: map[string]string{
+				"method": "GET",
+				// otel_scope_* labels should always be filtered out regardless of feature gate
+			},
+		},
+	}
+
+	for _, tt := range tests {
+		t.Run(tt.name, func(t *testing.T) {
+			defer testutil.SetFeatureGateForTest(t, RemoveScopeInfoGate, tt.featureEnabled)()
+
+			attrs := pcommon.NewMap()
+			populateAttributes(pmetric.MetricTypeGauge, tt.labels, attrs)
+
+			// Verify expected attributes
+			require.Equal(t, len(tt.wantAttrs), attrs.Len(), "Unexpected number of attributes")
+
+			for key, expectedValue := range tt.wantAttrs {
+				actualValue, exists := attrs.Get(key)
+				require.True(t, exists, "Expected attribute %s not found", key)
+				require.Equal(t, expectedValue, actualValue.AsString(), "Unexpected value for attribute %s", key)
+			}
+
+			// Verify no otel_scope_ attributes are present regardless of feature gate
+			attrs.Range(func(k string, _ pcommon.Value) bool {
+				require.False(t, strings.HasPrefix(k, "otel_scope_"),
+					"Found otel_scope_ prefixed attribute %s in datapoint attributes - these should always be filtered", k)
+				return true
+			})
+		})
+	}
+}
+
 func TestMetricGroupData_toNumberDataUnitTest(t *testing.T) {
 	type scrape struct {
 		at     int64