プロセスとネットワークの監視 - システムの微細な動きと繋がりを解明する
サーバー監視において「CPU使用率が高い」という事実は、あくまで問題の表面(症状)に過ぎません。その原因が「どのプロセスの、どのユーザーが実行したコマンドなのか」、あるいは「特定の外部サービスとの通信遅延が引き金なのか」を特定できて初めて、真の解決に向けた一歩を踏み出すことができます。
Datadogは、ホスト内部でうごめく数千の「プロセス」と、それらが織りなす複雑な「ネットワーク通信(トポロジー)」を、かつてない解像度で可視化します。これを支えるのが Live Processes と Network Performance Monitoring (NPM) です。
本記事では、これら2つの強力な機能がどのように連携し、インフラエンジニアの「勘と経験」に頼らないデータ駆動型のトラブルシューティングを実現するのか、その全貌を徹底解説します。
1. Live Processes:全ホスト対応の「分散型 top コマンド」
従来の監視メトリクスは、通常15秒から1分間隔の平均値を記録します。しかし、瞬間的なプロセスのスパイクや、短命なワーカープロセスの暴走を見つけるには、この粒度では不十分です。
1.1. Live Processes の核心
Live Processesは、文字通り「今この瞬間」に実行されているプロセスを、あらゆるホストから秒単位の更新頻度で集約します。
- 一元化された top: Google検索のようなインターフェースで、全サーバーの中から
javaやpythonプロセスだけを横断検索し、メモリ消費量順に並べ替えることができます。 - コンテキストの保持: プロセス名だけでなく、実行コマンドの引数(
command line)も収集されます。これにより、同じスクリプトでも「どの引数で実行されたものが重いのか」まで特定可能です。
1.2. 過去のプロセスを「再生」する
Datadogの最大の特徴は、この詳細なプロセスリストを最大36時間分(設定による)記録している点です。障害が発生した1時間前に遡り、タイムラインをスクラブすることで、「あの時、確かにこのプロセスがCPUを食いつぶしていた」という証拠を掴むことができます。
2. Network Performance Monitoring (NPM):通信の「黒魔術」を暴く
ネットワークのトラブルは、インフラエンジニアにとって最も解決が困難な領域の一つです。アプリケーション側は「ネットワークが遅い」と言い、ネットワーク担当者は「経路に異常はない」と言う。この不毛な議論に終止符を打つのがNPMです。
2.1. eBPFテクノロジーによる魔法
NPMは、Linuxカーネルの高度な技術である eBPF を活用しています。これにより、OSのカーネルレベルでパケットの動きを極めて低負荷にキャプチャし、アプリケーションコードに一切変更を加えることなく、通信の依存関係を抽出します。
2.2. ネットワークマップ(トポロジー)
NPMは、抽出した通信データから「サービス間通信マップ」を自動生成します。
3. 主要メトリクスの読み解き:ネットワークの健康診断
NPMが提供するメトリクスは、従来の「パケット数」や「ビットレート」だけではありません。ビジネスへの影響に直結する指標にフォーカスしています。
| メトリクス | 意味すること | 異常時のサイン |
|---|---|---|
| Throughput | 単位時間あたりのデータ転送量。 | 急激な低下は通信遮断、過剰な増加はDDosやバックアップの重なりを示唆。 |
| Retransmits (再送) | 送信したパケットが届かず、再送された割合。 | **ネットワーク品質の悪化(ロス)**を直接示す、最も重要なアラート指標。 |
| RTT (Round Trip Time) | パケットが往復する時間。 | 「ネットワーク的な遅延(レイテンシ)」の正体。距離や輻輳が原因。 |
| TCP Connect Errors | 接続試行が失敗した数。 | ファイアウォールの拒否、または送信先サービスのダウンを示唆。 |
4. トラブルシューティングのワークフロー
プロセスとネットワークの情報を組み合わせることで、原因の切り分け(アイソレーション)が劇的に早まります。
ケーススタディ:DBへの接続が時々タイムアウトする
- NPMで確認: 特定のAPサーバーからDBへの
Retransmitsが急増していないかを確認。- 増えていれば:ネットワークインフラ(スイッチやNIC)またはVPCの設定を疑う。
- 増えていなければ:TCPコネクションは正常。アプリケーションの接続プール待ちを疑う。
- Live Processesで確認: そのDBサーバー上で、バックアッププロセスやバッチ処理が裏で走っていないかをチェック。
- プロセスがいれば:リソース競合(CPU争奪)が真犯人。
- いなければ:DBエンジンの内部ロック(Slow Query)を疑う。
5. 設定と導入の注意点
これらの強力な機能は、デフォルトでは最小限の収集設定になっています。真価を発揮させるためには以下の設定を datadog.yaml に追加する必要があります。
# プロセス収集の有効化
process_config:
process_collection:
enabled: true
# NPMの有効化 (Linuxのみ、system-probeが必要)
network_config:
enabled: trueCAUTION
NPMはeBPFを使用するため、非常に古いLinuxカーネル(4.4未満)では動作しません。AWSであればAmazon Linux 2以降、Ubuntuであれば16.04以降を推奨します。
6. まとめ
システムの運用において「何が起きているか」を正確に把握することは、解決への道のりの8割を占めます。
Live Processesは、個別の「実行(Do)」に光を当て、NPMはそれらの「繋がり(Connect)」を地図にします。これらが組み合わさることで、ブラックボックス化しがちな現代の分散システムは、透明性の高い、制御可能な存在へと変わります。
もし、あなたが「なぜか不安定」という言葉に悩まされているなら、まずはプロセスに耳を傾け、ネットワークの糸を解き明かしてみてください。そこには、数字だけでは語り得なかったシステムの真実が眠っているはずです。
関連記事:
出典: