help - MRTGで問題にぶつかったら
MRTGについて分からないと思うことが結構あるようです。ドキュメント化されたもの以外にもMRTGのヘルプが得られるリソースがたくさんあります。
Alex van den Bogaerdt <alex@ergens.op.Het.Net> は
http://faq.mrtg.org
にあるMRTG FAQ Webサイトを管理しています。
以下に続くセクションに追加のよくある質問とその回答があります。
誰も @#$%.pmdファイルを寄稿してないからです。mrtg-2.9.22/translate ディレクトリで自分用の翻訳ファイルを作成して下さい。もし満足いくものができたら、次のMRTGリリースに入れられるよう私に送って下さい。
たぶんすでにあると思います。mrtg-2.9.22/contribディレクトリを確認してください。00INDEXというファイルにそこに何があるかが書かれています。
SNMPについて解説したたくさんのリソースがネット上にあります。 Linuxジャーナルに載っていたDavid Guerreroの記事も読んでみてください:
http://www.develnet.es/~david/papers/snmp/
Ciscoにはもっと長い文章もあります
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/snmp.htm
*-{week,day,month,year}.pngを削除して、MRTGを再起動してみてください。MRTGを最初に起動した場合には、これを2回する必要がある場合があるかもしれません。新しくルータをcfgファイルに追加した時にも有効かもしれません。
ルータの管理者に尋ねるか、デフォルトのコミュニティ名である「public」を試してみて下さい。
短い回答としては SNMPクエリが発行されてレスポンスが戻って来なかった場合、MRTGはグラフに出力するものを何か推測しなくてはならず、デフォルトでは最後に来たレスポンスがゼロよりも実際に近いものと仮定します。この推測は(あなたが気づいたように)完璧ではありませんが、完全に機器が落ちたときに起こるトレードオフです。
もしこれが許容できないトレードオフならunknaszeroオプションを使用して下さい。
あなたが何をトレードオフしているかについて知りたいかもしれません。トレードオフの精神にあるように、これが長い回答です:
問題はMRTGがどうしてデータが戻ってこなかったのか理解できないことにあり、わかるのは戻ってこなかったということだけです。何かしなくてはいけないので、機器が落ちたと考えるよりパケットがロスしたと仮定します。
どうしていつも回線ダウンを仮定せず、ゼロも使わないかというと、たいていの場合(私たちが考えるに)それが正しいからです。あなたはもしかすると知らず知らずのうちにMRTGの「最後を推測」を利用しているかもしれません。
MRTGはSNMP (Simple Network Management Protocol) を使用してデータを収集しており、SNMPはUDP (User Datagram Protocol) を使用してパケットを運送しています。UDPはコネクションレス(保証がない)で - TCPのようにパケットは追跡され承認され必要に応じて再送されるわけではなく UDPはパケットをネットワークに放り投げて届くことを願うだけです。時にそれは届きません。
SNMPデータの紛失の原因として考えられるのは回線輻輳か、ルータが忙しい場合です。他には一時的なテレコミュニケーションの問題や、ルータのバッファオーバーフロー(輻輳に関連してかしないか)、「汚い接続」(エラー率の高い接続)、か神の仕業か。これらはいつでも起こっているが、多くのインタラクティブサービスはTCPベースで失われたパケットは自動的に再送されるため私たちが気づくことはありません。
SNMPパケットが失われてもトラフィックが流れているような上記の場合、ゼロと推測するのは間違っています。回線がいっぱいになるたびにすきっ歯のようなグラフが生成されることになるでしょう。MRTGは断続的なパケットロスの際にも正確と思われるスムーズなグラフが生成されるように、失われたデータを補間します。しかしながらV2.8.4以降では「unknaszero」オプションを使用してネットワークの状態に応じて最もよいとするグラフを生成させることができます。
Tobias Oetiker <oetiker@ee.ethz.ch>
橋本 理央 <e2j@mrtg.jp>