2014年12月26日金曜日

MySQL HandlerSocketのコネクションを記録するmuninプラグイン

http://www.flickr.com/photos/hejog/1402968379


MySQL HandlerSocketのコネクションを記録するmuninプラグインです。
SHOW PROCESSLISTから、HandlerSocketの読み込み/書き込み数を取得して、以下の様なグラフを生成します。



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

プラグインをダウンロードして設置。
# curl -o /usr/share/munin/plugins/hs_read https://raw.githubusercontent.com/takeshiyako2/contrib/master/plugins/mysql/hs_read
# curl -o /usr/share/munin/plugins/hs_write https://raw.githubusercontent.com/takeshiyako2/contrib/master/plugins/mysql/hs_write
# chmod +x /usr/share/munin/plugins/hs_read
# chmod +x /usr/share/munin/plugins/hs_write
# ln -s /usr/share/munin/plugins/hs_read /etc/munin/plugins/hs_read
# ln -s /usr/share/munin/plugins/hs_write /etc/munin/plugins/hs_write

MySQLホストの接続情報を設定ファイルに記述。
# vim /etc/munin/plugin-conf.d/munin-node
[hs_*]
env.mysql_host localhost
env.mysql_port  3306
env.mysql_user root
env.mysql_password password

動作テスト。
# cd /etc/munin/plugins/
# munin-run hs_read
# munin-run hs_write

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

Enjoy!

Redisのレイテンシを記録するmuninプラグイン


https://github.com/takeshiyako2/contrib/blob/master/plugins/redis/redis-speed
Redisのレイテンシを記録するmuninプラグインです。
PING time, SET time, GET timeを取得して、以下の様なグラフを生成します。
※ SETを発行しているので、Slaveではこのままでは使えません。コードを修正して使ってください。



以下、セットアップ方法です。難しいことはないです。

プラグインをダウンロードして設置。
# curl -o /usr/share/munin/plugins/redis-speed https://raw.githubusercontent.com/takeshiyako2/contrib/master/plugins/redis/redis-speed
# chmod +x /usr/share/munin/plugins/redis-speed
# ln -s /usr/share/munin/plugins/redis-speed /etc/munin/plugins/redis-speed

RedisホストのIPアドレスを設定ファイルに記述。
# echo "\n[redis-speed*]\nenv.host IPアドレス" >> /etc/munin/plugin-conf.d/munin-node

動作テスト。
# cd /etc/munin/plugins/
# munin-run redis-speed

munin-nodeをリスタート。
# service munin-node restart
グラフが出ているか、確認しましょう。

Enjoy!


2014年12月19日金曜日

EC2 HVMにRedisを載せたときの性能差は2倍以上

http://www.flickr.com/photos/othree/10945272436

EC2をHVMに移行するモチベーション – AWS Advent Calendar 2014:9日目 | Developers.IO http://dev.classmethod.jp/cloud/ec2-migration-to-hvm/

Developers.IOさん曰く、HVMインスタンスを使うとパフォーマンスがかなり良くなるという話だったので、Redisの場合はどうかなと思い、ベンチマークを走らせてみました。
結果、PVに比べてHVMは、ほぼ全てのパラメータで2倍以上の差がでました。

Redisのバージョンは2.8.19です。設定ファイルはデフォルトです。

EC2の環境
HVM AMI: CentOS 6 (x86_64) - with Updates HVM
PV AMI: CentOS 6 (x86_64) - with Updates
Instance Type: c3.xlarge + EBS-optimized instance
EBS: 100GB Provisioned IOPS (SSD) IOPS 3000

Linuxカーネルチューニング
# cat /etc/sysctl.conf
vm.swappiness = 0
net.core.somaxconn = 2048
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.ip_local_port_range = 1024 65000
vm.overcommit_memory = 1

ベンチマークコマンド
# time /usr/local/bin/redis-benchmark -c 1000 -r 100000 -n 10000 -q --csv

以下、結果のグラフです。
HVM/ PVそれぞれ5回試行しています。左の5本がHVM、右の5本がPVです。

Gitに脆弱性、Mac OS X YosemiteでGitをバージョンアップ

http://www.flickr.com/photos/nicmcphee/536062392

Gitに脆弱性が見つかったそうなので、Mac OS X Yosemiteでgitをバージョンアップしてみます。



報告の内容はこんな感じです。
http://article.gmane.org/gmane.linux.kernel/1853266
From: Junio C Hamano pobox.com>
Subject: [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)
Newsgroups: gmane.linux.kernel, gmane.comp.version-control.git
Date: 2014-12-18 21:11:19 GMT (3 hours and 58 minutes ago)
The latest maintenance release Git v2.2.1 is now available at
the usual places.

This is a security-fix for CVE-2014-9390, which affects users on
Windows and Mac OS X but not typical UNIX users. A set of new
releases for older maintenance tracks (v1.8.5.6, v1.9.5, v2.0.5, and
v2.1.4) are published at the same time and they contain the same fix.


以下、Gitのバージョンアップ方法です。
あらかじめ、brew(http://brew.sh/)が使えるように準備しておいてください。

brewを使ってGitをインストール
$ brew install git
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/git-2.2.1.yosemite.bottle.tar.gz
######################################################################## 100.0%
==> Pouring git-2.2.1.yosemite.bottle.tar.gz
==> Caveats
The OS X keychain credential helper has been installed to:
  /usr/local/bin/git-credential-osxkeychain

The "contrib" directory has been installed to:
  /usr/local/share/git-core/contrib

Bash completion has been installed to:
  /usr/local/etc/bash_completion.d

zsh completion has been installed to:
  /usr/local/share/zsh/site-functions
==> Summary
🍺  /usr/local/Cellar/git/2.2.1: 1356 files, 31M

インストールされたGitのバージョンを確認
$ /usr/local/bin/git --version
git version 2.2.1

コマンドPATH設定を確認
$ cat /etc/paths
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin

.bashrcを再読み込み
$ source ~/.bashrc

Gitのバージョンを確認
$ git --version
git version 2.2.1


最新バージョンが使えるようになりました。


参考)
brew upgrade gitしたのにバージョンあがらない問題 - DRYな備忘録
http://otiai10.hatenablog.com/entry/2014/12/19/101654

2014年12月18日木曜日

EC2のCentOS6 HVMでresize2fs "Nothing to do!"と言われたとき

http://www.flickr.com/photos/micahdowty/2932264540

EC2のCentOS6 HVMインスタンスを立ち上げたときは、そのままでは、resize2fsが動かずディスクサイズの増加ができません。
※ CentOS 6 (x86_64) - with Updates HVMのみ、CentOS 7版はOKです。
# resize2fs /dev/xvda1
resize2fs 1.41.12 (17-May-2010)
The filesystem is already 2096896 blocks long.  Nothing to do!
fdiskでパーティーションを作りなおしたりすれば良いのですが、若干面倒です。
cloud-initとcloud-utils-growpartを使った簡単な方法でディスクサイズを増加させます。

cloud-initをインストール
# yum -y install http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
# yum -y install cloud-init.noarch cloud-utils-growpart

下記の記述があることを確認
# cat /etc/cloud/cloud.cfg
 - growpart
 - resizefs

リブート
# reboot

もう一回、ログインしてリブート
※ ログインユーザがcentosになっているので注意。
$ ssh -i your.pem centos@xxxxxx.ap-southeast-1.compute.amazonaws.com
$ sudo su
# reboot

ディスクサイズが増えていることを確認
$ ssh -i your.pem centos@xxxxxx.ap-southeast-1.compute.amazonaws.com
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       99G  898M   93G   1% /
tmpfs            30G     0   30G   0% /dev/shm




参考)
AWS Marketplace版CentOSとの格闘記録 | tech
http://www.infilic.co.jp/tech/?p=221

1001714 – Add cloud-init to our base AMIs
https://bugzilla.mozilla.org/show_bug.cgi?id=1001714

Amazon EC2 CentOS 6 (x86_64) - with Updates HVM のディスク容量を増やす
http://takeshiyako.blogspot.jp/2015/02/amazon-ec2-centos-6-with-updates-hvm.html

2014年12月15日月曜日

BasecampのアップデートをSlackに投稿する

http://www.flickr.com/photos/qrush/14683721804

https://github.com/takeshiyako2/basecamp_to_slack
BasecampのアップデートをSlackに投稿するスクリプトを書きました。
以下のように通知してくれます。


もともと、Zapier(https://zapier.com/)というサービスで、BasecampとSlackを接続していたのですが、すぐにAccount Usageがフルになり使えなくなってしまいました。
調べたところ、BasecampにはAPIが提供されていたので、それを使ってみました。
https://github.com/birarda/logan
こちらのGemライブラリを利用しています。

Enjoy!



2014年12月12日金曜日

NagiosでAmazon Redshiftのディスク使用量をチェックする

http://www.flickr.com/photos/chewie/163892769

https://github.com/takeshiyako2/nagios-check_redshift_free_storage_space
Amazon Redshiftのディスク使用量をチェックするNagiosプラグインを書きました。


Amazon Redshiftは、ディスク使用率が50%を超えると性能が劣化してきます。
無理のないように早めにスケールさせて上がるとよいでしょう。

以下、セットアップ方法です。先に、rubyを使えるようにしておいてください。

1) CentOSの場合postgresql-develをインストール。
# yum -y install postgresql-devel

2) Gemライブラリをインストール.
# bundle

3) スクリプトを実行.
# ruby check_redshift_free_storage_space.rb -H xxxxx.ap-northeast-1.redshift.amazonaws.com -P 5439 -d my_database -u my_user -p my_password -w 50% -c 80%
OK - total: 7168GB, used: 2048GB (28%), free: 5120GB (72%)|used=2048

4) nrpe.cfgに設定を書き込み。nrpeをリスタート。


Enjoy!

2014年12月10日水曜日

EC2, EBS, ELB, RDS and ElastiCache to New Relic

http://www.flickr.com/photos/lizasperling/9110748397/in/photostream/

https://github.com/newrelic-platform/newrelic_aws_cloudwatch_plugin

"New Relic Amazon CloudWatch Plugin"を使って、AWSのサービスの監視データをNew Relicで確認できるようにします。以下の様なイメージです。


このプラグインは、CloudWatchから任意のデータを取得してNew Relicに入れるようになっています。データはCloudWatchでも確認可能な情報ですが、視認性の良いグラフで表示してくれます。

対応サービス:
EC2, EBS, ELB, RDS, SQS, SNS and ElastiCache(Memcached and Redis)

必要なスペック:
A single t1.micro EC2 instance (in any region)
Ruby (>= 1.9.2)
Rubygems (>= 1.3.7)
Bundler gem install bundler
Git

インストール方法:
※ 今回はCentOS6.6でインスールしました。

nokogiri に必要なyumライブラリをインストール。
# yum -y install libxml2-devel libxslt-devel

ソースを git clone。
# git clone https://github.com/newrelic-platform/newrelic_aws_cloudwatch_plugin.git

Gemライブラリをインストール。
# cd newrelic_aws_cloudwatch_plugin
# bundle install

設定ファイルを編集。
# cp config/template_newrelic_plugin.yml config/newrelic_plugin.yml
# emacs config/newrelic_plugin.yml

変更箇所は以下のようになります。

New Relicのライセンスキーを設定。
newrelic:
  #
  # Update with your New Relic account license key:
  #
  license_key: 'New Relicのライセンスキー'

AWSのアクセスキーと、シークレットキーを設定。
#
# AWS configuration.
#
aws:
  # Update with you AWS account keys:
  access_key: 'AWSアクセスキー'
  secret_key: 'AWSシークレットキー'

AWSのリュージョンを設定。Tokyoの場合は、ap-northeast-1 とします。
  # Specify AWS regions to query for metrics
  regions:
    -
      ap-northeast-1

どの項目をチェックするか設定します。
RDSの場合は、インスタンスID(DB Instance Identifier)を設定します。
#
# Agent configuration.
#
agents:
  #
  # Enable/disable agents with the enabled attribute or by commenting out each agent.
  ec2:
    enabled: true
  ebs:
    enabled: true
  elb:
    enabled: true
  rds:
    enabled: true
    instance_identifiers:
      - インスタンスID

エージェントをスタート。
# bundle exec bin/newrelic_aws 2>> /var/log/newrelic/newrelic_aws.log&
うまくいかなかったら、verboseオプションを有効にしてみてください。詳細をログに記録してくれます。
bin/daemonも用意されていますが、ログを落としてくれないので、上記のような起動にしています。スタートスクリプトは自作するのが良いかもしれません。
また、以下の様な警告がログに記録される場合があります。いつの間にかログが肥大したりすることもあるので注意しましょう。
Digest::Digest is deprecated; use Digest

Enjoy!

2014年12月2日火曜日

MySQLとAmazon RDSのレプリケーションをする方法

https://www.flickr.com/photos/atomictaco/5095355117

オンプレミスやEC2その他のサーバで動かしているMySQLとAmazon RDSをレプリケーションさせる方法です。
昨年、以下の資料が発表されています。

オンプレミスのMySQLデータをAmazon RDSに移動する
https://aws.amazon.com/blogs/aws/migrate-mysql-data-to-amazon-rds-and-back/

ダウンタイム無しでAmazon RDS MySQLデータベースにデータをインポート
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html


ひじょうに簡単になっていたので纏めてみました。

MySQLマスターサーバは既に立ち上がっているとします。
IPアドレス: 100.100.100.100

コンソールからRDSを作成します。
ホスト名: rds.xxx.ap-northeast-1.rds.amazonaws.com
ユーザ: userrds
パスワード: passwordrds


MySQLマスターにスレーブ用のユーザを作成。
$ mysql -uroot -pxxxxxxxx
mysql> GRANT REPLICATION SLAVE ON *.* TO userrds@"%"IDENTIFIED BY "passwordrds";
mysql> FLUSH PRIVILEGES;

mysqldumpを使ってMySQLマスターのデータベースをバックアップ。
$ /usr/bin/ionice -c2 -n7 /bin/nice -n19 /usr/bin/mysqldump -uroot -pxxxxxxxx --master-data=2 --single-transaction --routines --triggers --databases  databasename > databasename.sql

binlog名とポジションを調べて、控えておく。
$ head -100 databasename.sql | grep CHANGE
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000855', MASTER_LOG_POS=846543983;

RDSにデータベースを作っておく。
$ mysql -uuserrds -ppasswordrds -hrds.xxx.ap-northeast-1.rds.amazonaws.com
mysql> CREATE DATABASE  databasename;

RDSにバックアップファイルをインポートする。
$ mysql -uuserrds -ppasswordrds -hrds.xxx.ap-northeast-1.rds.amazonaws.com databasename < databasename.sql

RDSにMySQLマスターの情報を登録する。
$ mysql -uuserrds -ppasswordrds -hrds.xxx.ap-northeast-1.rds.amazonaws.com
mysql> CALL mysql.rds_set_external_master('100.100.100.100',3306,'userrds','passwordrds','mysql-bin.000855',846543983,0);

レプリケーションをスタート。
mysql> CALL mysql.rds_start_replication;

レプリケーションの状態を確認。
mysql> SHOW SLAVE STATUS\G

※ read_onlyがOFFになっているので、書き込み可能な状態になっています。お好みによって、read_onlyをONにしてください。
mysql> SHOW GLOBAL VARIABLES like 'read_only';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

以下、その他のコマンドです。

レプリケーションをストップする。
mysql> CALL mysql.rds_stop_replication;

レプリケーションを解除する。
mysql> CALL mysql.rds_reset_external_master;

レプリケーションの状態を確認する。
mysql> SELECT * FROM mysql.rds_replication_status;

レプリケーション設定のログを表示する。
mysql> SELECT * FROM mysql.rds_history;


参考資料)

Importing Data to an Amazon RDS MySQL DB Instance with Reduced Downtime - Amazon Relational Database Service
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html

付録: MySQL Amazon RDS SQL リファレンス - Amazon Relational Database Service
http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Appendix.MySQL.SQLRef.html

既存のMySQLサーバからRDSインスタンスへの移行をテストする « サーバーワークス エンジニアブログ
http://blog.serverworks.co.jp/tech/2011/10/17/mysql-to-rds-test/

EC2・オンプレ環境のMySQLからRDSのマイグレーションがやりやすくなった - まめ畑
http://d.conma.me/entry/2013/09/06/133656


2014年11月28日金曜日

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


2014年11月26日水曜日

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!

2014年11月19日水曜日

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

2014年11月18日火曜日

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!

2014年11月13日木曜日

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

2014年11月12日水曜日

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/



























簡単ですね!




2014年11月11日火曜日

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:'


簡単ですね!

2014年10月30日木曜日

Nginxのレスポンスタイムをパーセンタイル値で計測するMunin plugin

Alberto Permuy Leal

https://github.com/takeshiyako2/munin-nginx_request_time

nginxのレスポンスタイムをパーセンタイル値で計測するMunin pluginです。
id:t-cyrillさんのプラグインがオリジナルです。これをLTSVに対応させました。
90パーセンタイル, 95パーセンタイル値とMAX値をグラフにします。(MAX値は別グラフ)


min 最小値
median 中央値
percentile90 90パーセンタイル
percentile95 95パーセンタイル


パーセンタイルとは?
計測値の分布(ばらつき)を小さい数字から大きい数字に並べ変え、パーセント表示することによって、小さい数字から大きな数字に並べ変えた計測値においてどこに位置するのかを測定する単位。
 例えば、計測値として100個ある場合、5パーセンタイルであれば小さい数字から数えて5番目に位置し、50パーセンタイルであれば小さい数字から数えて50番目に位置し、95パーセンタイルであれば小さい方から数えて95番目に位置する。
 このようにパーセンタイルは全体における自分の位置を測定する単位として用いられ、企業年金においては年金ALMにおいて計算された数値を説明するのに用いられることがある。
パーセンタイル(percentile)|用語集|企業年金連合会
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::Descriptive
Muninプラグインを設置
# cd /usr/share/munin/plugins/
# wget --no-check-certificate https://raw.githubusercontent.com/takeshiyako2/munin-nginx_request_time/master/nginx_request_time
Muninプラグインにリンクを貼る
# 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_max
munin-nodeをリスタート。
# service munin-node restart
簡単ですね!

※ 他にも、レスポンスタイムの可視化として有効なのは、例えば、[10ms ~ 50ms], [51ms~ 100ms], [101ms以上]で別々でカウントしたりする方法があります。こちらも実装しておくと安心できるでしょう。

参考)
『性能エンジニアリング入門(2):負荷テストのデータ、読めてますか? (1/2)』
http://www.atmarkit.co.jp/ait/articles/1201/06/news121.html

負荷テストの勘所 その2 | 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

2014年10月28日火曜日

MySQLスレーブの整合性を保つための3つの設定

David Guthrie

MySQLのスレーブサーバが落ちて、立ち上げた時にマスターとの整合性を心配したくないのであれば以下の設定を入れると良いそうです。

MySQL設定ファイルに追記
# emacs /etc/my.cnf

[mysql]
binlog_checksum            = CRC32
relay_log_info_repository  = TABLE
relay_log_recovery         = ON

MySQLをリスタート
# service mysqld restart


各設定に意味については、下記サイトが参考になります。

binlog_checksum            = CRC32
”バイナリログが破損した場合に破損を検出し易くするために、バイナリログにチェックサムを追加”
http://thinkit.co.jp/story/2014/01/23/4717/page/0/1

relay_log_info_repository  = TABLE
relay_log_recovery         = ON
"MySQL 5.6でスレーブをクラッシュセーフにするには"
http://yakst.com/ja/posts/57


結果、スレーブサーバは以下の様な設定になりました。
※ HandlerSocket の設定込みです。


2014年10月23日木曜日

AWSガチャは下手なチューニングよりも効果が出る?

foxfoto_archives

Amazon EC2は立ち上げるインスタンスによって微妙なパフォーマンス差が出ると言われていて、複数回、インスタンスを立ち上げたり、捨てたりして、良いインスタンスを得ることを”Amazon EC2インスタンスガチャと”呼ばれています。
そのパフォーマンス差は、どれくらいなのか?気になったので測ってみました。

検証環境はこんな感じです。
AMI ID: CentOS 7 x86_64 (2014_09_29) EBS HVM-b7ee8a69-ee97-4a49-9e68-afaee216db2e-ami-d2a117ba.2 (ami-89634988)
Instance Type: c3.xlarge

1)Magnetic(standard)
2)Magnetic(standard) + EBS-Optimized
3)General Purpose (SSD) + EBS-Optimized
4)Provisioned IOPS (IOPS 1000) + EBS-Optimized

上記のディスクを接続した各10インスタンスづつ立てて、ベンチマークします。

fioでベンチマーク

まず。fioでIOPSを調べます。

fioをインストール。
# yum -y install epel-release.noarch
# yum -y install fio
fioをランダムリード・モードで実行。
# fio -rw=randread -bs=4k -size=1G -numjobs=32 -runtime=60 -direct=1 -invalidate=1 -ioengine=libaio -iodepth=32 -iodepth_batch=32 -group_reporting -name=randread


インスタンスによって差異が出てきました。

dbenchでベンチマーク

違うベンチマークツールでスループットを調べてみます。
ベンチマークには、dbench(https://dbench.samba.org/)を使います。

dbenchをインストール。
# yum -y install dbench
dbenchを実行。
# dbench 5 -D . > dbench.log



かなりの差が出てしましいました。

まとめ

インスタンスによっては、ディスク性能でけっこうな差がでてしまいました。

Magnetic(standard)はAWSガチャによってかなりの性能差が出ます。EBS-Optimizedをつけても変わりません。

一見、General Purpose (SSD)が良い結果を出しているように見えますが、バーストしている状態だと思われます。数十回ベンチマークをかけたら仕様どおりガクンと性能が落ちました。
(最も低い結果で iops=305, Throughput 75.5844 MB/sec, max_latency=7719.676 ms ほど)
長時間連続して負荷がかかる環境には使わないほうがよいでしょう。
逆に、バッチ処理などの用途では威力を発揮しそうです。
General Purpose (SSD)のバーストについては、こちらの記事が参考になります。
『Amazon EBSのGeneral Purpose(SSD)のバーストルールを理解する | Developers.IO』
http://dev.classmethod.jp/cloud/study-ebs-ssd-burst-rule/

 Provisioned IOPSはまあまあ安定しています。

ちなみにUnixBenchも試してみましたが、これは主にCPUへのベンチマークツールなので、差は殆どありませんでした。
MySQLのマスターサーバなどでディスク性能が要求される用途では、Provisioned IOPSを選ぶと安心できるでしょう。

※ 2014/10/24 General Purpose (SSD) + EBS-Optimized と Provisioned IOPS (IOPS 1000) + EBS-Optimized のベンチマークを追記。

2014年10月21日火曜日

CentOS7にMySQL5.6をyumレポジトリからインストール

Christian Ditaputratama


そういえば、まだ、CentOS 7をあまりいじっていなかったので、とりあえず手始めにMySQLをインストールしてみました。

環境はAmazon EC2です。
AMIは、CentOS 7 (x86_64) with Updates HVMです。

AMI ID: CentOS 7 x86_64 (2014_09_29) EBS HVM-b7ee8a69-ee97-4a49-9e68-afaee216db2e-ami-d2a117ba.2 (ami-89634988)
Instance Type: c3.xlarge
EBS: General Purpose (SSD)

* こちらのURLから最新のMySQLのyumレポジトリを探します。
http://dev.mysql.com/downloads/repo/yum/
Red Hat Enterprise Linux 7のDownloadリンクをクリック -> "No thanks, just start my download."のURLが最新です。

* MySQLのレポジトリをインストール。el7を選びます。
# rpm -i http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm

* MySQLをインストール。
# yum install mysql-community-server mysql-community-devel

* MySQLサービスをスタート。/etc/init.d/mysqldじゃあなくなっているので注意です。
# service mysqld start

* MySQLのステータスをチェック。色々出てくるようになりました。
# service mysqld status -l
edirecting to /bin/systemctl status  -l mysqld.service
mysqld.service - MySQL Community Server
   Loaded: loaded (/usr/lib/systemd/system/mysqld.service; disabled)
   Active: active (running) since Wed 2014-10-22 01:18:38 UTC; 1min 43s ago
  Process: 1513 ExecStartPost=/usr/bin/mysql-systemd-start post (code=exited, status=0/SUCCESS)
  Process: 1454 ExecStartPre=/usr/bin/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 1512 (mysqld_safe)
   CGroup: /system.slice/mysqld.service
           ├─1512 /bin/sh /usr/bin/mysqld_safe
           └─1652 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock

Oct 22 01:18:37 ip-172-31-7-208 mysql-systemd-start[1454]: Support MySQL by buying support/licenses at http://shop.mysql.com
Oct 22 01:18:37 ip-172-31-7-208 mysql-systemd-start[1454]: Note: new default config file not created.
Oct 22 01:18:37 ip-172-31-7-208 mysql-systemd-start[1454]: Please make sure your config file is current
Oct 22 01:18:37 ip-172-31-7-208 mysql-systemd-start[1454]: WARNING: Default config file /etc/my.cnf exists on the system
Oct 22 01:18:37 ip-172-31-7-208 mysql-systemd-start[1454]: This file will be read by default by the MySQL server
Oct 22 01:18:37 ip-172-31-7-208 mysql-systemd-start[1454]: If you do not want to use this, either remove it, or use the
Oct 22 01:18:37 ip-172-31-7-208 mysql-systemd-start[1454]: --defaults-file argument to mysqld_safe when starting the server
Oct 22 01:18:37 ip-172-31-7-208 mysqld_safe[1512]: 141022 01:18:37 mysqld_safe Logging to '/var/log/mysqld.log'.
Oct 22 01:18:37 ip-172-31-7-208 mysqld_safe[1512]: 141022 01:18:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Oct 22 01:18:38 ip-172-31-7-208 systemd[1]: Started MySQL Community Server.

* MySQLを初期化。
※ パスワードは便宜設定してください
# mysql_secure_installation

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MySQL
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MySQL to secure it, we'll need the current
password for the root user.  If you've just installed MySQL, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MySQL
root user without the proper authorisation.<

Set root password? [Y/n] Y
New password:AAAAAA
Re-enter new password:AAAAAA
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MySQL installation has an anonymous user, allowing anyone
to log into MySQL without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] Y  ... Success! By default, MySQL comes with a database named 'test' that anyone can access.  This is also intended only for testing, and should be removed before moving into a production environment. Remove test database and access to it? [Y/n] Y  - Dropping test database... ERROR 1008 (HY000) at line 1: Can't drop database 'test'; database doesn't exist  ... Failed!  Not critical, keep moving...  - Removing privileges on test database...  ... Success! Reloading the privilege tables will ensure that all changes made so far will take effect immediately. Reload privilege tables now? [Y/n] Y  ... Success! All done!  If you've completed all of the above steps, your MySQL installation should now be secure. Thanks for using MySQL! Cleaning up...

* ログインしてみる
# mysql -uroot -pAAAAAA
Warning: Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 14
Server version: 5.6.21 MySQL Community Server (GPL)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SELECT "Hello World!";
+--------------+
| Hello World! |
+--------------+
| Hello World! |
+--------------+
1 row in set (0.00 sec)

ログインできました。
簡単ですね!

2014年10月20日月曜日

Amazon RDSのディスクスペースをチェックするnagiosプラグイン

Docklandsboy

https://github.com/takeshiyako2/nagios-check_rds_free_storage_space

Amazon RDSのディスクスペースをチェックするnagiosのプラグインです。
Amazon RDSの情報は、CloudWatchから調べることができるのですが、非常に見づらいので、nagiosでもチェックできるようにしました。

コードは、こんな感じになりました。

使い方は、以下のようになります。
オプションがたくさんあります。

$ ./check_rds_free_storage_space.rb -a [CloudWatch access_key] -s [CloudWatch secret_key] -r [CloudWatch region] -e [RDS region] -i [DBInstanceIdentifier] -w [Nagios warning level] -c [Nagios critical level]

$ ./check_rds_free_storage_space.rb -a AAAAAA -s SSSSSS -r monitoring.ap-northeast-1.amazonaws.com -e rds.ap-northeast-1.amazonaws.com -i mysql1 -w 30 -c 20

リュージョンのところは、日本の場合は、ap-northeast-1が付くので要注意です。

2014年10月10日金曜日

MySQLサーバのswap増加を解決するチューニングのヒント

MySQLサーバでスワップ(swap)が増えていたので、これを解消しました。
カーネルの設定 vm.swappiness = 1 を入れて解決しています。
こちらのスライドの17ページを参考にしました。



OSは、CentOS6.5です。
# cat /etc/redhat-release
CentOS release 6.5 (Final)


swapを確認
sysstatでswapの状況を確認してみます。
メモリに関しては、こちらのスライドが参考になります。



swapの発生状況を確認

# sar -W
12:00:01 AM  pswpin/s pswpout/s
12:10:01 AM      0.00      0.00
12:20:01 AM      0.00      0.00
12:30:01 AM      0.00      0.00
12:40:01 AM      0.00      0.00
12:50:01 AM      0.00      0.00

pswpin/s 1秒間にスワップ領域からメモリに読み込んだページ数
pswpout/s 1秒間にメモリからスワップ領域へ書き込んだページ数

スワップが多発している訳ではなことがわかります。

swap回数の統計を確認

# sar -B
12:00:01 AM  pgpgin/s pgpgout/s   fault/s  majflt/s  pgfree/s pgscank/s pgscand/s pgsteal/s    %vmeff
12:10:01 AM      1.04   7490.29   2939.23      0.03   9099.59    106.70      0.00    106.70    100.00
12:20:01 AM      0.68    700.46   1314.42      0.02   5203.37     28.75      0.00     28.75    100.00
12:30:01 AM      0.19   1187.17   1449.92      0.01   4704.59     37.38      0.00     37.38    100.00
12:40:01 AM      0.29   2224.01   1333.28      0.01   6425.57    121.65      0.00    121.65    100.00
12:50:01 AM      0.45    671.65   1443.74      0.01   3858.88     42.24      0.00     42.24    100.00

pgpgin/s 1秒間にスワップ領域からメモリへページ・インしたページ数
pgpgout/s 1秒間にメモリからスワップ領域へページ・アウトしたページ数
%vmeff pgsteal / pgscanとして計算された数で、ページ回収の効率性を示す。100%に近い場合、ほぼ全ての非活動リストの末尾から来るページが回収された事を意味する。低すぎる場合(30%以下)、仮想メモリは何らかの問題を有している。出力対象の期間の間にページのスキャンが行われない場合は、このフィールドはゼロを示す。

ページ・アウトが発生していますが、ページ・インは少ないので、スラッシングは少ない状況です。
ページ・インが多い場合は、スラッシングが多発し、アプリケーションのパフォーマンスが劣化している状況なので、サーバのメモリ搭載量を増やすなどの対応が必要です。

参考)sarコマンドのマニュアル
http://backslash0134.blog.fc2.com/blog-entry-63.html


カーネルの設定

vm.swappinessの設定をします。
vm.swappinessは、swap領域の扱いを制御するカーネルの設定です。
この設定値が小さければ小さいほどswapを抑制します。
デフォルトは、vm.swappiness=60です。これを1にします。

参考)Swappiness
http://ja.wikipedia.org/wiki/Swappiness
vm.swappiness = 0 メモリが一杯になるまでスワップを利用しない
vm.swappiness = 60 規定値
vm.swappiness = 100 全体のパフォーマンスに影響しうるほど積極的にスワップ処理を行う

設定を確認
# sysctl vm.swappiness
vm.swappiness = 60

設定変更
# echo 1 > /proc/sys/vm/swappiness

再度、設定を確認
# sysctl vm.swappiness
vm.swappiness = 1

sysctl.confに設定を追記
# vim /etc/sysctl.conf
vm.swappiness = 1

参考)
Linux performance tuning tips for MySQL
http://www.percona.com/blog/2013/12/07/linux-performance-tuning-tips-mysql/
OOM relation to vm.swappiness=0 in new kernel; kills MySQL server process
https://www.percona.com/blog/2014/04/28/oom-relation-vm-swappiness0-new-kernel/


swapしたデータをメモリに戻す

# swapoff -a && swapon -a

swapの量によって時間がかかります。
若干の負荷かかるので注意してください。
今回は、ロードアベレージが +1 ほど増えました。

以上で、MySQLサーバのswap増加を解決しました。
メモリの量を見てみましょう。チューニングを実施したところからメモリとスワップの使用率が変化しているのがわかります。


2014年10月2日木曜日

Nagiosでドメインの有効期限を監視する check_domain プラグイン

h080


ドメインの有効期限を監視するnagiosプラグインを紹介します。
※ OSは、CentOS6.5です。

公式サイトで扱っている check_domain を試したのですが、うまく期限を検知してくれなかったり、あまり使えない感じで駄目でした・・・。
http://exchange.nagios.org/directory/Plugins/Internet-Domains-and-WHOIS/check_domain/details
色々調べた結果、susatadahiroさんが公開されているプラグインが良かったので、これをforkして利用していきます。
いきます。


whoisライブラリをインストール
# yum -y install jwhois

git cloneして、nagiosプラグインディレクトリに設置します。
# git clone https://gist.github.com/961a772db63ec474b954.git
# cp 961a772db63ec474b954/check_domain /usr/lib64/nagios/plugins/
# chmod 755 /usr/lib64/nagios/plugins/check_domain

動作テストしてみましょう。

30日前でWARNING、10日前でCRITICAL
# /usr/lib64/nagios/plugins/check_domain -d appvador.com -w 30 -c 10
OK - Domain will expire on  20-nov-2014

90日前でWARNING、10日前でCRITICAL
# /usr/lib64/nagios/plugins/check_domain -d appvador.com -w 90 -c 10
WARNING - Domain will expire after 49 days on  20-nov-2014

検知してくれました。

あとは、nagiosのcommands.cfgにコマンドを設定して、、
define command{
        command_name    check_domain
        command_line    $USER1$/check_domain -H $ARG1$ -w 30 -c 10
        }

serviceに追加すればOKです。
define service{
        use                             local-service
        host_name                       localhost
        service_description Domain Expiration
        check_command  check_domain!appvador.com
        }

nagiosを確認してみましょう。




Enjoy!


2014年9月3日水曜日

YAPC::Asia Tokyo 2014 でスタッフをさせていただきました


※画像は、入り口の看板です。

http://yapcasia.org/2014/
YAPC::Asia Tokyo 2014 でスタッフをさせていただきました。
スタッフをやるのは、2012, 2013と3回目です。


なぜ、ボランティアに応募したかというと。Perlは、一番初めの仕事で使った言語です。なので、社会人になってからの生活を支えてくれたプログラミング言語ともいえます。ボランティアに応募したのは、その、Perlへの貢献がしたかったからです。
今は、バリバリPerlを書いているわけではありませんが、いつ必要になるかわからないので、トレンドくらいは抑えておきたいなというところもあります。
また、他の言語(Scala, Java, Go, PHP, Ruby & etc..)、DevOps、インフラ・ネットワーク的な話も多岐に渡っていますし、それぞれの最新情報もざっくりキャッチしておきたいと考えて参加しています。(こんかいは、まさかのアイドル登壇があった・・・)


スタッフというと結構忙しいのかな?と思いますが、けっこうセッションを見る時間があるのです。
それはなぜか?というと、大体のスタッフは、セッションのための部屋にそれぞれ専属で仕事(ボランティア活動といったほうが適切?)をするのですが、部屋の仕事のキャパ以上の人的リソースを投入するからですね。だいたい2人位で足りるところを5人位投入という感じです。
これが、普通のWeb開発などをしている目から見ると意外と、目からうろこ的な感じなのです。それぞれの人に余裕が生まれることによって、人の目の数が増えるといいますか、細かいところに気がつくようになってきます。
例えば、他の部屋も見に行けるくらい余裕があるので、他の部屋では、どうやって進行しているのか、ホワイトボードをこんなかんじに使っているぞとか、ブラインドはこんなかんじで下げているぞとか、Twitter見てたら、寒いと行っている人がいるぞ、部屋のエアコン調節しよう、とか、色々あります。
サボる時間ができていながら、イベントのことを気にしてしまう。
こういうのができるのは、やっぱりスタッフのモチベーションが高いからでしょうね。
もちろん、オープン前やクローズ時などで急に仕事が増大した時にも、人手が多いのでスケールします。普通のシステム開発とは、まったく別の人的リソースの投入方法です。面白いです。




来年も多分やるんじゃないかな?との情報なので、来年、時間に余裕がある人は、スタッフに応募してみてはいかがでしょうか。
今年は、すぐに人が集まったようで、けっこうはやく募集の締め切りをしていました。
なので、春くらいの季節になったら、YAPCの情報を逐一チェックしておくといいかもしれないです。
スタッフ応募資格は、たぶんあんまり厳しくないんじゃあないかな?応募した時点で「やる気」のところはクリアしているでしょうし。
プログラムの言語が全くわからなくても大丈夫です。

2014年9月1日月曜日

SlackをNagiosに連携させる方法

Jeriff Cheng

チャットツールのSlackと、システム監視ソフトのNagiosを連携させる方法です。
Nagiosでアラートを検知した時に、Slackに通知します。

こんなイメージです。


SlackのNagiosサービスを有効にする


https://<グループID>.slack.com/services/new/nagios
を開く。
ページの下の [Add Integration] をクリック。



" New integration added! " と出たらOKです。
設定のためのチュートリアルが表示されます。基本的にこのまま従っていけばOKです。

トークンをメモっておきましょう。チュートリアルと、左側に表示されています。
---
TOKEN
The token for this integration is:
XXXXXXXXXXXXXXX <- これがトークンです。
---

---
my $opt_token = "XXXXXXXXXXXXXXX"; <- これがトークンです。
---

Slackに、naigosチャンネルを作っておきます。

Slack通知スクリプトを用意する



Perlモジュールをインストール
# yum install perl-libwww-perl perl-Crypt-SSLeay

公式スクリプトを取得&設置
# wget https://raw.github.com/tinyspeck/services-examples/master/nagios.pl --no-check-certificate 
# cp nagios.pl /usr/local/bin/slack_nagios.pl
# chmod 755 /usr/local/bin/slack_nagios.pl

slack_nagios.plを編集して、グループIDと、トークンを設定
# emacs /usr/local/bin/slack_nagios.pl
---
my $opt_domain = "<グループID>.slack.com"; # Your team's domain
my $opt_token = "<トークン>"; # The token from your Nagios services page
---

テスト投稿をしてみましょう。
# /usr/local/bin/slack_nagios.pl -field slack_channel=#nagios -field HOSTALIAS="HOSTNAME" -field SERVICEDESC="SERVICEDESC" -field SERVICESTATE="SERVICESTATE" -field SERVICEOUTPUT="SERVICEOUTPUT" -field NOTIFICATIONTYPE="NOTIFICATIONTYPE"



こんな感じで出てきたでしょうか?

Nagiosの設定ファイルを編集する


通知先のメンバーにslackを追加。
# emacs /etc/nagios/objects/contacts.cfg
---
define contact {
      contact_name                             slack
      alias                                    Slack
      service_notification_period              24x7
      host_notification_period                 24x7
      service_notification_options             w,u,c,r
      host_notification_options                d,r
      service_notification_commands            notify-service-by-slack
      host_notification_commands               notify-host-by-slack
}

define contactgroup {
  contactgroup_name admins
  alias             Nagios Administrators
  members           root, slack
}
---

通知コマンドを追加。slack_channel=<チャンネル名>を便宜設定します。
# emacs /etc/nagios/objects/commands.cfg
---
define command { 
command_name notify-service-by-slack 
command_line /usr/local/bin/slack_nagios.pl -field slack_channel=#nagios -field HOSTALIAS="$HOSTNAME$" -field SERVICEDESC="$SERVICEDESC$" -field SERVICESTATE="$SERVICESTATE$" -field SERVICEOUTPUT="$SERVICEOUTPUT$" -field NOTIFICATIONTYPE="$NOTIFICATIONTYPE$"
}

define command { 
command_name notify-host-by-slack 
command_line /usr/local/bin/slack_nagios.pl -field slack_channel=#nagios -field HOSTALIAS="$HOSTNAME$" -field HOSTSTATE="$HOSTSTATE$" -field HOSTOUTPUT="$HOSTOUTPUT$" -field NOTIFICATIONTYPE="$NOTIFICATIONTYPE$"
}
---

Nagiosの設定チェック
# /usr/sbin/nagios -v /etc/nagios/nagios.cfg

問題なかったらNagiosをリスタート
# /etc/init.d/nagios restart

テスト的にアラートを投げてみましょう。



こんな感じで色分けしてSlackに通知してくれます。
簡単ですね!

2014年7月22日火曜日

「AWS Summit Tokyo 2014」に登壇してきました。



『CloudFront、RedshiftなどAWSが支える動画広告の舞台裏~インフラのイノベーションがもたらす動画広告のイノベーション~』
と題して、セッションを行わせて頂きました。

Media & Entertainment セッションということで、全体的に”ビジネス寄りの話に厚みを持たせ、技術寄りの細かい話は、なるべくスーツの人にもわかりやすく”という内容でお話をさせて頂きました。
会場は、500人部屋で、満員御礼。
ビジネスの部は、CCI工藤さんと、上野くんで進めて頂きました。
場馴れしている感がありましたね。さすがです。
私のところに回ってきた時には、とにかくドモらないように、滑舌よく喋る。ということを意識してやりました。
2週間ほど、毎晩、妻の前で練習した成果もあって(付き合ってくれてありがとう!)、頭が真っ白になったりとか最悪の事態にはなりませんでしたが、途中、何回かつっかえてしまいました。
セッションが終わったあと友人に聞いたところ「言いたいことは伝わってましたよ」との事だったので、この点に関しては、悪すぎずまあまあだったのかなと思います。悪かったところを気にしていてもしようがないですからね。今度やるときは発声練習もちゃんとします。がんばります。

スライドだけでは伝わらない部分があるかと思いますので、「詳しく聞いてみたい」などご要望がありましたら。ご連絡頂けますと幸いです。
あらためまして、今回のセッションに関わっていただいた方たちに感謝いたします。

セッションの内容をまとめて頂きました。有難うございます!

AWS Summit 2014 〜 Media & Entertainment 〜 - Qiita
http://qiita.com/mattuso/items/96e5163ae1913b11d072

#1 AWS SUMMIT TOKYO 2014 に行ってきました
http://bensem.hateblo.jp/entry/20140718/1405692000

「AWS Summit Tokyo 2014 (Day 1)」に参加してきました - akiyoko blog
http://akiyoko.hatenablog.jp/entry/2014/07/17/230044