先日のGMOクラウドVPS
ダウンで、サポートに入れてあった問い合わせに返信メールが来て、SLA適用で月額の10％分をデポジットとしてチャージしたとの事。
管理画面で確認すると118円がチャージされていた。 しかし、6ヶ月契約してるから、次回の契約更新時にすこし（７０８０－１１８）値引きされる感じだね。
しかし、デポジットだから契約を継続しないと受けられないわけだな。
まぁ、どこの世界にも絶対に落ちないサーバは無いんだし、一度ミスった方が安全かもしれない？ しばらくつきあいますか・・・
(371)
先日のGMOクラウドVPSのダウン時に活躍した簡易スクリプト。
現在運用しているさくらVPS
、お名前.com VPS
と共に、このバッチを走らせて相互に簡易監視している。
#!/bin/sh
serverlist=(‘server1.hoge.tld’ ‘server2.hoge.tld’ ‘www.piyo.tld’)
mailto=’address@hoge.tld’
date=date '+%Y-%m-%d %H:%M:%S'
for server in ${serverlist[@]}
do
loss=ping -c 1 $server | grep "% packet loss" | sed -e "s/^.* \([0-9]*\)% packet loss.*/\1/"
if test $loss -ne 0; then
echo "[$server] : No responding." | mail -s "Server alert [$server] @ $date" $mailto
fi
done
HTTP監視とか一切せず、pingを一回打ってみて帰ってこなかったらサーバ名をメールするシェル。
serverlistに監視対象サーバを列挙して、mailtoに通知先アドレスを入れるだけ。
実行権限をつけてcronで、
*/5 * * * * /home/myhome/bin/pingwatch.sh
みたいにして回す。
ちょっと書き足して、wgetとかcurlを使うようにすればHTTP等の監視も出来るけど、これくらいがコンパクトで良いかと。
(214)
昨日（2012/10/18 20:47）からこのブログを入れているGMOクラウドVPSで障害が発生、結局、今日2時7分頃になってやっとサーバが立ち上がった。
ダウンタイムは5時間強、SLAで返金があるのかな。
会社から帰宅途中に監視のアラートメールがケータイに飛んできてなかなか慌てた（GMOクラウドとさくらで相互に監視している）
当初2時間近くアナウンスもなく公式サイトにも接続できず、ユーザのTwitterや掲示板で状況確認する羽目になった。
結局、得られた公式情報は22:30の公式Twitterが最初だった。 障害情報すら得られないのは困りものだ。
メールがバックアップサーバに飛んでいるからマスタサーバに統合しなきゃなぁ・・・
(334)
最近、島問題の影響のようでさくらVPSやお名前.com VPS(KVM)のホストにも大陸や半島方面からのDoS的なアクセスがままあってそのたびにホスト制限していたのですが、面倒くさいので、アドレス割り当て情報から大陸と半島からのアクセスを制限するためのiptables設定をしました。
-Aじゃなくて-Iなのは、許可ルール以前にこのIPを拒否したいため。
シェル実行してから /etc/init.d/iptables save で保存できる。
ドロップしたパケットを記録したい場合は、
-N LOGDROP
-A LOGDROP -j LOG –log-prefix “[iptables drop]”
-A LOGDROP -j DROP
みたいに、新しい挙動LOGDROPを定義して、LOGDROP挙同時にはLOGってDROPする動きにする。
で、従来の-j DROPの代わりに-j LOGDROPにしてやると、messagesログファイルにドロップした情報が記録されるようになる。
LOGDROPを定義せずにLOGって、DROPしてを繰り返し書いても良いけど、数が多いときはこの方が楽。
(1038)
MySQLの便利機能でGROUP_CONCATってのがある。
SELECT primary_id, GROUP_CONCAT(item_id) AS item_id_list FROM stock GROUP BY primary_id ORDER BY primary_id ASC LIMIT 50
みたいにすると、stockテーブルのprimary_idでグループ化して、そのグループ内のitem_idをカンマ区切りで返してくれる。
このとき、item_id_listはBLOBになったりする。
こんな感じでもっと複雑なテーブルについてきたとき、ORDERやLIMITの関係でtmpテーブルでの作業が発生するんだけど、BLOBがMEMORYエンジンに乗らないのでボトルネックになっていた。
さくらVPSやお名前.com VPS(KVM)では、物理マシンに比べてディスクI/Oが弱いのでTmp to Diskになると著しく遅くなるので改善したい。
ORDERやLIMITがINDEXで直ちに確定できない場合に、巨大なデータセットがtmpになるので、とりあえずこれをサブクエリにして
SELECT s.*, GROUP_CONCAT(item_id) AS item_id_list FROM (SELECT primary_id FROM stock GROUP BY primary_id ORDER BY primary_id ASC LIMIT 50) p LEFT JOIN stock s ON s.primary_id = p.primary_id GROUP BY s.primary_id ORDER BY s.primary_id ASC
みたいにした方が高速になった。
この場合は、外のクエリは結局tmpの処理があるんだけど、LIMIT処理がサブクエリ中でかかっているから、JOINの段階でデータサイズが小さくなってCopy to Tmp Tableの時間が短縮できる。
中間処理テーブルが大きくてLIMITが小さい場合ほど効果的。
まぁ、根本を直した方が良いんだけど、とりあえず、簡単な修正で処理時間を短縮できるメモ。
(1259)
MySQLで指定日数前の日付を取得する場合、
DATE(DATE_ADD(NOW(), INTERVAL -日数 DAY))
で取得出来る。
createdateに日付を入れていて、最近7日以内に作られたレコードを求める場合、
SELECT * FROM my_table WHERE createdate >= DATE(DATE_ADD(NOW(), INTERVAL -7 DAY))
みたいになる。 ちなみに -0 DAYなら今日になる。
関連して、日付の曜日を取得する場合、
WEEKDAY(日付)
で取得する。 0が月曜で始まる。
今週の月曜日の日付は、
DATE(DATE_ADD(NOW(), INTERVAL -WEEKDAY(NOW()) DAY))
で取得出来る。
今週の月曜日からの記録を切り出す場合、
createdate >= DATE(DATE_ADD(NOW(), INTERVAL -WEEKDAY(NOW()) DAY))
で取得。
先週の月曜から金曜までの記録を切り出す場合、
createdate >= DATE(DATE_ADD(NOW(), INTERVAL -WEEKDAY(NOW())-7 DAY)) AND createdate < DATE(DATE_ADD(NOW(), INTERVAL -WEEKDAY(NOW())-3 DAY))
※BETWEENは以上以下。 時刻なしのDATEは0時0分0秒扱いだから1秒減算する必要がある。
(953)
お名前.com VPS(KVM)に入っているMuninを使って自宅のRTX1000の監視をしてみる。
１，RTX側のSNMP設定を行う
基本
snmp host VPSのIPアドレス
snmp community read-only public
snmp yrifppdiplayatmib2 on
更に、NATの外から来るのでスタティックを追加
nat descriptor masquerade static NATデスクリプタ番号 テーブル番号 RTXの内側アドレス udp snmp
snmpポートのフィルタリングを追加
ip filter フィルタ番号 pass VPSのIPアドレス RTXの内側アドレス udp * snmp
ip filter フィルタ番号 restrict * RTXの内側アドレス udp * snmp
※VPSからのSNMP要求は通して、それ以外から来た物を捨てる。
２，VPS側でmunin設定を行う
まずはmunin-nodeを設定
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_1’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_3’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_5’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_6’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_35’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_91’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_92’
ln -s ‘/usr/share/munin/plugins/snmp__if_’ ‘/etc/munin/plugins/snmp_hoge.piyo.tld_if_93’
※hoge.piyo.tldはRTXのグローバルIPorホスト名
ifはインターフェースの通信量表示、1～3番はLAN1～3でLAN2を使っていないので1と3、4番はBRIで未使用、5番からがPPで今回はPP01と02を監視、35番はRAS用のPP Anonymous、91番からがTUNNELで今回は01～03の対地を監視。
後は、CPUとMEMを取得するプラグインをこちらのサイトから拝借して入れる ※念のためコピーを置いておく CPU MEM
cat > /etc/munin/plugins/snmp_hoge.piyo.tld_cpu
chmod 777 /etc/munin/plugins/snmp_hoge.piyo.tld_cpu
cat > /etc/munin/plugins/snmp_hoge.piyo.tld_mem
chmod 777 /etc/munin/plugins/snmp_hoge.piyo.tld_mem
そして、SNMP設定を設定ファイルに記述
vim /etc/munin/plugin-conf.d/munin-node
[snmp_hoge.piyo.tld*]
env.version 1
env.community public
env.host hoge.piyo.tld
出来たらmunin-nodeを再起動
/etc/init.d/munin-node restart
このままではmunin-nodeが値を取ってきているけど表画面には出てこないので、表側の設定も追加
vim /etc/munin/munin.conf
[hoge.piyo.tld]
address 127.0.0.1
use_node_name no
※addressはmunin-nodeのアドレスなので、ローカル動作なら127.0.0.1。
直ちに更新してみる場合は
sudo -u munin /usr/bin/munin-cron
これで、muninのトップにhoge.piyo.tldのページが追加されていて、各インターフェースの通信量とCPU・メモリ状況が出るようになる。
(483)
JVN
