https://github.com/takeshiyako2/munin-nginx_request_time
nginxのレスポンスタイムをパーセンタイル値で計測するMunin pluginです。
id:t-cyrillさんのプラグインがオリジナルです。これをLTSVに対応させました。
90パーセンタイル, 95パーセンタイル値とMAX値をグラフにします。（MAX値は別グラフ）
median 中央値
percentile90 90パーセンタイル
percentile95 95パーセンタイル
パーセンタイルとは？
計測値の分布（ばらつき）を小さい数字から大きい数字に並べ変え、パーセント表示することによって、小さい数字から大きな数字に並べ変えた計測値においてどこに位置するのかを測定する単位。パーセンタイル（percentile）｜用語集｜企業年金連合会
例えば、計測値として100個ある場合、5パーセンタイルであれば小さい数字から数えて5番目に位置し、50パーセンタイルであれば小さい数字から数えて50番目に位置し、95パーセンタイルであれば小さい方から数えて95番目に位置する。
このようにパーセンタイルは全体における自分の位置を測定する単位として用いられ、企業年金においては年金ＡＬＭにおいて計算された数値を説明するのに用いられることがある。
http://www.pfa.or.jp/yogoshu/ha/ha17.html
Nginxの$request_timeは、nginxがリクエストを受けてからレスポンスをクライアントに返しきるまでの時間なので、変に遅いクライアントが居ないとも限らない・・・。
平均値だと、極端な異常値が少しでもあったばあい、これに引きづられて数字が大きくなったりして、あまり信用できなくなったりします。
測定誤差をできるだけ減らしたいので、平均値ではなくてパーセンタイルを取ろうという考え方です。
以下、セットアップ方法です。
nginxのログフォーマットをLTSVに変更。※ LTSV公式サイトを参考にします。http://ltsv.org/
# emacs /etc/nginx/nginx.conf
log_format ltsv "time:$time_local"
"\thost:$remote_addr"
"\tforwardedfor:$http_x_forwarded_for"
"\treq:$request"
"\tstatus:$status"
"\tsize:$body_bytes_sent"
"\treferer:$http_referer"
"\tua:$http_user_agent"
"\treqtime:$request_time"
"\tapptime:$upstream_response_time"
"\tvhost:$host";
access_log /var/log/nginx/access.log ltsv; # mainをltsvに変更
nginxをリロード。
# /etc/init.d/nginx configtest # /etc/init.d/nginx reload
nginxのログを読めるようにしておきます。
# chmod 644 /var/log/nginx/access.log
logrotateの設定も変えておきます。
# emacs /etc/logrotate.d/nginx
create 640 nginx adm
->
create 644 nginx adm
CPANモジュールをインストール。# cpanm install Text::LTSV # cpanm install File::ReadBackwards # cpanm install Statistics::Lite # cpanm install Statistics::DescriptiveMuninプラグインを設置
# cd /usr/share/munin/plugins/ # wget --no-check-certificate https://raw.githubusercontent.com/takeshiyako2/munin-nginx_request_time/master/nginx_request_timeMuninプラグインにリンクを貼る
# ln -s /usr/share/munin/plugins/nginx_request_time /etc/munin/plugins/nginx_request_time # ln -s /usr/share/munin/plugins/nginx_request_time /etc/munin/plugins/nginx_request_time_maxmunin-nodeをリスタート。
# service munin-node restart簡単ですね！
※ 他にも、レスポンスタイムの可視化として有効なのは、例えば、[10ms ~ 50ms], [51ms~ 100ms], [101ms以上]で別々でカウントしたりする方法があります。こちらも実装しておくと安心できるでしょう。
参考）
『性能エンジニアリング入門（2）：負荷テストのデータ、読めてますか？ (1/2)』
http://www.atmarkit.co.jp/ait/articles/1201/06/news121.html
負荷テストの勘所 その２ | Insight Technology, Inc.
http://www.insight-tec.com/technical-information/%E8%B2%A0%E8%8D%B7%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E5%8B%98%E6%89%80%E3%80%80%E3%81%9D%E3%81%AE%EF%BC%92.html
負荷テストについて基本的なメモ - ablog
http://d.hatena.ne.jp/yohei-a/20090722/1248264521
第17回 Webアプリケーションのパフォーマンス改善（1）：Perl Hackers Hub｜gihyo.jp … 技術評論社
http://gihyo.jp/dev/serial/01/perl-hackers-hub/001701
突然のTwitter砲にもなんとか耐えたさくらVPSに感謝する - As a Futurist...
http://blog.riywo.com/2011/02/07/162154
