ネットワーキング

ネットワークトポロジー

ネットワーク境界

多くのユーザーは、複数のクラウド、リージョン、VPC、クラスターなど、多くのネットワーク境界を持つ複雑な本番環境を持っています。これらの境界の中で、観測可能性パイプラインワーカーをどこに位置づけるかを決めると、複雑になることがあります。そのため、Datadogで は、複数のアカウント、VPC、クラスターがある場合でも、リージョンごとに 1 つの観測可能性パイプラインワーカーアグリゲーターで始めることを推奨しています。この境界は、公衆インターネット上でのデータ送信を回避する最も広いネットワーク粒度です。複数のクラスターがある場合は、ユーティリティやツールクラスターに観測可能性パイプラインワーカーをデプロイするか、共有サービスに最も適したクラスタを選びましょう。

観測可能性パイプラインワーカーの利用が増えれば、複数の観測可能性パイプラインワーカーのデプロイがどのような位置づけになるかが明らかになります。

複数デプロイの詳細については、高度な構成を参照してください。

DNS とサービスディスカバリー

組織は、基本的な DNS を通じて促進されているとしても、何らかの形のサービスディスカバリーを採用しているかもしれません。観測可能性パイプラインワーカーアグリゲーターとサービスの発見は、サービスディスカバリーメカニズムによって解決される必要があります。

サービスディスカバリーを使用すると、名前付きホスト名 (固定 IP アドレスではない) で Agent を構成し、トラフィックのルーティングとロードバランシングを促進することができます。これは、Agent がロードバランサーを発見し、ロードバランサーが観測可能性パイプラインワーカーアグリゲーターを発見する方法です。

観測可能性パイプラインワーカー自身は DNS クエリの解決を行わず、システムレベルのリゾルバ (例えば Linux 解決など) に委ねます。

ネットワークトラフィック

プロキシ

観測可能性パイプラインワーカーには、すべての送信 HTTP トラフィックをプロキシ経由でルーティングするグローバルプロキシオプションがあります。プロキシを使用するかどうかは、組織のセキュリティとネットワークの設定に依存します。

ポート

観測可能性パイプラインワーカーは、ネットワーク管理者が簡単に発見できるように、すべてのポートを明示的に構成する必要があります。したがって、観測可能性パイプラインワーカーのコンフィギュレーションファイルを見ることで、公開されているすべてのポートの完全なインベントリを得ることができます。観測可能性パイプラインワーカーアグリゲーターは、以下のポートを公開するデフォルト構成で出荷されています。

管理者が公開ポートを変更している可能性がありますので、観測可能性パイプラインワーカーの構成を見直してください。

プロトコル

観測可能性パイプラインワーカーは、様々なプロトコルでデータを受信・送信できるように設計されています。Datadog では、インテグレーションで最もサポートされているプロトコルを使用することを推奨しています。可能であれば、アプリケーションレベルの配信確認とプラットフォーム間でのユビキタスなサポートのために、HTTP ベースのプロトコルを選択します。それ以外の場合は、TCP ベースのプロトコルを選択します。UDP は、データを失うリスクがあるため、推奨されません。

ワーカー間の通信

観測可能性パイプラインワーカーのソースとシンクを使用して、観測可能性パイプラインワーカーインスタンス間でデータを送信します (例えば、統一アーキテクチャを使用した場合など)。これらのソースは、効率的なロスレス通信のために GRPC プロトコルを使用します。

Agent 通信

観測可能性パイプラインワーカーは、多くの Agent のために特定のソースを提供します。例えば、datadog_agent ソースは Datadog Agent から全てのデータタイプをロスレス構造化フォーマットで受信する処理を行います。

圧縮

Datadog のベンチマークによると、圧縮を行うとスループットが 50% 低下する可能性があります。圧縮は慎重に使用し、有効にした後はパフォーマンスを監視してください。

ネットワークトラフィックの圧縮は、パフォーマンスに影響を与えるため、コスト重視のイグレスシナリオにのみ使用する必要があります (例えば、公衆インターネット上でのデータ送信など)。したがって、内部ネットワークトラフィックの圧縮は推奨されません。