prometheus compatibility: clarify that the service triplet is require…

…d to be unique by semantic conventions

CHANGELOG.md

@@ -28,6 +28,8 @@ release.
 
 - Prometheus compatibility: Clarify naming of the target info metric, and differences between various Prometheus formats.
   ([#3871](https://github.com/open-telemetry/opentelemetry-specification/pull/3871))
+- Prometheus compatibility: Clarify that the service triplet is required to be unique by semantic conventions.
+  ([#3945](https://github.com/open-telemetry/opentelemetry-specification/pull/3945))
 
 ### SDK Configuration
 

specification/compatibility/prometheus_and_openmetrics.md

@@ -425,8 +425,9 @@ formats do not include a notion of resource, and expect metric labels to
 distinguish scraped targets. By convention, [`job` and `instance`](https://prometheus.io/docs/concepts/jobs_instances/#jobs-and-instances)
 labels distinguish targets and are expected to be present on metrics exposed on
 a Prometheus pull exporter (a ["federated"](https://prometheus.io/docs/prometheus/latest/federation/)
-Prometheus endpoint) or pushed via Prometheus remote-write. In OTLP, the
-`service.name`, `service.namespace`, and `service.instance.id` triplet is
+Prometheus endpoint) or pushed via Prometheus remote-write. In OpenTelemetry
+semantic conventions, the `service.name`, `service.namespace`, and
+`service.instance.id` triplet is
 [required to be unique](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/resource/README.md#service),
 which makes them good candidates to use to construct `job` and `instance`. In
 the collector Prometheus exporters, the `service.name` and `service.namespace`