Merge branch 'main' into docs/languages/go/index

.github/workflows/pr-actions.yml

@@ -69,7 +69,7 @@ jobs:
 
       - run: |
           case $PR_ACTION in
-            all|refcache)
+            all|refcache|text)
               npm install --omit=optional
               ;&
             *)

.github/workflows/scripts/update-registry-versions.sh

@@ -82,9 +82,11 @@ for yaml_file in ${FILES}; do
         echo "${yaml_file}: Package name and/or registry are missing in the YAML file."
     else
         # Get latest version
-        latest_version=$(get_latest_version "$name" "$registry")
+        latest_version=$(get_latest_version "$name" "$registry" || echo "Could not fetch version.")
 
-        if [ "$latest_version" == "Registry not supported." ]; then
+        if [ "$latest_version" == "Could not fetch version." ]; then
+            echo "${yaml_file} ($registry): Registry not supported.";
+        elif [ "$latest_version" == "Registry not supported." ]; then
             echo "${yaml_file} ($registry): Registry not supported.";
         elif [ -z "$latest_version" ]; then
             echo "${yaml_file} ($registry): Could not get latest version from registry."
@@ -118,14 +120,22 @@ if [ "$existing_pr_count" -gt 0 ]; then
     exit 0
 fi
 
-$NPM run fix:format
+if [[ -n $(git status --porcelain) ]]; then
+    echo "Versions have been updated, formatting and pushing changes."
+
+    $NPM run fix:format
+
+    $GIT checkout -b "$branch"
+    $GIT commit -a -m "$message"
+    $GIT push --set-upstream origin "$branch"
 
-$GIT checkout -b "$branch"
-$GIT commit -a -m "$message"
-$GIT push --set-upstream origin "$branch"
+    body_file=$(mktemp)
+    echo -en "${body}" >> "${body_file}"
 
-body_file=$(mktemp)
-echo -en "${body}" >> "${body_file}"
+    echo "Submitting auto-update PR '$message'."
+    $GH pr create --title "$message" --body-file "${body_file}"
 
-echo "Submitting auto-update PR '$message'."
-$GH pr create --title "$message" --body-file "${body_file}"
+else
+    echo "No changes detected."
+    exit 0
+fi

.gitmodules

@@ -19,7 +19,7 @@
 [submodule "content-modules/semantic-conventions"]
 	path = content-modules/semantic-conventions
 	url = https://github.com/open-telemetry/semantic-conventions
-	semconv-pin = v1.28.0
+	semconv-pin = v1.29.0
 [submodule "content-modules/opamp-spec"]
 	path = content-modules/opamp-spec
 	url = https://github.com/open-telemetry/opamp-spec

.prettierignore

@@ -7,7 +7,8 @@
 !/layouts/shortcodes
 /layouts/shortcodes/*
 !/layouts/shortcodes/docs
-/layouts/shortcodes/pt
+!/layouts/shortcodes/es
+!/layouts/shortcodes/pt
 
 /content/ja
 /content/zh

README.md

@@ -44,8 +44,8 @@ We, the OTel Communications SIG, meet every two weeks on Monday at 10:00 PT.
 Check out the [OpenTelemetry community calendar][] for the Zoom link and any
 updates to this schedule.
 
-Meeting notes are available as a public [Google doc][]. If you have trouble accessing
-the doc, get in touch in the `#otel-comms` channel on [Slack][].
+Meeting notes are available as a public [Google doc][]. If you have trouble
+accessing the doc, get in touch in the `#otel-comms` channel on [Slack][].
 
 ## Roles
 
@@ -74,8 +74,8 @@ Here is a list of community roles with current and previous members:
   - [Morgan McLean](https://github.com/mtwo)
   - [jparsana](https://github.com/jparsana)
 
-Learn more about roles in the [community repository][]. Thanks to [all who have already
-contributed][contributors]!
+Learn more about roles in the [community repository][]. Thanks to [all who have
+already contributed][contributors]!
 
 ## Licenses
 

assets/scss/_registry.scss

@@ -39,3 +39,26 @@
 .registry-entry {
   @extend .shadow;
 }
+
+#searchForm .btn.btn-outline-success,
+.btn-outline-danger,
+.btn-outline-secondary {
+  &:hover {
+    color: var(--bs-white);
+  }
+}
+
+@include color-mode(dark) {
+  @media (prefers-color-scheme: dark) {
+    .border-default {
+      border-color: #a3a3a3;
+    }
+    .card.registry-entry {
+      box-shadow: 0 20px 50px rgba(0, 0, 0, 0.8) !important;
+    }
+    .card.registry-entry,
+    .list-group > .list-group-item {
+      background-color: #262d2c;
+    }
+  }
+}

content/en/blog/2019/opentelemetry-governance-committee-explained/index.md

@@ -74,6 +74,7 @@ your questions!
 Thanks [Sarah Novotny](https://twitter.com/sarahnovotny) for review and
 feedback!
 
-_A version of this article was [originally posted][] on [medium.com/opentelemetry](https://medium.com/opentelemetry)._
+_A version of this article was [originally posted][] on
+[medium.com/opentelemetry](https://medium.com/opentelemetry)._
 
 [originally posted]: {{% param canonical_url %}}

content/en/blog/2021/gc-election.md

@@ -6,6 +6,7 @@ canonical_url: https://medium.com/opentelemetry/announcing-the-2021-opentelemetr
 ---
 
 The OpenTelemetry project is excited to announce the 2021 OpenTelemetry
-Governance Committee (GC) election. For all the details, see the [original post][].
+Governance Committee (GC) election. For all the details, see the [original
+post][].
 
 [original post]: {{% param canonical_url %}}

content/en/blog/2021/womens-day.md

@@ -6,6 +6,7 @@ canonical_url: https://medium.com/opentelemetry/opentelemetry-observes-internati
 ---
 
 Happy International Women’s Day! The OpenTelemetry project would like to extend
-our thanks to all our women contributors. For all the details, see the [original post][].
+our thanks to all our women contributors. For all the details, see the [original
+post][].
 
 [original post]: {{% param canonical_url %}}

content/en/blog/2022/debug-otel-with-otel/index.md

@@ -229,8 +229,8 @@ in the NGINX module and we need to fix that.
 
 ### The fix
 
-To fix our problem we [added some checks to the module for NGINX][], that make sure
-that the trace headers are only set once.
+To fix our problem we [added some checks to the module for NGINX][], that make
+sure that the trace headers are only set once.
 
 This fix is contained in the [v1.0.1 release of the otel-webserver-module][].
 This means you can update the `Dockerfile` to install the NGINX module like the

content/en/blog/2022/exponential-histograms/index.md

@@ -40,12 +40,13 @@ The SDK is used to configure what happens with the data collected by the API.
 This typically includes processing it and exporting it out of process for
 analysis, often to an observability platform.
 
-The API entry point for metrics is the [meter provider][]. It provides meters for
-different scopes, where a scope is just a logical unit of application code. For example,
-instrumentation for an HTTP client library would have a different scope and therefore
-a different meter than instrumentation for a database client library. You use meters
-to obtain instruments. You use instruments to report measurements, which consist
-of a value and set of attributes. This Java code snippet demonstrates the workflow:
+The API entry point for metrics is the [meter provider][]. It provides meters
+for different scopes, where a scope is just a logical unit of application code.
+For example, instrumentation for an HTTP client library would have a different
+scope and therefore a different meter than instrumentation for a database client
+library. You use meters to obtain instruments. You use instruments to report
+measurements, which consist of a value and set of attributes. This Java code
+snippet demonstrates the workflow:
 
 ```java
 OpenTelemetry openTelemetry = // declare OpenTelemetry instance
@@ -73,7 +74,8 @@ and when the sum of the things is more important than their individual values
 the distribution of measurements is relevant for analysis. For example, a
 histogram is a natural choice for tracking response times for HTTP servers,
 because it's useful to analyze the distribution of response times to evaluate
-SLAs and identify trends. To learn more, see the guidelines for [instrument selection][].
+SLAs and identify trends. To learn more, see the guidelines for [instrument
+selection][].
 
 I mentioned earlier that the SDK aggregates measurements from instruments. Each
 instrument type has a default aggregation strategy (or simply [aggregation][])
@@ -125,10 +127,10 @@ request, you can determine:
   requests resolve quickly but a small number of requests take a long time and
   bring down the average.
 
-The second type of OpenTelemetry histogram is the [exponential
-bucket histogram][]. Exponential bucket histograms have buckets and bucket
-counts, but instead of explicitly defining the bucket boundaries, the boundaries
-are computed based on an exponential scale. More specifically, each bucket is
+The second type of OpenTelemetry histogram is the [exponential bucket
+histogram][]. Exponential bucket histograms have buckets and bucket counts, but
+instead of explicitly defining the bucket boundaries, the boundaries are
+computed based on an exponential scale. More specifically, each bucket is
 defined by an index _i_ and has bucket boundaries _(base\*\*i, base\*\*(i+1)]_,
 where _base\*\*i_ means that _base_ is raised to the power of _i_. The base is
 derived from a scale factor that is adjustable to reflect the range of reported
@@ -197,13 +199,14 @@ large range of measurement values.
 
 Let's bring everything together with a proper demonstration comparing explicit
 bucket histograms to exponential bucket histograms. I've put together some
-[example code][] that simulates tracking response time to an HTTP server in milliseconds.
-It records one million samples to an explicit bucket histogram with the default buckets,
-and to an exponential bucket histogram with a number of buckets that produces roughly
-the same size of [OTLP][] -encoded, Gzip-compressed payload as the explicit bucket
-defaults. Through trial and error, I determined that ~40 exponential buckets produce
-an equivalent payload size to the default explicit bucket histogram with 11 buckets.
-(Your results may vary.)
+[example code][] that simulates tracking response time to an HTTP server in
+milliseconds. It records one million samples to an explicit bucket histogram
+with the default buckets, and to an exponential bucket histogram with a number
+of buckets that produces roughly the same size of [OTLP][] -encoded,
+Gzip-compressed payload as the explicit bucket defaults. Through trial and
+error, I determined that ~40 exponential buckets produce an equivalent payload
+size to the default explicit bucket histogram with 11 buckets. (Your results may
+vary.)
 
 I wanted the distribution of samples to reflect what we might see in an actual
 HTTP server, with bands of response times corresponding to different operations.

content/en/blog/2022/instrument-apache-httpd-server/index.md

@@ -8,12 +8,13 @@ cSpell:ignore: Centos centos7 Debajit debuggability libmod uncompress webserver
 ---
 
 If you are using Apache HTTP Server and in dire need of some observability tool
-to monitor your web server, the [OpenTelemetry Module for Apache HTTP Server][] is
-the right candidate for you: it enables tracing of incoming requests to the server
-and it will capture the response time of many modules (including `mod_proxy`) involved
-in such an incoming request. With that you will get hierarchical time consumption
-by each module. This article demonstrates the monitoring capabilities of the OpenTelemetry
-Module for Apache HTTP Server and quick guide to get started with the module.
+to monitor your web server, the [OpenTelemetry Module for Apache HTTP Server][]
+is the right candidate for you: it enables tracing of incoming requests to the
+server and it will capture the response time of many modules (including
+`mod_proxy`) involved in such an incoming request. With that you will get
+hierarchical time consumption by each module. This article demonstrates the
+monitoring capabilities of the OpenTelemetry Module for Apache HTTP Server and
+quick guide to get started with the module.
 
 ## Getting Started with OpenTelemetry Module
 

content/en/blog/2022/k8s-metadata/index.md

@@ -172,10 +172,11 @@ reducing the scope of the collector service account to a single namespace.
 
 ## Using Resource detector processor
 
-As of [recently][pr#832], the [OpenTelemetry operator][] sets the `OTEL_RESOURCE_ATTRIBUTES`
-environment variable on the collector container with the K8s pod attributes. This
-lets you to use the resource detector processor, which attaches the environment variable
-values to the spans. This only works when the collector is deployed in sidecar mode.
+As of [recently][pr#832], the [OpenTelemetry operator][] sets the
+`OTEL_RESOURCE_ATTRIBUTES` environment variable on the collector container with
+the K8s pod attributes. This lets you to use the resource detector processor,
+which attaches the environment variable values to the spans. This only works
+when the collector is deployed in sidecar mode.
 
 For example, if you deploy the following manifest:
 

content/en/blog/2022/kubecon-na.md

@@ -8,8 +8,8 @@ cSpell:ignore: Kowall Logz Pothulapati unconference Vineeth
 
 The OpenTelemetry project maintainers, and members of the governance committee
 and technical committee are excited to be at [KubeCon NA][] in a few weeks! Join
-in to meet up in person or virtually for [OpenTelemetry](/) activities in Detroit
-from October 24 - 28, 2022.
+in to meet up in person or virtually for [OpenTelemetry](/) activities in
+Detroit from October 24 - 28, 2022.
 
 There are talks, workshops, an unconference as well as a project booth where you
 are welcome to stop by, say Hi! and tell us about how you are using

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

@@ -350,8 +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] and [Riaan] were my guests on the [On-Call
-Me Maybe Podcast]!)
+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? 🥰

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

@@ -25,9 +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]_, 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

content/en/blog/2023/ecs-otel-semconv-convergence.md

@@ -47,12 +47,13 @@ and join the discussion on our
 
 - [Announcement from Elastic][]
 - [OpenTelemetry Semantic Conventions][]
-- [OTEP 199: Merge Elastic Common Schema with OpenTelemetry Semantic Conventions][]
-- [OTEP Issue 197: Proposal: Add support for Elastic Common Schema (ECS)
-  in OpenTelemetry][]
+- [OTEP 199: Merge Elastic Common Schema with OpenTelemetry Semantic
+  Conventions][]
+- [OTEP Issue 197: Proposal: Add support for Elastic Common Schema (ECS) in
+  OpenTelemetry][]
 - [OTEP Pull Request 199: Support Elastic Common Schema in OpenTelemetry][]
-- [OTEP Pull Request 222: Support Elastic Common Schema (ECS)
-  in OpenTelemetry][]
+- [OTEP Pull Request 222: Support Elastic Common Schema (ECS) in
+  OpenTelemetry][]
 
 [Announcement from Elastic]:
   https://elastic.co/blog/ecs-elastic-common-schema-otel-opentelemetry-announcement

content/en/blog/2023/exponential-histograms.md

@@ -6,13 +6,14 @@ cSpell:ignore: Ganesh Ruslan subsetting Vernekar Vovalov
 canonical_url: https://dyladan.me/histograms/2023/05/04/exponential-histograms/
 ---
 
-Previously, in [Why Histograms?][] and [Histograms vs Summaries][], I went over the
-basics of histograms and summaries, explaining the tradeoffs, benefits, and limitations
-of each. Because they're easy to understand and demonstrate, those posts focused
-on so-called explicit bucket histograms. The exponential bucket histogram, also referred
-to as native histogram in Prometheus, is a low-cost, efficient alternative to explicit
-bucket histograms. In this post, I go through what they are, how they work, and the
-problems they solve that explicit bucket histograms struggle with.
+Previously, in [Why Histograms?][] and [Histograms vs Summaries][], I went over
+the basics of histograms and summaries, explaining the tradeoffs, benefits, and
+limitations of each. Because they're easy to understand and demonstrate, those
+posts focused on so-called explicit bucket histograms. The exponential bucket
+histogram, also referred to as native histogram in Prometheus, is a low-cost,
+efficient alternative to explicit bucket histograms. In this post, I go through
+what they are, how they work, and the problems they solve that explicit bucket
+histograms struggle with.
 
 ## Types of histograms
 
@@ -129,9 +130,8 @@ relative error = (bucketWidth / 2) / bucketMidpoint
                = 4.329%
 ```
 
-For more information regarding histogram errors, see [OTEP 149][] and the [specification
-for
-exponential histogram aggregations][].
+For more information regarding histogram errors, see [OTEP 149][] and the
+[specification for exponential histogram aggregations][].
 
 ## Choosing a scale