Merge branch 'main' into add-rh

.cspell.yml

@@ -33,6 +33,7 @@ words:
   - appender
   - appenders
   - aspecto
+  - autoconfiguration
   - autoload
   - autoloaded
   - autoloader

.github/CODEOWNERS

@@ -41,3 +41,4 @@ content/en/docs/kubernetes/helm/         @open-telemetry/docs-approvers @open-te
 content/en/docs/specs/                   @open-telemetry/docs-approvers @open-telemetry/specs-approvers
 content/en/docs/security/                @open-telemetry/docs-approvers @open-telemetry/sig-security-maintainers
 content/en/ecosystem/demo/               @open-telemetry/demo-approvers @open-telemetry/demo-approvers
+content/en/docs/contributing/       @open-telemetry/docs-approvers @open-telemetry/docs-maintainers

.github/workflows/auto-update-versions.yml

@@ -12,7 +12,7 @@ jobs:
     runs-on: ubuntu-20.04
     if: github.repository == 'open-telemetry/opentelemetry.io'
     env:
-      DEPTH: --depth 100 # submodule clone depth
+      DEPTH: --depth 500 # submodule clone depth
 
     steps:
       - name: Checkout
@@ -23,15 +23,7 @@ jobs:
           git config user.name opentelemetrybot
           git config user.email [email protected]
 
-      - name: Auto-update
-        run: |
-          .github/workflows/scripts/auto-update-version.sh opentelemetry-collector-releases vers content/en/docs/collector/_index.md
-          .github/workflows/scripts/auto-update-version.sh opentelemetry-java otel content/en/docs/instrumentation/java/_index.md
-          .github/workflows/scripts/auto-update-version.sh opentelemetry-java-instrumentation instrumentation content/en/docs/instrumentation/java/_index.md
-          .github/workflows/scripts/auto-update-version.sh opentelemetry-specification spec scripts/content-modules/adjust-pages.pl
-          .github/workflows/scripts/auto-update-version.sh opentelemetry-proto otlp scripts/content-modules/adjust-pages.pl
-          .github/workflows/scripts/auto-update-version.sh semantic-conventions semconv scripts/content-modules/adjust-pages.pl
-          .github/workflows/scripts/auto-update-version.sh semantic-conventions-java semconv content/en/docs/instrumentation/java/_index.md
+      - run: ./scripts/auto-update/all-versions.sh
         env:
           # change this to secrets.GITHUB_TOKEN when testing against a fork
           GH_TOKEN: ${{ secrets.OPENTELEMETRYBOT_GITHUB_TOKEN }}

.gitmodules

@@ -1,19 +1,24 @@
 [submodule "themes/docsy"]
 	path = themes/docsy
 	url = https://github.com/cncf/docsy.git
-	branch = opentelemetry.io
+	docsy-pin = v0.8.0-11-gce52bb0
 [submodule "content-modules/opentelemetry-specification"]
 	path = content-modules/opentelemetry-specification
 	url = https://github.com/open-telemetry/opentelemetry-specification.git
+	spec-pin = v1.29.0
 [submodule "content-modules/community"]
 	path = content-modules/community
 	url = https://github.com/open-telemetry/community
+	community-pin = 0cb6dca
 [submodule "content-modules/opentelemetry-proto"]
 	path = content-modules/opentelemetry-proto
 	url = https://github.com/open-telemetry/opentelemetry-proto
+	otlp-pin = v1.1.0
 [submodule "content-modules/semantic-conventions"]
 	path = content-modules/semantic-conventions
 	url = https://github.com/open-telemetry/semantic-conventions
+	semconv-pin = v1.24.0
 [submodule "content-modules/opamp-spec"]
 	path = content-modules/opamp-spec
 	url = https://github.com/open-telemetry/opamp-spec
+	opamp-pin = v0.8.0-5-g0360da8

.htmltest.yml

@@ -27,7 +27,7 @@ IgnoreURLs: # list of regexs of paths or URLs to be ignored
   # Sites that deny access, always yielding 401, 403 Forbidden, 406, or other:
   - ^https://(www\.)?linkedin\.com\b # 999 Request Denied
   - ^https://(www\.)?mvnrepository\.com
-  - ^https://eng.uber.com/flipr/ # 406
+  - ^https://(www\.|eng\.)?uber\.com/(blog|flipr)/ # 406
   - ^https://twitter.com
   - ^https://www.chathamhouse.org
   - ^https://www.zocdoc.com
@@ -59,3 +59,11 @@ IgnoreURLs: # list of regexs of paths or URLs to be ignored
   - ^https://oncallmemaybe.com
   # TODO drop after https://github.com/open-telemetry/opentelemetry-specification/pull/3834 is merged
   - ^https://wikipedia\.org/wiki/Monotonic_function
+  # TODO drop after https://github.com/open-telemetry/opamp-spec/pull/179 is merged into this repo
+  - ^http://www.watersprings.org/
+  # TODO move into content/en/blog/2023/humans-of-otel.md once https://github.com/open-telemetry/opentelemetry.io/issues/3889 is implemented
+  - ^https://shorturl.at/osHRX$
+  # TODO drop after https://github.com/open-telemetry/semantic-conventions/pull/678 is merged:
+  - ^https://wikipedia.org/wiki/(S.M.A.R.T|Hop_)
+  # TODO move into content/en/blog/2023/contributing-to-otel/index.md once https://github.com/open-telemetry/opentelemetry.io/issues/3889 is implemented
+  - ^https://shorturl.at/vLYZ0$

.textlintrc.yml

@@ -113,6 +113,9 @@ rules:
       # https://github.com/sapegin/textlint-rule-terminology/blob/ca36a645c56d21f27cb9d902b5fb9584030c59e3/index.js#L137-L142.
       #
       - ['3rd[- ]party', third-party]
+      - ['auto[- ](configur)(es?|ations?)', 'auto$1$2'] # cspell:ignore ations configur
+      - ['back[- ]end(s)?', 'backend$1']
+      - ['bugfix', 'bug fix']
       - [cpp, C++]
       - # dotnet|.net -> .NET, but NOT for strings like:
         # - File extension: file.net

content/en/blog/2022/apisix/index.md

@@ -29,8 +29,8 @@ and sends it to OpenTelemetry Collector through HTTP protocol. Apache APISIX
 starts to support this feature in v2.13.0.
 
 One of OpenTelemetry's special features is that the agent/SDK of OpenTelemetry
-is not locked with back-end implementation, which gives users flexibilities on
-choosing their own back-end services. In other words, users can choose the
+is not locked with backend implementation, which gives users flexibilities on
+choosing their own backend services. In other words, users can choose the
 backend services they want, such as Zipkin and Jaeger, without affecting the
 application side.
 
@@ -192,7 +192,7 @@ resulting in a call chain consisting of two spans.
 ### Step 1: Deploy OpenTelemetry
 
 The following uses `docker compose` as an example. For other deployments, see
-[Getting Started](/docs/collector/getting-started/).
+[Quick start](/docs/collector/quick-start/).
 
 You can see the following command to deploy[^1]:
 

content/en/blog/2022/frontend-overhaul/index.md

@@ -114,13 +114,13 @@ This proposal was presented to the OpenTelemetry demo SIG during one of the
 weekly Monday meetings and we were given the green light to move ahead. As part
 of the changes, we decided to use [Next.js](https://nextjs.org/) to not only
 work as the primary front-end application but also to work as an aggregation
-layer between the front-end and the gRPC back-end services.
+layer between the front-end and the gRPC backend services.
 
 ![New Front-end Data Flow](data-flow.png)
 
 As you can see in the diagram, the application has two major connectivity
 points, one coming from the browser side (REST) to connect to the Next.js
-aggregation layer and the other from the aggregation layer to the back-end
+aggregation layer and the other from the aggregation layer to the backend
 services (gRPC).
 
 ## OpenTelemetry Instrumentation
@@ -129,7 +129,7 @@ The next big thing we worked was a way to instrument both sides of the Next.js
 app. To do this we had to connect the app twice to the same collector used by
 all the microservices.
 
-A simple back-end solution was designed using the
+A simple backend solution was designed using the
 [official gRPC exporter](https://www.npmjs.com/package/@opentelemetry/exporter-trace-otlp-grpc)
 in combination with the
 [Node.js SDK](https://www.npmjs.com/package/@opentelemetry/sdk-node).
@@ -160,7 +160,7 @@ CORS requests from the web app.
 
 Once the setup is complete, by loading the application from Docker and
 interacting with the different features, we can start looking at the full traces
-that begin from the front-end user events all the way to the back-end gRPC
+that begin from the front-end user events all the way to the backend gRPC
 services.
 
 ![Front-end Trace Jaeger Visualization](jaeger.png)

content/en/blog/2022/instrument-kafka-clients/index.md

@@ -90,7 +90,7 @@ java -javaagent:path/to/opentelemetry-javaagent.jar \
       -jar kafka-consumer-agent/target/kafka-consumer-agent-1.0-SNAPSHOT-jar-with-dependencies.jar
 ```
 
-The agent leverages the auto-configuration SDK extension, you will see in a bit,
+The agent leverages the autoconfiguration SDK extension, you will see in a bit,
 by setting the main parameters through system properties.
 
 ## Instrumenting the Apache Kafka clients
@@ -128,14 +128,14 @@ available to the Kafka clients instrumentation library.
 
 This can be done in two different ways:
 
-- using an SDK extension for environment-based auto-configuration.
+- using an SDK extension for environment-based autoconfiguration.
 - using SDK builders classes for programmatic configuration.
 
-#### Using the SDK auto-configuration
+#### Using the SDK autoconfiguration
 
 It is possible to configure a global `OpenTelemetry` instance by using
-environment variables thanks to the SDK extension for auto-configuration,
-enabled by adding the following dependency to your application.
+environment variables thanks to the SDK extension for autoconfiguration, enabled
+by adding the following dependency to your application.
 
 ```xml
 <dependency>
@@ -146,7 +146,7 @@ enabled by adding the following dependency to your application.
 
 When the Kafka clients instrumentation library is used, it checks if there is an
 `OpenTelemetry` instance already created and registered. If it is not, the
-library code checks if the SDK auto-configure module is in the classpath and in
+library code checks if the SDK autoconfigure module is in the classpath and in
 this case initializes it for creating the `OpenTelemetry` instance
 automatically. The corresponding configuration happens through environment
 variables (or corresponding system properties). This is really a way to simplify
@@ -169,7 +169,7 @@ command line when launching the application They are `otel.service.name` and
 #### Using the SDK builders
 
 In order to build your own `OpenTelemetry` instance and not relying on the
-auto-configuration, it is possible to do so by using the SDK builders classes
+autoconfiguration, it is possible to do so by using the SDK builders classes
 programmatically. The OpenTelemetry SDK dependency is needed in order to have
 such SDK builders available in your code.
 

content/en/blog/2022/k8s-otel-expose/index.md

@@ -106,8 +106,8 @@ in this setup are mentioned in brackets.
   [v1.2.1] installed.
 - A Kubernetes [v1.23.3] edge cluster to create a test cluster. Using
   [Kind](https://kind.sigs.k8s.io/) is recommended.
-- Installed [OpenTelemetry Operator](/docs/collector/getting-started) [v0.58.0]
-  on both ends.
+- Installed [OpenTelemetry Operator](/docs/kubernetes/operator/) [v0.58.0] on
+  both ends.
 - Installed [Jaeger Operator](https://www.jaegertracing.io/docs/1.37/operator/)
   [v1.37.0] on your public cluster.
 - Installed [cert-manager](https://cert-manager.io/) [v1.9.1] on your public

content/en/blog/2022/otel-demo-app-nomad/index.md

@@ -350,11 +350,8 @@ Before I wrap this up, I do want to give a HUGE shoutout to
 [Luiz Aoqui](https://www.linkedin.com/in/luizaoqui/) of HashiCorp, who helped me
 tweak my Nomad jobspecs, and to
 [Riaan Nolan](https://www.linkedin.com/in/riaannolan/), for his continued work
-on HashiQube. (Aside, both
-[Luiz](https://oncallmemaybe.com/episodes/opentelemetry-nomad-with-luiz-aoqui-of-hashicorp)
-and
-[Riaan](https://oncallmemaybe.com/episodes/adventures-in-open-source-software-with-riaan-nolan-of-servian)
-were my guests on the [On-Call Me Maybe Podcast](https://oncallmemaybe.com)!)
+on HashiQube. (Aside, both [Luiz] and [Riaan] were my guests on the [On-Call Me
+Maybe Podcast]!)
 
 I will now leave you with a picture of Phoebe the rat, peering out of a pink
 basket. Doesn’t she look cute? 🥰
@@ -372,8 +369,12 @@ Have questions about the OTel Demo App on Nomad? Feel free to connect through
 ---
 
 The OpenTelemetry community is always looking for contributions!
-[Join us](https://github.com/open-telemetry/community)! If you're on Mastodon,
-be sure to follow
-[OpenTelemetry on Mastodon](https://fosstodon.org/@opentelemetry)
+[Join us](/community/#special-interest-groups)! If you're on Mastodon, be sure
+to follow [OpenTelemetry on Mastodon](https://fosstodon.org/@opentelemetry)
 
+[Luiz]:
+  https://open.spotify.com/episode/7ww8y3fy49MgEbcyFGvsNV?si=BMvp8u-dRgyPEkTkYxfDAA
 [nomad]: https://www.nomadproject.io
+[On-Call Me Maybe Podcast]: https://open.spotify.com/show/4ZI6pQwChwm4sVULdtHFMe
+[Riaan]:
+  https://open.spotify.com/episode/5YrBEsXoJV3UjrHRrLRqBP?si=BpWISRD0SLytJF-vJ02sSA

content/en/blog/2023/contributing-to-otel/index.md

@@ -2,9 +2,7 @@
 title: Thinking about contributing to OpenTelemetry? Here's how I did it.
 linkTitle: Contributing to OTel
 date: 2023-09-18
-author:
-  >- # If you have only one author, then add the single name on this line in quotes.
-  [Adriana Villela](https://github.com/avillela) (Lightstep),
+author: '[Adriana Villela](https://github.com/avillela) (Lightstep)'
 canonical_url: https://medium.com/cloud-native-daily/how-to-contribute-to-opentelemetry-5962e8b2447e
 cSpell:ignore: EUWG sayin
 ---
@@ -27,10 +25,9 @@ projects? I don't know about you, but for me, up until last year, the prospect
 of contributing to open source was just plain _scary_!! I mean, when you open up
 a
 [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
-(PR),
-_[you are putting yourself out there](https://oncallmemaybe.com/episodes/adventures-in-open-source-software-with-riaan-nolan-of-servian)_,
-to be judged by those little GitHub avatars that make up the approvers list for
-the repository you're contributing to. YIKES!
+(PR), _[you are putting yourself out there]_, to be judged by those little
+GitHub avatars that make up the approvers list for the repository you're
+contributing to. YIKES!
 
 But as scary as the thought of opening a PR might be, it's also SO VERY
 SATISFYING to see your contributions merged into a codebase. And most
@@ -194,3 +191,6 @@ findings and discoveries. Obviously, I do that too. But please also share these
 findings by contributing directly to the OTel docs and blog, to ensure that we
 have a single source of truth, and so that everyone, whether they're new to OTel
 or advanced practitioners, can benefit.
+
+[you are putting yourself out there]:
+  https://open.spotify.com/episode/5YrBEsXoJV3UjrHRrLRqBP?si=BpWISRD0SLytJF-vJ02sSA

content/en/blog/2023/end-user-discussions-01.md

@@ -82,7 +82,7 @@ you will have to send the spans to a centralized service.
 #### 3- Bifurcating data in a pipeline
 
 **Q:** If I want to use the Collector to send different sets of data to
-different back-ends, what’s the best way to go about it?
+different backends, what’s the best way to go about it?
 
 **A:**
 [Connectors](https://github.com/open-telemetry/opentelemetry-collector/pull/6140)

content/en/blog/2023/end-user-discussions-03.md

@@ -127,7 +127,7 @@ further exploration:
 - [Column data store for OpenTelemetry](https://github.com/open-telemetry/oteps/pull/171)
 - [OpAMP](/blog/2022/opamp/)
 - Your backend vendor’s tail-based sampling strategies
-- [Paper by Uber](https://www.uber.com/en-IN/blog/crisp-critical-path-analysis-for-microservice-architectures/)
+- [Paper by Uber](https://uber.com/blog/crisp-critical-path-analysis-for-microservice-architectures/)
 - [Tail sampling processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/tailsamplingprocessor/README.md)
 
 ### Adoption, Migration, and Implementation

content/en/blog/2023/end-user-q-and-a-01.md

@@ -28,10 +28,10 @@ OpenTelemetry with [GraphQL](https://graphql.org/).
 
 J and his team embarked on their OpenTelemetry journey for two main reasons:
 
-- J’s company uses a few different observability back-ends. His team had
-  switched to a vendor back-end that was different from the back-end used by
-  other teams that they interfaced with. OpenTelemetry allowed them to continue
-  to get end-to-end Traces in spite of using different vendors.
+- J’s company uses a few different observability backends. His team had switched
+  to a vendor backend that was different from the backend used by other teams
+  that they interfaced with. OpenTelemetry allowed them to continue to get
+  end-to-end Traces in spite of using different vendors.
 - His team was using GraphQL, and needed to be able to better understand what
   was happening behind the scenes with their GraphQL calls.
 
@@ -58,9 +58,9 @@ Across the organization, different teams have chosen to use different
 observability platforms to suit their needs, resulting in a mix of both open
 source and proprietary observability tools.
 
-J’s team had recently migrated from one observability back-end to another. After
+J’s team had recently migrated from one observability backend to another. After
 this migration, they started seeing gaps in trace data, because other teams that
-they integrated with were still using a different observability back-end. As a
+they integrated with were still using a different observability backend. As a
 result, they no longer had an end-to-end picture of their traces. The solution
 was to use a standard, vendor-neutral way to emit telemetry: OpenTelemetry.
 
@@ -133,7 +133,7 @@ is currently discouraging teams from creating their own custom spans. Since they
 do a lot of asynchronous programming, it can be very difficult for developers to
 understand how the context is going to behave across asynchronous processes.
 
-Traces are sent to their observability back-end using that vendor’s agent, which
+Traces are sent to their observability backend using that vendor’s agent, which
 is installed on all of their nodes.
 
 ### Besides traces, do you use other signals?
@@ -142,7 +142,7 @@ The team has implemented a custom Node.js plugin for getting certain
 [metrics](/docs/concepts/signals/metrics/) data about GraphQL, such as
 deprecated field usage and overall query usage, which is something that they
 can’t get from their traces. These metrics are being sent to the observability
-back-end through the
+backend through the
 [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector)’s
 [OTLP metrics receiver](https://github.com/open-telemetry/opentelemetry-collector/blob/main/receiver/otlpreceiver/README.md).
 
@@ -158,7 +158,7 @@ The team uses
 [Amazon Elasticache](https://en.wikipedia.org/wiki/Amazon_ElastiCache) and the
 [ELK stack](https://www.techtarget.com/searchitoperations/definition/Elastic-Stack)
 for logging. They are currently doing a proof-of-concept (POC) of migrating .NET
-logs to their observability back-end. The ultimate goal is to have
+logs to their observability backend. The ultimate goal is to have
 [metrics](/docs/concepts/signals/metrics/),
 [logs](/docs/concepts/signals/logs/), and
 [traces](/docs/concepts/signals/traces/) under one roof.
@@ -171,7 +171,7 @@ link traces and metrics.
 
 ### How is the organization sending telemetry data to various observability back-ends?
 
-J’s team uses a combination of the proprietary back-end agent and the
+J’s team uses a combination of the proprietary backend agent and the
 OpenTelemetry Collector (for metrics). They are one of the primary users of
 OpenTelemetry at J’s company, and he hopes to help get more teams to make the
 switch.
@@ -245,7 +245,7 @@ which they intend to give back to the OpenTelemetry community.
 
 ### Are you planning on instrumenting mainframe code?
 
-The observability back-end used by J’s team provided native instrumentation for
+The observability backend used by J’s team provided native instrumentation for
 the mainframe. J and his team would have loved to instrument mainframe code
 using OpenTelemetry. Unfortunately, there is currently no OpenTelemetry SDK for
 PL/I (and other mainframe languages such as
@@ -288,8 +288,8 @@ JavaScript environments are akin to the Wild West of Development due to:
 
 One of J’s suggestions is to treat OTel JavaScript as a hierarchy, which starts
 with a Core JavaScript team that splits into two subgroups: front-end web group,
-and back-end group. Front-end and back-end would in turn split. For example, for
-the back-end, have a separate Deno and Node.js group.
+and backend group. Front-end and backend would in turn split. For example, for
+the backend, have a separate Deno and Node.js group.
 
 Another suggestion is to have a contrib maintainers group, separate from core
 SDK and API maintainers group.