[ja] translate collector/deployment into ja #5900
Conversation
There was a problem hiding this comment.
Thanks for the PR.
Drive-by comment: do not include copies of images (such as content/ja/docs/collector/deployment/gateway/otel-gateway-arch.svg). For details, see Localization > Images.
Also see the errors reported in https://github.com/open-telemetry/opentelemetry.io/actions/runs/12665535073/job/35295361546?pr=5900.
There was a problem hiding this comment.
Thank you, @katzchang. I added requests to confirm nuances and consistency for future translation references.
|
|
||
| OpenTelemetryコレクターは、さまざまな方法で、さまざまなユースケースに使用できる単一のバイナリから構成されています。 | ||
| このセクションでは、デプロイメントパターン、それらのユースケース、および長所と短所、クロス環境およびマルチバックエンドデプロイメントにおけるコレクター設定のベストプラクティスについて説明します。 | ||
| デプロイメントのセキュリティに関する考慮事項については、[コレクターホスティングのベストプラクティス][security]をご参照ください。 |
There was a problem hiding this comment.
なんか硬いので「参照してください」あたりでどうでしょう
| コレクターのエージェントデプロイメントパターンは、OpenTelemetry SDKを使用して[計装された][instrumentation]アプリケーション（[OpenTelemetryプロトコル（OTLP）][otlp]を使用）や、他のコレクター（OTLPエクスポーターを使用）が、テレメトリーシグナルを[コレクター][]インスタンスに送信する構成です。 | ||
| このコレクターインスタンスは、アプリケーションと同じホストまたはアプリケーションの横に配置されたサイドカーやデーモンセットとして動作します。 | ||
|
|
||
| 各クライアント側SDKまたはダウンストリームコレクターは、コレクターの場所を設定します： |
|
|
||
| コレクターのエージェントデプロイメントパターンの具体例は以下のようになります。 | ||
| たとえば、[Javaアプリケーションを計装してメトリクスをエクスポート][instrument-java-metrics]するためにOpenTelemetry Java SDKを使用します。 | ||
| アプリケーションのコンテキスト内で、`OTEL_METRICS_EXPORTER`を`otlp`（デフォルト値）に設定し、[OTLPエクスポーター][otlp-exporter]をコレクターのアドレスで設定します。たとえば（Bashまたは`zsh`シェル）： |
There was a problem hiding this comment.
コロンを「次のように設定します」など適宜日本語に。
| export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4318 | ||
| ``` | ||
|
|
||
| `collector.example.com:4318` で動作するコレクターは次のように設定されます： |
|
|
||
| テレメトリーデータの処理が特定のコレクターで行われる必要があるユースケースでは、2層の設定を使用します。 | ||
| 1層目のコレクターは、[Trace ID/サービス名を意識したロードバランシングエクスポーター][lb-exporter]を使用して設定され、2層目ではスケールアウトを処理するコレクターが使用されます。 | ||
| たとえば、[Tail Samplingプロセッサ][tailsample-processor]を使用する場合、すべてのスパンが同じコレクターインスタンスに到達し、そこでそのサンプリングポリシーが適用されるように、ロードバランシングエクスポーターを使用する必要があります。 |
There was a problem hiding this comment.
カタカナ語でいけるものはカタカナ語な感じでやってるのと、「テイルサンプリング」が他のところで出てるのでカタカナにする方向でどうでしょうか。（固有名詞とするかどうかは悩ましいけど、Kubernetesとかでも割とカタカナにしちゃっているものがあるのでその方向に倣っている）
https://opentelemetry.io/ja/docs/concepts/sampling/#%E3%83%86%E3%82%A4%E3%83%AB%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AA%E3%83%B3%E3%82%B0
| ### ロードバランシングエクスポーター | ||
|
|
||
| コレクターの中央集約型デプロイメントパターンの具体的な例として、まずロードバランシングエクスポーターについて詳しく見ていきましょう。 | ||
| これには2つの主な設定項目があります： |
| - `routing_key`フィールドを使用するとロードバランシングエクスポーターがスパンを特定の下流のコレクターにルーティングするように指示します。 | ||
| このフィールドを`traceID`（デフォルト）に設定すると、ロードバランシングエクスポーターは`traceID`に基づいてスパンをエクスポートします。 | ||
| その他の場合、`routing_key`に`service`を設定すると、サービス名に基づいてスパンをエクスポートします。 | ||
| これは、[Span Metricsコネクター][spanmetrics-connector]のようなコネクターを使用する際に有用で、サービスのすべてのスパンが同じ下流のコレクターに送信され、メトリクス収集が行われ、正確な集約が保証されます。 |
There was a problem hiding this comment.
Span Metricsに関してTail Samplingと同様の悩ましい点があります
|
|
||
| ### ロードバランシングエクスポーター | ||
|
|
||
| コレクターの中央集約型デプロイメントパターンの具体的な例として、まずロードバランシングエクスポーターについて詳しく見ていきましょう。 |
There was a problem hiding this comment.
centralized はLearning OpenTelemetryでは「中央集権」としました
c.f. https://ejje.weblio.jp/content/centralized
| 長所： | ||
|
|
||
| - 中央で管理された認証情報などの関心事を分離できる | ||
| - 中央集約型でポリシー（たとえば、特定のログのフィルタリングやサンプリング）を管理できる |
|
|
||
| 短所： | ||
|
|
||
| - コレクション、処理、または取り込みの変更がある場合、コード変更が必要 |
Translate collector/deployment pages into ja: