2012-02-03
■ GrowthForecastでZusaar参加者数監視
本日から募集開始のqpstudyには申し込まれましたか？
というわけで、GrowthForecastとWebService::Simpleで参加者数監視してみました。
GrowthForecastの紹介
GrowthForecastは、WebAPIで値を突っ込むだけで良い感じにRRDtoolベースのグラフをさくっと作ってくれるビジネスメトリクス監視ツールで、WebAPIへ突っ込む部分をやってくれるgrouthforecast-workerと組み合わせると、単に数字を表示するプログラムを用意するだけで今日から様々なメトリクスを監視できるようになります。詳しくはここら辺を参照してください。
GrowthForecast本体の導入は上記の記事にあるので省略します。今回は、さらに同じサーバで既にApacheが立っているので、バーチャルホストからProxyPassしています。
grouthforecast-workerも適当なディレクトリに放り込むだけでOKです。
ZusaarのAPIから参加者数を取得
イベント管理ツールZusaarはAPIを提供していて、GETパラメータで検索条件を指定すると、JSON形式でイベントの情報を取得することができます。
そこで、WebAPIへのアクセスをラップしてくれるWebService::Simpleを使ってこんな感じのスクリプトを用意しました。
#!/usr/bin/perl use strict; use warnings; use WebService::Simple; my $event_id = 210003; my $zusaar = WebService::Simple->new( base_url => 'http://www.zusaar.com/api/event/', response_parser => 'JSON', ); my $response = $zusaar->get( { event_id => $event_id } ); my $json = $response->parse_response(); my $accepted = $json->{event}[0]{accepted}; my $waiting = $json->{event}[0]{waiting}; print "accepted\t$accepted\n"; print "waiting\t$waiting\n";
これを、grouthforecast-workerのディレクトリ以下の、scripts/qpconf_120225/bulk_pizza のようなファイル名で保存して実行権限も与えます。試しに実行してみるとこんな感じで出力されるのを確認します。
accepted 61 waiting 0
今回は、単純な参加者数だけでなく補欠の人数も取得したいので、複数の数値をまとめてハンドリングしてくれるbulk更新機能を使っています。
growthforest-workerの設定
grouthforecast.plを編集して、GrowthForecast本体のURLを設定します。今回は同じサーバ上なので以下のようになります。
my $growthforecast_endpoint = 'http://127.0.0.1:5125/api';
また、起動スクリプトを用意します。これは個人的好みで用意していますが、crontabに直接書いても良いです。
#!/bin/sh cd /home/***/***/grouthforecast-worker /usr/bin/perl grouthforecast.pl scripts
まずは手で起動スクリプトを実行し、GrowthForecast側に値が送られるのを確認して問題が無ければcrontabに登録します。
*/5 * * * * /home/masa/gf/grouthforecast-worker/go.sh
これでもう全部終わりです。
グラフの整備 (複合グラフの作成)
このままだと、定員に間に合った参加者数と、溢れてしまった補欠者数が別のグラフになって不便なので、その二つを積み上げた複合グラフを作成します。
GrowthForecastを開き、右上の「複合グラフの追加」から設定画面に入ります。
- パス、説明を記入
- 合計値の表示：する
- 最初のデータ：積み上げの下側のグラフ、今回は参加者数(*_accepted)のグラフを選択し、タイプは塗りつぶしを選びます。
- 2番目以降のデータ：上に来るグラフを順に選びます、今回は補欠者数(*_waiting)を選択肢、タイプはこちらも塗りつぶしにして、追加ボタンを押して確定させます。
これで追加ボタンを押すと、参加者数と補欠者数が積み上げられたグラフが設定できました。
表示色
表示色が自動で選ばれたものになってイメージと違うかもしれません。それぞれの個別のグラフに設定されている色が複合グラフでも継承されるので、qpstudy_acceptedやqpstudy_waitingといった個別グラフの項目名のすぐ下にある「設定」を押して、グラフの色を指定してあげてください。
完成品
というわけで、こんな感じで設定したグラフがこちらです。
モルテン(Molten) ゲームベスト( 10 枚セット)赤クリック: 60回
［改訂新版］ シェルスクリプト基本リファレンス...2012-02-02
■ Jenkins実践入門
うっかり積んであってようやく読了。
他の人がセットアップした環境でなんとなく使っているレベルだったので、曖昧に適当に使ってきた部分がはっきりした。具体的には赤と黄の意味とか。
- 赤丸：ビルドの失敗
- 黄丸：ビルド自体は成功したが、テストが失敗してる(p117)
たまたま使っているビルドスクリプトでテスト失敗が赤になっていたので、赤がテスト失敗だと思っていました……。分散ビルドやSeleniumの利用、プラグインの作成方法とかに至るまで具体的な方法まで触れられているので、少なくともJava開発であれば一通り困ることがなさそう。
Rubyとか他の言語での利用方法についてはほとんど書かれていないので、やはりこの部分はネットでの情報を集めたりしないといけないのは物足りないところだけど、読者層はやはりJavaがまず多いと思うので仕方ないところですかね。
2012-02-01
■ Logwatchをちゃんと使ってみる
デフォルトではゴミが毎日届くだけのLogwatchを、もうちょっと真面目に使ってみようと思います。
というか、それを言い訳に root@ 宛のメール読んでない人多いですよね？
基本的な設定方針は「異常や重要な変化だけ届いて欲しい」ので、現状のステータスや「想定内のエラー」ばかりを出力したりするサービスを削ります。できれば、設定ディレクティブ「Detail」に応じて、それぞれのサービスの中で本当の異常値だけを出力するような設定ができれば良いのですが、Logwatchの最低レベルであるLowに設定しても、ほとんどのサービスが正常値まで含めてしまうようです。
Logwatchは、/usr/share/logwatch/conf/logwatch.conf で指定されたデフォルト値に、/etc/logwatch/conf/logwatch.conf の設定値を上書きするようになっているので、/etc/logwatch/conf/logwatch.conf に以下のように設定してみました。
Service = "-zz-disk_space" Service = "-sshd" Service = "-http" Service = "-postfix" Service = "-named"
これで、ひとまず通常時のLogwatchの出力がなくなりメールが飛ばなくなりました。これでしばらく運用してみることにします。
2011-05-04
■ パスワードハッシュの記事を修正
shadowファイルのパスワードフィールドについて、説明が間違っていた部分があったので、修正して追記しました。
太古からのDES形式やMD5以外の形式についても知ってはいたのに、すっかり忘れていました(´・ω・｀)
Permalink | コメント(0) | トラックバック(0) | 12:46 
2011-05-03
■ いまどきのメールシステムに関するメモ
あとでもう少し真面目に書く用のメモ。
前提と方針
- アップデートの手間を極力下げるため、サポート期間の長いLinuxディストリビューションで、容易にパッケージが用意できるものを原則用いる。
- 極力シンプルな構成とする。
- Unixユーザ等と完全に独立したメールアドレス管理を提供する。
MTA/Submission
メールボックス
anti-spam
- spamassassin
- いつものルールファイルで今のところ困っていない。
- spamass-milterを使うことで、amavisdやspamc等を通さず直接Postfixから呼べる。
- greylistingは業務等ではデメリットによるインパクトが大きいので使わない。
- antivirusは要検討
認証管理
- Postfixadmin
ML
todo
- 認証やバーチャルドメインのメール転送関係のデータフローが分かりづらいので、図にしたほうが良いかも。
