【AI時代のLinuxエンジニア生存戦略】第2回：eBPFとオブザーバビリティで「システムの真実」を透視する

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
大好評の「AI時代のLinuxエンジニア生存戦略」シリーズ、第2回へようこそ！

AIやクラウドのマネージドサービスが発達した現代において、システムは極端に複雑化（マイクロサービス化）しました。一つのWebサイトを表示する裏側で、数十個のAPIが絡み合い、何百ものコンテナが連携しています。
このような環境で「Webサイトの表示がたまに1秒遅れる」という障害が発生した時、あなたはどうしますか？

先生、僕ならとりあえず top コマンドを見てCPUやメモリが足りているか確認します！あとは /var/log/nginx/error.log を見て、何かエラーが出ていないか調べます。もし分からなければ、ログを全部コピーしてChatGPTに「原因を教えて！」って投げ込みますね。

コウ君、それは10年前の「レガシーな監視（モニタリング）」の手法よ！
現代の複雑なシステムでは、エラーログに何も残らない『沈黙のスローダウン』が一番恐ろしいの。AIはあなたが与えたログからしか推測できないから、ログに証拠がなければAIもお手上げよ。
だからこそ、私たちはAIに頼る前に、OSのカーネル内部で何が起きているのかを『透視』する技術が必要なの。それが『オブザーバビリティ（可観測性）』と『eBPF』よ！

本記事では、対象OSを最新の Ubuntu 26.04 LTS (Linux Kernel 7.0) に設定し、インフラエンジニアの市場価値を決定づける最新技術「eBPF」を用いたトラブルシューティングと可観測性の極意を、8000文字超えの特大ボリュームで徹底的に解説します。

1. 監視（モニタリング）の限界と「可観測性（オブザーバビリティ）」への進化

まず、SRE（サイト信頼性エンジニア）の世界で常識となっている「モニタリング」と「オブザーバビリティ」の違いを明確にしましょう。これらは似て非なる概念です。

1-1. モニタリング（監視）とは？

モニタリングとは、「あらかじめ想定されている障害」を検知するための仕組みです。
例えば「CPU使用率が90%を超えたらアラートを鳴らす」「Nginxが落ちたらSlackに通知する」といったものです。これは「既知の未知（Known Unknowns）」に対する防御策であり、ダッシュボードを見て「何が起きているか」を把握するためのものです。

1-2. オブザーバビリティ（可観測性）とは？

一方、オブザーバビリティは「全く想定していなかった未知の障害」の原因を究明するための能力です。
「CPUもメモリも余裕がある。ネットワークの帯域も余っている。なのに、なぜかユーザーの決済処理だけがたまに5秒かかる」。このような「未知の未知（Unknown Unknowns）」に直面したとき、システムが自らの内部状態を外部からどれだけ推測（デバッグ）できるかを示す度合いが「可観測性」です。

生成AIは、ログやメトリクスという「与えられた情報」から推測することは得意ですが、「そもそもログに出力されていない情報（カーネル内で起きている微小な遅延など）」を勝手に取得することはできません。だからこそ、私たちがシステムにオブザーバビリティを組み込み、隠された真実のデータを取り出してAIに食わせる（あるいは人間が分析する）技術が必要不可欠なのです。

2. Ubuntu 26.04の切り札「eBPF」という黒魔術

オブザーバビリティを極限まで高めるための技術、それが「eBPF（Extended Berkeley Packet Filter）」です。Ubuntu 26.04 LTS（Linux Kernel 7.0）において、この技術は完全に成熟し、インフラ運用の必須スキルとなりました。

2-1. 従来のデバッグツール（strace等）の致命的欠陥

昔のLinuxエンジニアは、謎の遅延を調査するために strace や tcpdump といったツールを使っていました。これらは非常に強力ですが、本番環境（プロダクション）で使うと「システムがフリーズする（あるいは極端に重くなる）」という致命的な欠陥を抱えていました。

あ！僕も以前、先輩に言われて本番のWebサーバーで strace -p コマンドを叩いた瞬間、Webサイトへのアクセスが全部タイムアウトして大目玉を食らったことがあります……。あれはどうしてなんですか？

それはね、strace が「コンテキストスイッチ」という非常に重い処理を大量発生させるからよ。
アプリケーション（ユーザー空間）がOS（カーネル空間）にお願い事をするたびに、処理を一時停止させてデータをコピーして監視プログラムに渡すの。秒間何千回もリクエストを処理している本番サーバーでこれをやったら、システムが死ぬのは当然よ！

2-2. eBPFによる「カーネル内サンドボックス」の実現

eBPFは、このオーバーヘッド（負荷）の問題を完全に解決しました。eBPFは、「Linuxカーネルの内部に安全な砂場（サンドボックス）を作り、監視用のプログラムを直接カーネルの中で動かす」という革新的なアプローチをとります。

データを取り出すためにいちいちユーザー空間にデータをコピー（コンテキストスイッチ）するのではなく、カーネル空間の中で直接データを集計し、結果だけを人間に返します。そのため、本番環境で実行してもパフォーマンスの低下（オーバーヘッド）がほぼゼロという、まさに魔法のようなツールなのです。

3. eBPFアーキテクチャの真髄：VerifierとJITコンパイル

「カーネルの中に勝手にプログラムを注入するなんて、もしそのプログラムが無限ループのバグを持っていたら、OS全体がクラッシュ（カーネルパニック）するんじゃないの？」
鋭いエンジニアなら必ずそう疑問に思います。eBPFが世界中で採用されている理由は、その圧倒的な「安全性」の仕組みにあります。

3-1. 鉄壁の検問所「Verifier（検証器）」

eBPFのプログラム（C言語などで書かれたコード）をカーネルに注入しようとすると、カーネル内にある Verifier（検証器） という門番がコードを徹底的にスキャンします。

• 無限ループになるコードはないか？（必ず終了するコードか？）
• 許可されていないメモリ領域（他のプロセスのデータ）にアクセスしようとしていないか？
• プログラムのサイズが制限を超えていないか？

これらの厳格なテストを一つでもクリアできなければ、Verifierはコードの実行を冷酷に拒否します。これにより、「eBPFプログラムが原因でOSがクラッシュすることは原理的にあり得ない」という絶対の安全性が担保されています。

3-2. JITコンパイラによるネイティブな実行速度

Verifierの審査を通過したeBPFコードは、JIT（Just-In-Time）コンパイラによって、そのサーバーのCPUが直接理解できる機械語（ネイティブコード）に瞬時に翻訳されます。これにより、元からカーネルに組み込まれていた機能と同じスピードで、超高速に実行されるのです。

Ubuntu 26.04 (Kernel 7.0) では、このVerifierの性能とJITコンパイルの効率が飛躍的に向上しており、より複雑な監視プログラムを安全に動かせるようになっています。

4. 実践準備：Ubuntu 26.04 への bcc-tools / bpftrace の導入

理論を理解したところで、実際にあなたのUbuntu 26.04サーバーにeBPFの監視環境を構築しましょう。
eBPFのプログラムをC言語からゴリゴリ書くのは至難の業ですが、インフラエンジニア向けに「すぐに使える便利なeBPFツールの詰め合わせ（bcc-tools）」と、「簡単にカスタムスクリプトが書けるツール（bpftrace）」が提供されています。

4-1. インストールコマンド

SSHでサーバーにログインし、以下のコマンドを実行します。

# パッケージリストの更新
sudo apt update

# bcc-tools (BPF Compiler Collection) と bpftrace のインストール
# 依存するLinuxカーネルヘッダーも同時にインストールします
sudo apt install bpfcc-tools bpftrace linux-headers-$(uname -r) -y

インストールが完了すると、/usr/sbin/ ディレクトリに -bpfcc という拡張子がついた100種類以上の強力な監視コマンドが配置されます。これらが、AI時代のインフラエンジニアの新たな武器となります。

PR

エンジニアが最初に読むべき Linuxサーバの教科書 【電子書籍】[ 大津 真 ] 価格:3740円 (2026/7/17 19:14時点) 感想(0件)

5. 【実技1】見えない短命プロセスを捕獲する「execsnoop」

よくあるトラブルに、「数分に一回、一瞬だけCPUが跳ね上がるが、top や htop を見ても一瞬すぎて犯人のプロセスが特定できない」というものがあります。
cronで動いているシェルスクリプトや、マルウェアが不審なコマンドを一瞬だけ実行しているようなケースです。

5-1. execsnoopの実行

ここで活躍するのが execsnoop-bpfcc です。これは、システム内で「新しいプロセスが起動した（execveシステムコールが呼ばれた）瞬間」をすべてキャッチして画面に出力します。

sudo execsnoop-bpfcc

PCOMM            PID    PPID   RET ARGS
crond            10245  1        0 /usr/sbin/crond
sh               10246  10245    0 /bin/sh -c /opt/scripts/backup_db.sh
backup_db.sh     10246  10245    0 /bin/bash /opt/scripts/backup_db.sh
mysqldump        10247  10246    0 /usr/bin/mysqldump -u root wordpress
gzip             10248  10246    0 /bin/gzip

このように、バックグラウンドで一瞬だけ起動して消えていく mysqldump や gzip といったコマンドの連鎖（PPID: 親プロセスIDとPIDの親子関係）や、実行された際の引数（ARGS）までが完全に丸見えになります。
これを見れば、「あ、裏で重いバックアップスクリプトが動いていたのが遅延の原因だ」と一撃で特定できるわけです。

6. 【実技2】ディスクI/Oの真実を暴く「biolatency」のヒストグラム解析

クラウド環境（AWSのEBS等）でデータベースを運用していると、「平均的なディスクの応答速度は速いのに、なぜか時々DBのクエリが詰まってしまう」ことがあります。
平均値（Average）だけを見ていると、この「たまに起きる極端な遅延」を見逃してしまいます。

6-1. biolatencyによる遅延分布の可視化

biolatency-bpfcc は、ディスクへの読み書き（Block I/O）にかかった時間（レイテンシ）を計測し、それを「ヒストグラム（分布図）」として表示してくれます。

# 10秒間のディスクI/Oのレイテンシ分布を計測する
sudo biolatency-bpfcc 10

Tracing block device I/O... Hit Ctrl-C to end.
     usecs               : count     distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 0        |                                        |
         4 -> 7          : 0        |                                        |
         8 -> 15         : 120      |* |
        16 -> 31         : 4500     |****************************************|
        32 -> 63         : 3200     |**************************** |
        64 -> 127        : 50       |                                        |
       128 -> 255        : 10       |                                        |
       256 -> 511        : 5        |                                        |
       512 -> 1023       : 2        |                                        |
      1024 -> 2047       : 0        |                                        |
      2048 -> 4095       : 0        |                                        |
      4096 -> 8191       : 800      |******* |  <-- ここに注目！
      8192 -> 16383      : 1200     |********** |  <-- ここに注目！
     16384 -> 32767      : 500      |**** |

【プロの視点での解析】
この出力を見ると、ほとんどのI/Oは「16〜63マイクロ秒（爆速）」で処理されています。おそらくOSのページキャッシュが効いているのでしょう。
しかし、下の方を見ると「4096〜16383マイクロ秒（4〜16ミリ秒）」という遅い処理の「第二の山」ができています。
このように山が2つある状態をバイモーダル分布（双峰性分布）と呼びます。平均値を計算するとごまかされてしまいますが、実際には「クラウドストレージ側の帯域制限（バーストクレジット枯渇）に引っかかっている」等の物理的な制約が起きていることが、このヒストグラムから確実に読み取れるのです。

7. 【実技3】ネットワークのオーバーヘッドをゼロで監視する「tcplife」

マイクロサービス化されたシステムにおいて、「どのコンテナが、どの外部APIと通信していて、どれくらい時間がかかっているか」を把握するのは至難の業です。パケットキャプチャツール（tcpdump）を本番で回すと、データ量が膨大になりすぎてサーバーが死にます。

7-1. tcplifeによるセッションのライフサイクル監視

tcplife-bpfcc を使えば、TCPのセッションが「確立されてから切断されるまで」の要約データだけを、負荷ゼロで美しく抽出できます。

sudo tcplife-bpfcc

PID   COMM       LADDR           LPORT RADDR           RPORT TX_KB RX_KB MS
1234  nginx      192.168.1.100   80    203.0.113.50    54321 12.5  0.8   15.2
5678  python3    10.0.0.5        34567 8.8.8.8         443   0.2   0.5   3005.1

一目瞭然ですね。PID 5678 の Python アプリケーションが、Google（8.8.8.8）の 443番ポートと通信し、たった数百バイトのやり取りに 3005ミリ秒（約3秒）もかかっていることがわかります。
「アプリが遅い」とユーザーからクレームが来た際、「ソースコードのアルゴリズムが悪いのか」、それとも「呼び出している外部APIの応答が遅いのか」を切り分ける神ツールです。

8. プロの領域：bpftraceを用いた「自作のカーネル監視スクリプト」

bcc-tools の用意されたコマンド群でも十分強力ですが、「もっと特定の条件に絞って監視したい！」というプロの欲求に応えるのが bpftrace です。これはAWK言語のように、非常に短いスクリプト（ワンライナー）で自分専用のeBPF監視ツールを作れる仕組みです。

8-1. システムで「どんなファイルが開かれているか」を監視する

例えば、「謎のプロセスが大量のファイルをオープンしてディスクをいじめている」と疑われる場合、sys_enter_openat（ファイルを開くシステムコール）をフックして、プロセス名とファイル名を出力させるスクリプトを1行で書けます。

sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("%s opened %s\n", comm, str(args->filename)); }'

Attaching 1 probe...
node opened /etc/resolv.conf
nginx opened /var/www/html/index.html
php-fpm opened /var/run/php/php-fpm.sock
python3 opened /var/log/app.log

このように、システム内で動く全プロセスが「今、どのファイルに触っているか」が滝のように流れてきます。特定のディレクトリ（例えば /etc/passwd）を触ろうとする不審なプロセスを検知するセキュリティツールとしても応用できます。C言語を書かずに、ここまでOSの深部にアクセスできるのが bpftrace の恐ろしさです。

9. AI（LLM）とeBPFを組み合わせた次世代のインシデント調査手法

さて、ここまでeBPFを使って「カーネルの真実のデータ」を取り出す方法を学びました。最後は、冒頭で述べた「AIを部下として使いこなす」生存戦略の実践です。

eBPFが出力するデータ（ヒストグラムやシステムコールのトレース）は、人間が読むと少し難解です。そこで、この「高解像度なeBPFの出力データ」を生成AI（GeminiやChatGPT）のプロンプトに食わせるのです。

9-1. AIへの次世代プロンプト例

「あなたはLinuxカーネルチューニングとSREのシニアエキスパートです。
Ubuntu 26.04 (Kernel 7.0) の本番DBサーバーにて、不定期なパフォーマンス低下が発生しています。

以下は、障害発生時に取得した `biolatency-bpfcc` と `tcplife-bpfcc` の出力結果です。

【biolatency の出力】
[ここにヒストグラムを貼り付け]

【tcplife の出力】
[ここにTCPセッションのデータを貼り付け]

このデータを基に、以下の3点を分析してください。
1. ディスクI/Oのレイテンシ分布から読み取れる、ストレージ層のボトルネックの有無。
2. ネットワークの遅延とディスクI/Oの遅延の相関関係の推測。
3. 今後、OSのカーネルパラメータ（sysctl）またはDBの設定で調整すべき項目の提案。」

AIは、ログの表面的なエラーメッセージ（Symptoms）をググるだけのアシスタントから、「物理的な限界とOSの挙動（Root Cause）を考察する超優秀なコンサルタント」へと化けます。
「eBPFで真実のデータを抽出する（人間の仕事）」×「そのデータを多角的に分析し解決策を提示する（AIの仕事）」。これが、2026年以降のインフラエンジニアが生き残るための「最強のペアプログラミング（協業）」の形です。

総まとめ：カーネルの声が聞こえるエンジニアになれ

第2回の講座、本当にお疲れ様でした！

モニタリングからオブザーバビリティへのパラダイムシフト、そしてUbuntu 26.04の切り札である eBPF の凄さを実感していただけたでしょうか。

1. eBPFはカーネル内の安全なサンドボックスである： VerifierとJITのおかげで、本番環境でも負荷ゼロで安全に監視ができる。
2. 見えないものを見る技術： 短命プロセス（execsnoop）、隠れ遅延（biolatency）、通信のオーバーヘッド（tcplife）を可視化できる。
3. AIとの最強のシナジー： 表面的なログではなく、カーネル深部の高解像度データをAIに食わせることで、真の根本原因解決が可能になる。

ブラックボックス化したクラウドやコンテナ環境において、「なぜか遅い」「なぜか落ちる」という魔物と対峙したとき、eBPFというレントゲンを持っていれば、あなたはもう闇雲に設定を弄る必要はありません。カーネルが発する「真実の声」を聴き取ることができるからです。

次回、第3回「MLOpsとLinux：AIモデルを安定稼働させるインフラ設計術」では、いざAIモデル（LLMや推論API）をサーバーで動かす際に直面する「GPUリソースの制御」と「メモリの枯渇問題」にLinuxエンジニアとしてどう立ち向かうのか、実践的なアーキテクチャ設計を解説します。
AIを使う側から、AIを「ホストする（飼い慣らす）側」へ。次回のレベルアップもお楽しみに！