Skip to content

Commit 40ac76c

Browse files
committed
add anchors
1 parent c525cc4 commit 40ac76c

File tree

1 file changed

+6
-6
lines changed
  • content/ja/docs/collector/deployment/gateway

1 file changed

+6
-6
lines changed

content/ja/docs/collector/deployment/gateway/index.md

+6-6
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ cSpell:ignore: filelogreceiver hostmetricsreceiver hostnames loadbalancer loadba
2828

2929
## 例 {#examples}
3030

31-
### NGINXを「アウトオブボックス」のロードバランサーとして使用
31+
### NGINXを「アウトオブボックス」のロードバランサーとして使用 {#nginx-as-an-out-of-the-box-load-balancer}
3232

3333
2つのコレクター(`collector1``collector2`)が設定され、NGINXを使用してその間でトラフィックをロードバランシングしたい場合、次の設定を使用できます。
3434

@@ -73,7 +73,7 @@ upstream collector4318 {
7373
}
7474
```
7575

76-
### ロードバランシングエクスポーター
76+
### ロードバランシングエクスポーター {#load-balancing-exporter}
7777

7878
コレクターの中央集権型デプロイメントパターンの具体的な例として、まずロードバランシングエクスポーターについて詳しく見ていきましょう。
7979
これには2つの主な設定項目があります:
@@ -176,7 +176,7 @@ service:
176176
177177
ロードバランシングエクスポーターは、`otelcol_loadbalancer_num_backends`や`otelcol_loadbalancer_backend_latency`などのメトリクスを出力し、これらを使用してOTLPエンドポイントコレクターのヘルスとパフォーマンスを監視できます。
178178

179-
## エージェントとゲートウェイのコレクターの組み合わせたデプロイメント
179+
## エージェントとゲートウェイのコレクターの組み合わせたデプロイメント {#combined-deployment-of-collectors-as-agents-and-gateways}
180180

181181
複数のOpenTelemetryコレクターをデプロイする場合、エージェントとしてもゲートウェイとしてもコレクターを実行することがよくあります。
182182

@@ -212,12 +212,12 @@ service:
212212
[tailsample-processor]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/tailsamplingprocessor
213213
[spanmetrics-connector]: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/connector/spanmetricsconnector
214214

215-
## 複数のコレクターとシングルライター原則
215+
## 複数のコレクターとシングルライター原則 {#multiple-collectors-and-the-single-writer-principle}
216216

217217
OTLP内のすべてのメトリクスデータストリームには、[シングルライター](/docs/specs/otel/metrics/data-model/#single-writer)が必要です。
218218
ゲートウェイ構成で複数のコレクターをデプロイする際は、すべてのメトリクスデータストリームに対してシングルライターとグローバルにユニークなIDを確保することが重要です。
219219

220-
### 潜在的な問題
220+
### 潜在的な問題 {#potential-problems}
221221

222222
複数のアプリケーションが同じデータを変更または報告する並列アクセスは、データ損失やデータ品質の劣化を引き起こす可能性があります。
223223
たとえば、リソース上で複数のソースから一貫性のないデータを確認する場合があります。
@@ -239,7 +239,7 @@ OTLP内のすべてのメトリクスデータストリームには、[シング
239239
- メトリクス`M1`は、13:56:24のタイムスタンプで`120`という値を持って受信された
240240
- メトリクス`M1`は、13:56:04のタイムスタンプで`110`という値を持って受信された
241241

242-
### ベストプラクティス
242+
### ベストプラクティス {#best-practices}
243243

244244
- [Kubernetes属性プロセッサー](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/k8sattributesprocessor)を使用して、異なるKubernetesリソースにラベルを追加します。
245245
- [リソース検出プロセッサー](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/README.md)を使用して、ホストからリソース情報を検出し、リソースメタデータを収集します。

0 commit comments

Comments
 (0)