Friday, November 28, 2014

AWS Service Health Dashboard to Slack

https://www.flickr.com/photos/10295270@N05/4311226721

https://github.com/takeshiyako2/monitor-aws-status-to-slack
AWSヘルスダッシュボードの情報を拾って、Slackに投稿するスクリプトです。
オリジナルは、https://github.com/hirose31/monitor-aws-status です。メッセージのポスト先をSlackに変更して、cpanfileを置きました。これでセットアップが簡単になったと思います。



セットアップ方法は以下のようになります。

今回は、Amazon Linux AMI release 2014.09を使用します。
# yum -y update
# cat /etc/system-release
Amazon Linux AMI release 2014.09
Install some library.

yumライブラリをインストール。
# yum -y install perl-ExtUtils-Manifest perl-ExtUtils-MakeMaker perl-CPAN-Meta perl-Module-Build perl-XML-Parser perl-XML-LibXML gcc openssl-devel git

ソースをGit clone
# git clone https://github.com/takeshiyako2/monitor-aws-status-to-slack.git
# cd monitor-aws-status-to-slack; ls -al;

cpanmとPerlモジュールをインストール。
# curl -LO http://xrl.us/cpanm
# perl cpanm --installdeps .

スクリプトを開いて、SlackのIncoming Webhook URLを設定します。
our $slack_url = 'https://hooks.slack.com/services/your/webhook/url';

スクリプトの動作チェック。
# perl monitor-aws-status-to-slack.pl -d

スクリプトをバックグラウンドで実行。
# perl monitor-aws-status-to-slack.pl &

Enjoy!

MySQL slow logのローテーションを安全に行う

https://www.flickr.com/photos/vmos/355693767

MySQL slow logのローテーションを安全に行う方法です。
mysqladmin flush-logsを実行して、ログファイルをまとめて更新する方法もありますが、flush-logsのみならずbinlogファイルまでも更新はさせたくありませんでした。
MySQL 5.5.3移行では各種ログを個別にフラッシュできるようになっているので、これを利用してslow logのみを更新します。

ローテートファイルを作成
# emacs /etc/logrotate.d/mysql-log
/var/lib/mysql/slow.log  {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    dateext
    postrotate
        mysql -uroot -pxxxxxxxxxxxxxxx -e'FLUSH SLOW LOGS'
    endscript
}

logrotateを実行せずにテスト
# logrotate -dv /etc/logrotate.d/mysql-log

logrotateを手動実行
# logrotate -f /etc/logrotate.d/mysql-log

ローテートされたことを確認
# ls -al /var/lib/mysql | grep '\.log'
-rw-rw----   1 mysql mysql       185 Nov 28 10:16 slow.log
-rw-rw----   1 mysql mysql       165 Nov 28 03:48 slow.log-20141127.gz
-rw-rw----   1 mysql mysql       173 Nov 28 10:20 slow.log-20141128.gz

Enjoy!


参考)
MySQL :: MySQL 5.6 Reference Manual :: 13.7.6.3 FLUSH Syntax
http://dev.mysql.com/doc/refman/5.6/en/flush.html


Wednesday, November 26, 2014

MHA + HAproxyで、MySQLのHA構成を組む

https://www.flickr.com/photos/iwanamadrid/5808172940/in/photostream/

MHAとHAproxyを使って、MySQLのHA構成を組みます。
どちらも枯れたソフトウェアなので、使い方などを書いている方はかなり多いと思いますが、個人的なまとめとしてスライドに書き起こしてみました。
構成は下のようになります。



ポイントは、MySQLへの接続の中継をすべてHAproxyが担っているところです。
電車の線路における分機器といったイメージです。
これをアプリケーションと同じサーバに同居させています。HAproxyは、かなり軽いソフトウェアなのでアプリケーションの邪魔をしません。
MySQLへの参照を分散しているため、参照への高負荷対策としては、基本的にMySQL Slaveを増やしていきさえすれば良いとなります。
HAproxyはgraceful restartが可能なので、分散先のMySQL Slaveを設定したときに、無停止で投入することができます。

以下、HAproxyの設定のサンプルです。

MySQLへの参照アクセスはtimeout checkで10秒間以上の接続を切るようにしています。
log-errorで設定したファイルに、HAproxyがMySQLをチェックするタイミングで以下のログが書き込まれます。
2014-11-27 14:52:03 25199 [Warning] Client failed to provide its character set. 'utf8' will be used as client character set.
http://bugs.mysql.com/bug.php?id=72543
[3 Nov 18:04] Paul Dubois Noted in 5.6.23, 5.7.6 changelogs. The server no longer logs the following warnings because they are uninformative: Client failed to provide its character set. 'charset' will be used as client character set.
とのことです。
アプリケーションの要求によってそれぞれパラメータを調整するとよいでしょう。

Enjoy!

Wednesday, November 19, 2014

CapistranoのデプロイをカウントするMuninプラグイン

https://www.flickr.com/photos/pocait/5463692073

https://github.com/takeshiyako2/munin-capistrano_deploy
CapistranoのデプロイをカウントするMuninプラグインです。
下のようなグラフを表示してくれます。



サーバリソースの性能劣化などがあったとき、ある時点のアプリケーションのCapistranoデプロイ後に起きているかどうかを同じMunin上で確認できるようになるので、調査が捗るようになると思います。

以下セットアップ方法です。

1) プラグインをダウンロードして設置
# cd /usr/share/munin/plugins/
# wget --no-check-certificate https://raw.githubusercontent.com/takeshiyako2/munin-capistrano_deploy/master/capistrano_deploy
# chmod +x capistrano_deploy
# ln -s /usr/share/munin/plugins/capistrano_deploy /etc/munin/plugins/capistrano_deploy

2) プラグインの設定ファイルを編集
# emacs /etc/munin/plugin-conf.d/munin-node
[capistrano_deploy]
env.log /home/[you]/[your app]/revisions.log

3) 動作チェック
# munin-run capistrano_deploy
count.value 2

4) munin-nodeをリスタート
# service munin-node restart

Enjoy!


See also.
https://github.com/hrix/munin-plugin-capistrano_deploy_uptime

Tuesday, November 18, 2014

NginxのログをカウントするMuninプラグイン

https://www.flickr.com/photos/psd/7741067918

https://github.com/takeshiyako2/munin-nginx_access_log
https://github.com/takeshiyako2/munin-nginx_error_log
NginxのログをカウントするMuninプラグインです。
下記のようなグラフを出力するようにしました。


毎日どれくらいのアクセスがあるのか、ざっくりと視覚的に知ることが出来ます。
また、Muninのほかのグラフと同じ時系列で見比べることができるので、何か急激な変化が起きたときなどに役に立つと思います。
※ 途中でグラフがストンと落ちているのは、ログをローテートしているためです。

Enjoy!

DNSサーバをチェックするNagiosプラグイン

https://www.flickr.com/photos/denisdervisevic/4080531063

https://github.com/takeshiyako2/nagios-check_nameserver
DNSサーバをチェックするNagiosプラグインです。

先日(2014-11-05)、JPCERTコーディネーションセンターより、ドメイン名ハイジャックに関する注意喚起がされました。ネームサーバー情報の不正書き換えです。

登録情報の不正書き換えによるドメイン名ハイジャックに関する注意喚起
https://www.jpcert.or.jp/at/2014/at140044.html

対策としては、『IDやパスワードをきちんと管理する』となります。
軽減策として提示されていた下記をNagiosプラグインで実装しました。ハイジャックされた事をいち早く気づくためのものです。

V. 軽減策
  管理する登録情報が、不正に書き換えられるインシデントに備えて、早期に
検知・対応できるよう、以下の軽減策の適用を検討してください。
  - whois などのコマンドを利用し、ネームサーバ情報などの登録情報が正し
    く設定されているか定期的に確認する (※)

以下、プラグインの設置方法です。

1) チェックスクリプトをNagiosプラグインディレクトリにコピー

2) コマンドを設定
# emacs /etc/nagios/objects/commands.cfg
define command{
        command_name    check_nameserver
        command_line    $USER1$/check_nameserver.pl -d $ARG1$ -n $ARG2$
}

3) serviceを記述
define service{
        use  [your service]
        host_name  [your host]
        service_description Nameserver
        check_command  check_nameserver![your domain]![nameserver1],[nameserver2]
}

Enjoy!

Thursday, November 13, 2014

New RelicのNginxプラグイン

http://www.flickr.com/photos/techcrunch/14117501056

New RelicのNginxプラグインです。

NGINX Updates New Relic Plugin

2014年10月にNginxのNew Relic Pluginバージョン2.0.0がリリースされました。
しかし、このバージョンを使っていたところ、いつの間にか動かなくなっていました。
ログも吐かず、データのアップデートをしない。。。

旧バージョンでも十分に要件を満たしているので、バージョン1.2.1のコピーを取っておきました。
こちらです。使い方は、README.txtを参照してください。

一部、コードを編集しています。新しいNginxコンソールに仕様を合わせています。

HTTP ベンチマークツール wrk の使い方

http://www.flickr.com/photos/dandechiaro/4151566643

https://github.com/wg/wrk.git
Will GlozerさんのHTTPベンチマークツール wrk をインストールして使ってみます。
曰く、Modern HTTP benchmarking toolだそうです。
HTTP/1.1対応のベンチマークツールで、負荷をかける時間を決めて試験することが出来ます。

Mac OS Xの場合。
$ brew search wrk
$ brew install wrk

CentOS6の場合。
事前にyumライブラリを用意してインストールします
# sudo yum groupinstall 'Development Tools'
# sudo yum install  openssl-devel
# sudo yum install  git
# git clone https://github.com/wg/wrk.git
# cd wrk
# make
# sudo cp wrk /usr/bin/wrk

バージョンを確認します。
# wrk --version
wrk 3.1.1 [epoll] Copyright (C) 2012 Will Glozer
Usage: wrk  
  Options:
    -c, --connections   Connections to keep open
    -d, --duration      Duration of test
    -t, --threads       Number of threads to use

    -s, --script        Load Lua script file
    -H, --header        Add header to request
        --latency          Print latency statistics
        --timeout       Socket/request timeout
    -v, --version          Print version details

  Numeric arguments may include a SI unit (1k, 1M, 1G)
  Time arguments may include a time unit (2s, 2m, 2h)

wrkを実行してみます。12スレッド起動し、合計400接続を30秒間リクエストを送信します。
$ wrk -t12 -c400 -d30s http://192.168.33.10/
Running 30s test @ http://192.168.33.10/
  12 threads and 400 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    88.84ms  167.00ms 942.61ms   91.55%
    Req/Sec   705.81    459.71     3.70k    79.74%
  232063 requests in 30.00s, 187.88MB read
Requests/sec:   7735.40
Transfer/sec:      6.26MB

ベンチマークのヒントが書いてありましたので、簡単に訳してみました。
Benchmarking Tips

The machine running wrk must have a sufficient number of ephemeral ports
available and closed sockets should be recycled quickly. To handle the
initial connection burst the server's listen(2) backlog should be greater
than the number of concurrent connections being tested.

A user script that only changes the HTTP method, path, adds headers or
a body, will have no performance impact. If multiple HTTP requests are
necessary they should be pre-generated and returned via a quick lookup in
the request() call. Per-request actions, particularly building a new HTTP
request, and use of response() will necessarily reduce the amount of load
that can be generated.

wrkを走らせるマシンは十分なエフェメラルポートを持っている必要があり、閉じたソケットは迅速に再利用されるべきです。
初期接続を処理するために、サーバーのlisten(2) backlogのバーストが、テストされている同時接続数よりも大きくなければなりません。

ユーザスクリプトは、パフォーマンスに影響を与えないHTTPメソッド、パス、ヘッダーの追加もしくはbodyを変更できます。
もし、多数のHTTPリクエストが必要な場合は、それらは事前に生成された迅速な request() の呼び出しにより返されるはずです。
リクエストごとのアクション、新しいHTTPリクエストの生成とresponse() は、生み出される負荷の絶対量を減らすでしょう。


参考)

net.core.somaxconnについて調べてみた
http://d.hatena.ne.jp/tetsuyai/20111220/1324466655

Unicorn!
https://github.com/blog/517-unicorn
Unicornのbacklog設定についての説明がある。

listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について
http://blog.nomadscafe.jp/2014/05/listenbacklogtcp-defer-accept.html

nginx + PHP-FPM for high loaded websites
http://www.saltwaterc.eu/nginx-php-fpm-for-high-loaded-websites.html

EC2など 高負荷クラウド環境における Redis のチューニングについて
http://tech.guitarrapc.com/entry/2013/08/02/210858

Wednesday, November 12, 2014

httping for Mac OS X

http://www.flickr.com/photos/zimpenfish/2408559508/in/photolist-5nAtLr-btaHpc-btaKKv-btaKaF-btaFE4-btaHeZ-btaJPc-btaHBH-btaKuK-btaMVa-btaLTB-btaJCX-btaJhk-btaM8z-btaJZH-btaL8X-btaMu6-btaLoX-btaJ6K-btaN7e-7bXKPL-KqBTu-5LYu4Y-iVfzxz-8ZkXdq-4EQuQ5-4CzNuA-8aryYR-g9wff-btaJtZ-btaLFM-btaNBX-btaMHV-btaHVD-btaNsX-btaFXH-btaMhB-btaHLR-btaH4a-btaGfH-bS1XMM-bD7b1s-tK1H-8nDSFY-7GCKSB-dFPGWk-9Vafpd-6T8nL2-57J1mL-8Vm7Sc/

httping (http://www.vanheusden.com/httping/)は、httpへの疎通チェックをpingのように確認できるコマンドラインツールです。
このhttpingがいつの間にかMacのbrewでインストールできるようになっていたので、インストールしてみました。

以下、手順です。

まず、brewをインストールしておいてください。
http://brew.sh/

brewをアップデート。
$ brew update

httpingを探す。
$ brew search httping
httping

httpingをインストール。
$ brew install httping
==> Installing dependencies for httping: xz, gettext
==> Installing httping dependency: xz
==> Downloading http://fossies.org/linux/misc/xz-5.0.6.tar.gz

curl: (22) The requested URL returned error: 410 Gone
Trying a mirror...
==> Downloading http://tukaani.org/xz/xz-5.0.6.tar.gz
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/xz/5.0.6
==> make install
  /usr/local/Cellar/xz/5.0.6: 58 files, 1.5M, built in 58 seconds
==> Installing httping dependency: gettext
==> Downloading http://ftpmirror.gnu.org/gettext/gettext-0.19.2.tar.xz
######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/gettext/0.19.2 --with-included-gettext --with-included-glib --with-included-libcroco --with-included-libunistring --with-emacs --disable-java --disable-csharp --without-git --without-cvs
==> make
==> make install
==> Caveats
This formula is keg-only, which means it was not symlinked into /usr/local.

Mac OS X provides similar software, and installing this software in
parallel can cause all kinds of trouble.

OS X provides the BSD gettext library and some software gets confused if both are in the library path.

Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:

    LDFLAGS:  -L/usr/local/opt/gettext/lib
    CPPFLAGS: -I/usr/local/opt/gettext/include

==> Summary
  /usr/local/Cellar/gettext/0.19.2: 1920 files, 18M, built in 4.7 minutes
==> Installing httping
==> Downloading http://www.vanheusden.com/httping/httping-2.3.4.tgz
######################################################################## 100.0%
==> make install PREFIX=/usr/local/Cellar/httping/2.3.4
  /usr/local/Cellar/httping/2.3.4: 9 files, 132K, built in 12 seconds


うまくインストールされました。
httpingのバージョンをチェック。
$ httping --version
HTTPing v2.3.4, (C) 2003-2013 folkert@vanheusden.com
 * SSL support included (-l)
 * ncurses interface included (-K)

URLへの疎通を確認してみます。
$ httping -K http://takeshiyako.blogspot.jp/



























簡単ですね!




Tuesday, November 11, 2014

CapistranoデプロイをSlackに通知する

http://www.flickr.com/photos/secretaria_cultura/14509650477

https://github.com/onthebeach/capistrano-slackify
CapistranoデプロイをSlack(https://slack.com/)に通知するgemライブラリです。(Capistrano v3に対応)
以下のようにSlackにデプロイを通知してくれるようになります。











以下、設定方法です。

まず、SlackのIncoming WebHooksでトークンを発行します。








Webhook URLをメモしておきます。

CapistranoにSlack通知ライブラリを設定していきます。
Gemfileに以下を書き込み。
gem 'capistrano-slackify'

bundleを実行。
$ bundle

Capfileに以下を書き込み。
require 'capistrano/slackify'

あとは、config/deploy.rb に以下の記述を書き込むだけです。
set :slack_url, '<Webhook URL>'
set :slack_channel, '#random'
set :slack_emoji, ':surfer:'


簡単ですね!