【実務・中級編】Datadog eBPFベースのネットワーク監視とプロセスインサイト：カーネルレベルでの深層オブザーバビリティ実践 – 運用監視・オブザーバビリティ活用バイブル

カーネルを味方につけろ：Datadog eBPF（System Probe）で実現する深層オブザーバビリティの極意

テックリードの皆さん、日々の障害対応やパフォーマンスチューニングでこんなフラストレーションを抱えていないだろうか。

「アプリケーション層のメトリクスは完璧なのに、なぜか特定のマイクロサービス間だけレイテンシーが跳ねる」
「コンテナが乱立するKubernetes環境で、どのPodとどのPodが裏で重いTCPコネクションを張っているのか、netstatやssコマンドの嵐に溺れている」
「APMエージェントをこれ以上コードに組み込むと、ランタイムのオーバーヘッドが無視できなくなる」

これらは、ユーザースペース（アプリケーション層）からシステムを観測しようとする限界に起因している。OSのカーネルという「真実の源泉（Single Source of Truth）」をバイパスしている限り、本当の意味でのオブザーバビリティは手に入らない。

そこで登場するのが、eBPF（Extended Berkeley Packet Filter） をベースにした Datadog System Probe だ。本記事では、カーネルレベルでシステムを丸裸にし、オーバーヘッドを極限まで削ぎ落としながらネットワークとプロセスの振る舞いを完全に把握するための実践知を、プロの視点で余すところなく伝授する。

—

1. eBPFテクノロジーを採用したDatadog System Probeの仕組みとオーバーヘッド削減効果

ユーザースペース監視の限界とeBPFのパラダイムシフト

従来の監視エージェントやAPMは、アプリケーションのランタイム（JVM、Node.js、Pythonなど）や、OSのシステムコールをフックするためにライブラリのインジェクションやラッパーを使用していた。これらはコンテキストスイッチの多発やメモリ消費、さらには予期せぬガベージコレクションの誘発といった「監視の副作用」を常に生んでいた。

一方、DatadogのSystem Probeは、Linuxカーネル空間で安全に動作するバイトコード（eBPFプログラム）をJITコンパイルし、カーネルのイベントフック（Kprobes, Tracepoints, XDPなど）にアタッチする。

[ ユーザーアプリケーション / コンテナ ]
▲
│ (従来のオーバーヘッド大：システムコール / ライブラリ介入)
▼
+—————————————+
| Linux Kernel Space |
| ├── eBPF Programs (System Probe) | <── カーネル内で直接パケットやTCP状態を解析 | └── Ring Buffer / Maps | +---------------------------------------+ │ (軽量なデータ転送) ▼ [ Datadog Agent (Userspace) ] ──> [ Datadog SaaS ]

このアーキテクチャが生み出す圧倒的なメリットは以下の3点だ：
1. コンテキストスイッチの劇的削減: カーネル内でデータ集計（集約・フィルタリング）を完結させ、ユーザースペースへ渡すデータ量を最小化する。
2. ゼロ・インストルメンテーション: アプリケーションコードの変更や再ビルド、ランタイムの再起動が一切不要。
3. オーバーヘッドの極小化: CPU使用率を数%未満（通常1〜2%以下）に抑えつつ、TCPの全パケットやプロセス情報を網羅的にキャプチャ。

—

2. カーネル空間でのTCP再送やコネクション追跡の実装手順

理論はこれくらいにして、実際にこれをプロダクション環境（ここではKubernetes / Docker環境を想定）で有効化する設定のベストプラクティスを解説する。

実用的な設定ファイル（YAML）のベストプラクティス構成例

Datadog AgentをDaemonSetとしてデプロイする際、System Probeを有効化し、ネットワークパフォーマンス監視（NPM）とプロセスインサイトをフル稼働させるための設定（`datadog.yaml` の抜粋およびKubernetesマニフェストの一部）を示す。

datadog.yaml – System Probe & NPM Production Config
api_key: “YOUR_DATADOG_API_KEY”
site: “datadoghq.com”

— System Probe Core Config —
system_probe_config:
enabled: true
# カーネルオブザーバビリティの心臓部。eBPFマップのメモリ上限を設定
max_tracked_connections: 131072
# デバッグやトラブルシューティング用に関数トレースを有効化する場合に指定
btf_path: “” # 空白の場合、自動検出

# ネットワークパフォーマンス監視 (NPM) の有効化
network_config:
enabled: true
# すべてのコンテナ間のトラフィックを追跡（ホストネットワーキング含む）
collect_local_traffic: true
# UDPトラフィックの追跡も網羅する場合
enable_udp_flow_monitoring: true

# プロセスインサイト (Process Service Monitoring) の有効化
process_config:
enabled: true
scrub_sensitive_args: true # パスワードやトークンなどの機密引数をマスク（セキュリティ必須）
interval: 2s # プロセス収集間隔（高負荷時は5sに調整を検討）

— Runtime Security / OTel 連携等 —
runtime_security_config:
enabled: false # セキュリティ機能を使う場合はtrueに

デプロイ時の注意点：特権コンテナの権限

eBPFをカーネルにロードするためには、KubernetesのDaemonSet側で適切なCapabilities（特権）を付与する必要がある。以下のセキュリティコンテキストを必ず担保すること。

securityContext:
capabilities:
add:

  • SYS_ADMIN
  • SYS_RESOURCE
  • SYS_PTRACE
  • NET_ADMIN
  • NET_BROADCAST
  • NET_RAW
  • IPC_LOCK
  • DAC_READ_SEARCH

—

3. コンテナ間の通信ボトルネックをeBPFで特定する実務のユースケース

ここからが本題だ。現場で起きた障害を、DatadogのeBPFメトリクスを使っていかに秒速で解決するか、具体的なシナリオを見ていこう。

ユースケース：マイクロサービス間の「原因不明のレイテンシー急増」の特定

ある日、API Gatewayから決済サービス（`payment-service`）へのリクエストで、p99レイテンシーが突如として跳ね上がった。APMのトレースを見ると、決済サービス内の処理時間は正常に見える。ということは、ネットワーク層またはインフラ層に原因がある。

1. Datadog Network Performance Monitoring (NPM) ダッシュボードへの直行

Datadogの「Network > Processes」画面、またはカスタムダッシュボードで以下のメトリクスを監視する。

  • `system.net.tcp.retransmits` (TCP再送数)
  • `system.net.tcp.rtt` (ラウンドトリップタイム)

ここで、`api-gateway` Podから `payment-service` Podへの通信において、TCP再送率（Retransmit Rate）が急増していることを発見する。

2. eBPFによるコネクション追跡の真骨頂：ドロップパケットとウィンドウサイズの分析

従来の `netstat` では「今どうなっているか」しか分からないが、eBPFベースのSystem Probeは、カーネルのTCPステートマシンから以下の瞬間を捉えている。

  • Zero Window: 受信側のバッファが溢れ、送信側に「これ以上送るな」と告げている瞬間。
  • TCP Retransmission: パケットロスや輻輳により、カーネルが再送を余儀なくされている瞬間。

これらは `datadog_system_probe` が提供する以下のメトリクスでダッシュボード化しておくべきだ：

推奨監視クエリ（Datadog Metrics Explorer）
sum(system.net.tcp.retransmits) by {pod_name, dest_host}

3. 根本原因の特定

調査の結果、`payment-service` が稼働するノードのネットワークインターフェース（NIC）のキュー溢れ、あるいはKubernetesのCNI（Container Network Interface）のオーバーヘッドによるパケットドロップが原因であると判明した。アプリケーションコードを1行も修正することなく、インフラのボトルネックをピンポイントで特定し、ノードのスケールアウトやCNIパラメータのチューニング（`net.core.somaxconn` やバッファサイズの調整）へと即座に移行できた。

—

4. プロフェッショナルのための実践テクニック＆時短術

最後に、チーム全体の開発・運用スピードを極限まで引き上げるための「プロの隠し味」を共有する。

1. 開発スピードを劇的に高めるキーボードショートカット (Datadog UI)

障害対応中にマウスをカチカチ動かしている暇はない。Datadog UIでの神ショートカットを体に叩き込め。

  • `G` + `N`: Networkダッシュボードへ一瞬でジャンプ
  • `Alt` + グラフクリック: 任意のタイムレンジを瞬時にズームイン
  • `Cmd/Ctrl` + `K`: グローバルコマンドパレット（サービス、ダッシュボード、ノートブックを名前で一発検索）

2. チーム開発で役立つ設定の共有化ルール

eBPFやSystem Probeのパラメータは、カーネルバージョン（Linux Kernel 4.15以上、できれば5.x以上推奨）や環境（EKS, GKE, オンプレ等）によってチューニングが必要になる場合がある。

  • GitOps管理: `datadog.yaml` やKubernetesのHelmチャート（`values.yaml`）は必ずモノレポのインフラストラクチャディレクトリで一元管理し、PRレビューを必須とする。
  • 環境変数のオーバーライド: 開発環境（Dev）と本番環境（Prod）で `max_tracked_connections` などのリソース消費量を分けるため、Helmのテンプレート機能で動的に制御する。

Helm values.yaml のベストプラクティス例
agents:
useHostNetwork: false
systemProbe:
enabled: true
# 本番環境では多めに、ステージングでは省リソースに
maxTrackedConnections: {{ .Values.environment.isProduction | ternary 262144 32768 }}
network:
enabled: true

—

結び：カーネルを見据えるエンジニアであれ

オブザーバビリティの進化は、アプリケーションの「中身」を覗くことから、OSの「心臓部」であるカーネルをシームレスに観測する時代へとシフトした。

Datadog System ProbeとeBPFを導入することは単なるツールのアップグレードではない。「見えない不安」を「確実なデータ」に置き換え、障害対応の主導権を完全にエンジニアリングチームに取り戻すための最強の武器である。

今日からあなたのインフラストラクチャにもカーネルレベルの目を宿し、ノイズのない、真に持続可能なシステム運用を実現してほしい。

スポンサーリンク
タイトルとURLをコピーしました