2. 耐障害性の構築

10 minutes

OpenTelemetry Collector の FileStorage Extension は、より耐障害性の高いテレメトリーパイプラインを構築するための重要なコンポーネントです。これにより、Collector は処理中のデータを確実にチェックポイントし、リトライを効率的に管理し、貴重なテレメトリーを失うことなく一時的な障害を適切に処理できます。

FileStorage を有効にすると、Collector は中間状態をディスクに永続化できるため、ネットワークの中断、バックエンドの停止、または Collector の再起動時にもトレース、メトリクス、ログが失われないことが保証されます。つまり、ネットワーク接続が切断されたり、バックエンドが一時的に利用できなくなったりしても、Collector はテレメトリーの受信とバッファリングを継続し、接続が復旧すると配信をシームレスに再開します。

FileStorage Extension をパイプラインに統合することで、オブザーバビリティスタックの耐久性を強化し、接続が不安定な環境でも高品質なテレメトリー取り込みを維持できます。

メモ

このソリューションは、接続ダウンタイムが短い場合（最大15分）のメトリクスに対して機能します。ダウンタイムがこれを超えると、Splunk Observability Cloud はデータポイントの順序が乱れないようにデータをドロップする可能性があります。

ログについては、今後の Splunk OpenTelemetry Collector リリースで完全なエンタープライズ対応ソリューションを実装する計画があります。

2.1 File Storage の設定

この演習では、agent.yaml ファイルの extensions: セクションを更新します。このセクションは OpenTelemetry 設定 YAML の一部であり、OpenTelemetry Collector の動作を拡張または変更するオプションのコンポーネントを定義します。

これらのコンポーネントはテレメトリーデータを直接処理しませんが、Collector の機能を向上させる貴重な機能とサービスを提供します。

Exercise

重要

すべての ターミナルウィンドウを 2-building-resilience ディレクトリに移動し、clear コマンドを実行してください。

ディレクトリ構造は以下のようになります

.
├── agent.yaml
└── gateway.yaml

agent.yaml の更新: Agent ターミナル ウィンドウで、既存の health_check Extension の下に file_storage Extension を追加します

  file_storage/checkpoint:             # Extension Type/Name
    directory: "./checkpoint-dir"      # Define directory
    create_directory: true             # Create directory
    timeout: 1s                        # Timeout for file operations
    compaction:                        # Compaction settings
      on_start: true                   # Start compaction at Collector startup
      # Define compaction directory
      directory: "./checkpoint-dir/tmp"
      max_transaction_size: 65536      # Max. size limit before compaction occurs

Exporter への file_storage の追加: otlphttp Exporter を変更して、リトライとキューイングメカニズムを設定し、障害が発生した場合にデータが保持され再送信されるようにします。endpoint: "http://localhost:5318" の下に以下を追加し、インデントが endpoint と一致していることを確認してください

    retry_on_failure:
      enabled: true                    # Enable retry on failure
    sending_queue:                     #
      enabled: true                    # Enable sending queue
      num_consumers: 10                # No. of consumers
      queue_size: 10000                # Max. queue size
      storage: file_storage/checkpoint # File storage extension

services セクションの更新: 既存の extensions: セクションに file_storage/checkpoint Extension を追加します。設定は以下のようになります

service:
  extensions:
  - health_check
  - file_storage/checkpoint            # Enabled extensions for this collector

metrics パイプラインの更新: この演習では、デバッグとログのノイズを減らすために、Metric パイプラインから hostmetrics Receiver をコメントアウトします。設定は以下のようになります

    metrics:
      receivers:
      # - hostmetrics                    # Hostmetric reciever (cpu only)
      - otlp

otelbin.io を使用して Agent 設定を検証してください。参考までに、パイプラインの metrics: セクションは以下のようになります

%%{init:{"fontFamily":"monospace"}}%%
graph LR
    %% Nodes
      REC1(&nbsp;&nbsp;otlp&nbsp;&nbsp;<br>fa:fa-download):::receiver
      PRO1(memory_limiter<br>fa:fa-microchip):::processor
      PRO2(resourcedetection<br>fa:fa-microchip):::processor
      PRO3(resource<br>fa:fa-microchip<br>add_mode):::processor
      EXP1(&ensp;debug&ensp;<br>fa:fa-upload):::exporter
      EXP2(otlphttp<br>fa:fa-upload):::exporter
      EXP3(&ensp;file&ensp;<br>fa:fa-upload):::exporter
    %% Links
    subID1:::sub-metrics
    subgraph " "
      subgraph subID1[**Metrics**]
      direction LR
      REC1 --> PRO1
      PRO1 --> PRO2
      PRO2 --> PRO3
      PRO3 --> EXP1
      PRO3 --> EXP3
      PRO3 --> EXP2
      end
    end
classDef receiver,exporter fill:#8b5cf6,stroke:#333,stroke-width:1px,color:#fff;
classDef processor fill:#6366f1,stroke:#333,stroke-width:1px,color:#fff;
classDef con-receive,con-export fill:#45c175,stroke:#333,stroke-width:1px,color:#fff;
classDef sub-metrics stroke:#38bdf8,stroke-width:1px, color:#38bdf8,stroke-dasharray: 3 3;

2.2 耐障害性テスト用の環境セットアップ

次に、File Storage 設定をテストする準備として環境を設定します。

Exercise

Gateway の起動: Gateway ターミナル ウィンドウで以下を実行します

../otelcol --config=gateway.yaml

Agent の起動: Agent ターミナル ウィンドウで以下を実行します

../otelcol --config=agent.yaml

5つのテストスパンを送信: Loadgen ターミナル ウィンドウで以下を実行します

../loadgen -count 5

Agent と Gateway の両方がデバッグログを表示し、Gateway が ./gateway-traces.out ファイルを作成するはずです。

すべてが正常に機能している場合、システムの耐障害性のテストに進むことができます。

2.3 障害のシミュレーション

Agent の耐障害性を評価するために、一時的な Gateway の停止をシミュレートし、Agent がそれをどのように処理するかを観察します

Exercise

ネットワーク障害のシミュレーション: Gateway ターミナル で Ctrl-C を使用して Gateway を停止し、Gateway のコンソールが停止したことを示すまで待ちます。Agent は引き続き実行されますが、Gateway にデータを送信できません。Gateway ターミナル の出力は以下のようになります

2025-07-09T10:22:37.941Z        info    service@v0.126.0/service.go:345 Shutdown complete.      {"resource": {}}

トレースの送信: Loadgen ターミナル ウィンドウで、loadgen を使用してさらに5つのトレースを送信します。

../loadgen -count 5

Agent のリトライメカニズムが有効になり、データを再送信しようと継続的に試みていることに注目してください。Agent のコンソール出力には、以下のようなメッセージが繰り返し表示されます

2025-01-28T14:22:47.020+0100  info  internal/retry_sender.go:126  Exporting failed. Will retry the request after interval.  {"kind": "exporter", "data_type": "traces", "name": "otlphttp", "error": "failed to make an HTTP request: Post \"http://localhost:5318/v1/traces\": dial tcp 127.0.0.1:5318: connect: connection refused", "interval": "9.471474933s"}

Agent の停止: Agent ターミナル ウィンドウで、Ctrl-C を使用して Agent を停止します。Agent のコンソールが停止を確認するまで待ちます

2025-07-09T10:25:59.344Z        info    service@v0.126.0/service.go:345 Shutdown complete.      {"resource": {}}

重要

Agent を停止すると、リトライ用にメモリに保持されているメトリクス、トレース、ログは失われます。ただし、FileStorage Extension を設定しているため、ターゲットエンドポイントでまだ受け入れられていないすべてのテレメトリーはディスクに安全にチェックポイントされています。

Agent の停止は、Agent が再起動されたときにシステムがどのように復旧するかを明確に示すための重要なステップです。

2.4 復旧

この演習では、Gateway Collector を再起動することで、OpenTelemetry Collector がネットワーク障害からどのように復旧するかをテストします。Gateway が再び利用可能になると、Agent は最後にチェックポイントされた状態からデータの送信を再開し、データ損失がないことを保証します。

Exercise

Gateway の再起動: Gateway ターミナル ウィンドウで以下を実行します

../otelcol --config=gateway.yaml

Agent の再起動: Agent ターミナル ウィンドウで以下を実行します

../otelcol --config=agent.yaml

Agent が起動して実行されると、File_Storage Extension がチェックポイントフォルダー内のバッファされたデータを検出します。最後のチェックポイントフォルダーから保存されたスパンをデキューし始め、データが失われないことを保証します。

Agent デバッグ出力の確認: Agent のデバッグ出力は変化せず、以下の行を表示し続け、新しいデータがエクスポートされていないことを示していることに注意してください

2025-07-11T08:31:58.176Z        info    service@v0.126.0/service.go:289 Everything is ready. Begin running and processing data.   {"resource": {}}

Gateway デバッグ出力の確認 Gateway のデバッグ画面から、以前見逃されていたトレースを追加のアクションなしで受信し始めていることが確認できるはずです。例

Attributes:
   -> user.name: Str(Luke Skywalker)
   -> user.phone_number: Str(+1555-867-5309)
   -> user.email: Str(george@deathstar.email)
   -> user.password: Str(LOTR>StarWars1-2-3)
   -> user.visa: Str(4111 1111 1111 1111)
   -> user.amex: Str(3782 822463 10005)
   -> user.mastercard: Str(5555 5555 5555 4444)
   -> payment.amount: Double(75.75)
      {"resource": {}, "otelcol.component.id": "debug", "otelcol.component.kind": "exporter", "otelcol.signal": "traces"}

gateway-traces.out ファイルの確認: jq を使用して、再作成された gateway-traces.out 内のトレース数をカウントします。Gateway がダウンしていたときに送信した数と一致するはずです。

jq '.resourceSpans | length | "\(.) resourceSpans found"' gateway-traces.out

"5 resourceSpans found"

重要

Agent と Gateway のプロセスを、それぞれのターミナルで Ctrl-C を押して停止してください。

まとめ

この演習では、file_storage Extension の設定、otlp Exporter のリトライメカニズムの有効化、および一時的なデータ保存用のファイルベースのキューの使用により、OpenTelemetry Collector の耐障害性を強化する方法を示しました。

ファイルベースのチェックポイントとキューの永続化を実装することで、テレメトリーパイプラインが一時的な中断から適切に復旧できることを保証し、本番環境でより堅牢で信頼性の高いものにします。

2. 耐障害性の構築

2. Building Resilienceのサブセクション

2.1 File Storage の設定

2.2 耐障害性テスト用の環境セットアップ

2.3 障害のシミュレーション

2.4 復旧

まとめ