Merge branch 'main' into svrnm-patch-3

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

@@ -0,0 +1,35 @@
+---
+title: 計装
+description: OpenTelemetryはどのように計装を促進するか
+weight: 15
+default_lang_commit: d8c5612
+---
+
+システムを観測可能にするためには、システムが **計装** されなければなりません。
+つまり、システムコンポーネントのコードが[トレース](/docs/concepts/signals/traces/)、[メトリクス](/docs/concepts/signals/metrics/)、[ログ](/docs/concepts/signals/logs/)といったテレメトリーシグナルを送出しなければなりません。
+
+OpenTelemetry を使えば、主に2つの方法でコードを計装できます。
+
+1. 公式の[各言語向けのAPIとSDK](/docs/languages/)を使った[コードベースソリューション](/docs/concepts/instrumentation/code-based)
+2. [ゼロコードソリューション](/docs/concepts/instrumentation/zero-code/)
+
+**コードベース** ソリューションは、より深い洞察とリッチなテレメトリーをアプリケーション自身から得ることを可能にします。
+OpenTelemetry APIを使ってアプリケーションからテレメトリーを生成でき、ゼロコードソリューションによって生成されたテレメトリーを補完する重要な役割を果たします。
+
+**ゼロコード** ソリューションは、テレメトリーの取得を初めて行うときや、テレメトリーを取得する必要のあるアプリケーションを修正できない時に最適です。
+それらは、あなたが使用しているライブラリや、アプリケーションが動作している環境から、豊富なテレメトリーを提供します。
+別の考え方をすれば、アプリケーションの _エッジで_ 何が起こっているかについての情報を提供する、ということです。
+
+両方のソリューションを同時に使うこともできます。
+
+## OpenTelemetryのその他の利点 {#additional-opentelemetry-benefits}
+
+OpenTelemetryが提供するのは、ゼロコードやコードベースのテレメトリーソリューションだけではありません。
+以下のものもOpenTelemetryの一部です。
+
+- ライブラリは依存関係として OpenTelemetry API を活用することができ、OpenTelemetry SDK がインポートされない限り、そのライブラリを使用するアプリケーションに影響はありません。
+- それぞれの[シグナル](/docs/concepts/signals)(トレース、メトリクス、ログ)に対して、それらを作成、処理、エクスポートするためのいくつかの方法が用意されています。
+- [コンテキスト伝播](/docs/concepts/context-propagation)が実装に組み込まれているので、シグナルがどこで生成されたかに関係なく、シグナルを相関させられます。
+- [リソース](/docs/concepts/resources)と[計装スコープ](/docs/concepts/instrumentation-scope)は、[ホスト](/docs/specs/semconv/resource/host/)、[オペレーティングシステム](/docs/specs/semconv/resource/os/)、[Kubernetesクラスター](/docs/specs/semconv/resource/k8s/#cluster)のように、異なるエンティティごとにシグナルをグループ化できます。
+- APIとSDKの各言語固有の実装は、[OpenTelemetry仕様](/docs/specs/otel/)の要件と期待に従います。
+- [セマンティック規約](/docs/concepts/semantic-conventions)は、コードベースやプラットフォーム間で標準化のために使用できる共通の命名スキーマを提供します。

content/ja/docs/concepts/instrumentation/code-based.md

@@ -0,0 +1,49 @@
+---
+title: コードベース
+description: コードベース計装のセットアップに不可欠なステップを学ぶ
+weight: 20
+cSpell:ignore: proxying
+default_lang_commit: d8c5612
+---
+
+## OpenTelemetry APIとSDKをインポートする {#import-the-opentelemetry-api-and-sdk}
+
+まず、あなたのサービスコードに OpenTelemetry をインポートする必要があります。
+もし、実行可能なバイナリによって消費されることを意図したライブラリやその他のコンポーネントを開発しているのであれば、APIにだけ依存することになるでしょう。
+アーティファクトがスタンドアロンのプロセスやサービスであれば、APIとSDKに依存することになります。
+OpenTelemetry APIとSDKの詳細については、[仕様](/docs/specs/otel/)を参照してください。
+
+## OpenTelemetry API を設定する {#configure-the-opentelemetry-api}
+
+トレースやメトリクスを作成するには、まずトレーサーやメーターのプロバイダーを作成する必要があります。
+一般的に、SDKはこれらのオブジェクトに対して単一のデフォルトプロバイダーを提供することを推奨します。
+次に、そのプロバイダーからトレーサーまたはメーターのインスタンスを取得し、名前とバージョンを与えます。
+たとえばライブラリを書いているのであれば、ライブラリの名前（たとえば `com.example.myLibrary`）を付けるべきです。
+また、ライブラリやサービスの現在のバージョンに対応するバージョン文字列（例：`semver:1.0.0`）を指定することを推奨します。
+
+## OpenTelemetry SDK を設定する {#configure-the-opentelemetry-sdk}
+
+サービスプロセスを構築している場合、テレメトリーデータを解析バックエンドにエクスポートするための適切なオプションをSDKに設定する必要もあります。
+この設定は、設定ファイルまたはその他のメカニズムを通じてプログラムで処理することを推奨します。
+また、場合によっては使いたくなるであろう、言語ごとのチューニングオプションもあります。
+
+## テレメトリーデータの作成 {#create-telemetry-data}
+
+APIとSDKを設定したら、プロバイダーから取得したトレーサーオブジェクトとメーターオブジェクトを通して、トレースとメトリックイベントを自由に作成できるようになります。
+依存関係のために計装ライブラリを利用しましょう。これらの詳細については、[レジストリ](/ecosystem/registry/) やあなたの言語のレポジトリをチェックしてください。
+
+## データのエクスポート {#export-data}
+
+テレメトリーデータを作成したら、それをどこかに送信したいでしょう。
+OpenTelemetryは、プロセスから分析バックエンドにデータをエクスポートする2つの主要な方法をサポートしています。
+プロセスから直接エクスポートするか、[OpenTelemetryコレクター](/docs/collector)を通してプロキシする方法です。
+
+プロセス内からのエクスポートでは、1つ以上の _エクスポーター_ をインポートして依存する必要があります。
+エクスポーターとは、OpenTelemetry のメモリ内のスパンやメトリクスオブジェクトを、JaegerやPrometheusのようなテレメトリー分析ツールに適したフォーマットに変換するライブラリです。
+さらに、OpenTelemetry は `OTLP` として知られるワイヤプロトコルをサポートしていて、これはすべての OpenTelemetry SDK でサポートされています。
+このプロトコルは、OpenTelemetryコレクターにデータを送るために使用できます。
+OpenTelemetryコレクターはスタンドアローンのバイナリプロセスで、サービスインスタンスのプロキシやサイドカーとして実行したり、別のホストで実行したりできます。
+コレクターは、このデータを転送し、好きな分析ツールにエクスポートするように設定できます。
+
+JaegerやPrometheusのようなオープンソースツールに加えて、OpenTelemetryからのテレメトリデータの取り込みをサポートする企業のリストが増えています。
+詳細は、[ベンダー](/ecosystem/vendors/)のページを参照してください。