Merge branch 'main' into feature/issue-6003-create-context-propagatio…

…n.md

.github/workflows/build-semconv-daily.yml

@@ -20,3 +20,6 @@ jobs:
     with:
       success: ${{ needs.build-dev.result == 'success' }}
       repo: open-telemetry/semantic-conventions
+    secrets:
+      opentelemetrybot_github_token:
+        ${{ secrets.OPENTELEMETRYBOT_GITHUB_TOKEN }}

.github/workflows/reusable-workflow-notification.yml

@@ -11,6 +11,9 @@ on:
       repo:
         type: string
         required: false
+    secrets:
+      opentelemetrybot_github_token:
+        required: false
 
 jobs:
   workflow-notification:
@@ -20,10 +23,9 @@ jobs:
 
       - name: Open issue or add comment if issue already open
         env:
-          # need to use opentelemetrybot for opening issues in other repos
+          # need to use opentelemetrybot token when opening issues in other repos
           GH_TOKEN:
-            ${{ inputs.repo && secrets.OPENTELEMETRYBOT_GITHUB_TOKEN ||
-            secrets.GITHUB_TOKEN }}
+            ${{ secrets.opentelemetrybot_github_token || secrets.GITHUB_TOKEN }}
         run: |
           if [ -z "${{ inputs.repo }}" ]; then
             repo="$GITHUB_REPOSITORY"

.github/workflows/scripts/check-i18n-helper.sh

@@ -5,7 +5,7 @@ echo "For localization docs, see https://opentelemetry.io/docs/contributing/loca
 CHANGES=`git status --porcelain`
 
 if [[ -z $CHANGES ]]; then
-  echo "All localization pages have the requisit commit hash. <3"
+  echo "All localization pages have the requisite commit hash. <3"
   exit;
 fi
 

.github/workflows/survey-on-merged-pr.yml

@@ -35,6 +35,6 @@ jobs:
       - name: Add comment to PR if author is not a member
         if: env.MEMBER_FOUND == 'false'
         run: |
-          gh pr comment ${PR_NUM} --body "Thank you for your contribution! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out out this survey: ${SURVEY_URL}"
+          gh pr comment ${PR_NUM} --body "Thank you for your contribution! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey: ${SURVEY_URL}"
         env:
           GH_TOKEN: ${{ secrets.OPENTELEMETRYBOT_GITHUB_TOKEN }}

archetypes/blog.md

@@ -30,7 +30,7 @@ markdown formatter (see below).
 
 ## Images
 
-If you use images, make sure that your blog post is located in it's own
+If you use images, make sure that your blog post is located in its own
 directory. Put the images into the same directory.
 
 If you have an image stored at `content/en/{{ .File.Dir }}imagename.png`, you

content/en/blog/2022/announcing-opentelemetry-demo-release/index.md

@@ -14,7 +14,7 @@ announce
 With this demo, you’ll be able to quickly run a complete end-to-end distributed
 system instrumented with 100% OpenTelemetry Traces and Metrics.
 
-![The system architecture of the demo application represented as directed acyclic graph in Jaeger UI](sytem-architecture.png)
+![The system architecture of the demo application represented as directed acyclic graph in Jaeger UI](system-architecture.png)
 
 One of our primary goals of this project has been to create a robust sample
 application for developers to use in learning OpenTelemetry, and we’re proud to
@@ -37,7 +37,7 @@ Now, it’d be enough to just provide a great demonstration of OpenTelemetry, bu
 one thing we wanted to focus on for our 1.0 release was showing not just the
 ‘how’, but the ‘why’, of OpenTelemetry. To that end, we’ve built a framework for
 implementing [failure scenarios](/docs/demo/#scenarios) gated by feature flags.
-In addition, we include pre-configured dashboards and walk-throughs in our docs
+In addition, we include pre-configured dashboards and walkthroughs in our docs
 on how to read and interpret the telemetry data each service emits to discover
 the underlying cause of performance regressions in the application.
 

content/en/blog/2022/demo-announcement/index.md

@@ -7,7 +7,7 @@ author: '[Carter Socha](https://github.com/cartersocha)'
 
 ## TL;DR
 
-The OpenTelemetry community has taken a good pre-existing demo (thanks,
+The OpenTelemetry community has taken a good preexisting demo (thanks,
 [Google](https://github.com/GoogleCloudPlatform/microservices-demo)!) and is in
 the process of making it even better. Every GA SDK (besides Swift) will be
 represented, demo support will be extended to Metrics and Logs, and canonical
@@ -66,8 +66,8 @@ backend choice, and they’re overly reliant on instrumentation libraries.
 As a starting point, we have selected a fork of the popular GCP microservices
 demo. Our first feature additions have been to simplify local deployment by
 consolidating the project onto a single docker compose file, updating the
-documentation, and replacing a pre-existing service with a Ruby example.
-Otherwise the pre-existing feature set from the GCP demo remains the same:
+documentation, and replacing a preexisting service with a Ruby example.
+Otherwise the preexisting feature set from the GCP demo remains the same:
 
 - 10 application microservice with support for 6 languages (C#, Go, Java,
   Node.js, Python, and Ruby)

content/en/blog/2022/instrument-nginx/index.md

@@ -4,9 +4,9 @@ linkTitle: Instrument Nginx
 date: 2022-08-22
 author: >-
   [Debajit Das](https://github.com/debajitdas), [Kumar
-  Pratyus](https://github.com/kpratyus), [Severin
+  Pratyush](https://github.com/kpratyus), [Severin
   Neumann](https://github.com/svrnm) (Cisco)
-cSpell:ignore: Debajit Kumar Pratyus webserver
+cSpell:ignore: Debajit Kumar Pratyush webserver
 ---
 
 Apache HTTP Server and NGINX are the most popular web servers. It's most likely

content/en/blog/2022/v1.0-trio.md

@@ -1,5 +1,5 @@
 ---
-title: OpenTelemetry Erlang/Elixir, Javascript, and Ruby v1.0 (Medium)
+title: OpenTelemetry Erlang/Elixir, JavaScript, and Ruby v1.0 (Medium)
 linkTitle: Erlang/Elixir, JS, and Ruby 1.0
 date: 2022-02-01
 canonical_url: https://medium.com/opentelemetry/opentelemetry-erlang-elixir-javascript-and-ruby-v1-0-3a0c32e0add4

content/en/blog/2023/lambda-release.md

@@ -21,7 +21,7 @@ had a
 and they've been available on AWS for years.
 
 You're totally correct. Rest assured, we're not reinventing the wheel. However,
-there are some pre-existing problems that may impact users:
+there are some preexisting problems that may impact users:
 
 - The OTel Lambda layers were only released as part of the
   [AWS Distribution for OTel (ADOT)](https://aws-otel.github.io/), and the

content/en/blog/2024/go-contrib-removal.md

@@ -7,7 +7,7 @@ author: >-
 issue: 4542
 sig: SIG Go
 # prettier-ignore
-cSpell:ignore: aws Benedetti Fabrizio Ferri gopkg labstack macaron moduled otelaws otelecho otellambda otelmacaron otelmongo otelmux
+cSpell:ignore: aws Benedetti Fabrizio Ferri gopkg labstack macaron otelaws otelecho otellambda otelmacaron otelmongo otelmux
 ---
 
 The Go SIG will remove the code of contrib modules that lack code owners
@@ -30,7 +30,7 @@ Currently unowned modules include the following:
 - [`go.opentelemetry.io/contrib/samplers/aws/xray`](https://pkg.go.dev/go.opentelemetry.io/contrib/samplers/aws/xray)
 
 For a full list of modules at risk for removal, see the
-[Remove unowned moduled](https://github.com/orgs/open-telemetry/projects/92/views/1)
+[Remove unowned modules](https://github.com/orgs/open-telemetry/projects/92/views/1)
 project board.
 
 ## Why are those modules going to be removed?

content/en/blog/2024/otel-collector-container-log-parser/index.md

@@ -81,7 +81,7 @@ combine them into one at first place:
 
 ```text
 2024-04-06T00:17:10.113242941Z stdout P This is a very very long line th
-2024-04-06T00:17:10.113242941Z stdout P at is really really long and spa
+2024-04-06T00:17:10.113242941Z stdout P at is really, really, long and spa
 2024-04-06T00:17:10.113242941Z stdout F ns across multiple log entries
 ```
 

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).
 

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

content/en/blog/2025/go-goals.md

@@ -0,0 +1,139 @@
+---
+title: OpenTelemetry Go 2025 Goals
+linkTitle: Go 2025 Goals
+date: 2025-01-22
+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
+---
+
+As we kick off 2025, the
+[OpenTelemetry Go](https://github.com/open-telemetry/opentelemetry-go) team has
+come together to set a roadmap for the year. Our focus is on driving the
+OpenTelemetry Go project forward while strengthening its integration with the
+broader OpenTelemetry ecosystem.
+
+## Goals
+
+Here's an overview of our goals, their expected timelines, and the key
+contributors supporting each initiative.
+
+### New Semantic Conventions (Weaver)
+
+- Priority: First quarter goal
+- Tracking Issue:
+  [#5668](https://github.com/open-telemetry/opentelemetry-go/issues/5668)
+- Sponsor: [@MrAlias](https://github.com/MrAlias)
+
+Semantic conventions are foundational to OpenTelemetry and the cornerstone of
+data quality across the ecosystem. The OpenTelemetry community has recently
+updated the tooling used to generate these conventions into usable code by
+introducing the [weaver](https://github.com/open-telemetry/weaver) project. We
+plan to integrate this new tooling into the OpenTelemetry Go project and provide
+updates to the latest versions of semantic conventions.
+
+### SDK Self-Observability Signals
+
+- Priority: Yearly goal
+- Tracking Issue:
+  [#2547](https://github.com/open-telemetry/opentelemetry-go/issues/2547)
+- Sponsor: [@dashpole](https://github.com/dashpole)
+
+This goal aims to enhance the observability of the OpenTelemetry Go SDK itself.
+We plan to add metrics about the tracing portions of the SDK as a first step,
+but hope to expand this with more signals measuring all areas of the SDK.
+Unified semantic conventions across all OpenTelemetry languages will play a
+critical role in achieving this objective.
+
+### Go Runtime Metrics Stabilization
+
+- Priority: Yearly goal
+- Tracking Issue:
+  [#5655](https://github.com/open-telemetry/opentelemetry-go-contrib/issues/5655)
+- Sponsor: [@dashpole](https://github.com/dashpole)
+
+Recently, the Go team
+[updated runtime metrics within the Go language](https://github.com/golang/go/issues/67120).
+These updates have been
+[codified in OpenTelemetry semantic conventions](https://github.com/open-telemetry/semantic-conventions/pull/981),
+and are provided as opt-in metrics in the
+[`runtime` package](https://pkg.go.dev/go.opentelemetry.io/contrib/instrumentation/runtime#pkg-overview).
+The Go SIG plans to gather community feedback and transition these metrics to an
+opt-out model, allowing better observability of Go runtimes.
+
+### Logs API Stability
+
+- Priority: Yearly goal
+- Tracking Project:
+  [Go: Logs (GA)](https://github.com/orgs/open-telemetry/projects/43)
+- Sponsor: [@pellared](https://github.com/pellared)
+
+Stabilizing the Logs API is crucial for providing a logging solution that aligns
+with OpenTelemetry’s overarching goals. Currently, a non-stable "beta"
+implementation of this API is provided in the
+[`log` package](https://pkg.go.dev/go.opentelemetry.io/otel/log), along with
+many bridges to popular logging packages:
+
+- [`otellogr`](https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otellogr)
+- [`otellogrus`](https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otellogrus)
+- [`otelslog`](https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otelslog)
+- [`otelzap`](https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otelzap)
+- [`otelzerolog`](https://pkg.go.dev/go.opentelemetry.io/contrib/bridges/otelzerolog)
+
+The Go SIG plans to continue its effort in developing the upstream
+specification. Work to stabilize the OpenTelemetry Go implementation depends on
+this upstream development, including the addition of Events.
+
+### `otelhttp` Stabilization
+
+- Priority: Yearly goal
+- Tracking Project:
+  [Go: HTTP Semconv Migration](https://github.com/orgs/open-telemetry/projects/87)
+- Sponsor: [@dmathieu](https://github.com/dmathieu)
+
+Stabilizing the
+[`otelhttp` instrumentation package](https://pkg.go.dev/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp)
+will ensure seamless HTTP observability and improved integration with the
+OpenTelemetry ecosystem. Before this can be accomplished, the instrumentation
+needs to be upgraded to use the latest stable version of semantic conventions.
+Currently, the `otelhttp` package supports duplicating semantic conventions as
+we transition to the newer version. We plan to finish supporting this
+duplication in all HTTP instrumentation, and then transition to an opt-out model
+for the latest semantic conventions in all instrumentation packages.
+
+### File-Based Configuration
+
+- Priority: Yearly goal
+- Tracking Label:
+  [File-Based Configuration](https://github.com/open-telemetry/opentelemetry-go-contrib/labels/area%3A%20config)
+- Sponsors: [@MrAlias](https://github.com/MrAlias)
+  [@codeboten](https://github.com/codeboten)
+
+This effort focuses on enabling configuration of the SDK with YAML and JSON
+files, making it easier for users to adopt and customize OpenTelemetry without
+relying solely on environment variables or code changes. Currently, the
+[`config` package](https://pkg.go.dev/go.opentelemetry.io/contrib/config)
+provides and implementation of this feature. As
+[file-based configuration is stabilized upstream in the specification](https://github.com/orgs/open-telemetry/projects/38),
+we plan to keep `config` up-to-date with these changes and provide feedback to
+its development.
+
+## Wrapping Up
+
+The OpenTelemetry Go team has an ambitious but focused set of goals for 2025.
+These initiatives will enhance the observability landscape, improve developer
+experience, and strengthen the integration of OpenTelemetry within the broader
+ecosystem. We’re excited to work with the community to bring these goals to
+fruition!
+
+We want to hear from you! Let us know what is missing or what you would like to
+see prioritized by commenting on
+[our tracking GitHub issue](https://github.com/open-telemetry/opentelemetry-go/issues/6175).
+
+If you'd like to participate in any of our efforts and become a contributor to
+the OpenTelemetry Go SIG, join our weekly SIG meetings on Thursday alternating
+between 09:00 PT and 10:00 PT and our channel
+[#otel-go](https://cloud-native.slack.com/archives/C01NPAXACKT) on
+[CNCF Slack](https://slack.cncf.io).

content/en/docs/collector/building/connector/index.md

@@ -41,11 +41,11 @@ services. Both these processors ingest trace data and convert them to metrics
 data. Since pipelines in the OpenTelemetry Collector are for only one type of
 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 work-around 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.
+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.
 
 Additional details about the connector's full capabilities can be found at the
 following links:

content/en/docs/collector/custom-collector.md

@@ -57,15 +57,15 @@ https://github.com/open-telemetry/opentelemetry-collector-releases/releases/down
 chmod +x ocb
 ```
 
-{{% /tab %}} {{% tab "MacOS (AMD 64)" %}}
+{{% /tab %}} {{% tab "macOS (AMD 64)" %}}
 
 ```sh
 curl --proto '=https' --tlsv1.2 -fL -o ocb \
 https://github.com/open-telemetry/opentelemetry-collector-releases/releases/download/cmd%2Fbuilder%2F{{% version-from-registry collector-builder %}}/ocb_{{% version-from-registry collector-builder noPrefix %}}_darwin_amd64
 chmod +x ocb
 ```
 
-{{% /tab %}} {{% tab "MacOS (ARM 64)" %}}
+{{% /tab %}} {{% tab "macOS (ARM 64)" %}}
 
 ```sh
 curl --proto '=https' --tlsv1.2 -fL -o ocb \

content/en/docs/collector/troubleshooting.md

@@ -344,8 +344,8 @@ The Collector might exit or restart due to:
 - Memory pressure from a missing or misconfigured
   [`memory_limiter` processor](https://github.com/open-telemetry/opentelemetry-collector/blob/main/processor/memorylimiterprocessor/README.md).
 - Improper sizing for load.
-- Improper configuration. For example, a queue size configured higher than
-  available memory.
+- Improper configuration. For example, a queue sized to be larger than available
+  memory.
 - Infrastructure resource limits. For example, Kubernetes.
 
 #### Collector fails to start in Windows Docker containers

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/).

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)

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
 

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.