Fixes #4368

content/en/docs/collector/deployment/gateway.md

@@ -212,6 +212,47 @@ Cons:
 - Added latency in case of cascaded collectors
 - Higher overall resource usage (costs)
 
+## Additional Considerations Deploying Multiple Collectors
+
+### The Single-Writer Principle
+
+The Single-Writer Principle is a design principle that ensures a single logical writer for a particular resource.
+Concurrent access from multiple applications that modify or report on the same data can lead to data
+loss or, at least, degraded data quality. In gateway collector deployments, applying this principle guards against sending
+inconsistent data to the backend.
+
+#### Context in OTLP
+
+All metric data streams within OTLP must have a [single writer](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#single-writer)
+This is because gateway collector deployments can involve multiple collectors in the same system.
+It is possible in this case for instances to receive and process data from the same resources,
+which is a violation of the Single-Writer principle. A potential consequence of this may be that
+these data streams overwrite each other, leading to inconsistent time series data.
+
+#### Example Scenario
+
+Consider the following configuration:
+
+There is a gateway deployment configured to handle all traffic for three other collectors in the same system.
+If the collectors are not uniquely identified and the SDK fails to distinguish between them, they may
+send identical data to the gateway collector from different points in time. In this scenario,
+it would be possible to observe inconsistent values for the same series.
+
+
+#### Detection
+
+There are patterns in the data that may provide some insight into whether this is happening or not.
+For example, upon visual inspection, a series with unexplained gaps or jumps in the same series may be a clue that
+multiple collectors are sending the same samples. Unexplained behavior in a time series could potentially
+point to the backend scraping data from multiple sources.
+
+
+#### Prevention
+
+All metric streams produced by OTel SDKs should have a globally unique [Metric Identity](https://opentelemetry.io/docs/specs/otel/metrics/data-model/#opentelemetry-protocol-data-model-producer-recommendations).
+This is to lower the risk of duplication, and ensure writers are sending unique data to the backend.
+
+
 [lb-exporter]:
   https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/loadbalancingexporter
 [tailsample-processor]:

content/en/docs/concepts/signals/traces.md

@@ -118,7 +118,7 @@ that matches the `span_id` of the `hello` span.
 ```
 
 This span represents the third operation in this trace and, like the previous
-one, it's a child of the `hello` span. That also makes it a sibling of the
+one, it's a child of the 'hello' Span. That also makes it a sibling of the
 `hello-greetings` span.
 
 These three blocks of JSON all share the same `trace_id`, and the `parent_id`

content/en/docs/languages/java/automatic/spring-boot.md

@@ -137,10 +137,10 @@ The OpenTelemetry starter uses OpenTelemetry Spring Boot
 
 ```xml
 <dependencies>
-  <dependency>
-    <groupId>io.opentelemetry.instrumentation</groupId>
-    <artifactId>opentelemetry-spring-boot-starter</artifactId>
-  </dependency>
+	<dependency>
+		<groupId>io.opentelemetry.instrumentation</groupId>
+		<artifactId>opentelemetry-spring-boot-starter</artifactId>
+	</dependency>
 </dependencies>
 ```
 
@@ -253,11 +253,11 @@ from tracing:
 
 ```xml
 <dependencies>
-  <dependency>
-    <groupId>io.opentelemetry.contrib</groupId>
-    <artifactId>opentelemetry-samplers</artifactId>
+	<dependency>
+		<groupId>io.opentelemetry.contrib</groupId>
+		<artifactId>opentelemetry-samplers</artifactId>
     <version>1.33.0-alpha</version>
-  </dependency>
+	</dependency>
 </dependencies>
 ```
 
@@ -450,26 +450,26 @@ appender in your `logback.xml` or `logback-spring.xml` file:
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
 <configuration>
-    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
-        <encoder>
-            <pattern>
-                %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
-            </pattern>
-        </encoder>
-    </appender>
-    <appender name="OpenTelemetry"
-        class="io.opentelemetry.instrumentation.logback.appender.v1_0.OpenTelemetryAppender">
-        <captureExperimentalAttributes>false</captureExperimentalAttributes>
-        <captureCodeAttributes>true</captureCodeAttributes>
-        <captureMarkerAttribute>true</captureMarkerAttribute>
-        <captureKeyValuePairAttributes>true</captureKeyValuePairAttributes>
-        <captureLoggerContext>true</captureLoggerContext>
-        <captureMdcAttributes>*</captureMdcAttributes>
-    </appender>
-    <root level="INFO">
-        <appender-ref ref="console"/>
-        <appender-ref ref="OpenTelemetry"/>
-    </root>
+	<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
+		<encoder>
+			<pattern>
+				%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
+			</pattern>
+		</encoder>
+	</appender>
+	<appender name="OpenTelemetry"
+		class="io.opentelemetry.instrumentation.logback.appender.v1_0.OpenTelemetryAppender">
+		<captureExperimentalAttributes>false</captureExperimentalAttributes>
+		<captureCodeAttributes>true</captureCodeAttributes>
+		<captureMarkerAttribute>true</captureMarkerAttribute>
+		<captureKeyValuePairAttributes>true</captureKeyValuePairAttributes>
+		<captureLoggerContext>true</captureLoggerContext>
+		<captureMdcAttributes>*</captureMdcAttributes>
+	</appender>
+	<root level="INFO">
+		<appender-ref ref="console"/>
+		<appender-ref ref="OpenTelemetry"/>
+	</root>
 </configuration>
 ```
 
@@ -593,10 +593,10 @@ With the datasource configuration, you need to add the following dependency:
 
 ```xml
 <dependencies>
-  <dependency>
-    <groupId>io.opentelemetry.instrumentation</groupId>
-    <artifactId>opentelemetry-jdbc</artifactId>
-  </dependency>
+	<dependency>
+		<groupId>io.opentelemetry.instrumentation</groupId>
+		<artifactId>opentelemetry-jdbc</artifactId>
+	</dependency>
 </dependencies>
 ```
 
@@ -617,14 +617,14 @@ You have to add the OpenTelemetry appender to your `log4j2.xml` file:
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
 <Configuration status="WARN" packages="io.opentelemetry.instrumentation.log4j.appender.v2_17">
-    <Appenders>
-        <OpenTelemetry name="OpenTelemetryAppender"/>
-    </Appenders>
-    <Loggers>
-        <Root>
-            <AppenderRef ref="OpenTelemetryAppender" level="All"/>
-        </Root>
-    </Loggers>
+	<Appenders>
+		<OpenTelemetry name="OpenTelemetryAppender"/>
+	</Appenders>
+	<Loggers>
+		<Root>
+			<AppenderRef ref="OpenTelemetryAppender" level="All"/>
+		</Root>
+	</Loggers>
 </Configuration>
 ```
 

data/registry/collector-exporter-azure-monitor.yml

@@ -9,7 +9,7 @@ tags:
 license: Apache 2.0
 description: The Azure Monitor Exporter for the OpenTelemetry Collector.
 authors:
-  - name: OpenTelemetry Authors
+  - name: Microsoft
 urls:
   repo: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/azuremonitorexporter
 createdAt: 2020-06-06

data/registry/exporter-js-instana.yml

@@ -15,4 +15,4 @@ createdAt: 2022-04-18
 package:
   registry: npm
   name: '@instana/opentelemetry-exporter'
-  version: 3.7.0
+  version: 3.6.0

data/registry/instrumentation-php-slim.yml

@@ -15,4 +15,4 @@ createdAt: 2022-12-14
 package:
   registry: packagist
   name: open-telemetry/opentelemetry-auto-slim
-  version: 1.0.5
+  version: 1.0.4

static/refcache.json

@@ -2951,10 +2951,6 @@
     "StatusCode": 200,
     "LastSeen": "2024-03-19T10:16:37.692028682Z"
   },
-  "https://github.com/open-telemetry/community/issues/1971": {
-    "StatusCode": 200,
-    "LastSeen": "2024-05-03T07:21:04.501478-07:00"
-  },
   "https://github.com/open-telemetry/community/issues/828": {
     "StatusCode": 200,
     "LastSeen": "2024-01-18T19:37:16.771654-05:00"
@@ -3127,10 +3123,6 @@
     "StatusCode": 200,
     "LastSeen": "2024-04-04T11:07:15.276911438-07:00"
   },
-  "https://github.com/open-telemetry/opentelemetry-collector/issues/9375": {
-    "StatusCode": 200,
-    "LastSeen": "2024-05-03T08:34:29.3339-07:00"
-  },
   "https://github.com/open-telemetry/opentelemetry-collector/pull/6140": {
     "StatusCode": 200,
     "LastSeen": "2024-01-30T05:18:24.402543-05:00"
@@ -4183,10 +4175,6 @@
     "StatusCode": 200,
     "LastSeen": "2024-01-30T05:18:13.065627-05:00"
   },
-  "https://github.com/orgs/open-telemetry/projects/83": {
-    "StatusCode": 200,
-    "LastSeen": "2024-05-03T07:21:05.157831-07:00"
-  },
   "https://github.com/orgs/open-telemetry/teams/technical-committee": {
     "StatusCode": 200,
     "LastSeen": "2024-01-30T16:15:03.796394-05:00"
@@ -5819,14 +5807,6 @@
     "StatusCode": 206,
     "LastSeen": "2024-03-19T10:16:59.755536357Z"
   },
-  "https://opentelemetry.io/blog/2024/otel-collector-anti-patterns/": {
-    "StatusCode": 206,
-    "LastSeen": "2024-05-06T07:53:28.679391-07:00"
-  },
-  "https://opentelemetry.io/blog/2024/scaling-collectors/": {
-    "StatusCode": 206,
-    "LastSeen": "2024-05-06T07:53:28.903161-07:00"
-  },
   "https://opentelemetry.io/docs/collector": {
     "StatusCode": 206,
     "LastSeen": "2024-02-23T22:55:03.656226-05:00"