- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
多くのユーザーは、複数のクラウド、リージョン、VPC、クラスターなど、多くのネットワーク境界を持つ複雑な本番環境を持っています。これらの境界の中で、観測可能性パイプラインワーカーをどこに位置づけるかを決めると、複雑になることがあります。そのため、Datadogで は、複数のアカウント、VPC、クラスターがある場合でも、リージョンごとに 1 つの観測可能性パイプラインワーカーアグリゲーターで始めることを推奨しています。この境界は、公衆インターネット上でのデータ送信を回避する最も広いネットワーク粒度です。複数のクラスターがある場合は、ユーティリティやツールクラスターに観測可能性パイプラインワーカーをデプロイするか、共有サービスに最も適したクラスタを選びましょう。
観測可能性パイプラインワーカーの利用が増えれば、複数の観測可能性パイプラインワーカーのデプロイがどのような位置づけになるかが明らかになります。
複数デプロイの詳細については、高度な構成を参照してください。
組織は、基本的な DNS を通じて促進されているとしても、何らかの形のサービスディスカバリーを採用しているかもしれません。観測可能性パイプラインワーカーアグリゲーターとサービスの発見は、サービスディスカバリーメカニズムによって解決される必要があります。
サービスディスカバリーを使用すると、名前付きホスト名 (固定 IP アドレスではない) で Agent を構成し、トラフィックのルーティングとロードバランシングを促進することができます。これは、Agent がロードバランサーを発見し、ロードバランサーが観測可能性パイプラインワーカーアグリゲーターを発見する方法です。
観測可能性パイプラインワーカー自身は DNS クエリの解決を行わず、システムレベルのリゾルバ (例えば Linux 解決など) に委ねます。
観測可能性パイプラインワーカーには、すべての送信 HTTP トラフィックをプロキシ経由でルーティングするグローバルプロキシオプションがあります。プロキシを使用するかどうかは、組織のセキュリティとネットワークの設定に依存します。
観測可能性パイプラインワーカーは、ネットワーク管理者が簡単に発見できるように、すべてのポートを明示的に構成する必要があります。したがって、観測可能性パイプラインワーカーのコンフィギュレーションファイルを見ることで、公開されているすべてのポートの完全なインベントリを得ることができます。観測可能性パイプラインワーカーアグリゲーターは、以下のポートを公開するデフォルト構成で出荷されています。
ポート | ソース | プロトコル | 方向 | 説明 |
---|---|---|---|---|
8282 | Datadog Agent | HTTP | 着信 | フルエントソースからデータを受け取ります。 |
123 | ファイル | Syslog | 着信 | Syslog ソースからデータを受け取ります。 |
管理者が公開ポートを変更している可能性がありますので、観測可能性パイプラインワーカーの構成を見直してください。
観測可能性パイプラインワーカーは、様々なプロトコルでデータを受信・送信できるように設計されています。Datadog では、インテグレーションで最もサポートされているプロトコルを使用することを推奨しています。可能であれば、アプリケーションレベルの配信確認とプラットフォーム間でのユビキタスなサポートのために、HTTP ベースのプロトコルを選択します。それ以外の場合は、TCP ベースのプロトコルを選択します。UDP は、データを失うリスクがあるため、推奨されません。
観測可能性パイプラインワーカーのソースとシンクを使用して、観測可能性パイプラインワーカーインスタンス間でデータを送信します (例えば、統一アーキテクチャを使用した場合など)。これらのソースは、効率的なロスレス通信のために GRPC プロトコルを使用します。
観測可能性パイプラインワーカーは、多くの Agent のために特定のソースを提供します。例えば、datadog_agent
ソースは Datadog Agent から全てのデータタイプをロスレス構造化フォーマットで受信する処理を行います。
Datadog のベンチマークによると、圧縮を行うとスループットが 50% 低下する可能性があります。圧縮は慎重に使用し、有効にした後はパフォーマンスを監視してください。
ネットワークトラフィックの圧縮は、パフォーマンスに影響を与えるため、コスト重視のイグレスシナリオにのみ使用する必要があります (例えば、公衆インターネット上でのデータ送信など)。したがって、内部ネットワークトラフィックの圧縮は推奨されません。