Merge branch 'main' into update-community-members

open-telemetry · Jan 23, 2025 · a1ae55a · a1ae55a
2 parents ce1a34a + f16349f
commit a1ae55a
Show file tree

Hide file tree

Showing 26 changed files with 146 additions and 63 deletions.
diff --git a/.textlintrc.yml b/.textlintrc.yml
@@ -159,6 +159,8 @@ rules:
       - ['screen[- ]shot(s)?', screenshot$1]
       - ['time[- ]stamp(s)?', timestamp$1]
       - ["uid['’]?(s)?", UID$1]
+      - ['(walk)-(throughs?)', $1$2] # cSpell:disable-line
+      - ['(work)-(arounds?)', $1$2]
       # Enable the following to find and replace "instrumentation module/package" with "instrumentation library":
       # - ["(auto(matic)?[- ])?instrumentation (module|package)", "instrumentation library"]
       # - ["(auto(matic)?[- ])?instrumentation (modules|packages)", "instrumentation libraries"]
diff --git a/content/en/blog/2023/end-user-discussions-01.md b/content/en/blog/2023/end-user-discussions-01.md
@@ -196,7 +196,7 @@ Please also check out
 **A:** Implementing correlation takes time and is a work in progress.
 Correlation work is more mature for some languages (e.g. Java, Go) than for
 others. The best approach is to raise this issue in one of the language-specific
-repositories that pertains to your situation. A possible work-around is to start
+repositories that pertains to your situation. A possible workaround is to start
 traces at the log level, whereby every log will have its own associated trace.
 
 #### 3- Profiling

diff --git a/content/en/blog/2024/otel-operator-q-and-a/index.md b/content/en/blog/2024/otel-operator-q-and-a/index.md
@@ -116,7 +116,7 @@ env:
 ```yaml
 exporters:
   otlp:
-    endpoint: '<your_backend_ndpoint_here>'
+    endpoint: '<your_backend_endpoint_here>'
     headers:
       '<token_name>': '${TOKEN_VALUE}'
 ```
@@ -130,8 +130,8 @@ along with the
 
 For every Collector release, there is an Operator release which provides support
 for that Collector version. For example, at the time of this writing, the latest
-Operator version is 0.98.0. Thus, the the default image of the Collector used by
-the Operator is version 0.98.0 of the
+Operator version is 0.98.0. Thus, the default image of the Collector used by the
+Operator is version 0.98.0 of the
 [core distribution](/blog/2024/otel-collector-anti-patterns/#3--not-using-the-right-collector-distribution-or-not-building-your-own-distribution)
 (as opposed to the contrib distribution).
 

diff --git a/content/en/blog/2024/prom-and-otel/index.md b/content/en/blog/2024/prom-and-otel/index.md
@@ -220,7 +220,7 @@ Let’s dig into each of these.
 The Target Allocator’s first job is to discover targets to scrape and OTel
 Collectors to allocate targets to. It does so as follows:
 
-1. The Target Allocator finds all of the the metrics targets to scrape
+1. The Target Allocator finds all of the metrics targets to scrape
 2. The Target Allocator finds all of the available Collectors
 3. The Target Allocator determines which Collectors scrape which metrics
 4. The Collectors query the Target Allocator to find out what metrics to scrape

diff --git a/content/en/blog/2025/go-goals.md b/content/en/blog/2025/go-goals.md
@@ -6,7 +6,7 @@ author: >-
   [Tyler Yahn](https://github.com/MrAlias) (Splunk)
 sig: SIG Go
 # prettier-ignore
-cSpell:ignore: Yahn dashpole pellared otelhttp dmathieu otelhttp codeboten otellogr otellogrus otelslog otelzap otelzerolog
+cSpell:ignore: codeboten dashpole dmathieu otelhttp otellogr otellogrus otelslog otelzap otelzerolog pellared Yahn
 ---
 
 As we kick off 2025, the

diff --git a/content/en/docs/collector/building/connector/index.md b/content/en/docs/collector/building/connector/index.md
@@ -43,9 +43,9 @@ data, it is necessary to convert the trace data from the processor in the traces
 pipeline and send it to the metrics pipeline. Historically, some processors
 transmitted data by making use of a workaround that follows a bad practice where
 a processor directly exports data after processing. The connector component
-solves the need for this work-around and the processors that used the work
-around have been deprecated. On the same line, above mentioned processors are
-also now deprecated in recent releases and are replaced by the connectors.
+solves the need for this workaround and the processors that used the workaround
+have been deprecated. On the same line, above mentioned processors are also now
+deprecated in recent releases and are replaced by the connectors.
 
 Additional details about the connector's full capabilities can be found at the
 following links:

diff --git a/content/en/docs/concepts/components.md b/content/en/docs/concepts/components.md
@@ -133,7 +133,7 @@ For more information, see [K8s Operator](/docs/kubernetes/operator/).
 OpenTelemetry supports various methods of monitoring Function-as-a-Service
 provided by different cloud vendors. The OpenTelemetry community currently
 provides pre-built Lambda layers able to auto-instrument your application as
-well as a the option of standalone Collector Lambda layer that can be used when
+well as the option of a standalone Collector Lambda layer that can be used when
 instrumenting applications manually or automatically.
 
 For more information, see [Functions as a Service](/docs/faas/).
diff --git a/content/en/docs/demo/collector-data-flow-dashboard/index.md b/content/en/docs/demo/collector-data-flow-dashboard/index.md
@@ -110,4 +110,4 @@ example, you might observe more than one instance of otelcol running on the
 system during restarts or similar. This can be useful for understanding spikes
 on dataflow.
 
-![OpenTelemetry Collector Process Metrics](otelcol-dashbord-process-metrics.png)
+![OpenTelemetry Collector Process Metrics](otelcol-dashboard-process-metrics.png)
diff --git a/...oard/otelcol-dashbord-process-metrics.png → ...ard/otelcol-dashboard-process-metrics.png b/...oard/otelcol-dashbord-process-metrics.png → ...ard/otelcol-dashboard-process-metrics.png
diff --git a/.../docs/demo/screenshots/gragana-jaeger.png → .../docs/demo/screenshots/grafana-jaeger.png b/.../docs/demo/screenshots/gragana-jaeger.png → .../docs/demo/screenshots/grafana-jaeger.png
diff --git a/content/en/docs/demo/screenshots/index.md b/content/en/docs/demo/screenshots/index.md
@@ -28,7 +28,7 @@ aliases: [demo_screenshots]
 
 | Prometheus Data Source                        | Jaeger Data Source                    |
 | --------------------------------------------- | ------------------------------------- |
-| ![Grafana-Prometheus](grafana-prometheus.png) | ![Grafana-jaeger](gragana-jaeger.png) |
+| ![Grafana-Prometheus](grafana-prometheus.png) | ![Grafana-jaeger](grafana-jaeger.png) |
 
 ## Load Generator UI
 

diff --git a/content/en/docs/faas/_index.md b/content/en/docs/faas/_index.md
@@ -19,7 +19,7 @@ also known as Lambda.
 ### Community Assets
 
 The OpenTelemetry community currently provides pre-built Lambda layers able to
-auto-instrument your application as well as a the option of standalone Collector
+auto-instrument your application as well as the option of a standalone Collector
 Lambda layer that can be used when instrumenting applications manually or
 automatically.
 

diff --git a/content/en/docs/languages/java/api.md b/content/en/docs/languages/java/api.md
@@ -979,7 +979,7 @@ public class CounterUsage {
 
 #### Async Counter
 
-[ObservableLongCounter](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-api/latest/io/opentelemetry/api/metrics/ObservableLongCounter.htmll)
+[ObservableLongCounter](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-api/latest/io/opentelemetry/api/metrics/ObservableLongCounter.html)
 and
 [ObservableDoubleCounter](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-api/latest/io/opentelemetry/api/metrics/ObservableDoubleCounter.html)
 are used to observe monotonic (positive) sums.

diff --git a/content/en/docs/languages/js/exporters.md b/content/en/docs/languages/js/exporters.md
@@ -51,7 +51,7 @@ JavaScript) from the
 [Getting Started](/docs/languages/js/getting-started/nodejs/) like the following
 to export traces and metrics via OTLP (`http/protobuf`) :
 
-{{< tabpane text=true >}} {{% tab Typescript %}}
+{{< tabpane text=true >}} {{% tab TypeScript %}}
 
 ```ts
 /*instrumentation.ts*/
@@ -256,7 +256,7 @@ npm install --save @opentelemetry/exporter-prometheus
 Update your OpenTelemetry configuration to use the exporter and to send data to
 your Prometheus backend:
 
-{{< tabpane text=true >}} {{% tab Typescript %}}
+{{< tabpane text=true >}} {{% tab TypeScript %}}
 
 ```ts
 import * as opentelemetry from '@opentelemetry/sdk-node';
@@ -314,7 +314,7 @@ npm install --save @opentelemetry/exporter-zipkin
 Update your OpenTelemetry configuration to use the exporter and to send data to
 your Zipkin backend:
 
-{{< tabpane text=true >}} {{% tab Typescript %}}
+{{< tabpane text=true >}} {{% tab TypeScript %}}
 
 ```ts
 import * as opentelemetry from '@opentelemetry/sdk-node';
@@ -347,7 +347,7 @@ const sdk = new opentelemetry.NodeSDK({
 
 {{% docs/languages/exporters/outro js "https://open-telemetry.github.io/opentelemetry-js/interfaces/_opentelemetry_sdk_trace_base.SpanExporter.html" %}}
 
-{{< tabpane text=true >}} {{% tab Typescript %}}
+{{< tabpane text=true >}} {{% tab TypeScript %}}
 
 ```ts
 /*instrumentation.ts*/

diff --git a/content/en/docs/languages/js/getting-started/browser.md b/content/en/docs/languages/js/getting-started/browser.md
@@ -36,8 +36,8 @@ Copy the following file into an empty directory and call it `index.html`.
     <!--
       https://www.w3.org/TR/trace-context/
       Set the `traceparent` in the server's HTML template code. It should be
-      dynamically generated server side to have the server's request trace Id,
-      a parent span Id that was set on the server's request span, and the trace
+      dynamically generated server side to have the server's request trace ID,
+      a parent span ID that was set on the server's request span, and the trace
       flags to indicate the server's sampling decision
       (01 = sampled, 00 = not sampled).
       '{version}-{traceId}-{spanId}-{sampleDecision}'

diff --git a/content/en/docs/languages/php/context.md b/content/en/docs/languages/php/context.md
@@ -25,7 +25,7 @@ like asynchronous or concurrent execution with `fibers`.
 
 ## Context keys
 
-Values as stored in context as key-value pairs. Context keys are used to store
+Values are stored in context as key-value pairs. Context keys are used to store
 and retrieve values from context.
 
 Keys can be created by calling `OpenTelemetry\Context\Context::createKey()`, for

diff --git a/content/en/docs/languages/php/instrumentation.md b/content/en/docs/languages/php/instrumentation.md
@@ -262,7 +262,7 @@ encouraged, attribute `service.version`, which holds the version of the service
 API or implementation.
 
 Alternative methods exist for setting up resource attributes. For more
-information, see [Resources](/docs/languages/js/resources/).
+information, see [Resources](/docs/languages/php/resources/).
 
 #### Global Providers
 

diff --git a/content/en/docs/languages/php/sdk.md b/content/en/docs/languages/php/sdk.md
@@ -98,14 +98,6 @@ $meter = OpenTelemetry\API\Globals::meterProvider()->getMeter('name', 'version',
 
 SDK autoloading happens as part of the composer autoloader.
 
-### Configuration from php.ini
-
-When providing configuration through `php.ini`, be sure to protect boolean
-values by double-quoting them, eg `"true"`, `"false"` so that PHP doesn't
-convert them to numbers.
-
-`php.ini`:
-
 ### Excluded URLs
 
 You can disable SDK autoloading if the request URL matches a regular expression.

diff --git a/content/en/docs/zero-code/php.md b/content/en/docs/zero-code/php.md
@@ -164,7 +164,7 @@ Append the following to `php.ini`, or another `ini` file that will be processed
 by PHP:
 
 ```ini
-OTEL_PHP_AUTOLOAD_ENABLED=true
+OTEL_PHP_AUTOLOAD_ENABLED="true"
 OTEL_SERVICE_NAME=your-service-name
 OTEL_TRACES_EXPORTER=otlp
 OTEL_EXPORTER_OTLP_PROTOCOL=grpc
@@ -208,7 +208,7 @@ trace the execution of that code.
 ```php
 <?php
 
-use OpenTelemetry\API\Common\Instrumentation\CachedInstrumentation;
+use OpenTelemetry\API\Instrumentation\CachedInstrumentation;
 use OpenTelemetry\API\Trace\Span;
 use OpenTelemetry\API\Trace\StatusCode;
 use OpenTelemetry\Context\Context;

diff --git a/content/fr/docs/concepts/context-propagation.md b/content/fr/docs/concepts/context-propagation.md
@@ -0,0 +1,50 @@
+---
+title: Propagation du contexte
+weight: 10
+description: Présentation du concept permettant le traçage distribué.
+default_lang_commit: 71833a5f8b84110dadf1e98604b87a900724ac33
+---
+
+La propagation du contexte permet de mettre en corrélation les
+[signaux](../signals), quelle que soit leur origine. Bien qu'elle ne soit pas
+limitée au traçage, la propagation du contexte permet aux
+[traces](../signals/traces) de créer des informations de causalité sur un
+système, même lorsque les services sont distribués de façon arbitraire à travers
+des limites de processus et de réseau.
+
+Pour comprendre la propagation du contexte, vous devez maîtriser deux concepts
+distincts : le contexte et la propagation.
+
+## Contexte {#context}
+
+Le contexte est un objet contenant les informations nécessaires pour que le
+service émetteur et le service récepteur, ou
+[unité d'exécution](/docs/specs/otel/glossary/#execution-unit), puissent mettre
+en corrélation un signal avec un autre.
+
+Prenons l'exemple d'un service A qui appelle un service B. Un span du service A,
+dont l'ID est inclus dans le contexte, sera utilisé comme span parent pour le
+prochain span créé par le service B. De plus, l'ID de trace inclus dans le
+contexte sera également utilisé pour le prochain span créé dans le service B, ce
+qui signifie que ce span fera partie de la même trace que le span du service A.
+
+## Propagation {#propagation}
+
+La propagation est le mécanisme permettant de transmettre le contexte entre
+services et processus. Elle sérialise et désérialise le contexte et fournit les
+informations nécessaires d'un service à l'autre.
+
+La propagation étant généralement gérée automatiquement par les librairies
+d'instrumentation, le mécanisme est transparent pour l'utilisateur. Si pour une
+raison ou une autre, vous souhaitez propager le contexte manuellement, vous
+pouvez utiliser
+l'[API des propagateurs](/docs/specs/otel/context/api-propagators/).
+
+Plusieurs propagateurs officiels sont maintenus par OpenTelemetry. Le
+propagateur par défaut utilise les en-têtes définies par la spécification
+[W3C TraceContext](https://www.w3.org/TR/trace-context/).
+
+## Spécification {#specification}
+
+Pour plus d'informations, consultez la page
+[Spécification du contexte](/docs/specs/otel/context/).
diff --git a/data/registry/exporter-dotnet-inmemory.yml b/data/registry/exporter-dotnet-inmemory.yml
@@ -17,4 +17,4 @@ createdAt: 2022-11-07
 package:
   registry: nuget
   name: OpenTelemetry.Exporter.InMemory
-  version: 1.11.0
+  version: 1.11.1
diff --git a/data/registry/instrumentation-go-cloudwego.yml b/data/registry/instrumentation-go-cloudwego.yml
@@ -22,4 +22,4 @@ isFirstParty: true
 package:
   registry: go
   name: github.com/hertz-contrib/obs-opentelemetry
-  version: v0.3.0
+  version: v0.3.1