SplunkとIsovalentによる高度なネットワークトラフィック分析

クラスターのトラフィックをリアルタイムで可視化しましょう。ネットワークマップが、ワークロード、名前空間、サービスを関連付けてくれます。これによってオペレーターは、予期しない接続やドロップされたフローを即座に特定できます。ネットワークに死角があると、パフォーマンス、セキュリティ、コンプライアンスのボトルネックに直結しやすいものです。従来のツールでは、パケットキャプチャやフローログで止まってしまうことが多いため、オペレーターは低レベルのデータをサービスやワークロードに関連付けるのに苦労しています。

Isovalentと連携したSplunk Observabilityは、まさにそうしたネットワークの暗い部分に光を当てます。IsovalentのeBPFベースのランタイム可視化とSplunkの分析および可視化プラットフォームを組み合わせることで、Network Explorerを再構築します。これによって、カーネルからクラスター、サービスに至るまで、IsovalentのTetragonおよびCiliumからのネットワークトラフィックに対するエンドツーエンドのオブザーバビリティが得られるようになります。

このブログでは、SplunkとIsovalentが環境全体にわたり比類のないネットワークオブザーバビリティを実現し、あらゆる種類のワークロードトラフィック(TCP、UDP、DNSなど)に一段と詳細なコンテキストを提供できるようにする、eBPF主導の高度な機能をご紹介します。

さらに詳しく知りたい場合は、ハンズオンラボ「Isovalent Runtime Security：Splunk統合」(英語)をご覧ください。この特別なラボでは、IsovalentとSplunkが連携して、クラウドネイティブ環境の補正ランタイム制御と高度な脅威検出を提供する方法をご説明します。

Splunk Network Explorerの新機能

Kubernetes対応ネットワークマップ

クラスターのトラフィックをリアルタイムで可視化します。ネットワークマップが、ワークロード、名前空間、サービスを関連付けてくれます。これによってオペレーターは、予期しない接続やドロップされたフローを即座に特定できます。

プロトコルダッシュボード(DNS、TCP、UDP、HTTP)

ワークロードの通信パターンを詳しく分析します。

• DNS：解決エラーとクエリー量を参照します。
• TCP/UDP：接続の試行、リセット、再送信を追跡します。
• HTTP：リクエストの成功率と応答コードを把握します。

Ciliumメトリクスによるインフラ健全性

フローを超えて、IsovalentデータパスとポリシーメトリクスをSplunkに取り込めるようになりました。これにより、パケット転送、ポリシー適用、クラスターネットワークの健全性を可視化できます。これはSREとセキュリティエンジニアの両者にとって重要なものです。

ワークロードの詳細分析

名前空間、サービス、Podごとにドリルダウンして、特定の接続を追跡し、ボトルネックを明らかにし、コンプライアンス要件を検証します。

なぜSplunkとIsovalentなのか？

ここでは、技術的な実装とダッシュボードについて詳しく説明する前に、概要を簡単に紹介します。

IsovalentのRuntime Securityは、それだけでも強力なオブザーバビリティエンジンです。さらに、Splunk Observability Cloudと組み合わせることで、これは未加工のメトリクス以上のものになります。

インサイトの単一の宛先として、インフラストラクチャの健全性からアプリケーションの動作に至るまでをカバーします。SplunkとIsovalentを使用すると、Kubernetesクラスターとクラウドインフラストラクチャの基盤となる健全性からマイクロサービスの細かい動作まで、あらゆるものを簡単に観察できます。

シグナルの相関付けを行い、ネットワークデータとログ、トレース、メトリクスを組み合わせて根本原因分析を迅速化します。データのサイロ化を超えた分析ということです。こうして相関付けされたインサイトにより、インシデントの根本原因(問題の原因が、ネットワーク、アプリケーションコード、インフラストラクチャ層のどれなのか)の特定が容易になり、より迅速かつ正確なトラブルシューティングが可能になります。

エンタープライズ規模に対応したSplunkの分析機能とアラート機能により、ノイズの中で信号を失うことなく、数千のPodとフローを監視できます。環境が拡大しても、ノイズの中で信号を失うことなく、異常を検出し、パフォーマンスのボトルネックを見つけ、コンプライアンスを確保するために必要な明確さを維持できます。

Isovalentのネットワークオブザーバビリティは、プロセスによって作成および受信されるインバウンドおよびアウトバウンドのネットワーク接続に関する詳細なインサイトを提供します。複雑でコストのかかるサイドカーを使ったサービスメッシュテクノロジーを実装する必要はありません。

Network Explorerが対応するユースケースをいくつか見てみましょう。

クラスター内で誰が誰と会話しているのか？

Tetragonは、eBPFを介してLinuxカーネルから直接リアルタイムのフローデータを収集し、すべてのネットワーク接続をKubernetesメタデータ(Pod、名前空間、サービス、さらにはプロセスバイナリ)に関連付けます。Kubernetesでは、IPアドレスとワークロードの間にリンクがありません。そこで、どのプロセスがどのIP/ポートを使用しているかをリアルタイムで把握することによって、ネットワークとワークロードの関連付けのギャップを解消します。

これにより、クラスター内で「誰が誰と通信しているか」について真のエンドツーエンドの可視性が得られ、インフラストラクチャレベルのトラフィックとアプリケーション/サービスコンテキスト間のギャップが埋められます。セキュリティチームと運用チームは、予期しない接続、ラテラルムーブメント、異常なトラフィックパターンを即座に発見できます。Tetragonは、成功した接続と失敗してドロップされた接続試行を記録します。各フローは特定のプロセス(バイナリ名、引数、PID)とコンテナイメージハッシュに関連付けられており、フォレンジックレベルのアクティビティの追跡が可能になります。

eBPFプログラムはすべてのKubernetesノードで実行され、フローイベント(接続、受け入れ、クローズ、ドロップ)をキャプチャし、それらをリアルタイムのKubernetesおよびプロセスメタデータで補強してからSplunkにエクスポートします。これは、最小限のオーバーヘッドで、サイドカーやコードインストルメンテーションなしで実行されます。

Splunk Observability内部では、これらの補強されたフローメトリクスに基づくインタラクティブな ネットワークマップ が、サービス、Pod、プロセス間のライブ通信を可視化します。この統合されたリアルタイムビューにより、SREとSecOpsは、不正接続の検出、パフォーマンス低下の調査、カーネルからアプリケーション層までの問題の追跡をシームレスに行うことができます。これらすべては、Splunk Observability内で行えます。

TCPレイテンシーと再送信をアプリケーションの動作や誤動作にリンクするには、どうすればよいか？

TCPパフォーマンスのボトルネックとアプリケーション側の原因の特定

信頼性の高いアプリケーションは、健全なTCPから始まります。Splunk Observability内で、オペレーターはサービス間のレイテンシー、再送信ストーム、または失敗した接続試行を迅速に可視化できます。これらはすべてプロセスレベルのコンテキストで補強されており、問題が発生した 場所 だけでなく、問題を引き起こしたのは どのワークロードやバイナリ なのかを正確に特定できます。

Isovalentの Tetragon を搭載した TCPプロトコルダッシュボード は、SYNカウント、接続試行、リセット、再送信、ウィンドウ動作、パケット損失など、Linuxカーネルからのリアルタイムメトリクスを浮き彫りにします。各フローは、ソースと宛先IP、ポート、Pod、名前空間、プロセスで自動的に補強され、通信のすべての層にわたって完全なコンテキストを提供します。

ダッシュボードは、フローごとの往復時間(RTT)を測定し、再送信またはタイムアウトの異常を強調表示します。これは、パフォーマンスの低下がネットワークパスに起因するものか、アプリケーション自体に起因するものかを識別するのに役立ちます。Splunkのスケーラブルなメトリクスプラットフォーム上に構築されたこのビューは、秒単位の粒度で計測オーバーヘッドなしで継続的なTCPヘルスモニタリングを実現します。

その結果、トランスポート層のパフォーマンスを、カーネルからサービスまでライブで表示できるようになります。これによってチームは、マイクロバーストの検出、遅い接続のトラブルシューティング、ネットワークの信頼性の検証をすべてSplunk Observability内で直接実施できます。

このワークロードはネットワークで何を実行しているのか？

Isovalentは、プロセスごとおよびPodごとのネットワークオブザーバビリティ機能を提供し、どのバイナリがどの接続を開始したかを示し、ネットワークアクティビティをプロセス、引数、コンテナイメージなどの実行コンテキストに結び付けます。

Splunk Observability内では、これらのインサイトがNetwork Explorerを通じて実現され、すべてのワークロードがリアルタイムトポロジーの対話型ノードになります。上記の例では、過去1時間の Kafka ワークロードのTCPの健全性を調査しています。マップには、Javaコンシューマーおよび Javaプロデューサーの ワークロードとの通信が、パケット損失、ラウンドトリップ時間、再送信などの主要なメトリックとともに強調表示されます。これらはすべて、カーネルレベルでeBPFを通じてキャプチャされ、Splunkに即座に表示されます。

これはワークロード中心のビューなので、ユーザーは UDP、DNS、HTTP、 または依存関係データのタブ間をスムーズに移動できます。各ビューはKubernetesとプロセスのメタデータで補強されています。その結果、各ワークロードがネットワーク上で何を行っているのか、どのようなパフォーマンスになっているのかについて、使い慣れたSplunk Observabilityですべてを包括的にライブで把握できます。

なぜいつもDNSなのか？

DNSの問題があると、アプリケーションのパフォーマンスが気づかないうちに低下したり、サービスの接続が切断されたりする可能性があります。Splunk Observabilityの Tetragonを活用したDNS メトリクスを使用すると、チームは、解決の遅さ、繰り返されるルックアップの失敗、または予期しない外部クエリーを即座に特定できます。これらはすべて、元のワークロード、Pod、プロセスにマッピングされています。

DNS概要ダッシュボードでは、すべてのクエリーと応答がリアルタイムでキャプチャされ、完全修飾ドメイン名、応答コード、待ち時間、リクエストを開始した正確なサービスが表示されます。このビューでは、DNSエラー率、応答分布、名前空間全体のミス/エビクションパターンが強調表示されるため、SREとプラットフォームチームは上流のリゾルバの問題とワークロードレベルの誤った構成を迅速に区別できます。

このアプローチは、アプリケーションで外部サービスへの断続的な接続障害が発生し始めるという一般的なシナリオに適用することを検討してください。従来のツールを使用する環境では、まずアプリケーションログを確認し、次にホストからdigまたはnslookupを実行し、最終的にはtcpdumpを使用してDNSトラフィックをキャプチャすることもあるでしょう。そのプロセスは多くの場合、手動で時間がかかり、Pod内のどの特定のプロセスが問題のあるクエリーを開始したかについての詳細なコンテキストも不十分です。

このデータはeBPFを通じてカーネルから直接収集され、Splunk Observabilityで可視化されるため、ほぼゼロのオーバーヘッドを維持しながらクラスターサイズに合わせて簡単に拡張できます。その結果、追加のインストルメンテーションやサイドカーを必要とせずに、Kubernetes環境全体でDNSの動作を1カ所で監視、検証、トラブルシューティングできる高忠実度の可視化が実現します。

UDPトラフィックに何が起こっているのか？

UDPは、DNS、サービスディスカバリ、および多くのカスタムアプリケーションプロトコルの中心に位置しますが、コネクションレスなので監視が難しいことが広く知られています。Tetragonを利用したUDPテレメトリは、Splunk Observabilityに直接表示されます。そのため、チームはワークロード、名前空間、ノード全体で送受信されるすべてのパケットをリアルタイムで可視化できます。

UDP概要ダッシュボードを使い、ユーザーはトラフィック量、パケットエラー、ワークロードまたはサービスごとの送受信アクティビティを追跡できます。各フローはKubernetesメタデータ(ソースと宛先Pod、名前空間、プロセス)で自動的に補強されるため、不正な動作をしているアプリケーションや突然のトラフィック異常の検出が容易になります。

このデータはカーネルレベルでキャプチャされ、Splunk Observabilityでライブで可視化されます。そのため、オペレーターは手順を追加する必要なく、ドロップされたパケット、プロトコルの誤用、またはUDPベースのサービス拒否パターンを迅速に特定できます。その結果、オブザーバビリティワークフローにネイティブだと感じられる、継続的で忠実度の高いUDPモニタリングが実現します。

詳細はこちら

voc.splunk.comにアクセスして登録し、今すぐお試しください。