# MRTG: The Multi Router Traffic Grapher > [!abstract] 概要(abstract の日本語訳) > 本論文は、MRTGの現行バージョンの歴史と動作、およびRound Robin Database Toolについて述べる。Round Robin Database Toolは数値データを効率的にログ・可視化するプログラムである。RRD Toolは次期メジャーリリースであるMulti Router Traffic Grapher(MRTG)の主要コンポーネントである。RRD Toolはすでに完全に実装され動作している。RRD Toolによって得られる大幅な性能向上のため、一部のサイトはすでにRRD Toolを本番環境で使い始めている。 ## 論文情報 - タイトル: *MRTG: The Multi Router Traffic Grapher* - 著者: [[Tobias Oetiker]]([[wiki/entities/ETH Zürich|ETH Zürich]]) - 会議: 12th USENIX Systems Administration Conference (LISA '98)、1998年12月6日〜11日、ボストン - URL: https://www.usenix.org/legacy/publications/library/proceedings/lisa98/full_papers/oetiker/oetiker.pdf - 会議ページ: https://www.usenix.org/conference/lisa-98/mrtg-multi-router-traffic-grapher - 原本: `.raw/papers/lisa98-oetiker-mrtg.pdf`(9ページ) ## 概要 MRTG(Multi Router Traffic Grapher)は、ルータのSNMPカウンタを5分ごとに問い合わせ、日・週・月・年のトラフィックグラフを含むWebページを自動生成するツールである。本論文は、単一ワークステーションでの運用を想定したMRTG-1から、Cによる高速化とロスによる解像度低下を伴うログファイル(lossy logfile)設計を導入したMRTG-2、そして時系列データストレージを汎用ツールキットとして切り出したRound Robin Database(RRD)を核とするMRTG-3への発展を、動機・設計判断・実運用事例とともに説明する。 ## 問題設定 1994年、De Montfort大学(英国レスター)では1000台超のネットワーク機器に対して64kBitの単一インターネット回線しか持たず、増速までの間、回線状況を学内に可視化する必要があった。この動機からMRTGが生まれ、5分間隔でルータのオクテットカウンタを取得しグラフ化するPerlスクリプトとして最初に実装された。日・週・月・年のトラフィックグラフを含むWebページが自動生成され、ブラウザを持つ全員が回線の状況を監視できるようになった。 ![[fig01-mrtg2-webpage-screenshot.png]] *図1(Figure 1): MRTG-2が生成するWebページのスクリーンショット。5分・30分・2時間・1日の各平均でトラフィックグラフを重ねて表示する。* MRTG-1が公開されると利用者からスケーラビリティと移植性の2つの課題が寄せられた。ログファイルを毎回全体書き換えする設計は10リンク程度なら問題ないが、大規模サイトでは性能限界に達した。加えて、SNMP取得に使っていたCMU SNMPパッケージが各種プラットフォームでコンパイルしづらく、移植性のボトルネックとなっていた。 ## 提案手法 ### MRTG-2: Cによる高速化とlossyログファイル Dave Randが実装したC製ユーティリティ`rateup`が、Perlスクリプトから最もCPU負荷の高いログファイル書き換えとグラフ生成をC実装へ移すことでMRTG-2開発の契機となった。Thomas BoutellのGDライブラリへの切り替えでGIF生成が高速化し、Simon LeinenのPerl SNMPモジュールへの切り替えでCMU SNMPへの依存が解消され移植性が改善した。 MRTG-2の鍵となる設計は、時間が経過するほど詳細データへの関心が比例的に減衰するという前提に基づく**lossyログファイル**である。ログは過去に向かって解像度を落としながらデータを保持し、2年より古いデータは破棄される。ログの解像度はWebページに表示するグラフの解像度と一致させてあるため、グラフ描画時にデータ削減処理が不要になり、ディスクI/Oが最小化される。 ![[fig02-ascii-logfile-processing.png]] *図2(Figure 2): ASCIIログファイル処理。`rateup`がログファイルを読み込み(read)、処理後に同じログファイルへ書き戻す(write)。* ログファイルは平文ASCIIで、各行がタイムスタンプとトラフィックデータからなる。更新のたびにファイル全体をメモリへ読み込み、処理し、ディスクへ書き戻す。 ![[fig03-mrtg2-logfile-processing.png]] *図3(Figure 3): MRTG-2ログファイル処理。5分平均が3件たまるごとに1件の15分平均へ、さらに上位解像度へと段階的に統合(consolidate)されながら、各段階で個別のログ書き換え(log rewrite)が発生する構造を示す。* ### MRTG-3とRound Robin Database(RRD) 利用者がMRTG-2をトラフィック以外の時系列データ(温度・負荷など)の監視に転用し始めたことから、MRTG-3ではネットワークトラフィック監視専用アプリケーションから、多様な時系列データソースを扱うための汎用ツールキットへと方向転換した。時間クリティカルな部分をCで実装し、糊付け部分はPerlのまま残すことで、再コンパイルなしにカスタマイズできる構成とした。 MRTG-3開発の中核として新設計されたデータストレージ機構がRound Robin Database(RRD)であり、C実装の`rrdtool`として、コマンドラインまたはPerlバインディング経由で利用できる。RRDはMRTG-2のログファイルと異なり、事前確保した固定サイズの循環領域(Round Robin Archive、RRA)へデータを格納する。RRAは時間解像度・サイズ・統合(consolidation)方式をそれぞれ独立に設定でき、1つのRRDに任意個のRRAを持たせられる。各RRA内の最新エントリ位置はポインタ配列で管理されるため、更新は1回の書き込みだけで済む。 ![[fig04-rrd-update-procedure.png]] *図4(Figure 4): MRTG-3/RRDの更新手順。静的ヘッダ(STATIC HEADER)にデータソース定義(DS1〜DS3)とRRAごとの準備領域(RRA1 PREP・RRA2 PREP)を持ち、RRD Toolが各RRA(RRA1・RRA2)を循環的に更新する。* RRDは複数のデータソースを並行して受け付けるよう構成でき、各RRDは設定可能な基準時間解像度を持つ。到着間隔が不規則なデータもこの基準解像度へ再サンプリング(re-sampling)され、以降の処理・格納を単純化する。 ![[fig05-data-resampling.png]] *図5(Figure 5): カウンタ型データソースを300秒間隔で再サンプリングする過程。到着タイミングが不規則な生データ値(data source value)を、面積(曲線下の値の総量)を保ったまま固定間隔の値(resampled data)へ変換する。* RRD形式はデータ格納にdouble型を使うことでMRTG-2で見られた整数オーバーフロー問題を解消し、スケーリングなしで小さな値(マシン負荷など)も記録できる。また、データ入力が0である状況と有効な新規データが得られない状況を区別するため、unknown値を格納できる。ログエントリ数・ログ解像度・並行して記録するデータソース数などはRRDごとに設定可能であり、ネイティブなバイナリ形式でデータを保持するため変換コストがかからない(RRDヘッダのcookieでアーキテクチャ互換性を検査する)。 RRD Toolのグラフ生成機能は、任意サイズ・任意期間のグラフを、複数のRRDにまたがる複数データソースから描画できる。設定可能なパラメータの多くには妥当なデフォルト値が自動選択され、RPN(逆ポーランド記法)演算を使った複数データソースの合成計算にも対応する。 ![[fig06-rrdtool-sample-graph.png]] *図6(Figure 6): RRD Toolによるサンプルグラフ。複数データソース(Alpha・Beta Text・Gamma 1・Delta 2・calc 5)と水平参照線を1枚のグラフに重ねて描画している。* `rrdtool create`でRRDを新規作成し、`rrdtool update`でデータを追加し、`rrdtool graph`でグラフを生成する。以下はセルシウス温度データをRPN演算(`CDEF`行)で華氏へ変換し、過去24時間分のグラフを生成する例である。 ``` rrdtool create demo.rrd --step=300 DS:COUNTER:400:0:1000000 \ DS:GAUGE:600:-100:100 RRA:AVERAGE:1:1000 RRA:AVERAGE:10:2000 \ RRA:MAX:10:2000 rrdtool update demo.rrd DATA:1994982:U rrdtool graph demo.gif --start=-86400 --title="LISA Demo Graph" \ --vertical-label='Degree Fahrenheit' \ DEF:celsius=demo.rrd:1:AVERAGE \ "CDEF:fahrenheit=celsius,9,*,5,/,32,+" \ AREA:fahrenheit#ff0000:"Temperature in Room J97" \ GPRINT:fahrenheit:AVERAGE:"Average for the last 24h %2.1fF" ``` ![[fig07-sample-line-output.png]] *図7(Figure 7): 上記グラフ生成コマンドの出力例。過去24時間の室温(華氏換算)を面グラフで表示する。* ## 新規性 - ログ解像度を過去へ向かって段階的に落とすlossyログ設計により、無人運用でもディスク容量が増大しない時系列ログ機構をMRTG-2で実現した点。 - ログファイル全体の読み込み・書き戻しに代わり、固定サイズの循環領域(RRA)へポインタ更新だけで書き込むRound Robin Databaseという時系列専用ストレージ形式を設計した点。 - グラフ描画・データ収集・データ統合・可視化を単一パッケージへ統合しつつ、MRTG-3ではネットワークトラフィック監視専用ツールから任意の時系列データソースを扱える汎用ツールキットへ再設計した点。 - RPN演算による任意のデータソース間の合成計算と、コマンドラインまたはPerlバインディングの双方から利用できるグラフ生成エンジンを提供した点。 ## 実験設定 論文中で明示的なベンチマーク実験の記述は限定的であり、性能に関する記述の多くは実運用事例からの数値である。 - RRD Toolの単体性能: Pentium 120(Linux)およびSparc Ultra Enterprise 2(Solaris、200MHz)でグラフ生成に約0.3秒。ローカルディスクアクセスでは秒間千オーダーのデータ値を格納可能だが、NFS経由やディスクキャッシュ不足時は性能が大幅に低下すると述べられている。 - 実運用事例: Otmar Lendlによる EUnet Austria 向け監視システムが、SPARCstation-5/170上でRRD Toolを用い、1200のネットワークインタフェース・サーバ・ダイヤルインラインから約6000変数を5分間隔で監視。 ## 実験結果 - MRTG-2は約600ルータポート/5分間隔で性能限界に達する(ログファイル全体の読み書き方式に起因)。 - RRD Toolのグラフ生成は約0.3秒(Pentium 120)で完了し、数千枚規模のGIF画像をオンデマンド生成しても許容可能な応答時間を保てると論じている。 - EUnet Austriaの実運用では低スペックマシン(SPARCstation-5/170)上で負荷0.2程度に収まっており、RRD Toolのオーバーヘッドの小ささを裏付ける事例として提示されている。 - MRTGホームページのリファラログ解析(1998年8月、過去2年分)から、少なくとも17500の異なるホスト・11400の2次ドメイン・120のトップレベルドメインでMRTGが使われていると推定される(バックリンクを外したサイトやリンクを一度も踏まないサイトは含まれないため下限値)。 ## 考察 - 著者は、NeTraMet・CFlowd・BigBrother・NetSCARFのScionといった同時代のツールと比較し、MRTGの独自性は長期分析と親しみやすいWeb提示の組み合わせにあったとしている。 - MRTG-2はMRTG-1から性能面で大きく改善したが根本設計はPerlスクリプトのままであり、利用が拡大するにつれ「意図しない用途(トラフィック以外の時系列データ監視)への転用」が設計の限界を露呈させ、MRTG-3への全面再設計を動機づけたと総括している。 - RRDの設計はMRTG-3の完成を待たずに単体で有用と判断され、開発者メーリングリストでの議論の結果、独立パッケージ`rrdtool`として切り出された。 ## 強み / 弱点・課題 - 強み: SNMPデータ取得・時系列ストレージ・グラフ生成という一連の機能をSNMPパッケージや外部データベースへの依存なしに単一パッケージへ統合した点(Integrated Solution)。ログが自動的に統合され肥大化しないため長期間の無人運用に耐える点(Easy Maintenance)。 - 弱点・課題(本文に明記): MRTG-2はログファイル全体の読み書き方式に起因して約600ポート/5分間隔で性能限界に達する。MRTG-2の設定の柔軟性は、特にネットワークトラフィック以外の時系列データを扱う際に限界が意識されやすいと述べられている。RRD Toolのアクセス性能はNFS経由やディスクキャッシュ不足時に大きく低下する。SNMPデータ収集自体の並列化(複数SNMPリクエストの並行発行)はMRTG-3の今後の計画として述べられており、本論文の時点では未実装。