午前2時の悪夢：なぜ標準ツールでは不十分なのか
午前2時、あなたの電話が鳴り響きます。優先度の高いアラートです。本番環境のデータベースの動作が極端に重くなり、APIのレスポンスタイムが急上昇しています。あなたはサーバーにSSHでログインし、topを実行します。CPU使用率は問題なさそうです。次にiostatを確認すると、ディスク使用率は90%に張り付いていますが、どのプロセスが原因なのか特定できません。top、ps、iostatといった古典的なツールは、何十年もの間、私たちの頼みの綱でした。これらは現状を素早く把握するには最適ですが、「何が」起きているかしか教えてくれません。「なぜ」起きているのか、あるいは「誰に」責任があるのかを説明してくれることは滅多にありません。
これらの伝統的なユーティリティは/procファイルシステムに依存しています。これは集計された統計情報、つまり本質的にはある時点のスナップショットを提供します。そのため、短命なプロセスや、個々のI/Oリクエストの細かなレイテンシを見逃してしまうことがよくあります。ここでeBPF（Extended Berkeley Packet Filter）がオブザーバビリティ（観測性）を再定義します。eBPFを使用すると、Linuxカーネル内でサンドボックス化されたプログラムを直接実行できます。カーネルのソースコードを書き換えたり、リスクのあるモジュールをロードしたりすることなく、ほぼすべてのイベントを追跡できます。
BPF Compiler Collection (BCC) は、このテクノロジーを扱いやすくしてくれます。BCCは、複雑なコンパイルロジックを肩代わりしてくれる数十のビルド済みPythonスクリプトを提供します。これらを使うのにカーネルエンジニアである必要はありません。私は、手作業でログを調べるのに何時間もかかるような謎を、これらのツールを使って数分で解決してきました。
インストール：BCCをマシンに導入する
BCCを実行するには、カーネルが比較的新しいバージョン（4.1以上）である必要があります。Ubuntu 20.04以降、Debian 11以降、またはRHEL 8以降を実行している環境のほとんどは、そのままで準備が整っています。パッケージ名はディストリビューションによって若干異なりますが、含まれるツールは同じです。
Ubuntu/Debianの場合
Debianベースのシステムでは、パッケージは標準リポジトリで提供されています。また、実行中のバージョンに一致するカーネルヘッダーもインストールする必要があります。これにより、BCCが実行時にBPFプログラムをコンパイルできるようになります。
sudo apt update
sudo apt install bpfcc-tools linux-headers-$(uname -r)RHEL/CentOS Stream/AlmaLinuxの場合
RHELベース of システムでは、AppStreamリポジトリにBCCが含まれています。以下のコマンドを使用して開始します。
sudo dnf install bcc-tools注意点として、RHELやAlmaLinuxのユーザーは、通常これらのスクリプトが/usr/share/bcc/toolsに格納されていることに気づくでしょう。そのディレクトリをPATHに追加するか、フルパスでツールを呼び出す必要があるかもしれません。
設定：カーネル環境の準備
ソフトウェアをディスクにインストールするのは最初の一歩に過ぎません。BCCは実行時にCコードをBPFバイトコードにコンパイルするため、カーネル設定へのアクセスが必要です。最小構成のクラウドイメージや制限されたコンテナで作業している場合、/lib/modules/$(uname -r)/build内のファイルが見つからないというエラーが表示されることがあります。
私はこれを4GBのRAMを搭載した本番環境のUbuntu 22.04インスタンスでテストしました。linux-headersが正しくマッピングされていることを確認することで、BCCを2秒以内に初期化できました。これらがないと、ツールは不可解なコンパイルエラーを出して失敗します。データベースがハングアップしているとき、スピードは極めて重要です。
opensnoopを実行してセットアップを確認しましょう。このツールは、OS全体で行われるすべてのopen()システムコールを追跡します。ファイルパスが表示され始めれば、詳細な診断の準備は完了です。
sudo /usr/sbin/opensnoop-bpfcc様々なPIDによってアクセスされているファイルのライブストリームが表示されれば、真のパフォーマンスボトルネックを探す準備が整ったことになります。
検証とモニタリング：実戦で役立つツール群
BCCスイートには100以上のユーティリティが含まれています。インシデントの真っ最中にマニュアルを読んでいる時間はありません。私は、一般的なパフォーマンスの謎の約90%を解決できる4つの特定のツールをリストアップしています。
1. execsnoopによる短命プロセスの追跡
topではシステムがアイドル状態に見えるのに、CPU使用率がスパイクするのを見たことはありませんか？これは多くの場合、数ミリ秒で起動して終了するスクリプトやcronジョブといった「ゴースト」プロセスが原因です。標準的なツールは、これらを捉えるほど頻繁にポーリングを行いません。
sudo execsnoop-bpfccこれは、親PIDや完全なコマンドライン引数を含む、すべての新しいプロセス実行を表示します。かつて、自分自身を再帰的に呼び出していた壊れたシェルスクリプトを見つけたことがあります。それは毎秒2,500ものプロセスを生成しており、htopでは完全に捕捉できなかった狂乱状態でした。
2. biolatencyによるディスクレイテンシの測定
ディスク使用率はしばしば誤解を招きます。使用率100%のディスクが依然として良好に動作していることもあれば、使用率10％のディスクが高いシークタイムのために大幅な遅延を引き起こしていることもあります。biolatencyは、実際のI/Oレイテンシのヒストグラムを提供することで、ノイズを排除します。
sudo biolatency-bpfcc 10 1このコマンドは10秒間データを収集し、分布を表示します。クラスター（塊）を探してください。スループットの数値がどうであれ、128ms以上の範囲に高いカウントが見られる場合、ストレージバックエンドに問題があります。
3. tcptopによるネットワーク帯域を占有するプロセスの特定
ネットワークが飽和状態のとき、iftopはホストごとの帯域幅を表示します。しかし、tcptopはプロセスごとのスループットを表示します。これは、どの特定のコンテナやサービスが帯域幅を食いつぶしているかを特定する最速の方法です。
sudo tcptop-bpfccこれはTCP接続版のtopのように機能します。PID、IPアドレス、および受信/送信スループットをKB単位で表示します。暴走したバックアップスクリプトやデータ漏洩をリアルタイムで発見するのに最適です。
4. ext4slowerによるファイルシステムのレイテンシ特定
ハードウェアは正常でも、ロックの競合によりファイルシステム層が遅くなることがあります。EXT4を使用している場合、ext4slowerは読み取りや書き込みなどの一般的な操作を追跡します。そして、10msなどの特定のしきい値を超えた操作のみを報告します。
sudo ext4slower-bpfcc 10これはデータベースのトラブルシューティングにおいて非常に貴重です。トランザクションログへのwrite()コールに50msかかれば、データベースのパフォーマンスはガタ落ちします。このツールは、遅延が発生した正確なファイルとPIDを特定します。
結果の解釈
BCCツールを使用する極意は、外れ値を見つけることです。健全なシステムでは、ヒストグラムは「トップヘビー」であるべきです。つまり、ほとんどの操作がマイクロ秒単位で行われている状態です。ミリ秒や秒の範囲に第2のピークが現れる「バイモーダル（二峰性）」な分布が見られたら、そこがパフォーマンス低下の原因です。
本番環境ではオーバーヘッドが大きな懸念事項となります。straceはプロセスを著しく停滞させ、速度を10倍以上低下させることがあります。BCCツールはeBPFを使用してオーバーヘッドを極めて低く（通常は1%未満）抑えています。この安全性により、アプリケーションをクラッシュさせることなく、高負荷なライブサーバー上で診断を実行できます。
次にシステムが重くなり、uptimeが高いロードアベレージを示しているのに明らかな原因が見当たらないときは、推測を捨てましょう。execsnoopを実行してプロセスの入れ替わりをチェックし、biolatencyでディスクを調査してください。通常、コーヒーが冷める前に、これらのツールのいずれかが根本原因へと導いてくれるはずです。
