check_mysql_queryで範囲指定 - InnoDBの空き容量を監視する - （ひ）メモ
なぎおす！ な！なんとなく〜 ぎ！ギャグでごまかそうと〜 お！おっさんどもが〜 す！すべってゆく〜 ハイ！ガショー！！ Nagios (nagios-plugins) にcheck_mysql_queryというのがあります。 http://nagiosplugins.org/man/check_mysql_query MySQLに任意のクエリを発行して、その結果を元に監視の可否をするプラグインです。 「SELECT 1」とかを発行して期待した応答が返ってくるかとか死活監視に使えますが、結果が数値の場合、範囲内/外にあるかどうかの監視もできます。 例えば、(innodb_file_per_tableしていない場合の)InnoDBの空き容量を調べる設定はこんな感じになります。 前提: "infra"というデータベースに、InnoDBの"health"というテーブルがある MySQLのユーザー"
Tracで、昨日クローズされたチケットの一覧をみたい - （ひ）メモ
修正後の動作確認のためとかに。 チケット見る→レポートの登録の、レポートのクエリに: select id as ticket, summary, changetime as modified ,milestone , owner as __group__ from ticket where status = 'closed' and changetime > strftime('%s','now','-$WITHIN day') order by owner desc, changetime descと入力して保存して、/report/13?WITHIN=1 とかにアクセスすればOK ご察しの通り、?WITHIN=3 とすればここ3日以内にcloseされたチケットの一覧が見られるでやんす。
フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - （ひ）メモ
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
MySQLのスロークエリログを別サーバに転送する - （ひ）メモ
複数台あるMySQLのスロークエリログを、いちいちDBサーバにログインして読むのがめんどうくさい log_output = FILE,TABLE としてテーブルに入れてリモートからSELECTできるようにするのは？ → テーブルに入れた場合、query timeとlock timeの型がTIME型になり精度が秒になってしまうのでダメ ファイルに出力したものをログサーバーにどうにかして飛ばす 10分おきとかにscpする →これでできるのはわかるけど、他にいい方法ないかなぁ syslogで飛ばすのはどうか (id:stanaka++) →srd!! スロークエリログに限らず、追記されるファイル全般に適用できると思います。 rsyslogの方がいけてるそうですが、自分が使ってるのは syslog-ng 2.0.9 なのでそ の設定例です。 DBサーバ # follow_freq(180) で 3
奥様に耳より情報！ Go DaddyでSSL証明書を買う前に必見！！ - （ひ）メモ
2010-11-11追記 いつの間にか$49.99/yearになってたんですが、 http://www.godaddy.com/Compare/gdcompare_ssl.aspx?isc=sslqasia1 を踏んで購入すると$12.99になる模様。 Go Daddy は、SSLサーバ証明書が安いです。 1年間有効のもので、たったの$29.99です。 これでもやすーいなんですが、promo codeを入れるともっとお買い求めしやすくなります！ 新規に証明書を購入する場合は、 GoDaddy Coupons – April 2010 - Promo-Code.net の「promossl」のリンクを踏んで Go Daddy のサイトにとんで、そこでカートに証明書を入れます。 これだけで、$29.99の証明書がなんと$12.99 (56.7%オフ)になります！ 新規じゃなくて更新する場合は、
IPアドレスブロックを集中管理する方法と、その活用法 - （ひ）メモ
やりたいこと 携帯3キャリアのIPアドレスブロックは比較的頻繁に変わるので自動更新したい 自宅やオフィスその他のIPアドレスは、変わることがあまりないので手動管理でいい これらIPアドレスブロックの情報は、後述する通りいろいろなところで使いたい 即ち、いろいろな形式で表現したい このように、頻度の差こそあれ、IPアドレスブロックは増減したり新しいブロックが追加したりするので、簡素な機構で包括的な管理をしたい。 実現方法 スクリプトを2つ書きました。いずれもgithubにあります。 http://github.com/hirose31/cidr-manager 図も用意しました。 update-mobilejp-cidr キャリアのサイトをスクレイピングして、指定されたディレクトリにその情報を書き出します。 その形式は、1行1アドレスブロック、コメントは "#" です。 $ cat plai
「Apache で特定の URL のみ Basic 認証を外す方法」に関連して - （ひ）メモ
Apache で特定の URL のみ Basic 認証を外す方法 を見て、env使ってBASIC認証バイパスしたりしてるなぁと思ったので晒してみます: <Location /> Satisfy Any Order Deny,Allow Deny from all Allow from env=trusted Allow from env=my_ktai AuthType Basic AuthName "HIMITSU" AuthUserFile /usr/irori/contents/example.com/htpasswd Require valid-user </Location>envに値をセットするのはSetEnvIfを使っていかようにも。 SetEnvIf User-Agent "^HIMITSU_Browser" trusted=1 SetEnvIf Request_URI "
synergyで、キーボードだけでスクリーンを移動する - (ひ)メモ
複数の PC を手元で操作 「Synergy」を使おう! -Win&Mac 混合対応版- - livedoor ディレクターブログ を読んで思い出したので。 通常、スクリーン間の移動はマウスポインタの移動によって行うのですが、switchToScreen(SCREEN_NAME) を使えばキーボード操作でもスクリーンの移動ができます。 「fvwm2で、ポインタ移動はマウスじゃなくてキーボード(Shift+Meta+矢印とか)で操作してます(ｷﾘｯ」とかいう生粋のキーボーダーでなくても、多面スクリーンだとカレントスクリーンを見失うことがよくあると思うので、「このキーを押せばこのマシンがカレントスクリーンになる」ってのは便利なんじゃないかと思います。 自分は Linux にキーボード/マウスを繋いでいるのですが、~/.synergy.conf はこんな感じで。 カレントスクリーンがどこであって
kumofsの死活監視はこんな感じでNagiosでやってます - （ひ）メモ
分散Key-Valueストア「kumofs」を公開しました！ - 古橋貞之の日記 ＼(＾o＾)／ kumofsは、弊社のフォトストレージサービス Ficia で現在大絶賛モリモリ稼働中なんですが、その死活監視は自家製の Nagios プラグインで行っています。 というわけで、kumofsをサービスで使いたい人の一助になればと思い、ぼくが実際に行っている kumofs の監視について紹介したいと思います。 サーバノードとマネージャノード サーバノードとマネージャノードの監視には、それぞれのノードに対してステータスを問い合わせるコマンドを発行して、その応答で死活を判断するスクリプトを書いて使っています。 kumofs公開記念ということでgithubにpushっておきました。 http://github.com/etolabo/nagios-check_kumofs 問い合わせの処理は、管理用コ
リモートのマシンで、iptablesでなんかいじる前に保険をかけておく - （ひ）メモ
#!/bin/sh # 保険をかける # echo '/root/clear-iptab' | at now + 3min # とか # echo '/root/clear-iptab' | at 13:00 # で。 # # そしたら iptables でなんかいじって、 # iptables ... (as you like) # 成功したら at の job を削除しておわり。 # atq # atrm N # 失敗したら正座して祈る。 iptables -F iptables -X iptables -Z iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -P FORWARD ACCEPT 追記: 2010-01-09 http://ya.maya.st/d/201001a.html#s20100107_1 で言
daemontoolsのrunファイルで、exec COMMANDじゃなくてshを介してexec sh -c 'exec COMMAND'する理由 - （ひ）メモ
だいぶ昔になんでかなーなんでだろーなーと思ったこと: dnscache-confで作ったrunファイルが、 #!/bin/sh exec 2>&1 exec <seed exec envdir ./env \ envuidgid dnscache softlimit -o250 -d "$DATALIMIT" /usr/local/bin/dnscache じゃなくて、こんなふうに、 #!/bin/sh exec 2>&1 exec <seed exec envdir ./env sh -c ' exec envuidgid dnscache softlimit -o250 -d "$DATALIMIT" /usr/local/bin/dnscache ' わざわざshをexecして、そのshのなかでお目当てのプログラムを起動してたこと。 で、今日、某IRCチャンネルみてて気がついたんです
Nagiosのcheck_snmpで警告レベル(WARNING, CRITICAL)別に通知先を変えたい - （ひ）メモ
やりたいこと 警告レベル (WARNING か CRITICAL) によって、通知先を切り替えたい。 WARNING は PC メールと IRC に CRITICAL は 携帯メールと PC メールと IRC に 外部ホストの監視は NRPE じゃなくて SNMP (check_snmp) を使っている。 通知先の切り替え なぜか warn と crit で contactgroup を別々にせねばという思い込みがあり、単一のservice定義では実現できなさそうと思ってたんですが、ひとつのcontactgroupに、service_notification_optionsがwのとcのcontactを入れとけば OK ですね。(thanks: @toshiak_netmark) unknownとcriticalは携帯＋PC＋IRCに、それ以外はPC＋IRCに通知するようなcontact,
く、くやしい・・・foregroundで起動できるなんて・・・ビ - （ひ）メモ
2009-12-15 追記 nginxのオプションが間違ってたので修正＞＜ × -g daemon=off ○ -g "daemon off;" 2009-12-16 追記 Apacheのrunファイルにpgrphackと補足文を追加。 daemontoolsのrunファイル。 Apache #!/bin/sh exec 2>&1 CONF=/usr/irori/etc/apache/httpd.conf DAEMON=/usr/local/app/apache/bin/httpd DAEMON_ARGS="-f $CONF -DNO_DETACH -DFOREGROUND" if [ ! -x "$DAEMON" ]; then echo "not executable: $DAEMON" exit 1 fi if ! $DAEMON $DAEMON_ARGS -t; then echo
実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - （ひ）メモ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
YAPC::Asia 2009 movie list - （ひ）メモ
2009-09-09 Pre-YAPC mini conference with Yokohama.pm on 2009-09-09 2009-09-10 Program on 2009-09-10 Six Apart Auditorium on 2009-09-10 DeNA Conference Room on 2009-09-10 West 5 Room on 2009-09-10 2009-09-11 Program on 2009-09-11 Six Apart Auditorium on 2009-09-11 DeNA Conference Room on 2009-09-11 West 5 Room on 2009-09-11 memo list of URL and title: http://gist.github.com/226000
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
keepalived.confのシンタックスチェックツール「keepalived-check」「haskell-keepalived 」が凄い！ - （ひ）メモ
id:viverさんとid:maoeさんが(7月ぐらいに)やってくれてました。 http://github.com/frsyuki/keepalived-check http://github.com/maoe/haskell-keepalived ずいぶん前からkeepalived.confのシンタックスチェックをするプログラムないかなーと思ってました。個人的にはバックアップ側のkeepalivedにまず反映して問題がないならマスタにも反映する、という運用手順をとっていますが、はやりsyntax checkerがあるのとないのとでは安心感が大違いです。 また、構築フェーズでは、keepalived.confをあれやこれやといじり試行錯誤するわけですが、confの書式が間違っていてもkeepalivedは警告も出さずスッコリなかったものとして知らん顔で起動するので、「設定してるはずの通りに
安全に一気にファイルの内容を書き換える - （ひ）メモ
ファイルを書き換えるときに、単純に open, write, close だと、そのファイルの性格にもよりますが、問題になるケースがあります。 書き込み処理中に異常終了しちゃった 例えば open my $fh, '>', '/foo/bar'; print $fh gen_header(); print $fh gen_section_1(); print $fh gen_section_2(); # ← die print $fh "# EOF\n"; close $fh な処理で、get_section_2 が異常終了してしまうと、その後書き込まれるはずのものが書き込まれずファイルの内容が中途半端になってしまいます。(まぁでもこのケースはエラー処理をちゃんとやれば回避できますね) 書いている途中で読まれちゃった サーバ名一覧のような定義ファイルや、毎回読まれるタイプの設定ファイルの場
YAPC::Asia 2009で「『Ficia』インフラとPerlにまつわるエトセトラ」というタイトルでしゃべってきました - （ひ）メモ
YAPC::Asia 2009 第一日目で「『Ficia』インフラとPerlにまつわるエトセトラ」というタイトルでしゃべってきましたのでその資料を公開します。 『Ficia』インフラとPerlにまつわるエトセトラView more documents from Masaaki HIROSE. 他の方のスライドも http://www.slideshare.net/event/yapcasia-2009 から参照できるようでっす。 以下、今回のトークの内容で参考にさせてもらったURLのリストです。 Linux のプロセスが Copy on Write で共有しているメモリのサイズを調べる - naoyaのはてなダイアリー http://d.hatena.ne.jp/naoya/20080212/1202830671 mod_perl における C10K Problem, 竹迫 良範 http
keepalived と 当ててるパッチたち - （ひ）メモ
今使ってるのは 1.1.17 、その前に使ってたのは 1.1.15 す。 keepalived 1.1.19 1.1.19ではpidfileとnopreemptパッチは取り込まれているので、 keepalived-1.1.13-extcheck-1.0.patch だけ当てています。 keepalived 1.1.17 keepalived-1.1.13-extcheck-1.0.patch DSASさんところのヘルスチェック拡張パッチです。ふふ。DNS_CHECKとSSL_HELLOを使ってます。 ちなみに、このパッチを当てないで DNS_CHECK とか SSL_HELLO を使うと、keepalived.confにreal_serverを複数書いているにも関わらず、ipvs的には1つしか有効にならないという不思議状態になりますので、バージョンアップのときとかにはパッチ当て忘れないよう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
