Merge branch 'main' into opentelemetrybot/auto-update-registry-f37001338afdbd51f1e096c1dd66447dabc359e4

Author: tiffany76

.cspell.yml

@@ -58,3 +58,5 @@ dictionaries:
 words: # Valid words across all locales
   - Docsy
   - htmltest
+  # Hugo
+  - warnf

.cspell/es-palabras.txt

@@ -14,3 +14,5 @@ Muestreadores
 muestreadores
 monitoreo
 multilenguaje
+redireccionar
+prerrellenada

content/en/blog/2023/http-conventions-declared-stable.md

@@ -3,9 +3,11 @@ title: HTTP semantic conventions declared stable
 linkTitle: HTTP semconv are stable
 date: 2023-11-06
 author: '[Trask Stalnaker](https://github.com/trask) (Microsoft)'
-cSpell:ignore: chalin Liudmila Molkova
+cSpell:ignore: Liudmila Molkova
 ---
 
+<!-- markdownlint-disable table-pipe-style table-column-count -->
+
 Early this year, we launched an effort to stabilize HTTP semantic conventions.
 Today, we proudly announce that the HTTP semantic conventions are the _first_
 OpenTelemetry semantic conventions to be declared
@@ -95,8 +97,6 @@ to
 | `net.sock.peer.name` | Removed |
 | New: `http.request.method_original` | Only captured when `http.request.method` is `_OTHER` |
 | New: `error.type` | New |
-
-{.td-initial .table .table-responsive}
 <!-- prettier-ignore-end -->
 
 References:
@@ -106,10 +106,8 @@ References:
 
 ### HTTP client span attributes
 
-<!-- TODO(@chalin): I'll move this embedded style elsewhere in a followup PR -->
 <style>
-.ot-table-first-row-50 td:first-child { width: 50%; }
-.ot-table-first-row-60 td:first-child { width: 60%; }
+.ot-table-first-col-50 th:first-child { width: 50%; }
 </style>
 
 <!-- prettier-ignore-start -->
@@ -119,8 +117,6 @@ References:
 | `http.resend_count` &rarr; `http.request.resend_count` | |
 | `net.peer.name` &rarr; `server.address` | |
 | `net.peer.port` &rarr; `server.port` | Now captured even when same as default port for scheme |
-
-{.td-initial .table .table-responsive .ot-table-first-row-60}
 <!-- prettier-ignore-end -->
 
 References:
@@ -139,8 +135,7 @@ References:
 | `http.client_ip` &rarr; `client.address` | If `http.client_ip` was unknown (i.e., no [X-Forwarded-For][], [Forwarded#for][] headers), then `net.sock.peer.addr` &rarr; `client.address`; now must be provided to sampler |
 | `net.host.name` &rarr; `server.address` | Now based only on [Host][Host header], [:authority][HTTP/2 authority], [X-Forwarded-Host][], [Forwarded#host][] headers |
 | `net.host.port` &rarr; `server.port` | Now based only on [Host][Host header], [:authority][HTTP/2 authority], [X-Forwarded-Host][X-Forwarded-Host], [Forwarded#host][] headers |
-
-{.td-initial .table .table-responsive .ot-table-first-row-50}
+{.ot-table-first-col-50}
 <!-- prettier-ignore-end -->
 
 References:
@@ -183,8 +178,6 @@ Metric changes:
 | `net.protocol.name` &rarr; `network.protocol.name` | Recommended &rarr; Conditionally required if not `http` and `network.protocol.version` is set |
 | `net.protocol.version` &rarr; `network.protocol.version` | Examples fixed: `2.0` &rarr; `2` and `3.0` &rarr; `3`; see note if [migrating from `<= v1.19.0`](#migrating-from--v1190) |
 | New: `error.type` | New |
-
-{.td-initial .table .table-responsive}
 <!-- prettier-ignore-end -->
 
 References:
@@ -216,8 +209,7 @@ Metric changes:
 | `net.host.name` → `server.address` | &bullet; Recommended → Opt-In (due to high-cardinality vulnerability since based on HTTP headers)<br>&bullet; Now based only on [`Host` span][Host header], [`:authority` span][HTTP/2 authority], [`X-Forwarded-Host` span][X-Forwarded-Host], [`Forwarded#host` span][Forwarded#host] headers |
 | `net.host.port` → `server.port` | &bullet; Recommended → Opt-In (due to high-cardinality vulnerability since based on HTTP headers)<br>&bullet; Now based only on [`Host` span][Host header], [`:authority` span][HTTP/2 authority], [`X-Forwarded-Host` span][X-Forwarded-Host], [`Forwarded#host` span][Forwarded#host] headers |
 | New: `error.type` | New |
-
-{.td-initial .table .table-responsive .ot-table-first-row-50}
+{.ot-table-first-col-50}
 <!-- prettier-ignore-end -->
 
 References:

content/en/docs/languages/js/_includes/browser-instrumentation-warning.md

@@ -0,0 +1,15 @@
+---
+title: # Bogus entry for markdownlint
+_build: { list: never, render: never }
+---
+
+{{% alert-md title=Warning color=warning %}}
+
+Client instrumentation for the browser is **experimental** and mostly
+**unspecified**. If you are interested in helping out, get in touch with the
+[Client Instrumentation SIG][sig].
+
+[sig]:
+  https://docs.google.com/document/d/16Vsdh-DM72AfMg_FIt9yT9ExEWF4A_vRbQ3jRNBe09w
+
+{{% /alert-md %}}

content/en/docs/languages/js/_index.md

@@ -10,8 +10,7 @@ weight: 20
 
 {{% docs/languages/index-intro js /%}}
 
-{{% alert title="Warning" color="warning" %}}
-{{% param notes.browser-instrumentation %}} {{% /alert %}}
+{{% include browser-instrumentation-warning.md %}}
 
 ## Version Support
 

content/en/docs/languages/js/getting-started/browser.md

@@ -5,8 +5,7 @@ description: Learn how to add OpenTelemetry to your browser app
 weight: 20
 ---
 
-{{% alert title="Warning" color="warning" %}}
-{{% param notes.browser-instrumentation %}} {{% /alert %}}
+{{% include browser-instrumentation-warning.md %}}
 
 While this guide uses the example application presented below, the steps to
 instrument your own application should be similar.

content/en/docs/languages/js/instrumentation.md

@@ -335,8 +335,7 @@ above, you have a `TracerProvider` setup for you already. You can continue with
 
 #### Browser
 
-{{% alert title="Warning" color="warning" %}}
-{{% param notes.browser-instrumentation %}} {{% /alert %}}
+{{% include browser-instrumentation-warning.md %}}
 
 First, ensure you've got the right packages:
 

content/es/docs/contributing/issues.md

@@ -0,0 +1,106 @@
+---
+title: Propuestas
+description:
+  Cómo solucionar un problema existente o informar un error, un riesgo de
+  seguridad o una posible mejora.
+weight: 10
+_issues: https://github.com/open-telemetry/opentelemetry.io/issues
+_issue: https://github.com/open-telemetry/opentelemetry.io/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3A
+default_lang_commit: 99f0ae5760038d51f9e9eb376bb428a2caca8167
+---
+
+## Solucionando una propuesta existente
+
+Una de las mejores maneras de contribuir a mejorar la documentación de
+OpenTelemetry (OTel) es solucionando un problema ya identificado.
+
+1. Navegar por la lista de [propuestas]({{% param _issues %}}).
+2. Seleccione una propuesta en el que le gustaría trabajar, idealmente una que
+   se pueda solucionar en poco tiempo.
+
+   <!-- prettier-ignore -->
+   <a name="first-issue"></a>
+   {{% alert title="Contribuyendo por la primera vez? " %}}
+
+   Seleccione una propuesta con las siguientes etiquetas:
+
+   - [Good first issue]
+   - [Help wanted]
+
+   <!-- prettier-ignore -->
+   > **NOTA**: **_No_ asignamos propuestas** a aquellos que aún no hayan contribuido a la organización [OpenTelemetry
+   > organization][org], a menos que sean parte de un proceso de tutoria o onboarding.
+   {.mt-3}
+
+   <!-- prettier-ignore -->
+   [good first issue]: {{% param _issue %}}%22good+first+issue%22
+   [help wanted]: {{% param _issue %}}%3A%22help+wanted%22
+   [org]: https://github.com/open-telemetry
+
+   {{% /alert %}}
+
+3. Lea los comentarios del problema, si los hay.
+4. Pregunta a los mantenedores si la propuesta sigue siendo relevante y aclara
+   cualquier duda publicando un comentario.
+5. Comparte tu intención de trabajar en el tema agregando un comentario a este
+   efecto.
+6. Trabaja para solucionar el problema y notifica a los mantenedores si surge
+   algún inconveniente.
+7. Cuando este listo, [envia tu trabajo con un pull request](../pull-requests)
+   (PR).
+
+## Reportar un problema
+
+Si encuentras un error o quieres hacer unas sugerencias para mejorar el
+contenido existente, abre una propuesta.
+
+1. Haz click en el enlace **Crea una propuesta para la documentación** de
+   cualquier documento. Eso te va a redireccionar a una pagina de la propuesta
+   GitHub prerrellenada con algunos encabezados.
+2. Describa el problema o la sugerencia de mejora. Proporcione tantos detalles
+   como pueda.
+3. Haz click en **Submit new issue**.
+
+Después de enviar el problema, verifique su problema de vez en cuando o active
+las notificaciones de GitHub. Puede que pasen algunos días hasta que los
+mantenedores respondan. Los revisores y otros miembros de la comunidad pueden
+hacer preguntas antes de poder tomar medidas sobre su problema.
+
+## Sugerir nuevos contenidos o funciones
+
+Si tienes una idea para un nuevo contenido o funcionalidad, pero no estás seguro
+de dónde debería ir, aún puedes presentar una propuesta. También puedes informar
+errores y vulnerabilidades de seguridad.
+
+1. Ve a [GitHub](https://github.com/open-telemetry/opentelemetry.io/issues/new/)
+   y selecciona **Nueva propuesta** dentro de la pestaña **Propuestas**.
+
+1. Seleccione el tipo de problema que mejor se aplica a su solicitud o duda.
+
+1. Rellene la plantilla.
+
+1. Envia la propuesta.
+
+### Como crear buenas propuestas
+
+Tenga en cuenta lo siguiente al crear una propuesta:
+
+- Proporcione una descripción clara del problema. Describa específicamente qué
+  falta, qué está desactualizado, qué está mal o qué necesita mejorarse.
+- Explique el impacto específico que tiene el problema en los usuarios.
+- Limite el alcance de un problema determinado a una unidad de trabajo
+  razonable. En el caso de problemas de gran alcance, divídelos en tareas más
+  pequeñas. Por ejemplo, "Corregir la documentación de seguridad" es demasiado
+  amplio, pero "Agregar detalles en la sección 'Restringir el acceso a la red'"
+  es lo suficientemente específico como para que se pueda llevar a cabo una
+  acción.
+- Busque los problemas existentes para ver si hay algo relacionado o similar al
+  nuevo problema.
+- Si el nuevo problema se relaciona con otro problema o solicitud de
+  incorporación de cambios, haga referencia a él por su URL completa o por el
+  número del problema o solicitud de incorporación de cambios precedido por el
+  carácter `#`, por ejemplo `Introducido por #987654`.
+- Sigue el
+  [Código de conducta](https://github.com/open-telemetry/community/blob/main/code-of-conduct.md).
+  Respete a sus compañeros colaboradores. Por ejemplo, decir "Los documentos son
+  terribles" no es un comentario útil ni cortés.

content/ja/docs/concepts/context-propagation.md

@@ -2,11 +2,11 @@
 title: コンテキスト伝搬
 weight: 10
 description: 分散トレーシングを可能にする概念について学ぶ
-default_lang_commit: 313e391
+default_lang_commit: d2368c7e90e6abeb4580193aa305dfabd21ed4f7
 ---
 
-コンテキスト伝搬により、[シグナル](/docs/concepts/signals)は、それらが生成された場所に関係なく、互いを相関させられます。
-トレースに限ったことではありませんが、コンテキスト伝搬によって、[トレース](/docs/concepts/signals/traces)は、プロセスやネットワークの境界を越えて任意に分散しているサービス間で、システムに関する因果情報を構築できます。
+コンテキスト伝搬により、[シグナル](../signals/)は、それらが生成された場所に関係なく、互いを相関させられます。
+トレースに限ったことではありませんが、コンテキスト伝搬によって、[トレース](../signals/traces/)は、プロセスやネットワークの境界を越えて任意に分散しているサービス間で、システムに関する因果情報を構築できます。
 
 コンテキストの伝播を理解するには、コンテキストと伝搬（プロパゲーション）という、2つの別々の概念を理解する必要があります。
 
@@ -23,7 +23,7 @@ default_lang_commit: 313e391
 コンテキストオブジェクトをシリアライズまたはデシリアライズし、あるサービスから別のサービスに伝搬される関連情報を提供します。
 
 伝播は通常、計装ライブラリによって処理され、ユーザーには透過的です。
-手動でコンテキストを伝播する必要がある場合は、伝搬APIを使用できます。
+手動でコンテキストを伝播する必要がある場合は、[伝搬API](/docs/specs/otel/context/api-propagators/)を使用できます。
 
 OpenTelemetryはいくつかの公式プロパゲーターを保守しています。
 デフォルトのプロパゲーターは[W3C TraceContext](https://www.w3.org/TR/trace-context/)仕様で指定されたヘッダーを使用しています。

content/ja/docs/concepts/instrumentation/zero-code.md content/ja/docs/concepts/instrumentation/zero-code/index.md

@@ -3,14 +3,16 @@ title: ゼロコード
 description: >-
   コードを書かずにアプリケーションにオブザーバビリティを追加する方法を学ぶ
 weight: 10
-default_lang_commit: d8c5612
+default_lang_commit: 35fde3d
 ---
 
 [運用担当者](/docs/getting-started/ops/)として、ソースを編集することなく、1つ以上のアプリケーションにオブザーバビリティを追加したいと思うかもしれません。
-OpenTelemetry を使えば、[コードベースの計装](/docs/concepts/instrumentation/code-based) のための OpenTelemetry API & SDK を使わなくても、サービスのオブザーバビリティを素早く得られます。
+OpenTelemetry を使えば、[コードベースの計装](/docs/concepts/instrumentation/code-based) のための OpenTelemetry API や SDK を使わなくても、サービスのオブザーバビリティを素早く得られます。
 
-ゼロコード計装は、OpenTelemetry APIとSDKの機能を使って、通常、エージェントあるいはそれに準ずる機能をアプリケーションに追加します。
-具体的なメカニズムは言語によって異なり、バイトコード操作、モンキーパッチ、あるいはeBPFから、アプリケーションにOpenTelemetry APIとSDKへの呼び出しを注入します。
+![Zero Code](./zero-code.svg)
+
+ゼロコード計装は、OpenTelemetry API と SDKの機能を使って、通常、エージェントあるいはそれに準ずる機能をアプリケーションに追加します。
+具体的なメカニズムは言語によって異なり、バイトコード操作、モンキーパッチ、あるいは eBPF から、アプリケーションにOpenTelemetry APIとSDKへの呼び出しを注入します。
 
 通常、ゼロコード計装は、使用しているライブラリの計装を追加します。
 つまり、リクエストとレスポンス、データベース呼び出し、メッセージキュー呼び出しなどが計装の対象となります。

content/ja/docs/concepts/signals/_index.md

@@ -2,15 +2,27 @@
 title: シグナル
 description: OpenTelemetryがサポートするテレメトリーのカテゴリについて学ぶ
 weight: 11
-default_lang_commit: 9b5e318
+default_lang_commit: 43ecc19b51fd86d5b2f30c638f6d734ee8b94932
 ---
 
 OpenTelemetryの目的は、**[シグナル][signals]** を収集、処理、エクスポートすることです。
 シグナルは、オペレーティングシステムやプラットフォーム上で動作しているアプリケーションの基本的な活動を記述するシステム出力です。
 シグナルは、温度やメモリ使用量のような特定の時点で測定したいもの、またはあなたが追跡したい分散システムのコンポーネントを通過するイベントです。
 異なるシグナルをグループ化して、同じテクノロジーの内部動作を異なる角度から観察することもできる。
 
-OpenTelemetry は現在、[トレース](/docs/concepts/signals/traces)、[メトリクス](/docs/concepts/signals/metrics)、[ログ](/docs/concepts/signals/logs)と[バゲッジ](/docs/concepts/signals/baggage)をサポートしています。
-_イベント_ は特定の種類のログで、_プロファイル_ はProfiling Working Groupによって[現在策定中](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/profiles/0212-profiling-vision.md)です。
+OpenTelemetry は現在、下記をサポートしています。
 
+- [トレース](traces)
+- [メトリクス](metrics)
+- [ログ](logs)
+- [バゲッジ](baggage)
+
+同様に、下記は開発中または[提案][proposal]の段階です。
+
+- [イベント][Events]は、特定の[ログ](logs)のタイプです。
+- [プロファイル][Profiles] は、Profiling Working Group によって現在策定中です。
+
+[Events]: /docs/specs/otel/logs/data-model/#events
+[Profiles]: https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/profiles/0212-profiling-vision.md
+[proposal]: https://github.com/open-telemetry/opentelemetry-specification/tree/main/oteps/#readme
 [signals]: /docs/specs/otel/glossary/#signals

content/ja/docs/concepts/signals/metrics.md

@@ -2,7 +2,7 @@
 title: メトリクス
 weight: 2
 description: 実行時に取得された測定値
-default_lang_commit: eb19d1dd5ab2f66343ec76adbfb31f81024da3a1
+default_lang_commit: f15873cbe9b2c3f3b51ef4629a6116de84eae08f
 ---
 
 **メトリクス**とは、実行時に取得されるサービスの**測定値**のことです。
@@ -52,9 +52,9 @@ OpenTelemetryでは、計測は **メトリクス計装** によって行われ
   たとえば、キューの長さは、キュー内のワークアイテムの数によって増減します。
 - **Asynchronous UpDownCounter（非同期アップダウンカウンター）**: **アップダウンカウンター**と同じですが、各エクスポートに対して一度だけ収集されます。
   連続的な変更にアクセスできず、集約された値（たとえば、現在のキューのサイズ）のみにアクセスできる場合に使用できます。
-- **Gauge（ゲージ）**: 読み取った時点での現在の値を測定します。たとえば、自動車の燃料計など。ゲージは非同期です。
+- **Gauge（ゲージ）**: 読み取った時点での現在の値を測定します。たとえば、自動車の燃料計など。ゲージは同期しています。
 - **Asynchronous Gauge（非同期ゲージ）**: **ゲージ**と同じですが、各エクスポートに対して一度だけ収集されます。
-  連続的な変更にアクセスできず、集約された値 のみにアクセスできる場合に使用できます。
+  連続的な変更にアクセスできず、集約された値のみにアクセスできる場合に使用できます。
 - **Histogram（ヒストグラム）**: リクエストのレイテンシーなどの値をクライアント側で集約したもの。
   値の統計に興味がある場合は、ヒストグラムが良いでしょう。
   たとえば、どれくらいのリクエストが1秒未満か、といった疑問に答えてくれます。
@@ -69,7 +69,7 @@ OTLPプロトコルは、このような集約されたメトリクスを伝送
 OpenTelemetry APIは、各計装に対してデフォルトの集約を提供します。これはビューを使ってオーバーライドできます。
 OpenTelemetryプロジェクトは、ビジュアライザーやテレメトリーバックエンドでサポートされるデフォルトの集計を提供することを目指しています。
 
-[リクエストトレース](/docs/concepts/signals/traces/)が、リクエストのライフサイクルを捕捉し、リクエストの個々の部分にコンテキストを提供することを意図しているのとは異なり、メトリクスは、集約された統計情報を提供することを意図しています。
+[リクエストトレース](../traces/)が、リクエストのライフサイクルを捕捉し、リクエストの個々の部分にコンテキストを提供することを意図しているのとは異なり、メトリクスは、集約された統計情報を提供することを意図しています。
 メトリクスの使用例には、次のようなものがあります。
 
 - プロトコルの種類ごとに、サービスによって読み取られた総バイト数を報告する。