Merge branch 'main' into blog-command

content/en/docs/concepts/signals/baggage.md

@@ -4,46 +4,52 @@ weight: 4
 description: Contextual information that is passed between signals.
 ---
 
-In OpenTelemetry, Baggage is contextual information that’s passed between spans.
-It's a key-value store that resides alongside span context in a trace, making
-values available to any span created within that trace.
+In OpenTelemetry, Baggage is contextual information that resides next to
+context. Baggage is a key-value store, which means it lets you
+[propagate](/docs/concepts/context-propagation/#propagation) any data you like
+alongside [context](/docs/concepts/context-propagation/#context).
 
-For example, imagine you want to have a `ClientId` attribute on every span in
-your trace, which involves multiple services; however, `ClientId` is only
-available in one specific service. To accomplish your goal, you can use
-OpenTelemetry Baggage to propagate this value across your system.
+Baggage means you can pass data across services and processes, making it
+available to add to [traces](/docs/concepts/signals/traces/),
+[metrics](/docs/concepts/signals/metrics/), or
+[logs](/docs/concepts/signals/logs/) in those services.
 
-OpenTelemetry uses
-[Context Propagation](/docs/concepts/signals/traces/#context-propagation) to
-pass Baggage around, and each of the different library implementations has
-propagators that parse and make that Baggage available without you needing to
-explicitly implement it.
+## Example
 
-![OTel Baggage](/img/otel-baggage.svg)
+Baggage is often used in tracing to propagate additional data across services.
+
+For example, imagine you have a `clientId` at the start of a request, but you'd
+like for that ID to be available on all spans in a trace, some metrics in
+another service, and some logs along the way. Because the trace may span
+multiple services, you need some way to propagate that data without copying the
+`clientId` across many places in your codebase.
 
-## Why does OTel Baggage exist?
+By using
+[Context Propagation](/docs/concepts/signals/traces/#context-propagation) to
+pass baggage across these services, the `clientId` is available to add to any
+additional spans, metrics, or logs. Additionally, instrumentations automatically
+propagate baggage for you.
 
-Baggage provides a uniform way to store and propagate information across a trace
-and other signals. For example, you may want to attach information from your
-application to a span and retrieve that information much later and use it later
-on with another span. However, spans in OpenTelemetry are immutable once
-created, and can be exported before you need information on them later on.
-Baggage allows you to work around this problem by providing a place to store and
-retrieve information.
+![OTel Baggage](/img/otel-baggage.svg)
 
 ## What should OTel Baggage be used for?
 
-Common use cases include information that’s only accessible further up a stack.
-This can include things like Account Identification, User IDs, Product IDs, and
-origin IPs, for example. Passing these down your stack allows you to then add
-them to your Spans in downstream services to make it easier to filter when
-you’re searching in your Observability backend.
+Baggage is best used to include information typically available only at the
+start of a request further downstream. This can include things like Account
+Identification, User IDs, Product IDs, and origin IPs, for example.
+
+Propagating this information using baggage allows for deeper analysis of
+telemetry in a backend. For example, if you include information like a User ID
+on a span that tracks a database call, you can much more easily answer questions
+like "which users are experiencing the slowest database calls?" You can also log
+information about a downstream operation and include that same User ID in the
+log data.
 
 ![OTel Baggage](/img/otel-baggage-2.svg)
 
 ## Baggage security considerations
 
-Sensitive Baggage items could be shared with unintended resources, like
+Sensitive Baggage items can be shared with unintended resources, like
 third-party APIs. This is because automatic instrumentation includes Baggage in
 most of your service’s network requests. Specifically, Baggage and other parts
 of trace context are sent in HTTP headers, making it visible to anyone
@@ -52,22 +58,21 @@ then this risk may not apply, but keep in mind that downstream services could
 propagate Baggage outside your network.
 
 Also, there are no built-in integrity checks to ensure that Baggage items are
-yours, so exercise caution when retrieving them.
+yours, so exercise caution when reading them.
 
-## Baggage is not the same as Span attributes
+## Baggage is not the same as attributes
 
-One important thing to note about Baggage is that it is not a subset of the
-[Span Attributes](/docs/concepts/signals/traces/#attributes). When you add
-something as Baggage, it does not automatically end up on the Attributes of the
-child system’s spans. You must explicitly take something out of Baggage and
-append it as Attributes.
+An important thing to note about baggage is that it is a separate key-value
+store and is unassociated with attributes on spans, metrics, or logs without
+explicitly adding them.
 
-For example, in .NET you might do this:
+To add baggage entries to attributes, you need to explicitly read the data from
+baggage and add it as attributes to your spans, metrics, or logs.
 
-```csharp
-var accountId = Baggage.GetBaggage("AccountId");
-Activity.Current?.SetTag("AccountId", accountId);
-```
+Because a common use cases for Baggage is to add data to
+[Span Attributes](/docs/concepts/signals/traces/#attributes) across a whole
+trace, several languages have Baggage Span Processors that add data from baggage
+as attributes on span creation.
 
 > For more information, see the [baggage specification][].
 

content/ja/docs/concepts/components.md

@@ -0,0 +1,109 @@
+---
+title: コンポーネント
+description: OpenTelemetryを構成する主なコンポーネント
+aliases: [data-collection]
+weight: 20
+default_lang_commit: 313e391
+---
+
+OpenTelemetryは現在、いくつかの主要コンポーネントで構成されています。
+
+- [仕様](#specification)
+- [コレクター](#collector)
+- [言語固有のAPIとSDKの実装](#language-specific-api--sdk-implementations)
+  - [計装ライブラリ](#instrumentation-libraries)
+  - [エクスポーター](#exporters)
+  - [ゼロコード計装](#zero-code-instrumentation)
+  - [リソース検出器](#resource-detectors)
+  - [サービス間プロパゲーター](#cross-service-propagators)
+  - [サンプラー](#samplers)
+- [Kubernetesオペレーター](#kubernetes-operator)
+- [Function as a Serviceアセット](#function-as-a-service-assets)
+
+OpenTelemetryは、テレメトリーデータの生成とエクスポートのためのベンダー固有のSDKとツールを置き換えられます。
+
+## 仕様 {#specification}
+
+仕様はすべての実装に対する言語横断的な要件と想定を記述しています。
+用語の定義だけでなく、この仕様では以下のことが定義されています。
+
+- **API:** トレース、メトリクス、およびロギングデータを生成および相関させるためのデータ型と操作を定義します。
+- **SDK:** 言語固有のAPI実装の要件を定義します。設定、データ処理、エクスポートの概念もここで定義されます。
+- **データ:** OpenTelemetryプロトコル（OTLP）と、テレメトリーバックエンドがサポートできるベンダー非依存のセマンティック規約を定義します。
+
+詳細は、[仕様](/docs/specs/)のページを参照してください。
+
+## コレクター {#collector}
+
+OpenTelemetryコレクターは、テレメトリーデータを受信、処理、エクスポートできる、ベンダー非依存のプロキシーです。
+複数のフォーマット（たとえば、OTLP、Jaeger、Prometheus、および多くの商用/独自ツール）でテレメトリーデータを受信し、1つ以上のバックエンドにデータを送信します。
+また、テレメトリーデータをエクスポートする前の処理やフィルタリングもサポートします。
+
+詳細は、[コレクター](/docs/collector/)のページを参照してください。
+
+## 言語固有のAPIとSDKの実装 {#language-specific-api--sdk-implementations}
+
+OpenTelemetryには言語SDKもあります。このSDKによってOpenTelemetryAPIを使って、選択した言語でテレメトリーデータを生成し、そのデータを好みのバックエンドにエクスポートできます。
+これらのSDKはまた、あなたのアプリケーションでの手動計装に接続するために使える、一般的なライブラリとフレームワーク用の計装ライブラリも組み込めます。
+
+詳細は、[計装](/docs/concepts/instrumentation/)のページを参照してください。
+
+### 計装ライブラリ {#instrumentation-libraries}
+
+OpenTelemetry は、サポートされている言語の一般的なライブラリやフレームワークから関連するテレメトリーデータを生成する、幅広い数のコンポーネントをサポートしています。
+たとえば、HTTPライブラリからのインバウンドとアウトバウンドのHTTPリクエストは、それらのリクエストに関するデータを生成します。
+
+OpenTelemetryの意欲的なゴールは、すべての一般的なライブラリがデフォルトでオブザーバビリティがあるようにビルドされることです。
+
+詳細は、[計装ライブラリ](/docs/concepts/instrumentation/libraries/)のページを参照してください。
+
+### エクスポーター {#exporters}
+
+{{% docs/languages/exporters/intro %}}
+
+### ゼロコード計装 {#zero-code-instrumentation}
+
+利用できる場合、OpenTelemetryの言語固有の実装は、ソースコードに触れることなくアプリケーションを計装する方法を提供します。
+基礎となる仕組みは言語に依存しますが、ゼロコード計装は、アプリケーションにOpenTelemetry API と SDK の機能を追加します。
+さらに、計装ライブラリのセットとエクスポーターの依存関係を追加するかもしれません。
+
+詳細は、[ゼロコード計装](/docs/concepts/instrumentation/zero-code/)のページを参照してください。
+
+### リソース検出器 {#resource-detectors}
+
+[リソース](/docs/concepts/resources/)はテレメトリーを生成するエンティティをリソース属性として表します。
+たとえば、Kubernetes上のコンテナで実行されているテレメトリーを生成するプロセスには、Pod名、名前空間、そして場合によってはデプロイメント名があります。
+これらの属性をすべてリソースに含めることができます。
+
+OpenTelemetry の言語固有の実装は、`OTEL_RESOURCE_ATTRIBUTES` 環境変数からのリソース検出と、プロセスのランタイム、サービス、ホスト、オペレーティングシステムのような多くの一般的なエンティティを提供します。
+
+詳細は、[リソース](/docs/concepts/resources/)のページを参照してください。
+
+### サービス間プロパゲーター {#cross-service-propagators}
+
+伝搬は、サービスやプロセス間でデータを移動させる仕組みです。
+トレースに限ったことではありませんが、伝搬により、プロセスやネットワークの境界を越えて任意に分散したサービス間で、トレースはシステムに関する因果情報を構築できます。
+
+ほとんどのユースケースでは、コンテキスト伝搬は計装ライブラリを通じて行われます。
+必要であれば、スパンのコンテキストや[バゲッジ](/docs/concepts/signals/baggage/)のような横断的な関心事をシリアライズおよびデシリアライズするために、プロパゲータを使用できます。
+
+### サンプラー {#samplers}
+
+サンプリングは、システムによって生成されるトレースの量を制限するプロセスです。
+OpenTelemetryの各言語固有の実装は、いくつかの[ヘッドサンプラー](/docs/concepts/sampling/#head-sampling)を提供しています。
+
+詳細は、[サンプリング](/docs/concepts/sampling)のページを参照してください。
+
+## Kubernetesオペレーター {#kubernetes-operator}
+
+OpenTelemetryオペレーターはKubernetesオペレーターの実装です。
+オペレーターはOpenTelemetryコレクターを管理し、OpenTelemetryを使用してワークロードの自動計装を行います。
+
+詳細は、[K8sオペレーター](/docs/kubernetes/operator/)のページを参照してください。
+
+## Function as a Serviceアセット {#function-as-a-service-assets}
+
+OpenTelemetryは、さまざまなクラウドベンダーが提供する Function-as-a-Service を監視するさまざまな方法をサポートしています。
+OpenTelemetryコミュニティは、現在、アプリケーションを自動計装できるビルド済みのLambdaレイヤーと、アプリケーションを手動または自動で計装する際に使用できるスタンドアロンのコレクターLambdaレイヤーのオプションを提供しています。
+
+詳細は、[Functions as a Service](/docs/faas/)のページを参照してください。

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

@@ -0,0 +1,33 @@
+---
+title: コンテキスト伝搬
+weight: 10
+description: 分散トレーシングを可能にする概念について学ぶ
+default_lang_commit: 313e391
+---
+
+コンテキスト伝搬により、[シグナル](/docs/concepts/signals)は、それらが生成された場所に関係なく、互いを相関させられます。
+トレースに限ったことではありませんが、コンテキスト伝搬によって、[トレース](/docs/concepts/signals/traces)は、プロセスやネットワークの境界を越えて任意に分散しているサービス間で、システムに関する因果情報を構築できます。
+
+コンテキストの伝播を理解するには、コンテキストと伝搬（プロパゲーション）という、2つの別々の概念を理解する必要があります。
+
+## コンテキスト
+
+コンテキストは、送受信サービスまたは[実行ユニット](/docs/specs/otel/glossary/#execution-unit)が、あるシグナルと別のシグナルを関連付けるための情報を含むオブジェクトです。
+
+たとえば、サービスAがサービスBを呼び出した場合、IDがコンテキスト内にあるサービスAのスパンは、サービスBで次に作成されるスパンの親スパンとして使用されます。
+コンテキスト内にあるトレースIDは、サービスBで次に作成されるスパンにも使用されるため、そのスパンはサービスAのスパンと同じトレースの一部であることを意味します。
+
+## 伝搬（プロパゲーション）
+
+伝搬は、サービスとプロセス間でコンテキストを移動させる仕組みです。
+コンテキストオブジェクトをシリアライズまたはデシリアライズし、あるサービスから別のサービスに伝搬される関連情報を提供します。
+
+伝播は通常、計装ライブラリによって処理され、ユーザーには透過的です。
+手動でコンテキストを伝播する必要がある場合は、伝搬APIを使用できます。
+
+OpenTelemetryはいくつかの公式プロパゲーターを保守しています。
+デフォルトのプロパゲーターは[W3C TraceContext](https://www.w3.org/TR/trace-context/)仕様で指定されたヘッダーを使用しています。
+
+## 仕様
+
+コンテキスト伝搬の詳細については、[コンテキストの仕様](/docs/specs/otel/context/)を参照してください。

data/ecosystem/adopters.yaml

@@ -86,7 +86,8 @@
 - name: Sicredi
   url: https://www.sicredi.com.br/
   components: [Collector, Go, Java, Python]
-  reference: ''
+  reference: https://medium.com/sicreditech/sicredis-path-for-opentelemetry-adoption-3564fc8a743a
+  referenceTitle: blog post
   contact: https://github.com/igorestevanjasinski
 - name: Skyscanner
   url: https://www.skyscanner.net/

data/ecosystem/distributions.yaml

@@ -83,3 +83,15 @@
   url: https://github.com/Azure/azure-sdk-for-python/tree/main/sdk/monitor/azure-monitor-opentelemetry
   docsUrl: https://learn.microsoft.com/azure/azure-monitor/app/opentelemetry-enable?tabs=python
   components: [Python]
+- name: Elastic Distribution for OpenTelemetry Java
+  url: https://github.com/elastic/elastic-otel-java
+  docsUrl: https://github.com/elastic/elastic-otel-java
+  components: [Java]
+- name: Elastic Distribution for OpenTelemetry .NET
+  url: https://github.com/elastic/elastic-otel-dotnet
+  docsUrl: https://github.com/elastic/elastic-otel-dotnet
+  components: [.NET]
+- name: Elastic Distribution for OpenTelemetry Node.js
+  url: https://github.com/elastic/elastic-otel-node
+  docsUrl: https://github.com/elastic/elastic-otel-node
+  components: [Node]

data/registry/exporter-js-instana.yml

@@ -15,4 +15,4 @@ createdAt: 2022-04-18
 package:
   registry: npm
   name: '@instana/opentelemetry-exporter'
-  version: 3.14.0
+  version: 3.14.1

static/refcache.json

@@ -2647,6 +2647,18 @@
     "StatusCode": 200,
     "LastSeen": "2024-01-18T20:05:36.185289-05:00"
   },
+  "https://github.com/elastic/elastic-otel-dotnet": {
+    "StatusCode": 200,
+    "LastSeen": "2024-06-26T13:02:09.356344196Z"
+  },
+  "https://github.com/elastic/elastic-otel-java": {
+    "StatusCode": 200,
+    "LastSeen": "2024-06-26T13:02:12.110420884Z"
+  },
+  "https://github.com/elastic/elastic-otel-node": {
+    "StatusCode": 200,
+    "LastSeen": "2024-06-26T13:02:15.527574357Z"
+  },
   "https://github.com/ent/ent/issues/1232#issuecomment-1200405070": {
     "StatusCode": 200,
     "LastSeen": "2024-02-24T14:33:06.756997-08:00"
@@ -5727,6 +5739,10 @@
     "StatusCode": 200,
     "LastSeen": "2024-01-18T19:02:09.258083-05:00"
   },
+  "https://medium.com/sicreditech/sicredis-path-for-opentelemetry-adoption-3564fc8a743a": {
+    "StatusCode": 200,
+    "LastSeen": "2024-06-25T12:05:30.755315709Z"
+  },
   "https://medium.com/velotio-perspectives/a-comprehensive-tutorial-to-implementing-opentracing-with-jaeger-a01752e1a8ce": {
     "StatusCode": 200,
     "LastSeen": "2024-01-18T08:06:14.054263-05:00"