スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

MRTG cfgmaker用ホストテンプレート

MRTGの設定ファイルを生成してくれるユーティリティcfgmakerは、標準ではネットワークインターフェースについての監視項目のみを生成するようになっている。対象ホストのその他の監視項目を自動生成したければ、「ホストテンプレート」という雛形ファイルを用意してこれをcfgmakerのコマンドラインオプションで指定することになっている。

Cheshire Cat Softwareにはさまざまなハードウェアに対応したホストテンプレートが置かれている。私はLinuxしか使っていないので、ここからHost template for Linuxをいただいてきて、これをベースとして使うことにした。

だが実際使ってみると、多少自分の環境に合わせて修正が必要だった。OIDを数値で指定しないと情報が取れないとか、PageTopに指定する文字列は<H1></H1>で囲まねばならないとか、あと自分の好みでメモリに関しては空きメモリではなく使用メモリを表示するようにしたとか、まあ些細なことであるが、一応ここに置いておく。

最終的には、手編集一切なしでMRTGの設定ファイルを作成したいのである。このテンプレートを(ファイル名host.tplとする)用いて、

$ cfgmaker --ifref=name --host-template=templates/host.tpl --global "WorkDir: /var/www/mrtg" --global "Options[_]: growright" --subdirs=HOSTNAME community1@host1 community2@host2

として設定ファイルを生成し、さらにその後にMRTG用のディスクエントリを自動生成するで作成したディスクパーティション監視用のエントリを結合して使う。

これで一応、自分の環境では手編集を行うことなくMRTGの設定を行うことができるようになった。
スポンサーサイト

MRTG用のディスクエントリを自動生成する

MRTGの設定ファイルを生成してくれるユーティリティとして、cfgmakerがある。デフォルトではネットワークインターフェースを監視するエントリしか生成してくれないが、一緒にホスト用のテンプレートファイルを使用することで、ロードアベレージその他の項目用のエントリも生成することが可能になる。各種ルータに対応したホストテンプレートを集積したサイトもあるので、私の場合もとりあえずそういったものを利用して、若干の手修正を加えたりして設定ファイルを作成した。

ただ、ディスクパーティションの使用率に関しては、手に入れたテンプレートでは対応していなかった。これは、ディスクパーティションに関しては、SNMPで取得したリストのうちどれが監視に値するものか判断するロジックが若干面倒で、テンプレートだけでは対処しきれないということもあるようである。

極端な話、dfコマンドやmountコマンドの出力から、各ホスト毎に手編集でエントリを作成してもいいのであるが、毎回同じ作業をするのも精神的に疲れる。若干調べてみると、世の中にはcfgmakerにインスパイアされたcfgstoragemakerというパッケージもあるらしい。これをインストールすれば解決か?と思ったのであるが、そう簡単ではなかった。

確かにDebianのサイトにはソースがあるのだが、apt-cacheではcfgstoragemakerは引っかからない。とりあえずこのサイトからall.debパッケージを持ってきてインストールしてみたが、HOST-RESOURCES-MIB.txtファイルが必要で、しかもこのファイルをまた適当に探してきてインストールしてみても、結局うまくSNMPで情報が取れないようである。つまりは、SNMPで完全に環境に依存せずディスクエントリを取得するのは意外と困難であるということのようだ。

それでまあ、このcfgstoragemakerの中を見てみると、比較的簡単なperlスクリプトである。簡単とは言っても、私のperlレベルはさらに心許ないので、自分の環境で動作するようにするついでに、perlよりはまだしも馴染みのあるPythonで書き直すことにした。

とりあえず、自分の環境でしかテストしていないので、多くの人の環境では手直しがいるであろうが、作成したスクリプトをここに置いておく。

このアーカイブを展開すると、
cfgstoragemaker.py
header.tpl
body.tpl

の3つのファイルができる。インストーラなどはないので、ここで説明させていただく。

インストール
header.tpl、body.tpl の二つのテンプレートファイルを、どこかのディレクトリに置く。デフォルトでは、cfgstoragemaker.pyを実行するユーザのホームディレクトリの下のtemplatesサブディレクトリを想定している。また、cfgstoragemaker.py自体はどこかpathの通ったところに置けばよい。

もし、テンプレートを標準の場所以外のところに置いたり、名前を変える場合は、cfgstoragamaker.py中の変数tpl_dir、tpl_header、tpl_bodyの定義を書き換えてもらえばよい。(97行目近辺にある)

先に言及したDebianサイトにあるオリジナルのcfgstoragemakerのテンプレートとは互換性がないので注意してほしい。両者を混在させるならテンプレートの置き場所かファイル名を変える必要がある。

あと、cfgstoragemaker.pyが動作するためには、libsnmp-pythonパッケージが必要である。

使用方法
前提として、ディスク情報取得のためにSNMPを使用するので、対象となる各ホストではSNMPが設定され、cfgstoragemaker.py を実行するマシンからアクセスできるものとする。

cfgstoragemaker.py コミュニティ名@ホスト名 [コミュニティ名@ホスト名 ...]

として実行する。つまりcfgmakerの書式でオプション指定を省いたものである。こうすると、標準出力にそれぞれのホストから得られたディスクパーティションのうち、「有効」と判断されたもの(どういう基準で判断しているかは後述する)に対応するものが、MRTGの設定ファイルの形式で出力されるので、いったん任意のファイルにリダイレクトしていただくのがいいだろう。

例:

$ cfgstoragemaker public@host1 public@host2 > disk.cfg

そして、このファイルを、既存のmrtg.cfgファイルにアペンドして使えば良い。(念のため、mrtg.cfg のバックアップを取ることをおすすめする) 必要に応じて、mrtg.cfgを編集してエントリの順番を入れ替えるなどしてほしい。
エントリが増えるので、indexmakerを再実行する必要があるだろう。

$ sudo cp /etc/mrtg.cfg /etc/mrtg.cfg.back
$ sudo cat /etc/mrtg.cfg disk.cfg > mrtg.cfg.new
$ sudo cp /etc/mrtg.cfg.new /etc/mrtg.cfg
$ sudo indexmaker /etc/mrtg.cfg > /var/www/mrtg/index.html

以下、細かいコメント。
オリジナルのcfgstoragemakerからの主な相違点

1. Pythonで書かれている(明らかに)。内部では、SNMPで得られたディスクパーティションを表すSnmpPartitonというクラスを定義している。PythonのSNMPモジュールを利用して、得られたパーティションをこのクラスのオブジェクトとしてリストにし、そのうち有効(isValid()メソッドが真となるもの)だけを選んで、その情報を用いてテンプレートの変数を置換して標準出力に書き出している。最終的に使用していないプロパティなども若干定義されているが気にしないように。

2. SNMPで情報を取得するMIBツリーを、オリジナルの.1.3.6.1.2.1.25.2.3.1から、.1.3.6.1.4.1.2021.9.1に変更した。これは前者は手持ちのDebian系Linuxではうまく情報が取れない部分があったからである。後者は後者で、パーティションの「タイプ」情報が取れないという問題はあったが、この情報は実際には「デバイス」と事実上同じものが帰ってくる実装のようなので、気にしないことにした。また、特定のMIBファイルがインストールされていることを前提とせず、数値表現でOIDを参照している。SNMPによる問い合わせ結果も数値でOIDが表示されるように、セッション作成時にオプション指定をしている。

3. 監視対象のデータを、使用バイト数ではなく、使用パーセンテージとした。また同時に、iノードの使用パーセンテージも監視している。ディスクの場合、システム監視の観点からはパーセンテージの方が重要と考えたためであるが、(900G使用中、より93%使用中、の方が直感的という観点である)バイト数を監視したければ、body.tplを編集して、OIDを

.1.3.6.1.4.1.2021.9.1.9.$index -> .1.3.6.1.4.1.2021.9.1.8.$index

とし、Optionsからnopercentを外せばいいだろう。

あと、SNMPで取得したディスクパーティションのうちどのようなものを有効と判断しているかであるが、

0. SNMPツリーでのインデックスが正であり、
1. 容量が正の値であり、
2. デバイス名が'/'で始まり('rootfs'だけはこの限りでない)、
3. さらにデバイス名がSnmpPartitionクラスのexcludesリストにあるものに一致しないこと

である。excludesリストは単に手元のマシンでの観察から、

('sysfs', 'proc', 'none', 'udev', 'devpts', 'tmpfs', 'cgroup', 'rpc_pipefs', 'gvfsd-fuse')

となっている。必要に応じて書き換えていただきたい。

最後に配布については、オリジナルのスクリプトがGPLバージョン2に従っているので、このスクリプトも一応同じとしておく。

Asus TF300Tからsamba/NFSサーバーをマウントする

表題の通りのことを、自分と同じタブレットを使っている人のためにメモしておく。

まず、前提として、私のTF300Tはroot化されており、Asusのダウンロードサイトで提供されているJellyBeanのROMイメージを用いて、ICSからアップデート済みである。「設定」→「タブレット情報」→「ビルド番号」の項を見ると JRO03C.JP_epad-10.4.2.17-20121018 となっている。

一般論として、まずandroidというOSはカーネルにはLinuxカーネルそのものが使用されている。そして、Linuxカーネルの持つさまざまな機能は、

無効化
カーネルに組み込んで有効化
モジュールとしてコンパイルし、必要に応じてカーネルに動的にロードする

の3つの状態のいずれかになっている。単純に考えると何でも有効になっていれば便利な気がするが、実際には有効になっている機能が多ければその分カーネルの使用するメモリが増えていくので、特にandroidデバイスの場合、有効にする機能は厳選しなければならない。モジュール化しておけば、必要な時だけカーネルに組み込むことができるのでその点は問題ないが、やはり潜在的に使用するかどうかわからない多数のモジュールをシステムに置いておくことはストレージ容量の圧迫にもつながる。

当然のことながら、無効化されている機能は使うことができない。さてそこで、TF300Tの場合であるが、JellyBeanにアップデート後、端末内で以下を実行して、カーネルの設定をチェックしてみる。ネットワーク経由でサーバーの持つファイルシステムをマウントする機能には、代表的なものとしてCIFS(Windows共有/samba)と、NFS(unix系)があるので、この両者について調べる。

$ zcat /proc/config.gz | grep CIFS
# CONFIG_CIFS is not set
$ zcat /proc/config.gz | grep NFS
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
# CONFIG_NFS_V4 is not set
CONFIG_ROOT_NFS=y
#CONFIG_NFSD is not set
CONFIG_NFS_COMMON=y

これから分かることは、Asusの提供するカーネルでは、CIFSについては、無効化されている。また、NFSに関しては、一番古いversion 2プロトコルだけがサポートされており、より効率化されたversion 3, 4については残念ながら無効になっているということである。

これを見る限り、CIFSは使えない、という結論になりそうなのだが、実は【朗報】無効化された機能でも、バージョンのマッチするカーネルで別途コンパイル済みのモジュールがあれば、それをカーネルに組み込める…のである。

で、ちょっと探したら、ここにあった。

ここからいただいてきたcifs_md4_10.4.2.17.zipを展開すると、cifs.koとmd4.koができる。.koはカーネルオブジェクト、つまりカーネルモジュールであることを表している。

これさえ手に入れば、あとは基本的に、PC・NASの動画をAndroidから「直接」再生する方法(要root)に従って設定すればいいのであるが、CifsManagerに上記モジュールのありかを教えておく必要がある。

cifs.koとmd4.koを任意のフォルダに…例えば/sdcard/cifsというフォルダを作ってその中に置く。そして、CifsManagerのSettingで、「Path to cifs.ko[:]*」の項目に、/sdcard/cifs/md4.ko:/sdcard/cifs/cifs.ko と入力した上で、「Load cifs module」、「Load via insmod」の項目をチェックしておく。その他は、上記ブログの記事を参照していただけばいいだろう。

ついでに、NFSについても触れておく。こちらはおおむね弁財天: AndroidにLinuxサーバのディレクトリをNFSマウントする:を参考にする。既にチェックした通り、Asus提供のJellyBeanカーネルではNFS version 2だけが使用可能(これにはモジュールは不要)である。実際にNFSサーバをマウントするには、クライアント側のツールが必要になるが、これはbusyboxがインストールされていればよい。root権限で、あらかじめマウントポイントとなるディレクトリを

# mount -o remount,rw /
# mkdir /mnt/test
# mount -o remount,ro /

などとして作成しておき、

# busybox -mount -o nolock,soft,intr,nfsvers=2 -t nfs NFSサーバのIPアドレス:NFSサーバのディレクトリ /mnt/test

のようにすればマウント可能である。アンマウント時は

# umount /mnt/test

とする。むろん、NFSサーバ側の/etc/exports等は正しく設定されていなければならない。

なお、より正式なアプローチとしては、自前でカーネルを再コンパイルして、自分が使う機能を有効化なりモジュール化なりしておくことである。しかし、一歩間違えばブートしなくなってしまうし、そもそも私自身がandroidでのカーネルコンパイル手順の詳細をまだチェックしていないので、当面はこのまま使用することにする。

Delicious Save this on Delicious

MRTG用のsnmp設定

Debian, Raspbian、UbuntuなどのDebian系LinuxでMRTGによるシステム監視を行うための設定についてメモしておく。
まず最初に、MRTG自体は、SNMPを利用してシステム情報を収集するのが基本ではあるが、必須ではないことを注意しておく。MRTG graphs without SNMPなどに記述されているように、何らかのコマンド経由で必要なシステム情報を取得さえできれば、その出力をスクリプトで整形してMRTGに渡す形で問題なく運用できる。

とはいえ、SNMPが動かせるならば、そちらの方がより統一的に情報収集ができるので良いだろう。以前に仕事で管理していたサーバーでSNMP設定を行ったのだが、詳細を忘れていたのと、現在は少し設定ファイルの記述方法も変化しているようだったので、今回Raspberry Piや玄箱Proで設定を行うついでにメモを残しておく。

あと、SNMPでは用語としてマネージャとエージェントという用語を用いるが、雑駁に言って、マネージャ→クライアント、エージェント→サーバという理解で問題ない。

さて、

#apt-get install snmp snmpd

でインストールを行った後、/etc/snmp/snmpd.conf を編集するが、デフォルトの設定ファイルから変更が必要な箇所は実は極めて少ない。状況としては、snmpdに対する問い合わせを同一ホスト上からしか行わない場合と、ネットワーク上の他のホストからも行う場合とに分かれる。

自分自身からの問い合わせにのみ応答する場合(MRTGも同じホストで動作させる想定)

rocommunity で始まる行がいくつかコメントアウトされた形で記述されているが、

rocommunity private localhost

だけ記述しておけばよい。サンプル記述では、privateではなくpublicになっているが、これはコミュニティ名であり自分で定義してかまわないので、ここではprivateとしておく。で、結局、これだけでよい。agentAdressの記述は変更する必要はない。また、昔は必要だった com2spec行でのコミュニティの記述も必要なくなっている。

#service snmpd restart
でサービスを再起動した後、

$snmpwalk -v 1 -c private localhost 1.3.6.1.2.1.2.2.1.16.2

で(この例は現在までのeth0のデータ送信総量を得るもの)

iso.3.6.1.2.1.2.2.1.16.2 = Counter32: 3485864205

のようにデータが取得できればOKである。

ローカルネットワークからの問い合わせに応答する場合(MRTGをネットワーク内の監視ホストで動作させる想定)

偉い人には分からんのですにあるごとく、
agentAddressの行を、

agentAddress udp:161

に変更。rocommunityの行は、次の2行を記述して他はコメントアウト。

rocommunity private localhost
rocommunity public 192.168.1.0/24 (自分のネットワーク設定に合わせる)

これだけでOK。後は上と同じくサービスを再起動した後、

ローカルホスト上で

snmpwalk -v 1 -c private localhost 1.3.6.1.2.1.2.2.1.16.2

また、監視ホスト上で

snmpwalk -v 1 -c public 監視対象ホスト(つまり上記設定を行ったホスト) 1.3.6.1.2.1.2.2.1.16.2

(コミュニティ名がそれぞれ設定したものに対応していることに注意)でそれぞれ

iso.3.6.1.2.1.2.2.1.16.2 = Counter32: 3486161250

のような応答が帰ってくれば、とりあえずSNMPの設定はできたということである。

あと、一つ注意しておくと、Debian系Linux以外のOSでの解説で、問い合わせ対象となるオブジェクトのIDをsystemやinterfacesといった名前で指定している場合があるが、Debian系Linuxではこれはできないようである。それは、この論理名を記述するMIBファイルがライセンス上の問題でフリーでは配布できないためらしい。(参照: Debian Bug report logs - #561578 system: Unknown Object Identifier (Sub-id not found: (top) -> system))

この参照先にある、snmp-mibs-downloaderというパッケージを取得してインストールしてみると、いくつかの追加MIBファイルがインストールされたようだが、論理名による問い合わせを可能にするものではなかったようだ。ということで、当面SNMPの問い合わせは、MRTGの記述も含めて具体的な数値によるツリー表記で行う必要がある。なおMRTG自体については、また後で書くことにする。

Delicious Save this on Delicious
プロフィール

GM3D

Author:GM3D
FC2ブログへようこそ!

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
FC2カウンター
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。