技術情報

ホスティングにおけるBPFtrace：サーバーの問題をより迅速に特定する

Linux環境におけるbpftraceホスティングが、エラーの原因を特定するまでの時間を劇的に短縮し、その過程で カーネル-信号を活用できるようにします。当て推量に頼るのではなく、システムコール、I/Oレイテンシ、ネットワークイベントをリアルタイムで イービーピーエフ-コンテキスト – サービスを停止することなく。.

中心点

以下の要点では、本記事の主な内容について簡単に概説しています。.

深い洞察 カーネルから直接、システムコール、I/O、ネットワークにおいて
オーバーヘッドが少ない カーネル内の安全なeBPFプログラムのおかげで
迅速な絞り込み プロセス、I/O、およびDBのボトルネックについて
柔軟なトレース フィルタ、ヒストグラム、スタックトレース付き
診療ワークフロー 緊急事態への対応は数分以内

bpftraceがホスティング環境における問題をより迅速に可視化する理由

現代のホスティング・スタックでは、多くのサービスが リソース, 一方、従来のダッシュボードは表面的な数値しか表示しないことがよくあります。私はさらに一歩踏み込みます。bpftraceはシステムコール、トレースポイント、関数フックにフックして、何が実際に処理を遅らせているのかを明らかにしてくれます。 CPU使用率が目立たない状態でのタイムアウトは、多くの場合、I/Oレイテンシやブロッキング呼び出しを示唆しています。まさにその点で、bpftraceはカウント、レイテンシヒストグラム、そして直接 カーネル. そこで、負荷の原因を具体的なプロセス、コンテナ、またはクエリに特定し、的を絞った対応を行います。.

eBPFとbpftraceの連携について

eBPFは、検証済みの小さなプログラムを カーネル …し、第一手情報のイベントを提供します。bpftraceは、実行時にスクリプトをeBPFバイトコードにコンパイルし、それらをプローブ、フィルター、アクションに紐付けます。例えば、ファイル読み取り用のトレースポイントを選択し、プロセス名でフィルタリングして、レイテンシをヒストグラムに集計します。複数のシグナルを同時に測定する場合でも、「プローブ – フィルター – アクション」というパターンは把握しやすいままです。このようにして、数分で観測セットを構築し、重要な指標を供給している。

いざという時のための手っ取り早い一言

インシデント対応ではスピードが重要です。私は、数秒でパターンを把握できる簡潔なワンライナーを活用しています。私がよく使う定番のフレーズをいくつか紹介します：

# プロセス名ごとの「ノイズの多い」ファイルアクセスをカウント（5秒ごとにクリア）
bpftrace -e „tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }
interval:s:5 { clear(@); }“

# ファイル読み取りのレイテンシヒストグラム（プロセス別）
bpftrace -e '
kprobe:vfs_read { @ts[tid] = nsecs; }
kretprobe:vfs_read /@ts[tid]/ {
  @lat[comm] = hist(nsecs - @ts[tid]);
  delete(@ts[tid]);
}'

# TCP再送信をカーネルスタックと束ねる
bpftrace -e 'tracepoint:tcp:tcp_retransmit_skb { @[kstack] = count(); }'

# SoftIRQの時間を合計する（10秒のウィンドウ）
bpftrace -e '
tracepoint:irq:softirq_entry { @t[args->vec] = nsecs; }
tracepoint:irq:softirq_exit /@t[args->vec]/ {
  @soft[args->vec] = sum(nsecs - @t[args->vec]);
  delete(@t[args->vec]);
}
interval:s:10 { print(@soft); clear(@soft); }'

# accept() の負荷を DB サーバーまたは Web サーバー上で可視化する
bpftrace -e 'tracepoint:syscalls:sys_enter_accept4 /comm=="mysqld" || comm=="nginx"/ { @[comm] = count(); }'

これらの「プローブ」を使えば、あるサービスが異常に多くのファイルを開いていないか、I/Oが停滞していないか、ネットワークが再送信を繰り返していないかを素早く確認できます。その後、フィルタをさらに絞り込みます。 PID, 、プロセス名、またはパス。.

稼働中のサーバーにおけるプロセスおよびリソースの診断

個々のアカウントやコンテナが共有サーバーのパフォーマンスを低下させている場合、私はシステムコールを プロセス そして、「騒がしい」原因を特定します。execveの呼び出しが異常に多い場合は、プロセスの起動が過剰であることを示しており、これは例えば不具合のあるcronジョブの存在を裏付けています。あるサービスが無数のファイルを開いている場合、私はそれを即座に把握し、フィルタを使って特定のパスに検査範囲を絞り込みます。アクセス数の多いWebサーバーにとっては、これは非常に貴重な機能です。なぜなら、問題の原因を迅速に特定できるからです。ツール活用のアイデアをさらに深く知りたい方は、以下のアプローチも併せてご参照ください。 eBPF解析ツール …し、その原則を自社のホストに適用する。.

cgroups を用いたコンテナおよび Kubernetes の視点

マルチテナント環境やKubernetesホストでは、明確なテナント分離が必要です。bpftraceは、そのために cgroup-視点こそが鍵：

# cgroup（コンテナ）およびプロセス名ごとにシステムコールをグループ化
bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[cgroup, comm] = count(); }'

こうすることで、個々のPIDを手動で収集することなく、どのコンテナが騒音の原因かを見極めることができます。より詳細な分析を行う際には、追加のフィルターを設定します：

# PHP-FPM のみを対象とする（例：アプリコンテナ内）
bpftrace -e 'tracepoint:syscalls:sys_enter_execve /comm=="php-fpm"/ { @[pid] = count(); }'

Kubernetesでは、よく ノード そして、cgroupごとにグループ分けします。測定結果を明確に参照できるように、cgroup IDとPod／コンテナ名の対応関係を、私のランブック（kubectl/CRI）に記録しておきます。.

I/Oおよびファイルシステムのレイテンシを確実に測定する

「まあまあの」CPUを使っているにもかかわらずページの読み込みが遅い場合は、多くの場合、以下の原因が考えられます 入出力-ボトルネックを特定します。プロセスごとの読み取り・書き込み操作を計測し、処理が遅いパスを記録し、レイテンシのヒストグラムを作成します。 WordPress環境では、これにより、多数の小さなPHPファイルや大きなメディアファイルのどちらがスループットを低下させているかを特定します。その後、キャッシュ、PHP Opcodeキャッシュ、あるいはファイルシステムのチューニングのどれを優先して適用すべきかを判断します。さらに深く掘り下げたい方は、以下の背景情報をご覧ください。ストレージにおけるディスクのレイテンシまた、測定ポイントを的確に調整することができます。.

オフCPUおよびロックの待ち時間を可視化する

すべての待機時間がI/Oであるとは限らない：スレッドは オフCPU ブロックする――たとえばロックなど。その際、私はFutexイベントとSchedulerイベントを利用しています。.

# Futexの待機時間（ロック競合）のヒストグラム
bpftrace -e '
tracepoint:syscalls:sys_enter_futex { @ts[tid] = nsecs; }
tracepoint:syscalls:sys_exit_futex /@ts[tid]/ {
  @futex[comm] = hist(nsecs - @ts[tid]);
  delete(@ts[tid]);
}'

こうしたプロファイルを見れば、PHP-FPMワーカーやDBスレッドがロックを待機しているかどうかがわかります。I/Oヒストグラムと組み合わせて、私は ストレージ- より コンカレンシー-問題。.

ネットワークエラー、ソフトIRQ、再送信を可視化する

時折発生するタイムアウトに関する苦情については、私はしばしばその原因を ネットワーク-信号を返します。私はカーネル内で直接、TCPの再送信、RSTイベント、および接続切断を監視しています。さらに、過負荷になったネットワークキューはSoftIRQに痕跡を残すため、そちらも確認しています。再送信とソフトIRQ時間の増加というパターンは、パケットドロップ、バッファのボトルネック、あるいはQoSの問題を示唆しています。原因究明には、以下の背景記事も参考になります。 SoftIRQとネットワークスループット, 、これをbpftraceの測定結果と関連付けています。.

事例：時折504タイムアウトが発生するWordPressホスティング

共有サーバーで504エラーが発生していますが、CPU使用率はわずか35%です。私の手順は以下の通りです：

「ネットワークかI/Oか」という仮説。再送信とSoftIRQの時間測定を開始した。結果：再送信は少なく、SoftIRQは安定している。.
I/Oへの切り替え：vfs_readのレイテンシヒストグラムによると、php-fpmでは80 msまでのロングテールが見られる。リクエストごとにopenatの呼び出しが多数発生している。.
wp-content および wp-includes 配下のパスにフィルターを適用：無数の小さなファイル読み取りが大部分を占めている。.
ロックのクロスチェック：Futex-Histoに異常なし – ロック競合なし。.
対策：OPCacheの設定を調整し、静的アセットをより積極的にキャッシュする。これにより、openatカウントとレイテンシが低下する。.

アクティブなトレース時間が15分未満であることから、ネットワークの問題ではなく、 ファイルI/Oとキャッシュの欠如 タイムアウトの原因となります。.

データベースとPHP-FPM：ボトルネックを迅速に特定する

MySQL/MariaDB では、 DBプロセス 。接続が滞ったり、TLSハンドシェイクがハングアップしたりしていないかを確認するため、accept/connectフェーズを追跡しています。PHP-FPMについては、execveやファイルアクセスが異常に多いかどうかを確認し、キャッシュが機能していない可能性がないか調べます。特定のシステムコールにおけるスタックトレースを確認することで、リクエストがどのコード箇所で待機しているかを特定します。このようにして、ネットワーク、アプリケーション、データベースを段階的に除外し、最も近い原因を特定します。場所.

生産性の高いサーバーのためのベストプラクティス

私は、すべてのトレースを明確な 問題提起 また、フィルタを使ってプローブを絞り込みます。時間制限や間隔を設定することで、データ量を管理可能な範囲に抑えます。繰り返し行う分析については、PID、cgroup、プロセス名などの適切なデフォルトフィルターを設定したスクリプトを保存しています。顧客のホストで実行する前に、複雑なスクリプトはステージング環境でテストします。これにより、オーバーヘッドを最小限に抑え、不必要な 副作用.

実務における測定精度、オーバーヘッド、および限界値

以下の点に注意すれば、bpftraceはターゲットを絞ったプローブを使用しても、CPUオーバーヘッドは1桁パーセント台に抑えられます：

入口でのろ過: マップで振り分ける前に、早い段階で（例えば comm/PID などで）フィルタリングしています。.
サンプリング: 非常に高温のサンプルについては、サンプリングを使用しています。例えば、イベントの1%など：
```
tracepoint:syscalls:sys_enter_openat
/ rand() % 100 == 0 / { @[comm] = count(); }
```
スタックトレースを最小限に抑える: kstack/ustack は必要な場合のみ――まずは数を数え、それから深さを増していく。.
バッファサイズ: イベントのピーク時には、リングバッファの容量を増やします：
```
export BPFTRACE_PERF_RB_PAGES=4096
```
ウィンドウを短く保つ: 間隔（5～30秒）を設け、明確な終了点を定めることで、データの混乱を防ぐ。.

「ドロップされたイベント」が見られた場合は、バッファを増やしたり、スタックの深さを減らしたり、フィルタを厳しくしたりします。精度を高めるためには、私は トレースポイント (安定版ABI) 対 kprobes（カーネル関数名は異なる場合があります）。.

セキュリティ、ガバナンス、およびマルチテナントに関するルール

共有ホスティングでは、私は以下の点に厳格に注意を払っています データ保護 そして明確な範囲設定。私は技術的なシグナルを追跡しており、顧客データは追跡しません。また、追跡の理由、範囲、期間を記録しています。マルチテナント環境については、誰がトレースを開始できるか、どのようなフィルタが必要か、いつトレースを終了するかといった明確なガイドラインを定めています。機密性の高いパスが含まれるログについては、その量を最小限に抑えるか、仮名化処理を施します。これにより、テナントの境界を侵害することなく、活用可能な技術データを取得し、 コンプライアンス にある。

移植性：BTF、シンボル分解能、および安定したプローブ

堅牢なスクリプトを作成する際には、私は BTF- フィールド解決の際に bpftrace を支援する型情報 (vmlinux)。これらが欠けている場合、kprobes ではなくトレースポイントを使用することを優先します。 uprobes （ユーザーランド）では、ストリップされていないバイナリや個別のデバッグシンボルが必要になります。特にPHP-FPMやmysqldの場合は、その手間をかける価値があります。「bpftrace –info」でバージョンを確認し、カーネルによってイベント名が異なる場合に備えて、スクリプト内に小さな互換性ブロックを用意しています。.

診療ワークフロー：症状から原因の特定まで15分

まず、私は次のことを定式化する。仮説: ネットワーク、I/O、CPU、それともDBか？その場合、再送信やファイルアクセス遅延など、最も可能性の高いレベルごとに高速トレースを設定します。最初の数分で何らかのパターンが見て取れる場合は、フィルタを絞り込み、スタックトレースを追加し、実行時間を制限します。疑いが裏付けられた場合は、影響を受けているサービスのより深い部分で測定を行い、関連するパスだけを捕捉します。この絞り込みを行うことで、手探りの状態を避け、最も狭い範囲に素早く絞り込むことができます。原因.

ランブック：15分間の初期対応

0～2分: 仮説を選択（ネットワーク／I/O／CPU／DB）。Baseline-One-Liner を実行する。.
3～5分: 最初の異常値を特定する（例：openatカウントの増加、再送信、futexヒストグラムなど）。.
6～8分: フィルタの精度向上（comm/PID/cgroup、パス）およびレイテンシヒストグラムの追加。.
9～12分: コードの該当箇所を可視化するために、ホットスポットでのみスタックトレースを有効にする。.
13～15分: 対策を考案し（キャッシュ、制限、設定変更など）、簡単にテストを行う。.

比較表：プローブと日常生活での活用例

以下の表は典型的なものである。試料, 、その適用分野、そしてホスティングの文脈における主な利点。私は、適切な測定ポイントを素早く選びたいときに、これをメモとして活用しています。.

プローブの種類	用途	例	ベネフィット
tracepoint:syscalls	システムコールのカウント／フィルタリング	sys_enter_openat、execve	„「ラウテ」“ プロセス探す
kprobe/kretprobe	カーネル関数の測定	vfs_read、tcp_retransmit	I/Oおよびネットワーク-遅延時間目に見える
uprobes/uretprobes	ユーザーランド関数のトレース	mysqld、php-fpm のシンボル	DB／アプリのホットスポットを特定する
tracepoint:net/*	ネットワークイベントを特定する	TCPの再送信、RST	タイムアウト-原因絞り込む
perf events	CPUおよびスケジューラの観点	on-cpu/off-cpu プロファイル	スケジューリングのボトルネックを特定する

管理者およびDevOps担当者向け要約

bpftrace は私に鋭い レンズ 従来のモニタリングでは見落とされがちな、カーネルやアプリケーションのシグナルに注目します。測定結果が明確になるよう、まずは小規模に始め、的を絞ってフィルタリングを行い、実行時間を管理します。わずか数行のスクリプトで、プロセスのノイズ、ファイルの遅延、ネットワークの再送信、データベースの待ち時間を検出できます。このアプローチにより、本番環境のホストにおける平均解決時間（MTTR）が顕著に短縮されます。bpftraceをワークフローに組み込むことで、ホスティングインシデントを的確に解決し、WebサイトやAPIのパフォーマンスを著しく向上させることができます。 レスポンシブ.