トップページへ / 最新 / RSS

戯れ言

この日記のはてなブックマーク数 Bloglinesで閲読登録 ADD TO Hatena::RSS Subscribe with livedoor Reader Add to Google

2013-03 / 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

最近 5 日分 / 今月の一覧

2013-03-25 Mon

Zabbixトラッパー(zabbix-sender) で、munin-node plugin のデータを取り込む [Zabbix][Munin]

Clip to Evernote

munin-node のデータを zabbix に取り込むには

oopsops さんの

MuninのPluginをZabbixで使うwrapper的なものを作ってみた(Zabbix 2.0.0rc2対応)
http://oopsops.hatenablog.com/entry/2012/04/18/191650

や、munin ならこの人、前佛さんの

サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて
http://www.slideshare.net/zembutsu/ss-17453167

で、紹介されている手法があります。どれも、zabbix-agentd を使って、key をベースに、munin-node のプラグインを呼び出すのですが、キー毎にプラグインが呼び出されるので、ちょっと冗長です。

たとえば、cpu plugin ですが

- user
- nice
- system
- idel
- iowait
- irq
- softirq
- steal

の計8つの値を返すのですが、zabbix-agent 経由だと、キー毎に zabbix-agent が、cpu plugin を呼び出すため、munin 単独で使ってたら、5分に1回しか動かいないのに、8回も動作させることになってしまい、ちょっといろいろと気になります。

で、ちょっと色々考えてたんですが、zabbix serverの zabbixトラッパー宛に、監視ノードから、zabbix-sender で一気にデータを流し込めば、解決できそうだと目星がつきました。

とりあえず、munin のアイテムとグラフを自動登録するために、一旦、Zabbix の設定画面から

設定 -> テンプレート -> テンプレートの作成

で、テンプレート名で "Template_Linux", 表示名で "Template Linux of Munin" とでもして、一旦テンプレートの作成をします。

その後、この "Template_Linux" めがけて、拙作の

munin2zabbix-register
https://github.com/kunitake/munin2zabbix-register

で、アイテムとそのグラフを登録していきます("Template_Linux"は、プログラム内に、ハードコーディングされてます orz)

このプログラムは

ZabbixAPI for Perl
https://github.com/mikeda/ZabbixAPI
http://mikeda.jp/wiki/zabbixapi.pm

が、その動作上必要となります。同一ディレクトリに、ZabbixAPI.pm を置いておくと動くと思います。
プログラム中に、API を叩くための認証情報と URL 情報があるので、これを書き換えます。

my $user = 'Admin';
my $pass = '';
my $api_url = 'http://localhost/zabbix/';


そのあとは、munin-node インストール済、munin-node-configure で各種プラグイン設定済のサーバで、

# perl munin2zabbix-register.pl -a

とすると、そのサーバ上で利用可能な munin-node pluginのアイテム登録と、グラフ登録がおこなれます。
とりあえず

# munin-run <plugin> config


して、できるだけ、グラフ描写に必要な情報は引き継ぐようにしていますが、いくつか未サポート(見てない)です。まぁいいよね...

あと Zabbix では、積算グラフと、LINEグラフを一度に同じグラフ上で描写することはできないため、積算グラフを優先して作成します。適時 LINE グラフは手動で作成してください。一部、Plugin が root 権限を必要とするので、root で動かす必要があります。

これで、このテンプレートを後述するmunin2zabbix-sender.pl を動作させるホストに適用すれば、Zabbix トラッパーでデータを受信する準備は整います。

データの流し込みには、これまた拙作の

munin2zabbix-sender
https://github.com/kunitake/munin2zabbix-sender

で、

# munin2zabbix-sender.pl -a


とかすると、利用可能な munin-ndoe の plugins を munin-runコマンド経由で呼び出して、一気に zabbix-sender で、zabbix server へとデータの流しこみが行われます。手元のサーバだと

特に変なエラーが発生していないことを確認の上

*/1 * * * * /usr/local/bin/munin2zabbix-sender.pl -a -i cpu,if_


みたいに cron に設定しておけばいいと思います。こっちのプログラムは、ZabbixAPI.pm とかは不要で、単独で動作します。Zabbix Serverに流しこむのに必要な情報は

/etc/zabbix/zabbix_agentd.conf


から読み取るので、Zabbix Agentd がきちんと動作する環境である必要があります。

なお、cpu とか、トラフィック情報は、zabbix agent で、より細かい時間でデータを取得してたりするので、"--ignore" オプションで、無視指定しておけば便利かな?と思います。

ということで、完全無保証ですが、よろしければどうぞ。



2012-11-02 Fri

RHEL6/CentOS6では、single-request-reopen を必須にしたい… [IPv6]

Clip to Evernote

結論から言えば、とりあえず RHLE6/CentOS6 な人は /etc/resolv.conf に

options single-request-reopen


を書いておこうという話です(全部小文字ですよ、念のため)

なぜか?

RHEL5/CentOS5/Ubuntu 10.04なLinuxとかでは、FQDN の解決をするときに

Image

1. DNSキャッシュサーバに AAAA RR の Queryを投げる
2. AAAA RR の Reply を受ける
3. DNSキャッシュサーバに A RR の Queryを投げる
4. A RR の Reply を受ける

という挙動でしたが、RHEL6/CentOS6 では

Image

1. DNSキャッシュサーバに A RR の Queryを投げる
2. DNSキャッシュサーバに AAAA RR の Queryを投げる
3. A RR の Reply を受ける
4. AAAA RR の Reply を受ける

となります(3., 4.は入れ替わる可能性はあります)

#すいません!厳密には、遊べる RHEL6 の環境を持ってなかったので未確認ですが、同じ挙動なはず

これは、過去の経緯とかを考えると、よりよい実装になったと言えそうなのですが、1つ問題があって、1., 2. で、Query を投げる側の source port番号が同一となっています(要は、socket を使い回している)

で、なにが困るかというと、世の中の Firewall で、この同一ポートからの Query を同一のセッションと見なすものがあるのです。
そうすると、なにが困るかというと、

Image

1. DNSキャッシュサーバに A RR の Queryを投げる
2. DNSキャッシュサーバに AAAA RR の Queryを投げる
3. たとえば AAAA RR の Reply を受け取る
4. Firewall が通信が終わったと判断して、セッションを close する
5. 残りの A RR の Reply が Firewall で drop される。
6. A RR の結果を受け取れなかったので、今度は別々に Queryを投げる
7. A RR の Query を投げる。
8. A RR の Reply が返るまで待つ。
9. A RR の Reply を受け取る。
10. 改めて AAAA RR の Queryを投げる
11. AAAA RR の Reply を受け取る。

こんな感じになります。最終的には名前が解決されるので、めでたしめでたし、なんですが、実際 A RR の Query を再送(fallback)するまで、5秒程度の時間がかかります。

たかが 5秒、されど 5秒。

最近のサーバは、サーバ間連携で外部のAPIを叩くことも珍しくありません。API のコール毎に、DNS を引いていたとしたら、この遅延が蓄積され、エンドユーザで体感するレスポンスの遅延は、数十秒以上になることもあります。

このあたりは man resolv.conf に書いてあります。

     single-request-reopen (since glibc 2.9)
           The resolver uses the same socket for the A and AAAA requests. Some hard-
           ware mistakenly only sends back one reply. When that happens the client
           sytem will sit and wait for the second reply. Turning this option on
           changes this behavior so that if two requests from the same port are not
           handled correctly it will close the socket and open a new one before send-
           ing the second request.


ここまでわかってるなら、default で、socket を別々に作ってくれよと思うのですが、オプションでの回避となっているようです。

#最近のUbuntuはどうなのか、確認する環境が手元になったので、わかりませんが、たしか最近は glibc 使ってなかったと思うので、問題は起こさないかも??

かくして、せっかくIPv6のために改善された挙動が、IPv6に起因するあらたな問題を生み出してしまったようです。Firewall が問題だ!という話もありますし、実際 Firewall側の設定変更で、回避可能な問題ではあるんですが、MacOS X 10.8.2 とかでは、query の source port は、別々なので、問題を引き起こしません。

ともあれ、すべての人に問題が発生するわけではなく、環境依存ではありますが、「IPv6無効にしたら早くなった」ネタが、新たに誕生してしまったのが切ない…

追記:2012-11-05 画像追加。文章調整しました。glibcのバージョンの言及を削除しました。



2012-10-25 Thu

failed to pause VDI [XenServer]

Clip to Evernote

下記、XenServer 5.6 SP2 + XS56EFP1001, XS56EFP1004, XS56EFP1005, XS56EFP1006, XS56ESP2, XS56ESP2001, XS56ESP2002, XS56ESP2003, XS56ESP2004, XS56ESP2005, XS56ESP2006, XS56ESP2007, XS56ESP2008, XS56ESP2009, XS56ESP2011, XS56ESP2013, XS56ESP2014, XS56ESP2015, XS56ESP2016

な環境での話。

検証環境でテストしていたら、妙な現象が。特定の VM でスナップショットが取れなくなっている。

Image

怪しげなログ(/var/log/SMlog)

[15446] 2012-10-12 16:03:53.947425 ***** BLKTAP2:call_pluginhandler: EXCEPTION XenAPI.Failure, ['HOST_OFFLINE', 'OpaqueRef:5d79ee19-6942-531e-7eb3-833fdbb29044']
[15446] 2012-10-12 16:03:53.954785 lock: released /var/lock/sm/a4c3399a-4cde-6738-2aab-d627f456f369/sr
[15446] 2012-10-12 16:03:53.955676 ***** vdi_snapshot: EXCEPTION util.SMException, failed to pause VDI c7514e13-25bd-4e0b-8ab7-32aad371a232
  File "/opt/xensource/sm/blktap2.py", line 1212, in call_pluginhandler
    {"sr_uuid":sr_uuid,"vdi_uuid":vdi_uuid})
  File "/usr/lib/python2.4/site-packages/XenAPI.py", line 229, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.4/site-packages/XenAPI.py", line 133, in xenapi_request
    result = _parse_result(getattr(self, methodname)(*full_params))
  File "/usr/lib/python2.4/site-packages/XenAPI.py", line 203, in _parse_result
    raise Failure(result['ErrorDescription'])

[15446] 2012-10-12 16:03:53.954785      lock: released /var/lock/sm/a4c3399a-4cde-6738-2aab-d627f456f369/sr
[15446] 2012-10-12 16:03:53.955676      ***** vdi_snapshot: EXCEPTION util.SMException, failed to pause VDI c7514e13-25bd-4e0b-8ab7-32aad371a232
  File "/opt/xensource/sm/SRCommand.py", line 94, in run
    return self._run_locked(sr)
  File "/opt/xensource/sm/SRCommand.py", line 131, in _run_locked
    return self._run(sr, target)
  File "/opt/xensource/sm/SRCommand.py", line 169, in _run
    return target.snapshot(self.params['sr_uuid'], self.vdi_uuid)
  File "/opt/xensource/sm/LVHDSR.py", line 997, in snapshot
    raise util.SMException("failed to pause VDI %s" % vdi_uuid)

[15446] 2012-10-12 16:03:53.982316      Raising exception [82, Failed to snapshot VDI [opterr=failed to pause VDI c7514e13-25bd-4e0b-8ab7-32aad371a232]]


HOST_OFFLINEとか出てるけど、全プールのホストは生きてる。適当にググってみたけど、それっぽいエラーがなかった。たまには

Citrix Support Forums

で質問してみようと、事象をまとめてたら、なんとなく原因がわかってしまった。

こんな感じで追っていった。

1. EXCEPTION を投げてるコードをざっくり眺める
-> ぱっと見、疑わしき点はなかった
2. VDIの破損を疑う
-> 対処のVMは、問題なく起動したり、shutdownできるので、VDIが破損している可能性はなさそう。
3. 対象のVMを full copy して Cloneを作成してみる。
-> 問題なく、Snapshot が取得可能。元VMの構成情報がおかしい?

VDIの操作で失敗しているので、VDIの構成情報を眺めてみることに。

まずはvdiのuuidを特定する。

# xe vbd-list vm-name-label=<VMの名前> params=vdi-uuid
vdi-uuid ( RO) : c7514e13-25bd-4e0b-8ab7-32aad371a232

vdi-uuid ( RO) : <not in database>


片方は、CD-ROMドライブなので、必要なのは 上のほう。

# xe vdi-param-list uuid=c7514e13-25bd-4e0b-8ab7-32aad371a232


このパラメータを、full copy して問題がない VM と見比べると、次のことがわかった。

VM が電源ONされると、sm-config に

host_OpaqueRef:1279ce49-0bdf-809f-d4a3-df67d3021873: RO;


が追加される。host_OpaqueRef は、VMを稼働させるhostによって、uuid が異なる(が、なんと、その uuidは host-uuidじゃない。意味わからん)
起動が完了すると

host_OpaqueRef:1279ce49-0bdf-809f-d4a3-df67d3021873: RW;


になる。VMを shutdown すると、このパラメータは消される。

で、Snapshotが取れないVMは、停止状態で

host_OpaqueRef:5d79ee19-6942-531e-7eb3-833fdbb29044: RO;


稼動状態で

host_OpaqueRef:1279ce49-0bdf-809f-d4a3-df67d3021873: RW; host_OpaqueRef:5d79ee19-6942-531e-7eb3-833fdbb29044: RO;


ん?2つある...

実は、この問題となったVMは、検証環境を再構築する際に、退避させていた VM。

どうやら、強制shutdownしたか、起動途中で強制shutdown したかはわからないが、sm-config にこのゴミ情報が残った状態で、VMのバックアップが取られてしまったらしい。
で、新環境では、その host_OpaqueRef で指定される host は存在しないので、HOST_OFFLINE となった模様(VMのmeta情報に、バックアップしては困る(多分しちゃだめな)情報が残ることは、ままある話だけど……以前あった話では、そのVMでは、使ってないSR情報が入ってて、そのSRがないから meta情報は importできないよ!って怒られたことがある。泣いた...)

で、こまったことに、sm-config って RW じゃない。

sm-config (MRO):


xeコマンド使って、書き換えできない...良い子は真似しちゃいけない、マスターサーバ上での state.db 直接書き換え

# xe pool-ha-disable
# /etc/init.d/xapi stop
# cp /var/xapi/state.db /var/xapi/state.db.bak
# vi /var/xapi/state.db <- 該当部分の削除
# /etc/init.d/xapi start


slaveサーバには、古い情報が残るけど、snapshotの作成&削除とかしてると、更新されるのでまぁいいでしょう。

state.db のクリーナーが欲しい今日この頃。

と、ここまで来ても、なんで RO な host_OpaqueRef が残ってたか、いつの時点でかはトレースできなかった。



2012-08-21 Tue

Time Machineと相性が悪いもの [Mac]

Clip to Evernote

内部的に、Time Machine は、pdumpfs っぽいらしく、ファイルが書き換わると、どんなに些細な変更であっても、そのファイル全体がバックアップ対象となります。なので、

- VMware などの仮想マシンイメージ
- Thunderbird など、メールをディレクトリ毎に単一のファイルとして持つタイプ(とそれらの全文検索データ)

と相性が悪いです。どう相性が悪いかというと、私の環境だと、上記2つを動かしたあとは、60GB越えのデータが Time Machine でバックアップが取られる感じ。

これは頂けないので、これらは Time Machine の対象外として

- VMware は、手動でバックアップ
- Thunderbird は、daily で、rsync してバックアップ

を考えてみる。

というか、Thunderbird にメールを溜めすぎなのか。標準の Mailクライアントに乗り換えると、幸せになれるんだろうか……



2012-08-20 Mon

Time Capsule を買ってみた&その後の格闘 [Mac]

Clip to Evernote

Buffalo の NAS を Time Machine で使っていたんだけど、Mountain Lion に上げてから、よくバックアップに失敗するようになった。やっぱり純正がいいのかなぁとおもっていたことと、家の無線LAN が自室で電波を拾い辛いこともあり、無線LAN機能のついている Time Capsule を買った。

Image

で、さらに困り事。

- Spotlight を有効にした
- Mountian Lion に上げた
- Buffalo NAS 用の NasNavigator2 をインストールした

のどれかの影響か、やたらと操作がひっかかるようになった。マウスポインタだけが動いて、固まったような状態。

Mountain Lion は、アップデートよりクリーンインストールの方がいいよという記事も散見されたので、この際だと思って、Time Capsule にバックアップを取ってから、クリーンインストールしてみた。で、何度か不具合があったので、その備忘録。

まずバックアップ。

寝る前に仕込んで置いて、朝起きてみたら……取れてない orz
どうも、書き込みエラーの形跡が……しかも Time Capsule に触ってみたら、熱い!熱暴走してた? 保冷剤&結露に気をつけながら冷却、再度バックアップ開始。6時間弱掛かって、1回目のフルバックアップが完了。

で、クリーンインストール。

[option] キーを押しながら、電源を入れて、復旧ディスクから起動。で、既存の HDD を消去してから、Mountain Lion の再インストール。インターネット経由でデータが取られるので、USBメモリの起動ディスクも要らないのはいいね。

これは無事終了(だと思ってた)

で、ちょこっとだけ素の Mountanin Lion を触ってから、

[アプリケーション] -> [ユーティリティ] -> [移行アシスタント]

を起動して、データを復元。やたら早い……怪しすぎる。

実際に触ってみたら、ユーザデータが全然ないよ!なにこれ?と思ったら、ユーザ名がフルネーム仕様になってる。これが原因か……以前のユーザ名と違っているので、復元対象にならなかったんだろう。

クリーンインストール2回目。

念のため、またクリーンインストールして、今度は、全データを直接 Time Capsule から復元するように修正。3,4時間ぐらい?掛かって完了!メールデータもプレゼン資料も復元されて完璧!(とこの時点では思ってました…)

さっそく Time Machine でバックアップを…

と思ったら、このディスクは使えない云々とエラーを吐いて、拒否られる(意味わからん)
一旦、Time Machine用のディスクを削除して、選択しなおせば、バックアップが取れるようだが、以前取ったデータがなかったことになってる。これは……このまま進んでいいのか?

なにかがおかしいんだろうなぁと思って、復元したマシンのターミナルを起動して、調べようとしたら、違和感。ありゃ?ホスト名が localhost になってるぞ?
結果からいえば、これが原因だったようで、Time Machine は、ホスト名で過去データの区別をしているようですね。

[システム設定] -> [共有] -> コンピュータ名を設定

で、既存のコンピュータ名に変更して完了。焦った…

#きっとこのあたりはマニュアル読めば書いてるんだろうな…

ともあれ、これで復元完了。操作が引っかかる件は、これでしばらく様子見。



2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12

最終更新時間: 2013-03-25 19:13