SystemTap は、実行中の Linux カーネルの振る舞いを動的にモニターおよびトレースする 1 つの方法です。ここで鍵となる言葉は「動的」です。SystemTap では、計測機能を備えた特殊なカーネルを作成することなく、実行時に動的に計測機能をインストールすることができるからです。SystemTap はその動的トレースを行うために Kprobes というアプリケーション・プログラミング・インターフェース (API) を使用します。この記事ではこの API について詳しく説明しますが、まずは以前のカーネルで行われていたトレースの手法をいくつか説明し、その上で SystemTap のアーキテクチャーと使用方法を詳しく探っていきます。
SystemTap は、Sun Solaris オペレーティング・システムを起源とする DTrace と呼ばれるかつての技術によく似ています。DTrace 内部では、開発者は D プログラミング言語 (C 言語のサブセットですが、トレース特有の振る舞いをサポートするように手が加えられています) でスクリプトを作成することができます。DTrace スクリプトのなかに含まれるのは、数々のプローブと、各プローブが「起動」されるとそれに対応して実行されるアクションです。プローブには例えばシステム・コールを呼び出すだけの単純なものもあれば、コードの特定の行を実行するといったもっと複雑な動作をするものもあります。リスト 1 は、単純な DTrace スクリプトの一例です。このスクリプトは、プロセスごとのシステム・コールの数をカウントします (カウントをプロセスに関連付けるには、辞書が使用されることに注意してください)。このスクリプトのフォーマットには、プローブ (システム・コールが行われると起動されるプローブ) とアクション (対応するアクションのスクリプト) が組み込まれています。
リスト 1. プロセスごとのシステム・コール数をカウントする単純な DTrace スクリプト
syscall:::entry
{
@num[pid,execname] = count();
}
|
DTrace は Solaris のなかでも羨望を集める技術であったため、Solaris 以外のオペレーティング・システムにもこの技術が展開されていったのは当然のことです。DTrace は CDDL (Common Development and Distribution License) の下でリリースされるようになり、FreeBSD オペレーティング・システムに移植されました。
便利なカーネル・トレース機能としては他にも、IBM が IBM® AIX® オペレーティング・システムのバージョン 6.1 用に開発した ProbeVue があります。ProbeVue はシステムの振る舞いとパフォーマンスを調べるためだけでなく、特定のプロセスに関する詳細な情報を表示するためにも使用することができます。このツールはこのような動的機能を、標準カーネルを使って実現します。例えばリスト 2 に記載する ProbeVue スクリプトは、sync システム・コールを呼び出している特定のプロセスを表示します。
リスト 2. sync を呼び出したプロセスを特定する単純な ProbeVue スクリプト
@@syscall:*:sync:entry
{
printf( "sync() syscall invoked by process ID %d\n", __pid );
exit();
}
|
DTrace と ProbeVue がそれぞれのオペレーティング・システムでどれほど役立っているかを考えれば、Linux を対象としたオープンソース・プロジェクトの誕生は当然の成り行きでした。2005年にオープンソース・プロジェクトとして開始された SystemTap は、DTrace のような機能と ProbeVue のような機能の両方を兼ね備えています。これを開発したのは、Red Hat、Intel、Hitachi、IBM といったメンバーが参加するコミュニティーです。
上記で挙げたソリューションのいずれにしてもプローブを使用し、プローブの起動時に対応するアクション・スクリプトを実行することによって同様の機能を提供します。次のセクションでは、SystemTap のインストールについて説明します。その後、SystemTap のアーキテクチャーと SystemTap の使用方法について詳しく説明します。
お使いのディストリビューションとカーネルによっては、SystemTap をインストールするだけで SystemTap をサポートできる場合もありますが、そうでない場合にはデバッグ・カーネル・イメージが必要となります。このセクションで説明するのは、Ubuntu バージョン 8.10 (Intrepid Ibex) での SystemTap のインストール手順です。この手順は、SystemTap をインストールする典型的な手順ではありません。これ以外のディストリビューションおよびバージョンでのインストール方法についての詳細は、「参考文献」を参照してください。
ほとんどのユーザーにとって必要となる作業は単純に SystemTap をインストールすることだけです。Ubuntu の場合は、以下のように apt-get を使用してインストールします。
$ sudo apt-get install systemtap |
インストールが完了したら、カーネルをテストして、SystemTap をサポートしているかどうかを調べます。それには、以下の単純なコマンドライン・スクリプトを実行します。
$ sudo stap -ve 'probe begin { log("hello world") exit() }'
|
上記のスクリプトが正常に動作すると、標準出力 (stdout) に「hello world」と表示されるはずですが、そうならない場合には残念ながら追加作業が必要になります。Ubuntu 8.10 にはデバッグ・カーネル・イメージが必要であるためです。本来なら apt-get を使用するだけで linux-image-debug-generic パッケージを取得できるはずですが、この場合には apt-get で直接取得できなかったので、パッケージをダウンロードし、dpkg を使ってインストールします。この汎用デバッグ・イメージをダウンロードしてインストールする方法は以下のとおりです。
$ wget http://ddebs.ubuntu.com/pool/main/l/linux/
linux-image-debug-2.6.27-14-generic_2.6.27-14.39_i386.ddeb
$ sudo dpkg -i linux-image-debug-2.6.27-14-generic_2.6.27-14.39_i386.ddeb
|
これで、汎用デバッグ・イメージはインストールされたはずです。Ubuntu 8.10 には、もう 1 つだけ必要な追加作業があります。それは SystemTap ディストリビューションの問題を解決することですが、SystemTap ソースを変更すれば、この問題は簡単に解決することができます。そのためのランタイム・ファイル time.c の更新方法については、「参考文献」を参照してください。
カスタム・カーネルを使用している場合は、確実に CONFIG_RELAY、CONFIG_DEBUG_FS、CONFIG_DEBUG_INFO、および CONFIG_KPROBES の各カーネル・オプションが有効になるようにする必要があります。
ここからは、実行中のカーネルに動的プローブを挿入する方法を理解するために、SystemTap の詳細をいくつか掘り下げて説明します。その後、スクリプトの作成プロセスから、作成したスクリプトを実行中のカーネル内でアクティブにする方法に至るまで、SystemTap がどのように機能するかを説明します。
SystemTap で実行中のカーネルを計測する手段としては、Kprobes と return プローブの 2 つが使用されます。一方、カーネルを理解する上で重要な要素は、シンボル情報 (関数と変数、およびそれぞれのアドレスなど) を提供するカーネルのマップです。マップがあれば、あらゆるシンボルのアドレスを解決することも、プローブの振る舞いをサポートするように変更することもできます。
バージョン 2.6.9 以降でメインライン Linux カーネルに統合されている Kprobes は、カーネルの探査を目的とした汎用サービスを提供します。Kprobes は何種類かのサービスを提供しますが、なかでも最も重要なのは Kprobe と Kretprobe の 2 つです。Kprobe はアーキテクチャーに特化されており、プローブ対象の命令の先頭バイトにブレークポイント命令を挿入します。ブレークポイント命令にヒットするとプローブ固有のハンドラーが実行され、それが完了すると本来の命令の実行が (ブレークポイントから) 再開され、実行が継続されます。
Kretprobe の場合は多少異なり、呼び出された関数から戻ってきた時点で動作します。関数には複数のリターン・ポイントがある場合もあるため、複雑なことのように思えますが、Kretprobe が実際に使用するのはトランポリン (trampoline) という単純な手法です。この手法では、関数のすべてのリターン・ポイントを計測するのではなく (これでは、すべての事例をキャッチできません)、わずかな量のコードを関数の入り口に追加します。このコードはスタックのリターン・アドレスをトランポリン・アドレス、つまり Kretprobe のアドレスに置き換えます。そのため関数の実行が終了すると、呼び出し側に制御が返される代わりに、Kretprobe が呼び出されます。そして呼び出された Kretprobe がその機能を実行した後、実際に関数を呼び出した側に制御を返すという仕組みです。
図 1 に SystemTap プロセスの基本フローを示します。このフローでは、5 つのフェーズで 3 つの対話型ユーティリティーを使用しますが、プロセスは SystemTap スクリプトから始まります。まず stap ユーティリティーを使って、stap スクリプトをプローブの振る舞いを提供するカーネル・モジュールに変換します。stap プロセスでの最初のステップは、スクリプトを解析ツリーに変換することです (pass 1)。次に精緻化ステップで、現在実行中のカーネルに関するシンボル情報を使用してシンボルを解決します (pass 2)。続く変換ステップでは、解析ツリーを C ソースに変換し (pass 3)、解決された情報を tapset スクリプト (SystemTap で定義された便利な機能を集めたライブラリー) と併せて使用します。stap での最後のステップは、カーネル・モジュールの作成です (pass 4)。これには、ローカル・カーネル・モジュール・ビルド・プロセスが使用されます。
図 1. SystemTap プロセス
カーネル・モジュールが使用可能になると、stap は制御を他の 2 つの SystemTap ユーティリティー、staprun と stapio に引き渡します。この 2 つのユーティリティーは連動して、カーネルへのモジュールのインストールを管理し、その出力を stdout にルーティングします (pass 5)。シェルで Ctrl-C が押された場合や、スクリプトが終了した場合は、クリーンアップ・プロセスによってモジュールがアンロードされ、その結果、関連するすべてのユーティリティーが終了します。
SystemTap で興味深い特徴は、スクリプト変換をキャッシュできることです。そのため、インストールされようとしているスクリプトに変更が加えられていなければ、モジュールの作成プロセスを繰り返すことなく、既存のモジュールを使用することができます。図 2 に、stapベースの変換プロセスに関連するユーザー空間およびカーネル空間の要素を示します。
図 2. カーネル/ユーザー空間から見た SystemTap プロセス
SystemTap には、必要なことを実現するためのさまざまな方法が用意されているため、スクリプトをごく簡単に、しかも柔軟に作成することができます。「参考文献」セクションには、この言語と機能についての詳細を説明するマニュアルへのリンクを記載しておきましたが、このセクションで紹介するいくつかの例をとおして実際の SystemTap スクリプトの感覚をつかんでください。
SystemTap スクリプトは、プローブと、プローブの起動時に実行されるように関連付けられたコードのブロックからなります。表 1 に記載されているように、プローブには多数の定義済みパターンがあります。この表には、カーネル関数を呼び出すプローブや、カーネル関数から返されるプローブを含め、さまざまなタイプのプローブが列挙されています。
表 1. プローブ・パターンの例
| プローブ・タイプ | 説明 |
|---|---|
begin
| スクリプトの開始時に起動 |
end
| スクリプトの終了時に起動 |
kernel.function("sys_sync")
| sys_sync が呼び出されると起動 |
kernel.function("sys_sync").call
| 同上 |
kernel.function("sys_sync").return
| sys_sync からリターンすると起動 |
kernel.syscall.*
| システム・コールが行われると起動 |
kernel.function("*@kernel/fork.c:934")
| fork.c の 934 行目にヒットすると起動 |
module("ext3").function("ext3_file_write")
| ext3 の write 関数が呼び出されると起動 |
timer.jiffies(1000)
| カーネルの 1000 jiffy ごとに起動 |
timer.ms(200).randomize(50)
| 線形に分布したランダムなミリ秒数 (-50 から +50) を 200 ミリ秒に加えた時間ごとに起動 (ランダムなミリ秒数は毎回計算) |
プローブを作成し、そのプローブにコードを関連付ける方法を説明するために、単純なプローブの例を見てみましょう。リスト 3 に記載するサンプル・プローブは、カーネル・システム・コール sys_sync が呼び出されると起動するプローブです。例えば、このプローブの起動時に、このシステム・コールの呼び出し回数をカウントし、そのカウントを呼び出し側のプロセス ID (PID) と併せて出力したいとします。それにはまず、任意のプローブが使用可能なグローバル変数を宣言し (グローバル名前空間は、すべてのプローブに共通)、このグローバル変数をゼロに初期化します。次に、カーネル関数 sys_sync の開始 (entry) プローブとなるブローブを定義します。このプローブに関連付けるスクリプトは、count 変数をインクリメントしてから、呼び出しの実行回数、そして現行の呼び出しに対応する PID を定義するメッセージを出力するというものです。この例は、プローブ定義の構文を別とすれば C 言語とよく似ており、C 言語の経験がある人にとっては非常に理解しやすいものになっています。
リスト 3. 単純なプローブとスクリプト
global count=0
probe kernel.function("sys_sync") {
count++
printf( "sys_sync called %d times, currently by pid %d\n", count, pid );
}
|
プローブが呼び出すことのできる関数も宣言できるので、複数のプローブで共通の関数に対応したいという場合でもまったく問題ありません。さらにこのツールでは、指定された深さでの再帰もサポートしています。
SystemTap はさまざまな型の変数定義を許可しますが、型はコンテキストから推論されるため、型を宣言する必要はありません。SystemTap では数値 (64 ビットの符号付き整数)、整数 (64 ビット)、文字列、リテラル (文字または整数) が使用されています。また、連想配列と統計を使用することもできます (後で詳しく説明します)。
SystemTap には C 言語で必要となる演算子のすべてが揃っており、従うルールも C 言語と同じです。演算子には、算術演算子、2 項演算子、代入演算子、ポインター逆参照があります。また、C 言語を基に単純化した文字列連結、連想配列要素、集合演算子なども使用されています。
プローブ内には、SystemTap が C 言語によく似た使いやすいステートメントを提供しています。注意する点として、この言語では複雑なスクリプトを開発することもできますが、プローブごとに実行できるのは 1000 のステートメントに限られます (ただし、この数は構成可能です)。概要を把握してもらうため、表 2 にこの言語のステートメントを要約します。この表に記載されている要素の多くは C 言語とまったく同じように見えますが、SystemTap に固有の要素も追加されていることに注意してください。
表 2. SystemTap の言語要素
| ステートメント | 説明 |
|---|---|
if (exp) {} else {}
| 標準的な if-then-else 文 |
for (exp1 ; exp2 ; exp3 ) {}
| for ループ |
while (exp) {}
| 標準的な while ループ |
do {} while (exp)
| do-while ループ |
break
| 繰り返し処理を終了 |
continue
| 繰り返し処理を続行 |
next
| プローブから戻る |
return
| 関数から式を返す |
foreach (VAR in ARRAY) {}
| 配列を繰り返し処理し、現行のキーを VAR に割り当てる |
C 言語には、統計および集合機能に相当する機能がないことから、この記事ではサンプル・スクリプトの統計および集合機能を取り上げて説明します。
SystemTap には、現行のコンテキストに関する追加情報を提供する数々の内部関数が用意されています。例えば、呼び出し側の関数を識別するには caller() を使用することができ、現行のプロセッサー番号を識別するには cpu() を、PID を返すには pid() を使用することができます。その他、SystemTap には呼び出しスタックおよび現行レジスターにアクセスするための関数など、多数の関数が揃っています。
SystemTap について簡単に紹介したところで、今度はいくつかの単純な例を用いて SystemTap が実際にどのように機能するのかを見ていくことにします。この記事では、集合をはじめ、このスクリプト言語が持つ興味深い側面についても説明します。
前のセクションでは、sync システム・コールをモニターする単純なスクリプトを取り上げました。今度はそれよりも一般的なスクリプトとして、すべてのシステム・コールをモニターし、それぞれについての追加情報を収集するスクリプトを検討します。
リスト 4 に記載する単純なスクリプトには、グローバル変数の定義と個別の 3 つのプローブが組み込まれています。最初のプローブは、スクリプトが初めてロードされると呼び出されます (begin プローブ)。このプローブでは単に、スクリプトがカーネル内で実行されていることを示すテキスト・メッセージを出力するだけです。次にあるのは、syscall プローブです。このプローブではワイルドカード (*) を使用していることに注意してください。ワイルドカードによって、一致するすべてのシステム・コールをモニターするように SystemTap に指示します。このプローブが起動したら、該当する PID とプロセス名の連想配列をインクリメントします。最後のプローブはタイマー・プローブで、10,000 ミリ秒 (10 秒) 後に起動するようになっています。このプローブが起動すると、これに関連付けられたスクリプトが、収集されたデータを出力します (連想配列のメンバーそれぞれを繰り返し処理します)。すべてのメンバーが繰り返し処理されると、exit 呼び出しによってモジュールがアンロードされ、関連付けられたすべてのSystemTap プロセスが終了します。
リスト 4. すべてのシステム・コールのモニター (profile.stp)
global syscalllist
probe begin {
printf("System Call Monitoring Started (10 seconds)...\n")
}
probe syscall.*
{
syscalllist[pid(), execname()]++
}
probe timer.ms(10000) {
foreach ( [pid, procname] in syscalllist ) {
printf("%s[%d] = %d\n", procname, pid, syscalllist[pid, procname] )
}
exit()
}
|
リスト 4 のスクリプトによる出力をリスト 5 に記載します。このスクリプトによって、ユーザー空間で実行されたプロセスと、それぞれのプロセスが 10 秒間に行ったシステム・コールの数がわかります。
リスト 5. profile.stp スクリプトによる出力
$ sudo stap profile.stp System Call Monitoring Started (10 seconds)... stapio[16208] = 104 gnome-terminal[6416] = 196 Xorg[5525] = 90 vmware-guestd[5307] = 764 hald-addon-stor[4969] = 30 hald-addon-stor[4988] = 15 update-notifier[6204] = 10 munin-node[5925] = 5 gnome-panel[6190] = 33 ntpd[5830] = 20 pulseaudio[6152] = 25 miniserv.pl[5859] = 10 syslogd[4513] = 5 gnome-power-man[6215] = 4 gconfd-2[6157] = 5 hald[4877] = 3 $ |
この例では前のスクリプトを少し変更して、特定の 1 つのプロセスでのシステム・コールのデータを収集します。さらに、システム・コールを行った回数を取得するだけでなく、ターゲット・プロセスを対象に行われた特定のシステム・コールの情報も取得します。このスクリプトをリスト 6 に記載します。
この例では対象とする特定のプロセス (この場合は syslog デーモン) をテストしてから、システム・コール名をカウントにマッピングするために連想配列を変更します。そしてタイマー・プローブの起動時に、このシステム・コールとカウント・データを出力します。
リスト 6. 変更後のシステム・コール・モニター・スクリプト (syslog_profile.stp)
global syscalllist
probe begin {
printf("Syslog Monitoring Started (10 seconds)...\n")
}
probe syscall.*
{
if (execname() == "syslogd") {
syscalllist[name]++
}
}
probe timer.ms(10000) {
foreach ( name in syscalllist ) {
printf("%s = %d\n", name, syscalllist[name] )
}
exit()
}
|
このスクリプトによる出力はリスト 7 のとおりです。
リスト 7. 変更後のスクリプト (syslog_profile.stp) による SystemTap の出力
$ sudo stap syslog_profile.stp Syslog Monitoring Started (10 seconds)... writev = 3 rt_sigprocmask = 1 select = 1 $ |
集合インスタンスは、数値の統計を得るのに最適な手段となります。この手法が効率的かつ有効に機能するのは、大量のデータを取り込んでいる場合です。この例では、ネットワーク・パケットの受信と送信に関するデータを収集します。リスト 8 では、ネットワーク入出力を取り込む 2 つの新規プローブを定義しています。それぞれのプローブが取り込むのは、指定されたネットワーク・デバイス名、PID、およびプロセス名に対応するパケット長です。ユーザーが Ctrl-C を押した場合に呼び出される終了プローブが、取り込んだデータを出力する手段となります。この例の場合、recv 集合の内容を繰り返し処理し、タプル (デバイス名、PID、プロセス名) ごとのパケット長を合計してデータを出力します。タプルを合計するために使用されているエクストラクターに注意してください。この @count エクストラクターによって、取り込まれたパケット長の数 (パケット・カウント) が取得されます。このエクストラクターの他、合計を出すための @sum エクストラクターや、最小あるいは最大の長さをそれぞれ収集する @min や @max などのエクストラクターを使用することもできます。また、@avg エクストラクターを使用すれば、平均値を計算することができます。
リスト 8. ネットワーク・パケット長データの収集 (net.stp)
global recv, xmit
probe begin {
printf("Starting network capture (Ctl-C to end)\n")
}
probe netdev.receive {
recv[dev_name, pid(), execname()] <<< length
}
probe netdev.transmit {
xmit[dev_name, pid(), execname()] <<< length
}
probe end {
printf("\nEnd Capture\n\n")
printf("Iface Process........ PID.. RcvPktCnt XmtPktCnt\n")
foreach ([dev, pid, name] in recv) {
recvcount = @count(recv[dev, pid, name])
xmitcount = @count(xmit[dev, pid, name])
printf( "%5s %-15s %-5d %9d %9d\n", dev, name, pid, recvcount, xmitcount )
}
delete recv
delete xmit
}
|
リスト 8 のスクリプトによる出力をリスト 9 に記載します。ここではユーザーが Ctrl-C を押すとスクリプトが終了して、取り込まれたデータが出力されることに注意してください。
リスト 9. net.stp による出力
$ sudo stap net.stp Starting network capture (Ctl-C to end) ^C End Capture Iface Process........ PID.. RcvPktCnt XmtPktCnt eth0 swapper 0 122 85 eth0 metacity 6171 4 2 eth0 gconfd-2 6157 5 1 eth0 firefox 21424 48 98 eth0 Xorg 5525 36 21 eth0 bash 22860 1 0 eth0 vmware-guestd 5307 1 1 eth0 gnome-screensav 6244 6 3 Pass 5: run completed in 0usr/50sys/37694real ms. $ |
最後に紹介する例は、SystemTap では簡単にデータを他のフォームで表示できることを説明するものです。この例の場合は、データをヒストグラムに表示します。前の例を用いて、データを histogram という名前の集合に取り込んでください (リスト 10 を参照)。次に netdev 受信および送信プローブを使用してパケット長データを取り込みます。プローブが終了したら、@hist_log エクストラクターを使ってデータをヒストグラム形式で出力します。
リスト 10. ヒストグラム・データの取り込みと表示 (nethist.stp)
global histogram
probe begin {
printf("Capturing...\n")
}
probe netdev.receive {
histogram <<< length
}
probe netdev.transmit {
histogram <<< length
}
probe end {
printf( "\n" )
print( @hist_log(histogram) )
}
|
リスト 10 による出力をリスト 11 に記載します。この例では、ブラウザー・セッション、FTP セッション、および ping を使用してネットワーク・トラフィックを生成しました。@hist_log エクストラクターは、2 を底とする対数ヒストグラムです (リスト 11 を参照)。他のヒストグラムを取り込むことで、バケットのサイズを定義することもできます。
リスト 11. nethist.stp によるヒストグラム出力
$ sudo stap nethist.stp
Capturing...
^C
value |-------------------------------------------------- count
8 | 0
16 | 0
32 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1601
64 |@ 52
128 |@ 46
256 |@@@@ 164
512 |@@@ 140
1024 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 2033
2048 | 0
4096 | 0
$
|
この記事は、SystemTap の機能を表面的にかじっただけにすぎません。SystemTap を使用する上で知っておかなければならないことは、「参考文献」セクションにリンクを記載した多数のチュートリアルやサンプル、そしてこの言語のリファレンスを調べればわかるはずです。既存の方法を利用した SystemTap は、それまでのカーネル・トレースの実装からの教訓を得ています。このツールはまだ活発に開発が進められていますが、現時点でも既にかなり使い物になるツールになっているので、今後どのような機能が追加されていくかが楽しみです。
学ぶために
- SystemTap プロジェクトの Web サイトにアクセスして、現行バージョン、ドキュメント、リンクなどの最新情報、そして SystemTap プロジェクトに関与する方法を調べてください。SystemTap はプローブ・ポイントを実行中のカーネルにインストールするための土台となる方法として Kprobes を使用しています。Kprobes について、この同じ Sourceware Web サイトで調べてください。
- SystemTap の使用方法については、IBM Redpaper「SystemTap: Instrumenting the Linux Kernel for Analyzing Performance and Functional Problems」で詳しく説明しています。
- IBM Blueprint for Linux on IBM systems に、Red Hat Enterprise Linux および SUSE Linux Enterprise Server での SystemTap のインストール方法と使用方法が記載されています。また、SystemTap スクリプトの作成とカーネル・イベントの可視化を簡易化する Eclipse ベースのツール、SystemTap GUI の使用方法について説明している Blueprint もあります。
- SystemTap を Ubuntu 8.10 で使用する場合に、ランタイムの time.c ファイルに含まれるバグを修正する方法を学んでください。
- 2004年の USENIX の記事「Dynamic Instrumentation of Production Systems」では、Sun Microsystems の著者らが DTrace の機能を紹介しています。
- 2005年に書かれた SystemTap のアーキテクチャーと設計フォーマットを紹介するこの文書を読んで、SystemTap の背後にある動機と要件を学んでください。この文書は SystemTap の技術詳細を詳しく説明しているだけでなく、優れた設計資料のモデルとなります。
- 2006年の Ottawa Linux シンポジウムのために開発されたこの Kprobes チュートリアルは、短いながらも Kprobes によるカーネル探査について有益な情報を提供しています。また、「Kprobes によるカーネルのデバッグ」(developerWorks、2004年8月) も興味深い記事です。
- Intel の Josh Stone によるプレゼンテーション「Dynamic Tracing and Performance Analysis Using SystemTap」は、SystemTap に関する優れたチュートリアルです。このプレゼンテーションでは、SystemTap およびその言語と使用方法を極めてわかりやすく紹介しています。
- 「SystemTap Language Reference」は、SystemTap 言語とそのすべての機能を学ぶ上で最適な情報源となります。
- ウィキペディアには、SystemTap、DTrace、および ProbeVue の資料が豊富に揃っています。さらに、それぞれの技術に関するプレゼンテーションとチュートリアルへの外部リンクも記載されています。
- developerWorks Linux ゾーンに豊富に揃った Linux 開発者向けの資料を調べてください。記事とチュートリアルの人気ランキングも要チェックです。
- developerWorks に掲載されているすべての「Linux のヒント」シリーズの記事と Linux チュートリアルを参照してください。
- developerWorks の Technical events and webcasts で最新情報を入手してください。
製品や技術を入手するために
- developerWorks から直接ダウンロードできる IBM ソフトウェアの試用版を使用して、Linux で次の開発プロジェクトを構築してください。
議論するために
- SystemTap Blueprints Community Forum で SystemTap および SystemTap GUI について話し合ってください。
- My developerWorks コミュニティーに加わってください。自分個人のプロファイルとカスタム・ホーム・ページを作成して、自分の興味に合わせて developerWorks をカスタマイズしたり、他の developerWorks ユーザーと対話したりすることができます。

M. Tim Jones は組み込みソフトウェアのエンジニアであり、『Artificial Intelligence: A Systems Approach』、『GNU/Linux Application Programming』(現在、第 2 版です) や『AI Application Programming』(こちらも現在、第 2 版です)、それに『BSD Sockets Programming from a Multilanguage Perspective』などの著者でもあります。技術的な経歴は静止軌道衛星用のカーネル開発から、組み込みシステム・アーキテクチャーやネットワーク・プロトコル開発まで、広範にわたっています。また、コロラド州ロングモン所在のEmulex Corp. の顧問エンジニアでもあります。