From dabcdbd44c8fb3f9c49c7459e5c2fa09e58cd030 Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Wed, 3 Jul 2024 11:08:50 +0900 Subject: [PATCH 01/10] feat: add trace --- content/ja/docs/concepts/signals/_index.md | 14 + content/ja/docs/concepts/signals/traces.md | 339 +++++++++++++++++++++ 2 files changed, 353 insertions(+) create mode 100644 content/ja/docs/concepts/signals/_index.md create mode 100644 content/ja/docs/concepts/signals/traces.md diff --git a/content/ja/docs/concepts/signals/_index.md b/content/ja/docs/concepts/signals/_index.md new file mode 100644 index 000000000000..1b81f2288404 --- /dev/null +++ b/content/ja/docs/concepts/signals/_index.md @@ -0,0 +1,14 @@ +--- +title: シグナル +description: OpenTelemetryがサポートするテレメトリーのカテゴリについて学ぶ +weight: 11 +default_lang_commit: 9b5e318 +--- + +OpenTelemetryの目的は、**[シグナル][]** を収集、処理、エクスポートすることです。 +シグナルは、オペレーティングシステムやプラットフォーム上で動作しているアプリケーションの基本的な活動を記述するシステム出力です。 +シグナルは、温度やメモリ使用量のような特定の時点で測定したいもの、またはあなたが追跡したい分散システムのコンポーネントを通過するイベントです。 +異なるシグナルをグループ化して、同じテクノロジーの内部動作を異なる角度から観察することもできる。 + +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/oteps/blob/main/text/profiles/0212-profiling-vision.md)です。 diff --git a/content/ja/docs/concepts/signals/traces.md b/content/ja/docs/concepts/signals/traces.md new file mode 100644 index 000000000000..55cea6f0d1a6 --- /dev/null +++ b/content/ja/docs/concepts/signals/traces.md @@ -0,0 +1,339 @@ +--- +title: トレース +weight: 1 +cSpell:ignore: Guten +description: アプリケーションを通過するリクエストの経路 +default_lang_commit: 9b5e318 +--- + +**トレース** は、リクエストがアプリケーションに投げられたときに何が起こるかの全体像を教えてくれます。 +あなたのアプリケーションが、単一のデータベースを持つモノリスであろうと、洗練されたメッシュサービスであろうと、トレースは、リクエストがアプリケーションの中でたどる完全な「経路」を理解するために不可欠です。 + +[スパン](#spans)で表現される以下の3つの塊で、これを探ってみましょう。 + +{{% alert title="Note" %}} + +以下のJSONの例は、特定のフォーマット、特に[OTLP/JSON](/docs/specs/otlp/#json-protobuf-encoding)を表すものではありません。OTLP/JSONは、より冗長です。 + +{{% /alert %}} + +`hello` スパン + +```json +{ + "name": "hello", + "context": { + "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", + "span_id": "0x051581bf3cb55c13" + }, + "parent_id": null, + "start_time": "2022-04-29T18:52:58.114201Z", + "end_time": "2022-04-29T18:52:58.114687Z", + "attributes": { + "http.route": "some_route1" + }, + "events": [ + { + "name": "Guten Tag!", + "timestamp": "2022-04-29T18:52:58.114561Z", + "attributes": { + "event_attributes": 1 + } + } + ] +} +``` + +これはルートスパンであり、オペレーション全体の始まりと終わりを示します。 +トレースを示す `trace_id` フィールドがありますが、`parent_id` がないことに注意してください。 +これがルートスパンであることを示します。 + +`hello-greetings` スパン + +```json +{ + "name": "hello-greetings", + "context": { + "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", + "span_id": "0x5fb397be34d26b51" + }, + "parent_id": "0x051581bf3cb55c13", + "start_time": "2022-04-29T18:52:58.114304Z", + "end_time": "2022-04-29T22:52:58.114561Z", + "attributes": { + "http.route": "some_route2" + }, + "events": [ + { + "name": "hey there!", + "timestamp": "2022-04-29T18:52:58.114561Z", + "attributes": { + "event_attributes": 1 + } + }, + { + "name": "bye now!", + "timestamp": "2022-04-29T18:52:58.114585Z", + "attributes": { + "event_attributes": 1 + } + } + ] +} +``` + +このスパンは、挨拶のような特定のタスクをカプセル化していて、その親は `hello` スパンです。 +このスパンはルートスパンと同じ `trace_id` を共有していて、同じトレースの一部であることを示しています。 +さらに、 `hello` スパンの `span_id` と一致する `parent_id` を持っています。 + +`hello-salutations` スパン + +```json +{ + "name": "hello-salutations", + "context": { + "trace_id": "0x5b8aa5a2d2c872e8321cf37308d69df2", + "span_id": "0x93564f51e1abe1c2" + }, + "parent_id": "0x051581bf3cb55c13", + "start_time": "2022-04-29T18:52:58.114492Z", + "end_time": "2022-04-29T18:52:58.114631Z", + "attributes": { + "http.route": "some_route3" + }, + "events": [ + { + "name": "hey there!", + "timestamp": "2022-04-29T18:52:58.114561Z", + "attributes": { + "event_attributes": 1 + } + } + ] +} +``` + +このスパンはこのトレースにおける3つ目の操作を表し、前のスパンと同様に`hello`スパンの子です。 +また、`hello-greetings`スパンの兄弟でもあります。 + +これらの3つのJSONブロックはすべて同じ `trace_id` を共有していて、`parent_id` フィールドは階層を表しています。 +これはトレースになる！ + +もうひとつ、各スパンが構造化されたログのように見えることにお気づきでしょう。 +それはその通りだからです！トレースについて考える一つの方法は、トレースはコンテキスト、相関関係、階層構造などを持つ構造化されたログの集まりであるということです。 +しかし、これらの「構造化されたログ」は、異なるプロセス、サービス、VM、データセンターなどから来る可能性があります。 +これにより、トレースはあらゆるシステムのエンドツーエンドのビューを表現できます。 + +OpenTelemetryでのトレースがどのように機能するかを理解するために、コードの計装の一翼を担う一連のコンポーネントを見てみましょう。 + +## トレーサープロバイダー + +トレーサープロバイダー（`TracerProvider` と呼ばれることもあります）は `トレーサー` のファクトリーです。 +ほとんどのアプリケーションでは、トレーサープロバイダーは一度初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。 +トレーサープロバイダーの初期化には、リソースとエクスポータの初期化も含まれます。 +これは通常、OpenTelemetry によるトレースの最初のステップです。 +いくつかの言語SDKでは、グローバルなトレーサープロバイダーがすでに初期化されています。 + +## トレーサー + +トレーサーは、サービス内のリクエストなど、与えられた操作で何が起こっているかについての詳細な情報を含むスパンを作成します。 +トレーサーはトレーサープロバイダーから作成されます。 + +## トレースエクスポーター + +トレースエクスポーターはトレースをコンシューマーに送信します。 +このコンシューマーは、デバッグや開発時間用の標準出力、OpenTelemetryコレクター、あるいは任意のオープンソースやベンダーのバックエンドです。 + +## コンテキスト伝搬 + +コンテキスト伝搬（プロパゲーション）は、分散トレースを可能にする中心となる概念です。 +コンテキスト伝搬を使用すると、スパンがどこで生成されたかに関係なく、スパンを相互に関連付け、トレースとして組み立てられます。 +このトピックについては、[コンテキスト伝搬](/docs/concepts/context-propagation)の概要を参照してください。 + +## スパン + +**スパン** は、作業や操作の単位を表します。 +スパンはトレースの構成要素です。 +OpenTelemetryでは、以下の情報を含みます。 + +- 名前 +- 親のスパンID（ルートスパンなら空） +- 開始と終了のタイムスタンプ +- [スパンコンテキスト](#span-context) +- [属性](#attributes) +- [スパンイベント](#span-events) +- [スパンリンク](#span-links) +- [スパンステータス](#span-status) + +次はスパンの例です。（訳注：JSON形式で表現しているだけで、必ずしもJSONではありません） + +```json +{ + "name": "/v1/sys/health", + "context": { + "trace_id": "7bba9f33312b3dbb8b2c2c62bb7abe2d", + "span_id": "086e83747d0e381e" + }, + "parent_id": "", + "start_time": "2021-10-22 16:04:01.209458162 +0000 UTC", + "end_time": "2021-10-22 16:04:01.209514132 +0000 UTC", + "status_code": "STATUS_CODE_OK", + "status_message": "", + "attributes": { + "net.transport": "IP.TCP", + "net.peer.ip": "172.17.0.1", + "net.peer.port": "51820", + "net.host.ip": "10.177.2.152", + "net.host.port": "26040", + "http.method": "GET", + "http.target": "/v1/sys/health", + "http.server_name": "mortar-gateway", + "http.route": "/v1/sys/health", + "http.user_agent": "Consul Health Check", + "http.scheme": "http", + "http.host": "10.177.2.152:26040", + "http.flavor": "1.1" + }, + "events": [ + { + "name": "", + "message": "OK", + "timestamp": "2021-10-22 16:04:01.209512872 +0000 UTC" + } + ] +} +``` + +スパンは、親スパンIDの存在によって暗示されるように、入れ子にできます。 +これによって、スパンはアプリケーションで行われる作業をより正確に把握できます。 + +### スパンコンテキスト + +スパンコンテキストは、各スパンの不変オブジェクトであり、以下を含みます。 + +- スパンが属するトレースを表すトレースID +- スパンのスパンID +- トレースフラグ。これはトレースに関する情報を含むバイナリエンコーディングです。 +- ベンダ固有のトレース情報を保持するキーと値のペアのリスト + +スパンコンテキストは、[分散コンテキスト](#context-propagation)や[バゲッジ](/docs/concepts/signals/baggage)と共にシリアライズされ、伝搬されるスパンの一部です。 + +スパンコンテキストにはトレースIDが含まれているため、[スパンリンク](#span-links)を作成する際に使用されます。 + +### 属性 + +属性（アトリビュート）はキーと値のペアで、スパンに注釈を付けるためのメタデータを含んでいます。このメタデータは追跡している操作に関する情報を伝えるためのものです。 + +たとえば、eコマースシステムでユーザーのショッピングカートに商品を追加する操作をスパンが追跡する場合、ユーザーのID、カートに追加する商品のID、カートIDを取得できます。 + +スパンには、スパン作成中または作成後に属性を追加できます。 +SDKサンプリングで属性を利用できるようにするには、スパン作成時に属性を追加することをおすすめします。 +スパン作成後に値を追加する必要がある場合は、その値でスパンを更新してください。 + +属性には、各言語SDKが実装する以下のルールがあります。 + +- キーは非NULL文字列値でなければならない +- 値は、非NULL文字列、ブール値、浮動小数点値、整数、またはこれらの値の配列でなければならない + +さらに、[セマンティック属性](/docs/specs/semconv/general/trace/)があり、これは一般的な操作に通常存在するメタデータのための既知の命名規則です。 +システム間で共通の種類のメタデータが標準化されるように、可能な限りセマンティック属性の命名を使用することは有用です。 + +### スパンイベント + +スパンイベントは、スパン上の構造化ログメッセージ（または注釈）と考えられます。通常、スパンの期間中、意味のある特異な時点を示すために使われます。 + +たとえば、ウェブブラウザでの2つのシナリオを考えてみましょう。 + +1. ページ読み込みの追跡 +2. ページがインタラクティブになるタイミングを示す + +スパンは、開始と終了がある操作なので、最初のシナリオに最も適しています。 + +スパンイベントは、意味のある特定の時点を表すため、2つ目のシナリオを追跡するのに最も適しています。 + +#### スパンイベントとスパン属性の使い分け + +スパンイベントにも属性が含まれるため、属性のかわりにいつイベントを使用するかという質問には、必ずしも明白な答えがあるとは限りません。 +決定するための参考として、特定のタイムスタンプに意味があるかどうかを考えてみてください。 + +たとえば、スパンで操作を追跡していて、操作が完了した時、操作からのデータをテレメトリーに追加したいと思うかもしれません。 + +- 操作が完了したタイムスタンプに意味がある場合、または関連性がある場合は、データをスパンイベントに添付する。 +- タイムスタンプに意味がない場合は、スパン属性としてデータを添付する。 + +### スパンリンク + +リンクは、あるスパンと別の1つ以上のスパンを関連付け、因果関係を示唆するために存在します。 +たとえば、ある操作がトレースによって追跡される分散システムがあるとしましょう。 + +これらの操作のいくつかに対して、追加の操作がキューに入れられ実行されますが、その実行は非同期です。 +この後続の操作もトレースで追跡できます。 + +後続の操作のトレースを最初のトレースに関連付けたいと思っても、後続の操作がいつ始まるかは予測できません。 +この2つのトレースを関連付ける必要があるので、スパンリンクを使用します。 + +最初のトレースの最後のスパンを、2番目のトレースの最初のスパンにリンクできます。 +これで、これらのスパンは互いに因果関係があることになります。 + +リンクは必須ではありませんが、トレーススパン同士を関連付ける良い方法として役立ちます。 + +### スパンステータス + +各スパンにはステータスがあります。可能な値は以下の3つです。 + +- `Unset` +- `Error` +- `Ok` + +デフォルト値は `Unset` です。 +スパンのステータスが `Unset` である場合は、追跡した操作がエラーなしで正常に完了したということです。 + +スパンのステータスが `Error` である場合、そのスパンが追跡する操作で何らかのエラーが発生したことを意味します。 +たとえば、リクエストを処理するサーバーでHTTP 500エラーが発生した場合などです。 + +スパンのステータスが `Ok` である場合、そのスパンはアプリケーションの開発者によって明示的にエラーなしとマークされたことを意味します。 +これは直感的ではありませんが、スパンがエラーなく完了したことが分かっている場合、スパンのステータスを `Ok` とする必要はありません。 +これは `Unset` でカバーされるからです。 +`Ok`は、ユーザーによって明示的に設定されたスパンのステータスの明確な「最終決定」を表すものです。 +これは、開発者がスパンの解釈を「成功した」以外のものにはしないことを望む場合に役立ちます。 + +もう一度確認します。 +`Unset` はエラーなしで完了したスパンを表します。 +`Ok` は、開発者が明示的にスパンを成功とマークした場合を表します。 +ほとんどの場合、スパンを明示的に `Ok` とマークする必要はありません。 + +### スパンの種類（SpanKind） + +スパンが作成されると、`Client（クライアント）`、 `Server（サーバー）`、 `Internal（内部）`、 `Producer（プロデューサー）`、 `Consumer（コンシューマー）` のいずれかとなります。 +このスパンの種類は、トレースがどのように組み立てられるべきかのヒントをトレースバックエンドに提供します。 +OpenTelemetryの仕様によると、サーバースパンの親はリモートクライアントスパンであることが多く、クライアントスパンの子は通常サーバースパンです。 +同様に、コンシューマースパンの親は、常にプロデューサであり、プロデューサースパンの子は、常にコンシューマである。提供されない場合、スパンの種類は内部的なものとみなされます。 + +SpanKindの詳細については、[SpanKind](/docs/specs/otel/trace/api/#spanKind)を参照してください。 + +#### Client（クライアント） + +クライアントスパンは、発信HTTPリクエストやデータベース呼び出しのような、同期的な発信リモート呼び出しを表します。 +この文脈では、「同期」は `async/await` を指すのではなく、後の処理のためにキューに入れることが出来ない、ということを指すことに注意してください。 + +#### Server（サーバー） + +サーバースパンは、HTTPリクエストやリモートプロシージャコールのような、 同期的に着信するリモートコールを表します。 + +#### Internal（内部） + +内部スパンは、プロセス境界を越えない操作を表します。 +関数呼び出しやNode.jsのExpressミドルウェアの計装などで、内部スパンを使用することがあります。 + +#### Producer（プロデューサー） + +プロデューサースパンは、後で非同期に処理される可能性のあるジョブの作成を表します。 +それは、ジョブキューに挿入されるようなリモートジョブかもしれないし、イベントリスナーによって処理されるローカルジョブかもしれません。 + +#### Consumer（コンシューマー） + +コンシューマースパンは、プロデューサーが作成したジョブの処理を表し、プロデューサースパンがすでに終了したずっと後に開始されることがあります。 + +## 仕様 + +詳細は[トレース仕様](/docs/specs/otel/overview/#tracing-signal)を参照してください。 From d26fcf71b719f1249fe65d7ca1bc825d25784c6e Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Wed, 3 Jul 2024 13:31:40 +0900 Subject: [PATCH 02/10] fix: add section hashes --- content/ja/docs/concepts/signals/traces.md | 36 +++++++++++----------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/content/ja/docs/concepts/signals/traces.md b/content/ja/docs/concepts/signals/traces.md index 55cea6f0d1a6..a604d3e13675 100644 --- a/content/ja/docs/concepts/signals/traces.md +++ b/content/ja/docs/concepts/signals/traces.md @@ -9,7 +9,7 @@ default_lang_commit: 9b5e318 **トレース** は、リクエストがアプリケーションに投げられたときに何が起こるかの全体像を教えてくれます。 あなたのアプリケーションが、単一のデータベースを持つモノリスであろうと、洗練されたメッシュサービスであろうと、トレースは、リクエストがアプリケーションの中でたどる完全な「経路」を理解するために不可欠です。 -[スパン](#spans)で表現される以下の3つの塊で、これを探ってみましょう。 +[スパン](#spans)で表現される以下の3つのJSONデータで、これを探ってみましょう。 {{% alert title="Note" %}} @@ -126,7 +126,7 @@ default_lang_commit: 9b5e318 OpenTelemetryでのトレースがどのように機能するかを理解するために、コードの計装の一翼を担う一連のコンポーネントを見てみましょう。 -## トレーサープロバイダー +## トレーサープロバイダー {#tracer-provider} トレーサープロバイダー（`TracerProvider` と呼ばれることもあります）は `トレーサー` のファクトリーです。 ほとんどのアプリケーションでは、トレーサープロバイダーは一度初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。 @@ -134,23 +134,23 @@ OpenTelemetryでのトレースがどのように機能するかを理解する これは通常、OpenTelemetry によるトレースの最初のステップです。 いくつかの言語SDKでは、グローバルなトレーサープロバイダーがすでに初期化されています。 -## トレーサー +## トレーサー {#tracer} トレーサーは、サービス内のリクエストなど、与えられた操作で何が起こっているかについての詳細な情報を含むスパンを作成します。 トレーサーはトレーサープロバイダーから作成されます。 -## トレースエクスポーター +## トレースエクスポーター {#trace-exporters} トレースエクスポーターはトレースをコンシューマーに送信します。 このコンシューマーは、デバッグや開発時間用の標準出力、OpenTelemetryコレクター、あるいは任意のオープンソースやベンダーのバックエンドです。 -## コンテキスト伝搬 +## コンテキスト伝搬 {#context-propagation} コンテキスト伝搬（プロパゲーション）は、分散トレースを可能にする中心となる概念です。 コンテキスト伝搬を使用すると、スパンがどこで生成されたかに関係なく、スパンを相互に関連付け、トレースとして組み立てられます。 このトピックについては、[コンテキスト伝搬](/docs/concepts/context-propagation)の概要を参照してください。 -## スパン +## スパン {#spans} **スパン** は、作業や操作の単位を表します。 スパンはトレースの構成要素です。 @@ -207,7 +207,7 @@ OpenTelemetryでは、以下の情報を含みます。 スパンは、親スパンIDの存在によって暗示されるように、入れ子にできます。 これによって、スパンはアプリケーションで行われる作業をより正確に把握できます。 -### スパンコンテキスト +### スパンコンテキスト {#span-context} スパンコンテキストは、各スパンの不変オブジェクトであり、以下を含みます。 @@ -220,7 +220,7 @@ OpenTelemetryでは、以下の情報を含みます。 スパンコンテキストにはトレースIDが含まれているため、[スパンリンク](#span-links)を作成する際に使用されます。 -### 属性 +### 属性 {#attributes} 属性（アトリビュート）はキーと値のペアで、スパンに注釈を付けるためのメタデータを含んでいます。このメタデータは追跡している操作に関する情報を伝えるためのものです。 @@ -238,7 +238,7 @@ SDKサンプリングで属性を利用できるようにするには、スパ さらに、[セマンティック属性](/docs/specs/semconv/general/trace/)があり、これは一般的な操作に通常存在するメタデータのための既知の命名規則です。 システム間で共通の種類のメタデータが標準化されるように、可能な限りセマンティック属性の命名を使用することは有用です。 -### スパンイベント +### スパンイベント {#span-events} スパンイベントは、スパン上の構造化ログメッセージ（または注釈）と考えられます。通常、スパンの期間中、意味のある特異な時点を示すために使われます。 @@ -261,7 +261,7 @@ SDKサンプリングで属性を利用できるようにするには、スパ - 操作が完了したタイムスタンプに意味がある場合、または関連性がある場合は、データをスパンイベントに添付する。 - タイムスタンプに意味がない場合は、スパン属性としてデータを添付する。 -### スパンリンク +### スパンリンク {#span-links} リンクは、あるスパンと別の1つ以上のスパンを関連付け、因果関係を示唆するために存在します。 たとえば、ある操作がトレースによって追跡される分散システムがあるとしましょう。 @@ -277,7 +277,7 @@ SDKサンプリングで属性を利用できるようにするには、スパ リンクは必須ではありませんが、トレーススパン同士を関連付ける良い方法として役立ちます。 -### スパンステータス +### スパンステータス {#span-status} 各スパンにはステータスがあります。可能な値は以下の3つです。 @@ -302,7 +302,7 @@ SDKサンプリングで属性を利用できるようにするには、スパ `Ok` は、開発者が明示的にスパンを成功とマークした場合を表します。 ほとんどの場合、スパンを明示的に `Ok` とマークする必要はありません。 -### スパンの種類（SpanKind） +### スパンの種類（SpanKind） {#span-kind} スパンが作成されると、`Client（クライアント）`、 `Server（サーバー）`、 `Internal（内部）`、 `Producer（プロデューサー）`、 `Consumer（コンシューマー）` のいずれかとなります。 このスパンの種類は、トレースがどのように組み立てられるべきかのヒントをトレースバックエンドに提供します。 @@ -311,29 +311,29 @@ OpenTelemetryの仕様によると、サーバースパンの親はリモート SpanKindの詳細については、[SpanKind](/docs/specs/otel/trace/api/#spanKind)を参照してください。 -#### Client（クライアント） +#### Client（クライアント） {#client} クライアントスパンは、発信HTTPリクエストやデータベース呼び出しのような、同期的な発信リモート呼び出しを表します。 この文脈では、「同期」は `async/await` を指すのではなく、後の処理のためにキューに入れることが出来ない、ということを指すことに注意してください。 -#### Server（サーバー） +#### Server（サーバー） {#server} サーバースパンは、HTTPリクエストやリモートプロシージャコールのような、 同期的に着信するリモートコールを表します。 -#### Internal（内部） +#### Internal（内部） {#internal} 内部スパンは、プロセス境界を越えない操作を表します。 関数呼び出しやNode.jsのExpressミドルウェアの計装などで、内部スパンを使用することがあります。 -#### Producer（プロデューサー） +#### Producer（プロデューサー） {#producer} プロデューサースパンは、後で非同期に処理される可能性のあるジョブの作成を表します。 それは、ジョブキューに挿入されるようなリモートジョブかもしれないし、イベントリスナーによって処理されるローカルジョブかもしれません。 -#### Consumer（コンシューマー） +#### Consumer（コンシューマー） {#consumer} コンシューマースパンは、プロデューサーが作成したジョブの処理を表し、プロデューサースパンがすでに終了したずっと後に開始されることがあります。 -## 仕様 +## 仕様 {#specification} 詳細は[トレース仕様](/docs/specs/otel/overview/#tracing-signal)を参照してください。 From ee8802d687c2c5f9fcd6f33c21c04e4e7f6944fb Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Wed, 3 Jul 2024 13:32:34 +0900 Subject: [PATCH 03/10] fix: fix target link --- content/ja/docs/concepts/signals/traces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/signals/traces.md b/content/ja/docs/concepts/signals/traces.md index a604d3e13675..d8dcc1b8f2d6 100644 --- a/content/ja/docs/concepts/signals/traces.md +++ b/content/ja/docs/concepts/signals/traces.md @@ -309,7 +309,7 @@ SDKサンプリングで属性を利用できるようにするには、スパ OpenTelemetryの仕様によると、サーバースパンの親はリモートクライアントスパンであることが多く、クライアントスパンの子は通常サーバースパンです。 同様に、コンシューマースパンの親は、常にプロデューサであり、プロデューサースパンの子は、常にコンシューマである。提供されない場合、スパンの種類は内部的なものとみなされます。 -SpanKindの詳細については、[SpanKind](/docs/specs/otel/trace/api/#spanKind)を参照してください。 +SpanKindの詳細については、[SpanKind](/docs/specs/otel/trace/api/#spankind)を参照してください。 #### Client（クライアント） {#client} From fdfde85174385b5e96034612b9743b79bc7a7bd1 Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Wed, 3 Jul 2024 13:39:02 +0900 Subject: [PATCH 04/10] feat: add translation of metrics --- content/ja/docs/concepts/signals/metrics.md | 96 +++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 content/ja/docs/concepts/signals/metrics.md diff --git a/content/ja/docs/concepts/signals/metrics.md b/content/ja/docs/concepts/signals/metrics.md new file mode 100644 index 000000000000..32579ee98e4c --- /dev/null +++ b/content/ja/docs/concepts/signals/metrics.md @@ -0,0 +1,96 @@ +--- +title: メトリクス +weight: 2 +description: 実行時に取得された測定値。 +default_lang_commit: 9b5e318 +--- + +**メトリクス**とは、実行時に取得されるサービスの**測定値**のことです。 +測定値を取得した瞬間は**メトリックイベント**として知られており、測定値そのものだけでなく、キャプチャした時刻と関連するメタデータから構成されます。 + +アプリケーションとリクエストのメトリクスは、可用性とパフォーマンスの重要な指標です。 +カスタムメトリクスは、可用性指標がユーザー体験やビジネスにどのような影響を与えるかについての洞察を提供できます。 +収集したデータを使用して、障害を警告したり、需要が高まったときにデプロイを自動的にスケールアップするスケジューリング決定をトリガしたりできます。 + +OpenTelemetryのメトリクスがどのように機能するのかを理解するために、コードの計装の一部を担うコンポーネントのリストを見てみましょう。 + +## メータープロバイダー {#meter-provider} + +メータープロバイダー（`MeterProvider` と呼ばれることもあります）は、`メーター`のファクトリーです。 +ほとんどのアプリケーションでは、メータープロバイダは一度初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。 +メータープロバイダーの初期化には、リソースとエクスポータの初期化も含まれます。 +これは通常、OpenTelemetryを使った計測の最初のステップです。 +いくつかの言語SDKでは、グローバルなメータープロバイダーがすでに初期化されています。 + +## メーター {#meter} + +メーターは[メトリクス計装](#metric-instruments)を作成し、実行時にサービスに関する測定値を取得します。 +メーターはメータープロバイダーから作成されます。 + +## メトリクスエクスポーター {#metric-exporter} + +メトリクスエクスポーターはメトリクスデータをコンシューマーに送ります。 +このコンシューマーは、開発中のデバッグのための標準出力、OpenTelemetryコレクター、あるいは、あなたが選んだオープンソースやベンダーのバックエンドです。 + +## メトリクス計装 {#metric-instruments} + +OpenTelemetryでは、計測は **メトリクス計装** によって行われます。メトリクス計装は以下のように定義されます。 + +- 名前 +- 種類 +- 単位（オプション） +- 説明（オプション） + +名前、単位、説明は、開発者が自分で定義するか、リクエストやプロセスメトリクスのような一般的なものについては、[セマンティック規約](/docs/specs/semconv/general/metrics/)を介して定義されます。 + +計装の種類は以下のいずれかです。 + +- **Counter（カウンター）**： 時間とともに蓄積される値。これは車のオドメーターのようなものだと考えられます。 +- **Asynchronous Counter（非同期カウンター）**： **カウンター** と同じですが、各エクスポートに対して一度だけ収集されます。 + 連続したインクリメントにアクセスできず、集約された値のみにアクセスできる場合に使用できます。 +- **UpDownCounter（アップダウンカウンター）**: 時間の経過とともに蓄積されるけれども、減少することもある値。 + たとえば、キューの長さは、キュー内のワークアイテムの数によって増減します。 +- **Asynchronous UpDownCounter（非同期アップダウンカウンター）**: **アップダウンカウンター**と同じですが、各エクスポートに対して一度だけ収集されます。 + 連続的な変更にアクセスできず、集約された値（たとえば、現在のキューのサイズ）のみにアクセスできる場合に使用できます。 +- **Gauge（ゲージ）**: 読み取った時点での現在の値を測定します。たとえば、自動車の燃料計など。ゲージは非同期です。 +- **Histogram（ヒストグラム）**: リクエストのレイテンシーなどの値をクライアント側で集約したもの。 + 値の統計に興味がある場合は、ヒストグラムが良いでしょう。 + たとえば、どれくらいのリクエストが1秒未満か、といった疑問に答えてくれます。 + +同期と非同期の計装、またどの種類の計装があなたのユースケースにもっとも適しているかについては、[補足ガイドライン](/docs/specs/otel/metrics/supplementary-guidelines/)を参照してください。 + +## 集約（アグリゲーション） {#aggregation} + +メトリクス計装に加えて、**集約（アグリゲーション）**という概念も理解すべき重要なものです。 +集約とは、多数の測定値を組み合わせて、ある時間ウィンドウの間に発生したメトリクスイベントに関する正確な統計値または推定統計値にする手法です。 +OTLPプロトコルは、このような集約されたメトリクスを伝送します。 +OpenTelemetry APIは、各計装に対してデフォルトの集約を提供します。これはビューを使ってオーバーライドできます。 +OpenTelemetryプロジェクトは、ビジュアライザーやテレメトリーバックエンドでサポートされるデフォルトの集計を提供することを目指しています。 + +[リクエストトレース](/docs/concepts/signals/traces/)が、リクエストのライフサイクルを捕捉し、リクエストの個々の部分にコンテキストを提供することを意図しているのとは異なり、メトリクスは、集約された統計情報を提供することを意図しています。 +メトリクスの使用例には、次のようなものがあります。 + +- プロトコルの種類ごとに、サービスによって読み取られた総バイト数を報告する。 +- 読み込んだ総バイト数とリクエストごとのバイト数を報告する。 +- システムコールの継続時間を報告する。 +- 傾向を把握するためにリクエストサイズを報告する。 +- プロセスのCPUまたはメモリ使用量を報告する。 +- 口座の平均残高値を報告する。 +- 現在処理中のアクティブなリクエストを報告する。 + +## ビュー {#views} + +ビューは、SDKによって出力されるメトリクスをカスタマイズする柔軟性をSDKのユーザーに提供します。 +どのメトリクス計装を処理するか、または無視するかをカスタマイズできます。 +また、集約をカスタマイズしたり、メトリクスにどのような属性をレポートするかをカスタマイズすることもできます。 + +## 言語サポート {#language-support} + +メトリクスはOpenTelemetry仕様の[stable](/docs/specs/otel/versioning-and-stability/#stable)シグナルです。 +Metrics APIとSDKの各言語固有の実装については、ステータスは以下の通りです。 + +{{% signal-support-table "metrics" %}} + +## 仕様 {#specification} + +OpenTelemetryのメトリクスの詳細については、[メトリクス仕様](/docs/specs/otel/overview/#metric-signal)を参照してください。 From 1e5eccbe3196ea3c9eed3e520fd15f48d1ae7172 Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Wed, 3 Jul 2024 14:11:09 +0900 Subject: [PATCH 05/10] feat: add translation of logs --- content/ja/docs/concepts/signals/logs.md | 89 ++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 content/ja/docs/concepts/signals/logs.md diff --git a/content/ja/docs/concepts/signals/logs.md b/content/ja/docs/concepts/signals/logs.md new file mode 100644 index 000000000000..7a606c7028fd --- /dev/null +++ b/content/ja/docs/concepts/signals/logs.md @@ -0,0 +1,89 @@ +--- +title: ログ +weight: 3 +description: イベントの記録 +default_lang_commit: 9b5e318 +--- + +**ログ**は、構造化（推奨）または非構造化された、メタデータを含む、タイムスタンプ付きのテキストレコードです。 +すべてのテレメトリーシグナルの中で、ログは最も大きな遺産を持っています。 +ほとんどのプログラミング言語には、組み込みのログ機能があるか、もしくはよく知られ、広く使われているログライブラリがあります。 +ログは独立したデータソースですが、スパンに添付することもできます。 +OpenTelemetryでは、分散トレースやメトリクスの一部でないデータはすべてログです。 +たとえば、_イベント_ は特定の種類のログです。 +ログは多くの場合、操作への入力、操作の結果、その操作をサポートするメタデータなどの詳細なデバッグ／診断情報を含んでいます。 + +トレースとメトリクスに関して、OpenTelemetryはゼロから設計するアプローチを取り、新しいAPIを指定し、このAPIの完全な実装を複数の言語SDKで提供します。 + +OpenTelemetryのログに対するアプローチは異なります。 +既存のロギングソリューションは、言語や運用のエコシステムに広く普及しているので、OpenTelemetryは、それらのログ、トレースやメトリクスシグナル、そして、他のOpenTelemetryコンポーネント間の「ブリッジ」として機能します。 +実際、ログのためのAPIは、この理由から「Logs Bridge API」と呼ばれています。 + +[ログ仕様][logs specification]には、この哲学の詳細が記載されています。 + +OpenTelemetry でのロギングの仕組みを理解するために、コードの計装の一翼を担うコンポーネントのリストを見てみましょう。 + +## ログアペンダー（Log Appender）／ブリッジ（Bridge） {#log-appender--bridge} + +アプリケーション開発者としては、**Log Bridge API** はログアペンダー/ブリッジを構築するためのロギングライブラリ作者のために提供されているので、直接呼び出すべきではありません。 +かわりに、好みのロギングライブラリを使い、OpenTelemetryのログレコードエクスポーターにログを出力できるログアペンダー（またはログブリッジ）を使うように設定するだけです。 + +OpenTelemetry言語SDKはこの機能を提供します。 + +## ロガープロバイダー {#logger-provider} + +> **Logs Bridge API**の一部であり、ロギングライブラリの作者である場合にのみ使用すべきです。 + +ロガープロバイダー（ `LoggerProvider` と呼ばれることもある）は `ロガー` のファクトリーです。 +ほとんどの場合、ロガープロバイダは一度初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。 +ロガープロバイダーの初期化には、リソースとエクスポーターの初期化も含まれます。 + +## ロガー {#logger} + +> **Logs Bridge API**の一部であり、ロギングライブラリの作者である場合にのみ使用すべきです。 + +ロガーはログレコードを作成します。ロガーはログプロバイダーから作成されます。 + +## ログレコードエクスポーター {#log-record-exporter} + +ログレコードエクスポーターは、ログレコードをコンシューマーに送信します。 +このコンシューマーは、デバッグや開発時間用の標準出力、OpenTelemetryコレクター、あるいは、お好みのオープンソースやベンダーのバックエンドです。 + +## ログレコード {#log-record} + +ログレコードはイベントの記録を表します。 +OpenTelemetryでは、ログレコードには2種類のフィールドがあります。 + +- 特定の型と意味を持つ名前付きトップレベルフィールド +- 任意の値と型のリソースと属性フィールド + +トップレベルのフィールドは以下の通りです。 + +| フィールド名 | 説明 | +| -------------------- | -------------------------------------------- | +| Timestamp | イベントが発生した時刻 | +| ObservedTimestamp | イベントが観測された時刻 | +| TraceId | リクエストトレースID | +| SpanId | リクエストスパンID | +| TraceFlags | W3Cトレースフラグ | +| SeverityText | 重要度テキスト（ログレベルとも呼ばれる） | +| SeverityNumber | 重要度の数値 | +| Body | ログレコードの本文 | +| Resource | ログのソース | +| InstrumentationScope | ログを出力したスコープ | +| Attributes | イベントに関する追加情報 | + +ログレコードとログフィールドの詳細については、[ログデータモデル](/docs/specs/otel/logs/data-model/) を参照してください。 + +## 言語サポート {#language-support} + +ログは OpenTelemetry 仕様の [stable](/docs/specs/otel/versioning-and-stability/#stable) シグナルです。 +ログAPIとSDKの各言語固有の実装については、ステータスは以下の通りです。 + +{{% signal-support-table "logs" %}} + +## 仕様 {#specification} + +OpenTelemetryのログについての詳細は、[ログ仕様][logs specification] を参照してください。 + +[logs specification]: /docs/specs/otel/overview/#log-signal From 3a10830077cc7ee092119bf2005510f1edf3a274 Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Wed, 3 Jul 2024 14:13:41 +0900 Subject: [PATCH 06/10] fix: add link target --- content/ja/docs/concepts/signals/_index.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/content/ja/docs/concepts/signals/_index.md b/content/ja/docs/concepts/signals/_index.md index 1b81f2288404..d136ab668f9e 100644 --- a/content/ja/docs/concepts/signals/_index.md +++ b/content/ja/docs/concepts/signals/_index.md @@ -5,10 +5,12 @@ weight: 11 default_lang_commit: 9b5e318 --- -OpenTelemetryの目的は、**[シグナル][]** を収集、処理、エクスポートすることです。 +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/oteps/blob/main/text/profiles/0212-profiling-vision.md)です。 + +[signals]: /docs/specs/otel/glossary/#signals From 33b48472e9fa88558240471c42bd26d37e119d53 Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Wed, 3 Jul 2024 14:31:24 +0900 Subject: [PATCH 07/10] feat: add translation of baggage --- content/ja/docs/concepts/signals/baggage.md | 57 +++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 content/ja/docs/concepts/signals/baggage.md diff --git a/content/ja/docs/concepts/signals/baggage.md b/content/ja/docs/concepts/signals/baggage.md new file mode 100644 index 000000000000..4ae3982b904e --- /dev/null +++ b/content/ja/docs/concepts/signals/baggage.md @@ -0,0 +1,57 @@ +--- +title: バゲッジ +weight: 4 +description: シグナル間でやり取りされるコンテキスト情報 +default_lang_commit: 9b5e318 +--- + +OpenTelemetryでは、バゲッジ（Baggage）はコンテキストの隣にあるコンテキスト情報です。 +バゲッジはキーバリューストアなので、[コンテキスト](/docs/concepts/context-propagation/#context)と一緒に好きなデータを[伝搬](/docs/concepts/context-propagation/#propagation)できます。 + +バゲッジは、サービスやプロセス間でデータを受け渡し、それらのサービス内の[トレース](/docs/concepts/signals/traces/)、[メトリクス](/docs/concepts/signals/metrics/)、[ログ](/docs/concepts/signals/logs/)に追加できるようにします。 + +## 例 {#example} + +バゲッジは、サービス間で追加データを伝播するためにトレースでよく使用されます。 + +たとえば、リクエストの最初に `clientId` があるとします。 +しかし、そのIDをトレース内のすべてのスパン、別のサービスのいくつかのメトリクス、そして途中のいくつかのログで利用できるようにしたいとします。 +トレースは複数のサービスにまたがる可能性があるため、 `clientId` を多くのサービスにコピーすることなくデータを伝播する方法が必要です。 +`clientId` をコードベースのあちこちにコピーすることなく、そのデータを伝播する方法が必要です。 + +[コンテキスト伝搬](/docs/concepts/signals/traces/#context-propagation)を使用して、これらのサービス間でバゲッジを渡すことで、 `clientId` を追加のスパン、メトリクス、またはログに追加できます。 +さらに、計装は自動的にバゲッジを伝搬してくれます。 + +![OTel Baggage](/img/otel-baggage.svg) + +## OTelバゲッジの使い道 {#what-should-otel-baggage-be-used-for} + +バゲッジは、通常リクエストの開始時にのみ利用可能な情報を、さらに下流に含めるために使用するのが最適です。 +これはたとえば、アカウント識別子、ユーザーID、製品ID、オリジンIPのようなものを含められます。 + +バゲッジを使ってこの情報を伝播することで、バックエンドのテレメトリーをより深く分析できます。 +たとえば、データベース呼び出しを追跡するスパンにユーザーIDのような情報を含めると、「どのユーザーがもっとも遅いデータベース呼び出しを経験しているか」のような質問に、より簡単に答えられます。 +また、下流の操作に関する情報をログに記録し、同じユーザーIDをログデータに含めることもできます。 + +![OTel Baggage](/img/otel-baggage-2.svg) + +## バゲッジのセキュリティに関する懸念事項 {#baggage-security-considerations} + +機密性の高いバゲッジのアイテムは、サードパーティのAPIなど、意図しないリソースと共有される可能性があります。 +これは、自動計装が、サービスのネットワークリクエストのほとんどにバゲッジを含むためです。 +具体的には、バゲッジやトレースコンテキストの他の部分はHTTPヘッダーで送信されるため、ネットワークトラフィックを検査する誰もがそれを見ることができます。 +トラフィックがネットワーク内で制限されている場合は、このリスクは適用されないかもしれませんが、下流のサービスがバゲッジをネットワーク外に伝播する可能性があることに留意してください。 + +また、バゲッジのアイテムがあなたのものであることを確認するための完全性チェックは組み込まれていません。そのため、読み取る際には注意が必要です。 + +## バゲッジは属性とは異なる {#baggage-is-not-the-same-as-attributes} + +バゲッジについて注意すべき重要な点は、バゲッジは独立したキーバリューストアであり、明示的に追加しない限り、スパン、メトリクス、ログの属性と関連付けられないということです。 + +バゲッジの要素を各テレメトリーの属性に追加するには、明示的にバゲッジからデータを読み取り、スパン、メトリクス、またはログに属性として追加する必要があります。 + +バゲッジの一般的な使用例は、トレース全体にわたって[スパン属性](/docs/concepts/signals/traces/#attributes)にデータを追加することなので、いくつかの言語には、スパン作成時にバゲッジからデータを属性として追加するバゲッジスパンプロセッサがあります。 + +> 詳細は[バゲッジ仕様][baggage specification]を参照のこと。 + +[baggage specification]: /docs/specs/otel/overview/#baggage-signal From 641c9fcf126faa7be1f5f1fe19c26e0d90136dde Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Wed, 3 Jul 2024 14:33:22 +0900 Subject: [PATCH 08/10] fix: run prettier to fix format --- content/ja/docs/concepts/signals/logs.md | 26 ++++++++++++------------ 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/content/ja/docs/concepts/signals/logs.md b/content/ja/docs/concepts/signals/logs.md index 7a606c7028fd..56b2a121bebb 100644 --- a/content/ja/docs/concepts/signals/logs.md +++ b/content/ja/docs/concepts/signals/logs.md @@ -59,19 +59,19 @@ OpenTelemetryでは、ログレコードには2種類のフィールドがあり トップレベルのフィールドは以下の通りです。 -| フィールド名 | 説明 | -| -------------------- | -------------------------------------------- | -| Timestamp | イベントが発生した時刻 | -| ObservedTimestamp | イベントが観測された時刻 | -| TraceId | リクエストトレースID | -| SpanId | リクエストスパンID | -| TraceFlags | W3Cトレースフラグ | -| SeverityText | 重要度テキスト（ログレベルとも呼ばれる） | -| SeverityNumber | 重要度の数値 | -| Body | ログレコードの本文 | -| Resource | ログのソース | -| InstrumentationScope | ログを出力したスコープ | -| Attributes | イベントに関する追加情報 | +| フィールド名 | 説明 | +| -------------------- | ---------------------------------------- | +| Timestamp | イベントが発生した時刻 | +| ObservedTimestamp | イベントが観測された時刻 | +| TraceId | リクエストトレースID | +| SpanId | リクエストスパンID | +| TraceFlags | W3Cトレースフラグ | +| SeverityText | 重要度テキスト（ログレベルとも呼ばれる） | +| SeverityNumber | 重要度の数値 | +| Body | ログレコードの本文 | +| Resource | ログのソース | +| InstrumentationScope | ログを出力したスコープ | +| Attributes | イベントに関する追加情報 | ログレコードとログフィールドの詳細については、[ログデータモデル](/docs/specs/otel/logs/data-model/) を参照してください。 From 5a907e3df514e7c66edf9b2203f3b7cd101bd171 Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Thu, 4 Jul 2024 14:29:13 +0900 Subject: [PATCH 09/10] fix: adopted the review comments --- content/ja/docs/concepts/signals/baggage.md | 2 +- content/ja/docs/concepts/signals/metrics.md | 8 ++++---- content/ja/docs/concepts/signals/traces.md | 16 ++++++++-------- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/content/ja/docs/concepts/signals/baggage.md b/content/ja/docs/concepts/signals/baggage.md index 4ae3982b904e..bfb927eceabf 100644 --- a/content/ja/docs/concepts/signals/baggage.md +++ b/content/ja/docs/concepts/signals/baggage.md @@ -12,7 +12,7 @@ OpenTelemetryでは、バゲッジ（Baggage）はコンテキストの隣にあ ## 例 {#example} -バゲッジは、サービス間で追加データを伝播するためにトレースでよく使用されます。 +バゲッジは、トレースで、サービス間で追加データを伝播するためによく使用されます。 たとえば、リクエストの最初に `clientId` があるとします。 しかし、そのIDをトレース内のすべてのスパン、別のサービスのいくつかのメトリクス、そして途中のいくつかのログで利用できるようにしたいとします。 diff --git a/content/ja/docs/concepts/signals/metrics.md b/content/ja/docs/concepts/signals/metrics.md index 32579ee98e4c..1eba182065b2 100644 --- a/content/ja/docs/concepts/signals/metrics.md +++ b/content/ja/docs/concepts/signals/metrics.md @@ -1,7 +1,7 @@ --- title: メトリクス weight: 2 -description: 実行時に取得された測定値。 +description: 実行時に取得された測定値 default_lang_commit: 9b5e318 --- @@ -10,14 +10,14 @@ default_lang_commit: 9b5e318 アプリケーションとリクエストのメトリクスは、可用性とパフォーマンスの重要な指標です。 カスタムメトリクスは、可用性指標がユーザー体験やビジネスにどのような影響を与えるかについての洞察を提供できます。 -収集したデータを使用して、障害を警告したり、需要が高まったときにデプロイを自動的にスケールアップするスケジューリング決定をトリガしたりできます。 +収集したデータを使用して、障害を警告したり、需要が高まったときにデプロイを自動的にスケールアップするスケジューリング決定をトリガーしたりできます。 OpenTelemetryのメトリクスがどのように機能するのかを理解するために、コードの計装の一部を担うコンポーネントのリストを見てみましょう。 ## メータープロバイダー {#meter-provider} -メータープロバイダー（`MeterProvider` と呼ばれることもあります）は、`メーター`のファクトリーです。 -ほとんどのアプリケーションでは、メータープロバイダは一度初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。 +メータープロバイダー（`MeterProvider` と呼ばれることもあります）は、`Meter`のファクトリーです。 +ほとんどのアプリケーションでは、メータープロバイダーは一度だけ初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。 メータープロバイダーの初期化には、リソースとエクスポータの初期化も含まれます。 これは通常、OpenTelemetryを使った計測の最初のステップです。 いくつかの言語SDKでは、グローバルなメータープロバイダーがすでに初期化されています。 diff --git a/content/ja/docs/concepts/signals/traces.md b/content/ja/docs/concepts/signals/traces.md index d8dcc1b8f2d6..d508b8bd89a7 100644 --- a/content/ja/docs/concepts/signals/traces.md +++ b/content/ja/docs/concepts/signals/traces.md @@ -17,7 +17,7 @@ default_lang_commit: 9b5e318 {{% /alert %}} -`hello` スパン +`hello` スパンは次のとおりです。 ```json { @@ -48,7 +48,7 @@ default_lang_commit: 9b5e318 トレースを示す `trace_id` フィールドがありますが、`parent_id` がないことに注意してください。 これがルートスパンであることを示します。 -`hello-greetings` スパン +`hello-greetings` スパンは次のとおりです。 ```json { @@ -82,11 +82,11 @@ default_lang_commit: 9b5e318 } ``` -このスパンは、挨拶のような特定のタスクをカプセル化していて、その親は `hello` スパンです。 +このスパンは、挨拶（`greetings`）のような特定のタスクをカプセル化していて、その親は `hello` スパンです。 このスパンはルートスパンと同じ `trace_id` を共有していて、同じトレースの一部であることを示しています。 さらに、 `hello` スパンの `span_id` と一致する `parent_id` を持っています。 -`hello-salutations` スパン +`hello-salutations` スパンは次のとおりです。 ```json { @@ -117,7 +117,7 @@ default_lang_commit: 9b5e318 また、`hello-greetings`スパンの兄弟でもあります。 これらの3つのJSONブロックはすべて同じ `trace_id` を共有していて、`parent_id` フィールドは階層を表しています。 -これはトレースになる！ +これは1つのトレースになります！ もうひとつ、各スパンが構造化されたログのように見えることにお気づきでしょう。 それはその通りだからです！トレースについて考える一つの方法は、トレースはコンテキスト、相関関係、階層構造などを持つ構造化されたログの集まりであるということです。 @@ -128,9 +128,9 @@ OpenTelemetryでのトレースがどのように機能するかを理解する ## トレーサープロバイダー {#tracer-provider} -トレーサープロバイダー（`TracerProvider` と呼ばれることもあります）は `トレーサー` のファクトリーです。 -ほとんどのアプリケーションでは、トレーサープロバイダーは一度初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。 -トレーサープロバイダーの初期化には、リソースとエクスポータの初期化も含まれます。 +トレーサープロバイダー（`TracerProvider` と呼ばれることもあります）は `Tracer` のファクトリーです。 +ほとんどのアプリケーションでは、トレーサープロバイダーは一度だけ初期化され、そのライフサイクルはアプリケーションのライフサイクルと一致します。 +トレーサープロバイダーの初期化には、リソースとエクスポーターの初期化も含まれます。 これは通常、OpenTelemetry によるトレースの最初のステップです。 いくつかの言語SDKでは、グローバルなトレーサープロバイダーがすでに初期化されています。 From 46e0f3aed89c76aa8f8359ce9908b3c81b11629b Mon Sep 17 00:00:00 2001 From: Yoshi Yamaguchi Date: Thu, 4 Jul 2024 14:33:51 +0900 Subject: [PATCH 10/10] fix: adopted the rest review comments --- content/ja/docs/concepts/signals/traces.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/concepts/signals/traces.md b/content/ja/docs/concepts/signals/traces.md index d508b8bd89a7..90ab6ea4cc3f 100644 --- a/content/ja/docs/concepts/signals/traces.md +++ b/content/ja/docs/concepts/signals/traces.md @@ -224,10 +224,10 @@ OpenTelemetryでは、以下の情報を含みます。 属性（アトリビュート）はキーと値のペアで、スパンに注釈を付けるためのメタデータを含んでいます。このメタデータは追跡している操作に関する情報を伝えるためのものです。 -たとえば、eコマースシステムでユーザーのショッピングカートに商品を追加する操作をスパンが追跡する場合、ユーザーのID、カートに追加する商品のID、カートIDを取得できます。 +たとえば、eコマースシステムでユーザーのショッピングカートに商品を追加する操作をスパンが追跡する場合、ユーザーのID、カートに追加する商品のID、カートIDを捕捉できます。 スパンには、スパン作成中または作成後に属性を追加できます。 -SDKサンプリングで属性を利用できるようにするには、スパン作成時に属性を追加することをおすすめします。 +SDKでのサンプリングで属性を利用できるようにするには、スパン作成時に属性を追加することをおすすめします。 スパン作成後に値を追加する必要がある場合は、その値でスパンを更新してください。 属性には、各言語SDKが実装する以下のルールがあります。