- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
高耐久性とは、システム障害が発生したときにデータを保持できることです。アグリゲーターアーキテクチャは、高耐久性の責任を負うように設計されています。このため、Agent からアグリゲーターに負担を移し、ローカライズすることで、耐久性戦略を簡素化することができます。さらに、この集中的なアプローチにより、すべての Agent ノードに渡って実装することが困難な耐久性戦略が可能になります。
高耐久性を実現するために
Agent をシンプルなデータ転送装置として構成し、Observability Pipelines Worker アグリゲーターに直接データをストリーミングします。これにより、データがまだ冗長化されていないため、エッジでのデータロスにさらされる時間が短縮されます。
記録システムとして機能する耐久性の高い宛先を選択します (例えば、Amazon S3)。このシステムは、静止しているデータの耐久性に責任があり、一般的にアーカイブやデータレイクと呼ばれます。
最後に、記録システムに書き込む Observability Pipelines Worker のシンクを構成し、エンドツーエンド確認応答とディスクバッファを有効にしてください。例:
sinks:
aws_s3:
acknowledgments: true
buffer:
type: "disk"
Observability Pipelines Worker のオペレーティングシステムプロセスの問題により、問題の発生時にメモリに保持されているデータが失われる危険性があります。Observability Pipelines Worker のエンドツーエンド確認応答機能を有効にして、データ消失のリスクを軽減してください。
sinks:
aws_s3:
acknowledgments: true
この機能を有効にすると、Observability Pipelines Worker は、データが永続的に保持されるまで Agent に応答しません。これにより、Agent が早期にデータを解放し、確認応答を受信していない場合に再度送信することを防ぐことができます。
ノード障害は個々のノードの完全な障害を扱います。これらはエンドツーエンドの確認応答を使って対処することもできます。詳しくはエンドツーエンド確認応答の使用を参照してください。
ディスク障害は個々のディスクの障害を扱います。ディスク障害に関連するデータ損失は、ブロックストレージ (例えば、Amazon EBS) のように、複数のディスクにデータを複製する高耐久性のファイルシステムを使用することで軽減できます。
Observability Pipelines Worker は、不正なデータを処理しようとすると、ログのパースに失敗するなどの問題が発生することがあります。この問題を軽減する方法は 2 つあります。
ダイレクトアーカイブ: ソースからアーカイブに直接データをルーティングします。これにより、データが落とされるリスクなしにアーカイブに到達することを保証します。また、このデータは、処理エラーを修正した後に再生することができます。
イベントルーティングの失敗: Observability Pipelines Worker は、構造化データやリッチ化データなど、処理したデータをアーカイブしたいユーザー向けに、失敗したイベントのルーティングを提供します。Observability Pipelines Worker の変換には、耐久性と再生のためにシンクに接続することができるドロップ出力が付属しているものがあります。
耐久性が最も重要な基準である場合は、データ損失のシナリオに対応するため、ダイレクトアーカイブ方式を使用します。アーカイブでのデータ分析を希望する場合は、一般にデータレイクとも呼ばれる失敗イベントルーティング方式を使用します。アーカイブ/データレイクを長期的な分析に使用できる利点があります。Datadog Log Archives や Amazon Athena は、アーカイブストレージソリューションの一例です。
宛先の障害とは、ダウンストリームの宛先 (例えば Elasticsearch) の全障害を指します。ダウンストリーム宛先の問題に対して、停止時間を持続させるのに十分な大きさのディスクバッファを使用することで、データ損失を軽減できます。これにより、サービスが停止している間、データを持続的にバッファリングし、サービスが回復したときにデータを排出することができます。このため、少なくとも 1 時間分のデータを保持するのに十分な大きさのディスクバッファを使用することをお勧めします。詳しくは、インスタンスの最適化を参照してください。