このチュートリアルは、Alex van den Bogaerdtによって書かれました。
# このチュートリアルは、RRD Tutorialを翻訳したものです。
RRDtoolは、Tobias Oetiker <oetiker@ee.ethz.ch>によって書かれたプログラムで、世界中の沢山の人々が協力しています。このドキュメントは、RRDtoolとは何で、RRDtoolを使って何をできるのかについて、あなたの理解を助けるためにAlex van den Bogaerdt <alex@ergens.op.het.net>によって書かれました。
RRDtoolに添付されているドキュメントは、多くの人にとっては技術的すぎるものでしょう。このチュートリアルは、RRDtoolの基本を理解するのを助けるためのものです。このドキュメントを読むためには、あなたは自分自身で準備をしなければなりません。また、ネットワーキングを中心とした統計に関する一般的な事柄についても説明します。
このドキュメント中で読み飛ばしをしないで下さい! このドキュメントの最初の部分では基本的なことを説明しており、おそらく退屈なものでしょう。しかし、もしあなたがその基本的なことを理解していないのであれば、あとで出てくる動作例はおそらく意味がよくわからないものとなってしまうことでしょう。
RRDtoolは、Round Robin Database tool(ラウンド ロビン データベース ツール)の一つです。ラウンドロビンとは、データの総量が固定されたデータを扱うときに用いられる技術で、その時々に応じた要素へのポインタのことです。円周上にドットが打たれた円を考えます。このドットはデータを格納できる場所です。ドットの一つに円の中心から矢印を引くと、この矢印がポインタです。(ポインタが示す)現在のデータを読み書きすると、このポインタ(矢印)は次のドットに移動します。この円の上で移動する限り始まりも終わりもなく、ずっと進み続けることができます。全ての利用できるドットを全て利用すると(つまり一周すると)、自動的に古い場所が再利用されます。そのため、データベースののサイズは増加せず、それ故にメンテナンスが必要とされることはありません。RRDtoolは、Round Robin Databases(RRDs)を使い、データを取得したり格納したりします。
おそらくあなたが想像するすべてのデータは、RRDに適合するはずです。そのために、あなたはいくつかのタイミングで測定し、その情報をRRDtoolへ渡すべきです。渡すことができれば、RRDtoolは情報を蓄えることができます。この測定値は数値である必要がありますが、MRTGのように整数である必要はありません。
沢山の例は、Simple Network Management Protocolの接頭語であるSNMPを題材として説明をしています。ここでいうSimpleは、プロトコルが単純であるということであって、ネットワークをモニターしたり管理したりするのが簡単という意味ではありません。このドキュメントを読み終われば、何が話されているかがわかるぐらいの知識が得られるでしょう。今のところ、SNMPとはデバイスが保持しているカウンタの値を問い合わせる方法の一つであると覚えておいて下さい。これらのカウンタから得られた値はRRDに保存されます。
RRDtoolの起源はMRTGです(Multi Router Traffic Grapher)。MRTGは、インターネットと接続している回線の使用状態を表わすグラフを書くための小さな小さなスクリプトとして生み出されました。そして、MRTGは温度や速度、電圧、プリントした枚数のような他のデータも扱えるようなツールへと進化しました。おそらく、あなたはRRDtoolをSNMPを通じて収集したデータを処理させるためにRRDtoolを使い始めるでしょう。このようなデータは、ほとんどの場合ネットワークかコンピュータを通過したバイト数かビット数です。RRDtoolは、データベースを作成し、データをそのデータベースに保存し、データベースからデータを受けとり、グラフをGIF形式の画像でウェブブラウザに表示することができます。それらのGIF画像はあなたが収集したデータ次第であり、たとえばネットワークの平均的な使用状態やそのピーク発生の概観を示すものです。津波の様子や太陽放射の強度、消費電力、展示会の来場者数、空港近くでの騒音の大きさ、あなたが休日を過ごすお気に入りの場所の気温、冷蔵庫の温度、その他なんでもあなたが思い付くものを表示するのに使うことができます。勿論、それらのデータをRRDtoolに渡すためには、データの測定器が必要です。
何はともあれ、このチュートリアルをもう一度読み返して下さい。おそらく何か間違えていることでしょう。もしあなたがソースをコンパイルできなくても、一般的なOSを使っているのならば、まずRRDtoolのせいではありません。インターネット上でいくつかのコンパイル済みのバイナリを見付けられるでしょう。バイナリの配布元が信用できるなら、それを入手して下さい。もしもプログラムの実行結果があなたの期待しているものと異なるのならば、おそらくあなたの設定の方に問題があります。設定内容を見直し、このチュートリアルの実行例と比較してみて下さい。
メーリングリスト15があり、そのアーカイブもあります。過去数週間分の投稿を見たり、アーカイブを検索したりしてみましょう。アーカイブの検索もせずに質問することは、かなり粗野で無礼なことであるということを考慮して下さい。あなたの問題は、ほかの誰かによって既に解決していることがほとんどです。これはこのメーリングリストに限らず、ほかのほとんど全てのメーリングリストについても言えることです。RRDtoolに附属しているドキュメントで、メーリングリストのありかや使い方を良く読んで下さい。
今すぐにSubjectを'subscribe'としたメールを<rrd-users-request@list.ee.ethz.ch>宛に送って、メーリングリストに参加することをお勧めします。もし、メーリングリストから抜けたい場合には、同じアドレスにSubjectが'unsubscribe'のメールを送って下さい。
詳細な例と詳細な説明を与えることによって、です。示された手順の通りに自分自身で実験してみることで、RRDtoolについての十分な知識が得られることでしょう。最初の挑戦でうまく機能しなくても諦めないで下さい。理解したと思った部分ももう一度読み直してみて下さい、おそらくどこか間違っているのでしょう。以下の例を実際に試してみることで、あなたは実地でのハンズ・オン(hands-on)形式の経験と、それがどのようにして動いているのかという、より重要な背景知識を得られることでしょう。
まず、16進法の数字表記について知っておく必要があります。もし知らないならば、このドキュメントを読み進める前にbin_dec_hexのmanpageを見ておいて下さい。1
[1] 訳注:bin_dec_hexはRRDtoolに含まれるman pageの一つです。英語ですが、基数の変換について書かれています。
これは私の意見ですが、何かを学ぶ最良の方法はそれを実際にやってみることです。早速始めてみましょう。まずデータベースを作成し、そのデータベースへいくつかの値を入れ、再びさきほど入れたデータをデータベースから取り出します。あなたの手元での実行結果は、このドキュメントに含まれるサンプルの出力と全く同じになるはずです。
このサンプルでは、ルータを車に、そしてビットやバイトを速度にたとえる簡単な題材から始めます。どちらも全く同じことです。ある時点での何らかの数字なのです。
ここで、インターネットとの間でデータをやり取りできるデバイスを持っているとしましょう。このデバイスは0から始まり、1バイト転送するごとに増加するカウンタを実装しています。もし表現できる最大の数値に到達し、さらに1バイトが計測されると、カウンタは0に戻ります。これは、車の総走行距離メータのような、世界中にあるたくさんのカウンタと全く同じ挙動です。ネットワーキングに関するほとんどの議論においては、ビット毎秒という単位が話題になります。ので、ここでもそうしましょう。1バイトは8ビットであると仮定し、(バイトではなく)ビットで考えます。しかしそれでも、実際のカウンタはバイトでカウントします! SNMPでは、ほとんどのカウンタが32ビットです。32ビットとは、そのカウンタが0から4294967295までをカウントすることを意味します。この例では、そういった数値を使います。このデバイスは、問い合わせに対して、現在のカウンタの値を返します。前に問い合わせた時刻(とそのときの数値)がわかっているなら、何秒間で何バイトの転送が行われたかと、一秒あたりの平均転送バイト数を計算できます。この計算は難しいものではなく、次のようにして行われます。
この式を自動車の例で考えると分かりやすいかもしれません。が、実際にこの例を自動車では試さないで下さい。もし試してみたとしても、そのことで私を責めないで下さい。2
[2] 訳注: 下記では、車で時速144kmを出す例が出てきます。この速度は、日本においては明らかに道路交通法違反ですので、実行するのは頭の中だけに留め、実際にやらないようにしましょう。
速度として時速キロメートル単位を使わない人々は、kmを1.6で割ることで毎時マイルに変換することができます。今後、私は以下の略語を使用します。
車を運転しているとしましょう。12:05にダッシュボードにあるカウンタを見てみると、車はそれまでに12345KM移動していました。12:10に再び見てみると、カウンタは12357KMを示していました。これは、あなたが5分の間に12KMを移動したことを意味しています。科学者はメートル毎秒に変換するでしょう。このことは5分あたりのバイト数と(5分毎バイト)、ビット毎秒とのよい対比です。
私達は12キロメートル(12000メートル)移動しました。5分間を300秒へ変換します。私達の速度は12000M / 300Sであり、これは40M/Sと同じことです。
ここでKM/Hでの速度も計算できます。一時間の中には5分間が12回あることから、12KMに12を掛けて144KM/Hと計算できます。マイルで考えれば90MPH(マイル毎時)ですが、マイル法の国々でもこれは試せません :)
これらの数値は平均でしかないことを覚えておいて下さい。一定のスピードで車を走らせていたかどうかをこれらの数字から知る方法はありません。このことについて説明する例はチュートリアルの後の方で出てきます。
M/S(メートル毎秒)やbps(ビット毎秒)の計算において何一つ違いがなかったことを理解していただけたでしょうか。ただ、データの収集方法だけが異なるのです。 ネットワークにおける用語 'k'が1000を意味するように、'K'も同じキロを意味するのです。
ここで、興味のある全てのデータを保存しておけるデータベースを作成しましょう。以下のプログラムバイナリを実行する方法は、OSごとにわずかに違っているかもしれませんが、あなたのOSで違うように動作したとしてもきっとそれと分かることでしょう。ただ、以下のコマンドを入力し実行するとき、間違ってもOSのシステムファイルに上書きしないように注意して下さい。以下の実行するコマンドラインはあくまでも長い一行で、読みやすいように'\'文字でエスケープして改行してあるだけですので、'\'は取り除いて入力して下さい。
rrdtool create test.rrd \
--start 920804400 \
DS:speed:COUNTER:600:U:U \
RRA:AVERAGE:0.5:1:24 \
RRA:AVERAGE:0.5:6:10
(ここでエンターキーを押して下さい。: rrdtool create test.rrd --start 920804400 DS ...)
たった今、test (test.rrd)というファイル名で1999年3月7日3正午に始まるラウンドロビンデータベースを作成しました。このデータベースは'speed'という名前のデータソース(DS: Data Source)を持ち、そのデータソースは(おそらく車のダッシュボードにある総走行距離計の)カウンタから取得されます。 このカウンタは(デフォルトでは)5分毎に読みとられ、先程作成したラウンドロビンデータベースにある二つのラウンドロビンアーカイブ(RRA)に保持されます。
[3]補足: これは原著者であるAlex van den Bogaerdtが、このドキュメントを書き始めた日でもあります。
一つ目のRRAは、毎時刻に読み取られた数値の平均を24個保存します(5分が24個ですから二時間分)4。もうひとつのRRAは、6個の値(つまり5分×6個で30分)の平均を10個(つまり0.5時間×10個で五時間分)の平均を格納します。残りのオプションについては、あとで説明します。
[4]訳注: 平均するとき、対象となる数字が一つなら平均しても変わらないですよね n/1=n
RRDtoolにおけるタイムスタンプは、UNIXの世界におけるものと同じです。このタイムスタンプは、これは1970年1月1日(グリニッジ標準時)からの経過秒数です。このタイムスタンプは、それぞれの地域における現地時刻に変換されるため、タイムゾーンが違うと違う時刻のように見えることがあります。
以降の例では、あなたの出力とこのドキュメントが同じにならない部分がある可能性があります。このことは、あなたのタイムゾーンが(このドキュメントのものとは)違うことを意味しています。時刻について説明されている全ての例において、時(hour)の部分は違っているかもしれません。この例における結果において、読んでいる間、時(hour)の部分については読み変えて下さい。たとえば、私が12:05と書いたとき、UK(英国)においては11:05です。
ここで、さきほど作ったデータベースに、データとなる数値を入れます。以下の数値をカウンタから読み取ったとしましょう。
12:05 12345 KM 12:10 12357 KM 12:15 12363 KM 12:20 12363 KM 12:25 12363 KM 12:30 12373 KM 12:35 12383 KM 12:40 12393 KM 12:45 12399 KM 12:50 12405 KM 12:55 12411 KM 13:00 12415 KM 13:05 12420 KM 13:10 12422 KM 13:15 12423 KM
以下のようにしてデータベースへデータを入れて下さい。
rrdtool update test.rrd 920804700:12345 920805000:12357 920805300:12363 rrdtool update test.rrd 920805600:12363 920805900:12363 920806200:12373 rrdtool update test.rrd 920806500:12383 920806800:12393 920807100:12399 rrdtool update test.rrd 920807400:12405 920807700:12411 920808000:12415 rrdtool update test.rrd 920808300:12420 920808600:12422 920808900:12423
これは、以下に続く数字で我々の実験用データベースを更新したことを意味します。
time 920804700, value 12345 time 920805000, value 12357 などなど
これを見ると、一つのコマンドラインで複数の数値(のペア)を与えることができるように思えます。ただ、読み易さと、実際上のOSごとに依存する制限によって、3つで止めておいた方が無難です。
ここで、'rrdtool fetch'コマンドを使って、データベースからデータを取り出してみましょう。
rrdtool fetch test.rrd AVERAGE --start 920804400 --end 920809200
以下のような出力が得られるでしょう。
speed 920804700: NaN 920805000: 0.04 920805300: 0.02 920805600: 0.00 920805900: 0.00 920806200: 0.03 920806500: 0.03 920806800: 0.03 920807100: 0.02 920807400: 0.02 920807700: 0.02 920808000: 0.01 920808300: 0.02 920808600: 0.01 920808900: 0.00 920809200: NaN
もし、このように表示されていないのらば、なにかが間違っています。たぶんあなたのOSは、数字ではなくて 'NaN' を表示しているでしょう。それは、データが'Not a Number'(数字ではない)ことを示しています。もし、あなたのOSが'U'とか'UNKN'とかなにかそれに良く似た表示を出力しているならば、大丈夫です。もし他のなにかが間違っているならば、それはあなたが犯してしまったエラーが原因でしょう(もちろん、このチュートリアルが正しいと仮定していますが :-) 5)。その場合には、データベースを削除して、もう一度最初からやり直して下さい。
この出力が何を表わすのかは、チュートリアルの残りの部分で明らかになります。
[5] 訳注: この文章の場合、加えて私の翻訳も正しいことを仮定しています。もし間違いを見付けたら、私(fjshg@photonway.net)まで教えて下さい。
以下のコマンドラインを試して見て下さい。
rrdtool graph speed.gif \
--start 920804400 --end 920808000 \
DEF:myspeed=test.rrd:speed:AVERAGE \
LINE2:myspeed#FF0000
このコマンドラインは、(横軸が)12:00に始まり13:00に終わるspeed.gifというファイルを作ります。myspeedという名前の変数の定義があり、これはデータベース'test.rrd'の中のspeedという名前のRRA(ラウンド ロビン アーカイブ)から取得されるデータです。そして変数myspeedにより、2ピクセルの高さで赤い線が描かれます。あなたはグラフの始まりが12:00ではなく12:05であることに気がつくでしょう。なぜならば、その時刻と一つ前の時刻との差を時間で割った平均を描かせるわけですから、一つ前のデータがない12:00での平均がわからないのです。これは、いくつかのサンプル(測定データ)を逃すときにのみ発生し、ほとんどの場合では発生しません。
このように正常にいっているなら、万々歳です。もしそうでないなら、どこが間違っているのか確認して下さい。
この線の色は、赤と緑と青の組合せです。おのおのの要素(赤/緑/青)をどれぐらい使うのかを、16進数で00(全く使わない)からFF(全て使う)までの間で指定します。白という色は赤 / 緑 / 青の組み合わせでFFFFFF、黒という色は全ての色の要素がない000000です。
できたGIFファイルはお好みの画像ビューワで表示できます。ウェブブラウザでも、GIFファイルを'file://path/to/speed.gif'というURLで指定することで表示されることでしょう。
グラフを見ていると、横軸に12:10, 12:20, 12:30, 12:40, 12:50と刻まれていることに気がつくでしょう。残りの二つの時刻(12:00と13:00)は、うまく表示されずにスキップされています。縦軸は、入力した数値の範囲で表示されています。私達はキロメートル単位でRRDtoolに渡しましたが、300秒で距離の数値を割り算したために、非常に小さな数字になってしまいました。正確には、最初の数値12 (12357-12345 = 12)を300(秒)で割ったことで0.04(km/s)となり、RRDtoolは40mとして表示しました。ここでのここでの40mとは40/1000のことであり、'm'は単位のメートルではなく指数のミリ(10^-3)を表しています。RRDtoolは、このあたりのことを理解しているわけではなく、'm'をメートルとしてではなくただ数字として扱っています。
私達が犯した間違いは、キロメートル単位ではなくメートル単位で測定するべきだったということです。つまり、(12357000-12345000)/300 = 12000/300 = 40のように計算すべきだったのです。
この誤りを修正しましょう。データベースを作り直して正しいデータを格納させるよりも、もっと良い方法があります。gifファイルを作成している最中でも計算はできるのです。
rrdtool graph speed2.gif \
--start 920804400 --end 920808000 \
--vertical-label m/s \
DEF:myspeed=test.rrd:speed:AVERAGE \
CDEF:realspeed=myspeed,1000,* \
LINE2:realspeed#FF0000
GIFファイルを見てみると、'm'の表示が消えています。正しく修正されたわけです。ついでに画像中の縦軸にラベルを追加しました。それ以外の点では、GIFファイルのグラフは同じはずです。
この計算はCDEFの部分で行われ、逆ポーランド演算で書かれています。上の例では、'データを変数myspeedから取り、整数1000を用意し、それらを掛け合わせる'と書いてあります。RPN(逆ポーランド演算)についてはまだ悩まないで下さい。あとでより詳細な説明をします。おそらくCDEFについてのチュートリアルと、Steve RaderのRPNについてのチュートリアルを読みたくなるでしょう。しかし、まずはこのチュートリアルをやり終えましょう。
落ち着いて考えて下さい。数値に1000を掛けられるということは、同じデータからキロメートル毎時を表示させることもできるわけですよね。
メートル毎秒で測定されたデータの変換を見てみましょう。メートル毎時を計算するには、データ × 3600です。キロメートル毎時を計算するには、データ / 1000です。まとめると、データ × (3600 / 1000) == データ × 3.6で、キロメートル毎時を計算できます。
この例のデータベースは、作成時に誤りを犯してしまいましたので、1000を掛けることで補正する必要があります。この修正も考慮すると、データ × 3.6 × 1000 == データ × 3600すれば良さそうです。
では、いくつかの魔法を加えて、新しいGIFファイルを作りましょう。
rrdtool graph speed3.gif \
--start 920804400 --end 920808000 \
--vertical-label km/h \
DEF:myspeed=test.rrd:speed:AVERAGE \
"CDEF:kmh=myspeed,3600,*" \
CDEF:fast=kmh,100,GT,kmh,0,IF \
CDEF:good=kmh,100,GT,0,kmh,IF \
HRULE:100#0000FF:"Maximum allowed" \
AREA:good#00FF00:"Good speed" \
AREA:fast#FF0000:"Too fast"
見栄えが良くなったでしょう。速度はKM/Hであり、(私が走行する際に)道路上で出して良い最大の速度を示す線も描画されています。速すぎる速度域と許される速度域で色を変えてもみました。
計算が複雑になってきました。 よい速度とは... 変数kmhが100より大きいか(GT)チェックする ( kmh, 100) GT もしそうなら0を返し、そうでないならkmhを返す ( (( kmh,100) GT), 0, kmh) IF そうじゃない(速すぎる)速度とは... 変数kmhが100より大きいかチェックする ( kmh, 100) GT もしそうならkmhを返し、そうでないなら0を返す ( (( kmh,100) GT), kmh, 0) IF
私は、RRDtoolのグラフ描画機能には、データ操作の制限が事実上ないと信じています。以下のコマンドラインがどのように機能するか説明はしません。できたGIFファイルを見てみて下さい。
rrdtool graph speed4.gif \
--start 920804400 --end 920808000 \
--vertical-label km/h \
DEF:myspeed=test.rrd:speed:AVERAGE \
"CDEF:kmh=myspeed,3600,*" \
CDEF:fast=kmh,100,GT,100,0,IF \
CDEF:over=kmh,100,GT,kmh,100,-,0,IF \
CDEF:good=kmh,100,GT,0,kmh,IF \
HRULE:100#0000FF:"Maximum allowed" \
AREA:good#00FF00:"Good speed" \
AREA:fast#550000:"Too fast" \
STACK:over#FF0000:"Over speed"
ここで、大雑把ですが、ここまで改造してきた3つのGIFグラフを見られるHTMLのページを作りましょう。
<HTML><HEAD><TITLE>Speed</TITLE></HEAD><BODY> <IMG src="speed2.gif" alt="Speed in meters per second"> <BR> <IMG src="speed3.gif" alt="Speed in kilometers per hour"> <BR> <IMG src="speed4.gif" alt="Traveled too fast?"> </BODY></HTML>
'speed.html'(あるいは似たような名前)で保存して、見てみて下さい。
以降やるべきことは、定期的に値を測定し、データベースを更新するのみです。その場合、データを見たくなったら、GIFファイル(おそらく複数でしょう)を再度作成し、ブラウザでの表示をリフレッシュするのを忘れないで下さい。注意:reloadボタンをクリックするだけでは、おそらく不十分です。Netscapeは独特の問題を抱えており、シフトキーを押しながらリロードボタンをクリックする必要があります。
私達は、既に'update'コマンドを利用しました。一つないしは複数のパラメータを '(<時間>:<値>)'の形で与えることができます。現在の時刻は、時刻として'N'と入力することで得られます。お望みなら、Perlの'time'関数も使えます。この例は、このチュートリアルにおいて最も短いものです :)
perl -e 'print time, "\n" '
どのようにして定期的にプログラムを実行するかは、OSに依存します。ここでは、擬似コードで例を示します。
値を測定し、'$spped'という変数に入れる rrdtool update speed.rrd N:$speed
(これを、ここまで使ってきた実験用のデータベースで実行しないで下さい。あとの例でまだで使いますから)
以上です。このスクリプトを5分ごとに実行して下さい。グラフがどのようになっているか知りたいならば、これまでのようなGIFを作るプログラムもスクリプトに加えて下さい。そのあと、index.htmlを見れば良いはずです。
5分ごとに車から実際のデータを取得できる人は、本当はほんのわずかでしょう。それ以外のほとんどの人々は、何か別の種類のカウンタを用意する必要があります。それは、プリンタで印刷された紙の枚数、コーヒーメーカーによって淹れられたコーヒーの量、消費電力量の計測デバイス、なんでも良いのです。いままで学んだことを利用すれば、増加しつづけるカウンタをモニタしグラフを描くことができます。あとで私たちは、温度のような別の種類の値をモニタできるようになります。ほとんどの人が、ネットワークデバイスによって転送されたオクテット(バイト)の変動を記録しておくためにカウンタを利用します。ここでもそうしましょう。まず、どのようにデータを収集するかについて説明します。こういったデータを収集するためのツールは既に存在するじゃないかと言われるかもしれません。まったくその通りです。しかしながら私は、そのようなツールは必要ないということを理解することが大事ではないかと思っています。なぜ事態がうまく行かなかったかを確定させなければならないときには、それらのツールがどのように機能するのかを知らなくてはならないのですから。
この例で用いるツールは、このチュートリアルの最初で軽く触れた、SNMPと呼ばれているものです。SNMPはデバイスと対話するための方法です。以下で使用するツールはsnmpgetと呼ばれ、このようにして使います。
snmpget device password OID
deviceには、お使いのデバイスのホスト名かIPアドレスを指定します。passwordは、SNMPではいわゆるコミュニティ名と呼ばれているものを指定します。いくつかのデバイスでは、コミュニティ名のデフォルトが、'public'になっていますが、これは無効化できますし、セキュリティやプライバシーの理由から変更されたり保護されたりしているかもしれません。このあたりについては、あなたのデバイスやプログラムのドキュメントを読んで下さい。
次に、オブジェクト識別子の意味を持つ、OIDと呼ばれる三番目のパラメータについてです。
SNMPについて勉強しようとすると、最初はとても混乱するでしょう。'MIB'(management Information Base)を見る分には、そう難しいわけではありません。MIBはデータを記述する逆さまの樹で、根(ルート)からいくつかの枝に分かれ、ノード(葉)にデータが結びつけられています。この枝は別のノードから分岐していき、その分岐先の枝も分岐しています。 全ての枝は名前を持ち、それらはずっと根まで辿ることのできるパスも形成しています。枝はiso, org, dod, internet, mgmt, mib-2のいずれかで始まる名前を持っています。これらの名前は、数字で記述することもでき、1 3 6 1 2 1 と表されます。
iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)
いくつかのプログラムが使用する先行ドットについては、かなり混乱するでしょう。OIDには先行ドットは ありません 。しかしながら、いくつかのプログラムは、デフォルトで上に挙げたような形式のOIDを使用しています。このことは、OIDを指定するとき、省略されたOIDsと先行するドットが必要な省略されない形式の違いを示しています。これらのプログラムはしばしば、あなたにデータを戻すときに、デフォルトの部分を省略した形式を使います。更に悪いことには、これらのプログラムはいくつかのデフォルトのプレフィクスを持っています。
まず、1.3.6.1.2.1 というOIDから始めてみます。ここで、私たちが特別に興味を持っている'interface'という枝は'2'でもあります(すなわち、1.3.6.1.2.1.2 か 1.3.6.1.2.1.interfaces)。
'2'という値を持つ'interface'枝は'2'に着目します(つまり、 1.3.6.1.2.1.2 または 1.3.6.1.2.1.interfaces ということです)。
最初に、なにかのSNMPのプログラムを手に入れなくてはなりません。あなたが使っているOS用のコンパイル済みパッケージがないかどうか探してみて下さい。その方がいいはずです。もしないならば、ソースを取得してコンパイルしないといけません。インターネット上にはたくさんのソースとプログラムがあります。サーチエンジンなどを使って情報を探して下さい。よく使われているCMU-SNMPを探すことを提案します。
無事プログラムを入手できたとしましょう。ほとんどのシステムで利用できるデータを集めようとして下さい。また、私達が興味を持っている樹の一部には、省略形があるということを覚えておいて下さい。
ここでは、樹をそのまま使うのではドキュメントが大きくなりすぎるので、その省略形を使いたいと思います。もしあなたの環境でうまく動かないようであれば、プレフィックス.1.3.6.1.2.1を付けてもう一度やってみて下さい。そして、良いマニュアルを読んで下さい。まだ理解できないのであれば、この部分を飛ばして下さい。それよりも、プログラムの実行方法と使用方法がわかるようになるべきですから。
snmpget myrouter public system.sysDescr.0
このデバイスは、自身の説明を返しますが、もしかするとそれは空かもしれません。正しい回答をデバイスから得られないとすれば、違うパスワードを使っているか、デバイス(myrouterの部分)が違うのでしょう。何も変えずに同じコマンドを実行することは無意味です。6
[6] 訳注: つまり上手く結果が得られないなら、トライアルアンドエラーでどこか変更してみて下さい :-) p
snmpget myrouter public interfaces.ifNumber.0
望むらくは、あなたは結果としてインターフェイス数を得られるでしょう。上手くできたなら、今度はsnmpgetではなく'snmpwalk'とよばれるプログラムを使ってみて下さい。
snmpwalk myrouter public interfaces.ifTable.ifEntry.ifDescr
インターフェイスのリストが得られたなら、ほとんど成功です。ここに、例を示しておきます。
[user@host /home/alex]$ snmpwalk cisco public 2.2.1.2 interfaces.ifTable.ifEntry.ifDescr.1 = "BRI0: B-Channel 1" interfaces.ifTable.ifEntry.ifDescr.2 = "BRI0: B-Channel 2" interfaces.ifTable.ifEntry.ifDescr.3 = "BRI0" Hex: 42 52 49 30 interfaces.ifTable.ifEntry.ifDescr.4 = "Ethernet0" interfaces.ifTable.ifEntry.ifDescr.5 = "Loopback0"
これはCiscoのルータで、'Ethernet0'インターフェイスを見てみたい場合には、4番を指定すれば良いことが分かります。。
[user@host /home/alex]$ snmpget cisco public 2.2.1.10.4 2.2.1.16.4 interfaces.ifTable.ifEntry.ifInOctets.4 = 2290729126 interfaces.ifTable.ifEntry.ifOutOctets.4 = 1256486519
2つのOIDsが得られました。1.3.6.1.2.1.2.2.1.10と1.3.6.1.2.1.2.2.1.107です。両方ともインターフェイス番号は4番です。
[7] 訳注: これは省略されていないOIDです。プレフィクス1.3.6.1.2.1が付与されています。
勘違いしないで下さい。これは私が一発で出した出力ではありません。これらの数字が何を意味しているか理解するために、私もいくらかの時間を要しました。それら(OIDs)が記述的なテキストに変換されることは、非常に助けとなります。少なくとも、人々がMIDsやOIDsについて語るとき、それがどういうことか分かるでしょう。インターフェイス番号を忘れないで下さい。snmpgetで答えを得られないならsnmpwalkを試して下さい。
もし、この部分を理解でき、あなたのデバイスから数字が得られたならば、チュートリアルを読み進めて下さい。そうでないならば、戻ってこの部分をもう一度読み直して下さい。
楽しい例を始めましょう。最初に、新しいデータベースを作成します。入力と出力という、二つのカウンタからのデータを保持します。このデータの平均がアーカイブに投入されます。このとき、1, 6, 24あるいは288個のサンプルを平均します。この平均と最大値がアーカイブに入れられ保存されます。このことはあとで説明します。サンプルを取る間隔は300秒ごとで、5分間を意味します。
MRTGと互換性を持つようにしてみましょう。MRTGは、以下のようにデータを記録しています。
[7] 訳注: (2日×24時)×12(60分/5) + 12(60分/5)×2=600
[8] 訳注: 48(24時間×2(60分/2)) × 12 + 24(12時間*2(60分/2)) = 600
[9] 訳注: 24(時間)/2(時間) × 50(日) = 600
これらの範囲と合わせてデータの総量がおおよそ797日になるように追加されます。RRDtoolは、データを異なった方法で格納します。毎日のアーカイブが止まっている間は、週間のアーカイブを開始しません。この二つの最近のアーカイブは、より測定時点に近いものです。それゆえに、MRTGが行なうよりも沢山のデータを保存する必要があります。
これだけ必要です。
rrdtool create myrouter.rrd \
DS:input:COUNTER:600:U:U \
DS:output:COUNTER:600:U:U \
RRA:AVERAGE:0.5:1:600 \
RRA:AVERAGE:0.5:6:700 \
RRA:AVERAGE:0.5:24:775 \
RRA:AVERAGE:0.5:288:797 \
RRA:MAX:0.5:1:600 \
RRA:MAX:0.5:6:700 \
RRA:MAX:0.5:24:775 \
RRA:MAX:0.5:288:797
次にすることは、データを収集して格納することです。例を示しておきます。一部は擬似コードで不完全に書いてありますので、あなたのOSで上手く動くようにする方法が必要です。
while not この世の終わり
do
get result of
snmpget router community 2.2.1.10.4
into variable $in
get result of
snmpget router community 2.2.1.16.4
into variable $out
rrdtool update myrouter.rrd N:$in:$out
wait for 5 minutes
done
そして、一日ごとのデータを収集したあとで、画像を作成します。
rrdtool graph myrouter-day.gif --start -86400 \
DEF:inoctets=myrouter.rrd:input:AVERAGE \
DEF:outoctets=myrouter.rrd:output:AVERAGE \
AREA:inoctets#00FF00:"In traffic" \
LINE1:outoctets#0000FF:"Out traffic"
これは、一日のトラフィック量を占めす絵を生成しているはずです。一日は、24時間で、一時間は60分で、一分は60秒なので、24×60×60=84600秒です。そこで、私達は、開始する日時から84600秒だけ引きます。ルータについてのデータベースから、入ってきたパケット(In)と出ていったパケット(Out)の量の平均値を定義(DEF)し、'in'については領域を、'out'については線で描画します。
この画像を見てから、さらに数日分のデータを記録してみて下さい。お好みならば、実験用データベースの例をやってみたり、様々なオプションや計算機能を経験したりして下さい。
提案:
バイト毎秒や、ビット毎秒で表示してみて下さい。あなたのイーサネットのグラフで、4Mbpsを越えたら、赤くなるようにしてみて下さい。
幾つか前の段落で、平均値の代わりに最大値を保存しておく可能性について言及しました。このことについて、より詳しく説明しましょう。
車の速度に関する事柄を思い出して下さい。5分間144KM/Hで運転し、25分間警察によって止められていたとしましょう。この部分の最後で、そのデータベースのデータを用いて画像ファイルを作って見ます。私達が作った二つ目のRRAを見ると、6個のサンプルの平均があります。測定したサンプルは、144+0+0+0+0+0=144 となり、30(分)で割って、誤りを修正するために1000で割って、最終的にKM/Hへ変換すると、結果は24KM/Hになります。もはやスピード違反ではないのに、手元には違反切符が残るでしょう。 :-)
この例で、平均に注目するのは明らかにおかしなことです。平均値が便利な場合もあります。移動距離KMを知りたいのならこの図を見るべきでしょう。一方で、移動した最大速度が見える方が価値があることもあります(あとでいくつかのタイプの紹介します)。
データについても同じことです。もし移動距離が知りたいならば、平均速度を見て下さい。速度や割合を知りたいならば、最大速度を見ましょう。時間の経過に従って、ますますバラバラに大きくなります。私達が最後に作成したデータベースにおいては、日々のデータを保存する二つのアーカイブがあります。平均値を取るアーカイブは低い数値を示し、最大値を保存するアーカイブはより高い数値を示すはずです。私の車の速度を例に取ると、平均の移動速度は96/24 = 4KM/H(これは、一日当たり94キロメートル移動するとして)で、平日の最大速度は120KM/H(私が毎日到達する最高速度)となるでしょう。
ここには大きな違いがあります。距離を評価するために最大値のグラフを見てはいけませんし、速度を評価するために平均値のグラフを見てはいけません。たとえば5分間のデータを見るときのように、両者がきわめて同じような値の時にはうまく評価できますが、平均を出してしまうとそうはいきません。
ある日、私は長く運転するとしましょう。もし、私がヨーロッパを横断して12時間以上移動したとすると、平均値のグラフは60KM/Hに上昇し、最大値のグラフは180KM/Hを示すでしょう。この日の移動距離は、60KM/H × 24時間 = 1440 KMということになります。私は、もっと速いスピードで走り、最高速度は180KM/H程度でした。もちろん、私が8時間だけ180KM/Hの速度で移動した10わけではありません! 実際には、ドイツでは非常に高速で走り、ガソリンとコーヒーのために数回停止しただけでした。オーストリアとオランダを通過するときには、ゆっくり走りました。山や村では注意して運転しないといけませんから。5分ごとの平均から作成されたグラフを見ると、図が大きな違うことが分かるでしょう。データを300秒ごとに測定してさえいれば、平均値と最大値のグラフではほぼ同じ数値が出るでしょう。私がいつ車を止めたか、いつトップギアをに変えたか、いつ高速道路に乗ったか、などを見ることができるでしょう。データの粒度(測定間隔)が小さくなればなるほど、沢山のことがわかるようになります。しかし、一時間に12サンプル (一日に288個) を取ったのでは、データを長い間保管しておくには多すぎます。そのため、私達はこれらを平均して、一日あたり一つの値にします。しかし、一つの値からは、それ以上の詳細を見ることはできません。11
[10] 訳注: 1440km ÷ 180km/h = 8時間
[11] 訳注: このことは、時間が経過すると見ることのできる粒度(あるいは解像度)が低下せざるをえないことを意味しています。
ここまでの数段落の内容をしっかりと理解して下さい。ただの軸と線には何の価値もありません。良い方法で、データを解釈しそれが何を意味をするのか知る必要があります。これはあらゆるデータについて言えることです。
最も大きな間違いは、収集したデータを適切でない用途で使用することです。このような場合に、(間違いを)目の当たりにしないというのは、全く幸運なことです。
あなたは、どうやってデータベースを作成するのか理解しました。数字をその中に入れ、イメージを作成することによって再度そのデータと取りだすこともできますし、データベースからとってきたデータを計算して生のデータのかわりに使うこともできるでしょう。最大値と平均の違いもわかっています。少なくともアイデアがあるなら使うときです。
RRDtoolでは、ここまでで学んできた以上のことができます。このチュートリアルの残りを読み進める前に、最初から読み直し、例をいくらか変更してみて下さい。全ての理解を確かなものにして下さい。その努力するだけの価値はあり、このドキュメントの残りだけでなく、このドキュメントを読んだあとの以後の日々のモニタリングをも助けてくれることでしょう。
続けて良さそうですね。お帰りなさい。12説明と例題の速度を上げる準備をして下さい。
[12] 訳注: 上の段落で、読み直しとサンプルの改良/変更をするように書いていましたから、それを受けているものと思われます :-)
カウンタ(増分レート)を見るためには、二つの数字を取得し、経過した時間で割り算しなければなりません。これは私があなたに示した例では意味のあることですが、そうではない場合もあります。私は、ルータの吸気口やホットスポットや排気口からの温度を受けとることができますが、これらの値はカウンタではありません。もし、この二つの値の差をとって300秒で割ると、毎秒あたりの(温度そのものではなく)温度変化を見ていることになります。願わくば、その値は0であってほしいものです! そうでなければ、コンピュータのある部屋は燃えているのでしょう :-)
さて、どうすればいいのでしょうか? RRDtoolに対して、私達が測定した値をそのまま入れろと言えばいいのです(このことは厳密には違いますが、十分正確です)。私達が作るグラフは、一定値を示し、現状を良く表わします。私はこのことを、非常にルータがビジーになっているときに知りました(ルータが稼働→電力消費→発熱→温度上昇)。また、ドアを開けっぱなしにしておいたときに知りました(部屋が冷える→建物の他の部屋の暖かい空気がコンピュータ室に入る→吸気口の温度が上昇)。今までデータベースを作るときにはCOUNTERを使っていましたが、今度は違ったデータタイプを使用します。このデータタイプには別の名前が与えられており、これをGAUGEといいます。ここでデータタイプの一覧を示します。
ここで新しくDERIVEとABSOLUTEという2つのタイプが出てきました。ABSOLUTEは、カウンタのように使いますが、一点だけ違います。RRDtoolは、カウンタを読みとるときに、0にリセットするものとしています。つまり、COUNTERタイプの場合には別途計算が必要ですが、ABSOLUTEの場合には計算することなく差を知ることができます。たとえば、最初の例(12345, 12357, 12636, 12636)は、unknown, 12, 6, 0と読みとられるでしょう。残りの計算も同じです。 このもうひとつのタイプであるDERIVEもカウンタに似ています。COUNTERと違うのは、差分が負になりうることです。残りの計算については同様です。
これを試してみて下さい。
rrdtool create all.rrd --start 978300900 \
DS:a:COUNTER:600:U:U \
DS:b:GAUGE:600:U:U \
DS:c:DERIVE:600:U:U \
DS:d:ABSOLUTE:600:U:U \
RRA:AVERAGE:0.5:1:10
rrdtool update all.rrd \
978301200:300:1:600:300 \
978301500:600:3:1200:600 \
978301800:900:5:1800:900 \
978302100:1200:3:2400:1200 \
978302400:1500:1:2400:1500 \
978302700:1800:2:1800:1800 \
978303000:2100:4:0:2100 \
978303300:2400:6:600:2400 \
978303600:2700:4:600:2700 \
978303900:3000:2:1200:3000
rrdtool graph all1.gif -s 978300600 -e 978304200 -h 400 \
DEF:linea=all.rrd:a:AVERAGE LINE3:linea#FF0000:"Line A" \
DEF:lineb=all.rrd:b:AVERAGE LINE3:lineb#00FF00:"Line B" \
DEF:linec=all.rrd:c:AVERAGE LINE3:linec#0000FF:"Line C" \
DEF:lined=all.rrd:d:AVERAGE LINE3:lined#000000:"Line D"
この結果は以下のようになります。23:10に始まり、次の日の00:10に終わります (uは不明値ないしはプロットされない点です)。
Line A: u u 1 1 1 1 1 1 1 1 1 u Line B: u 1 3 5 3 1 2 4 6 4 2 u Line C: u u 2 2 2 0 -2 -6 2 0 2 u Line D: u 1 2 3 4 5 6 7 8 9 10 u
もしあなたが作ったGIFがこれらを全て表示しているならば、入力データとタイプが正しいことがわかります。RRDtoolは正しく実行されており、あなたのビューワも怪しくなく、無事に2000年になりました:) 一行ずつにして四回別々に試してみて下さい。
データについて再び見てみましょう。
これからいくつか基本的なことをお見せします。いくつか重要なことがまだ説明されておらず、まだカウンタの桁あふれ13を見ていません。最初のカウンタの桁あふれとして、最初の車の例を考えます。カウンタが99987だったとします。ここで20KM走行すると、カウンタは1000007を示すはずです。ところが不幸なことにこのカウンタは、6ケタまでしかなく、実際には000007を示していました。もし、タイプDERIVEでプロットしていた場合、それは999980の減少を意味します。実際はそうではないわけで、こうならないように防止するための手段があります。この対策は、この種のカウンタを扱う場合には常に使うべきデータタイプCOUNTERでのみ利用可能です。どのように機能するか説明しましょう。COUNTERタイプは減少することはないので、もしカウンタが減少していたら、RRDtoolは回り込みが発生したと仮定してしかるべきです! もし差分が負であるならば、カウンタの最大値に1を足した数を足すことで補正できます。先程の車の場合だと、
Delta = 7 - 999987 = -999980 (1000007-999987=20の代わりに) Real delta = -999980 + 999999 + 1 = 20
このドキュメントが書かれた時点では、RRDtoolは32ビットか64ビットのサイズのカウンタを取り扱えます。これらのカウンタは、以下の値を取り扱うことができます。
- 32 bits: 0 .. 4294967295 - 64 bits: 0 .. 18446744073709551615
もしこの数字が奇妙に見えるなら、16進数で表示したほうが良いかもしれません。
- 32 bits: 0 .. FFFFFFFF - 64 bits: 0 .. FFFFFFFFFFFFFFFF
[13] 訳注: 原文ではCounter Wrapでした。桁あふれは、別名オーバーフロー(overflow)ともいいます。
RRDtoolは、両方のカウンタを同じように取り扱います。もし、オーバーフローが発生し差分が負になったら、RRDtoolはまず、より小さい方のカウンタの最大値に1を足した数字を差分に加えます。もし、それでも差分が負であるならば、より大きいカウンタであるとして補正を行ないます。あり得る範囲内での大きいカウンタの数値に1を足した数を加え、(先程の)間違って足した数字を引きます。これには、以下のリスクがあります。巨大な差分を加えているときに、大きなカウンタの回り込みが起きたとすると、なるべく小さな値を加えることで差分をプラスする理論で発生する問題です。これはありそうにないケースですが、正しくない結果を引き起します。
カウンタの最大値に近い数値がカウンタに加えられるということは、他にいくつかの問題を発生させますし、この問題はそれ以上考える価値を持ちません。この例を含めても、あなたはこの問題を判断することができます。
次に、カウンタの回り込みにおける実際の数値を用いた例をお見せします。実際にあなた自身で計算するか、あなたの電卓で計算できないのであれば、この結果を信用してください :)
正しい数値
32 bits: (4294967295+1) = 4294967296 64 bits: (18446744073709551615+1)-correction1 = 18446744069414584320 Before: 4294967200 Increase: 100 Should become: 4294967300 But really is: 4 Delta: -4294967196 Correction1: -4294967196 +4294967296 = 100 Before: 18446744073709551000 Increase: 800 Should become: 18446744073709551800 But really is: 184 Delta: -18446744073709550816 Correction1: -18446744073709550816 +4294967296 = -18446744069414583520 Correction2: -18446744069414583520 +18446744069414584320 = 800 Before: 18446744073709551615 ( maximum value ) Increase: 18446744069414584320 ( absurd increase, minimum for Should become: 36893488143124135935 this example to work ) But really is: 18446744069414584319 Delta: -4294967296 Correction1: -4294967296 + 4294967296 = 0 (not negative -> no correction2) Before: 18446744073709551615 ( maximum value ) Increase: 18446744069414584319 ( one less increase ) Should become: 36893488143124135934 But really is: 18446744069414584318 Delta: -4294967297 Correction1: -4294967297 +4294967296 = -1 Correction2: -1 +18446744069414584320 = 18446744069414584319
最後の2つのサンプルのように、RRDtoolが失敗するには奇妙な数字が必要となります(バグでなければ)ので、普通はこういったことは起きないでしょう。しかし、SNMPなど、データを集めるどんな手段においても、時々変な数値が報告されることがあります。私達は、全てのエラーを防ぐことはできませんが、しかしできることはいくつかあります。RRDtoolは、二つの特別なパラメータをcreateコマンドで使うことができます。それは、許容されうる最大値と最小値14を与えます。今まで、'U'を '不明(Unknown)'の意味で使っていました。もし、あなたがこれらのうち一つか両方をRRDtoolへ渡し、RRDtoolがその範囲外の数値を受信したなら、その数値は無視されます。摂氏温度計は、およそ-273が最小値です。私のルータにおいては、この最小値は10よりは大きいと仮定することができます。さらに、最大の温度はおおよそ80と言えるでしょう。その値を超えるようであれば、ルータの調子が悪いか故障していると考えられます。私の車では、速度計の値が負になることはないでしょうし、230より高い値にはならないだろうと期待して良いでしょう。この範囲にないなら、エラーがあったに違いありません。ただし、この逆は真実ではないことを覚えておいて下さい。渡された数値がこのチェックを通過したからといって、その数値が正しいということを意味するわけではありません。もし、奇妙なグラフを見たのであれば、グラフが正しいかどうかを偏執的に判断して下さい。
[14] 訳注: 例えば 'DS:a:COUNTER:600:U:U' だと後から二つの ':U:U' がそうです
ある重要なRRDtoolの機能をまだ紹介していませんでした。厳密に正確な間隔でデータを収集してRRDtoolへ渡すことは、事実上不可能です。RRDtoolはそれゆえに、正確な間隔になるようにデータに手を加えます。もしあなたが、これがどのような意味を持ち、どのように働くが知らないなら、以下の文章が参考になるでしょう。
毎秒ごとに正確に一つだけ増えるカウンタを想定します。300秒の間隔でこれを測定したいとしましょう。あなたはデータを正確に300秒だけ経過した後にデータを受けとらなければなりません。しかしながら様々の状況のため、あなたは数秒遅れてしまいデータの間隔が303秒になってしまいました。よってこの場合には、差は303秒になります。明らかにRRDtoolは、データベースに303を入れてはならないですし、あなたもカウンタが300秒で303だけ増えたと信じてはいけません。ここがRRDtoolがデータに手を加える場所です。303という数値が(303秒よりも)早く300秒に格納されたかのように手を加えます。次の時間には、あなたは正確な時刻に測定します。このことは、現在のインターバルが297秒であり、カウンタが297だけ増えていることを意味します。再びRRDtoolはデータに手を加えて、そうあるべきように300を格納します。
in the RDD in reality time+000: 0 delta="U" time+000: 0 delta="U" time+300: 300 delta=300 time+300: 300 delta=300 time+600: 600 delta=300 time+603: 603 delta=303 time+900: 900 delta=300 time+900: 900 delta=297
全く同じデータベースを作成しましょう。時間の範囲は920805000 から 920805900です。
rrdtool create seconds1.rrd \
--start 920804700 \
DS:seconds:COUNTER:600:U:U \
RRA:AVERAGE:0.5:1:24
for Unix: cp seconds1.rrd seconds2.rrd
for Dos: copy seconds1.rrd seconds2.rrd
for vms: how would I know :)
rrdtool update seconds1.rrd \
920805000:000 920805300:300 920805600:600 920805900:900
rrdtool update seconds2.rrd \
920805000:000 920805300:300 920805603:603 920805900:900
rrdtool graph seconds1.gif \
--start 920804700 --end 920806200 \
--height 200 \
--upper-limit 1.05 --lower-limit 0.95 --rigid \
DEF:seconds=seconds1.rrd:seconds:AVERAGE \
CDEF:unknown=seconds,UN \
LINE2:seconds#0000FF \
AREA:unknown#FF0000
rrdtool graph seconds2.gif \
--start 920804700 --end 920806200 \
--height 200 \
--upper-limit 1.05 --lower-limit 0.95 --rigid \
DEF:seconds=seconds2.rrd:seconds:AVERAGE \
CDEF:unknown=seconds,UN \
LINE2:seconds#0000FF \
AREA:unknown#FF0000
二つのグラフは全く同じものになるはずです。
このドキュメントもようやく終わりです。いまやあなたはRRDtoolを使う上で必要な全ての基本的なことを知り、ドキュメントを読むことができます。RRDtoolについてのより多くのことを明らかにしているドキュメントがまだまだあり、それを見つけてもっともっとRRDtoolのパッケージを使えます。RRDtoolとここで提供している例を使って、簡単にグラフを作成できます。すでにいくつか存在するフロントエンドを使うこともできます。
メーリングリスト15を講読することを忘れないで下さい。たとえあなたが質問に答えることができなくても、配送されるメールの中身は興味深いはずですし、以下に述べるようにあなたとそれ以外の人々の助けになります。MRTG(とそれゆえにRRDtool)について私が知っていることの大半は、メーリングリストに投稿したことによってではなく、配信されてくるメールを読むことによって勉強したものです。私はFAQ(読んで下さい!)にあったり、他のユーザによる数々のメールにあったりするような基本的なことを質問する必要はありませんでした。世界中には数千人のユーザがいます。あなたが答えることのできる質問をする人々は常に存在します。なぜならば、あなたはこのドキュメントや他のドキュメントを読み、彼等は読んでいないからです。
[15] 訳注: RRDtool-usersのメーリングリストは当然英語です。
RRDtoolのman page.
挙げてきた例と解説をお楽しみいただけることを望みます。楽しんでいただけたならば、基本的な質問をする人に対して、あなたがこのドキュメントを示すことで助けてあげて下さい。彼等はその質問に対する回答を得られるばかりでなく、同時にもっと沢山のことを学べるでしょうから。
Alex van den Bogaerdt <alex@ergens.op.het.net>
このチュートリアルを翻訳し公開することを許可して下さった原著者である Alex van den Bogaerdtに深く感謝しています。
また、翻訳したこのドキュメントのチェックをして下さった、私の友人である 和志武 功久 氏 および 松浦 匡 氏 にも、この場を借りて御礼を申し上げます。
いくつかの用語をCDEFチュートリアルと一貫性を持たせるためにいくつかの訳を変更しました。たとえば当初 Consideration Function を以前は「拡張機能」と訳しましたが、明らかに伝えるべきニュアンスが違うので、RRAの steps 引数個だけ保存されたデータを評価する関数というニュアンスを込めて「評価関数」に変更しました。