Nginxでproxy_passにホスト名を書いた時の名前解決のタイミング - （ひ）メモ
Nginx 1.4.2で試しました。 ネームサーバーは、ローカルのunboundをlocal-zone, local-dataを使って簡易コンテンツサーバーにして試しました。 local-zone: "oreno." static local-data: "api.oreno. 30 IN A 192.0.2.11" # local-data: "api.oreno. 30 IN A 192.0.2.12" proxy_passにホスト名を書くと→名前解決は一度だけ このように Nginx の設定を書いた場合、 location /api { proxy_pass http://api.oreno:9999; } 「api.oreno」の名前解決は、nginxの起動時に行われます 名前解決できない場合は、nginxは起動しません 名前解決できた場合は、ずっとそのIPアドレスにreverse
シェルスクリプトでハマった件→【募】ステキな回避方法 - （ひ）メモ
追記: 解答編を下の方に書きました！！！ 追記: お題に不備があったので変更しました＞＜ あとgistに一式置いたので簡単にテストできます！！ https://gist.github.com/hirose31/6232206 git clone https://gist.github.com/6232206.git oreno cd oreno ./test.sh source_me.sh ... シェルは GNU bash, version 4.1.5(1)-release です。 こんな source_me.sh と、 case $PATH in */oreno/bin*) : # do nothing ;; *) . orenorc LOADED_ORENO=1; export LOADED_ORENO ;; esac orenorc ってファイルがあって、 ORENO_HOME="
combinedに代わるオレ流ログフォーマット - （ひ）メモ
こんにちは、combinedログ撲滅委員会のひろせです。 ApacheのcombinedやNginxのデフォルトのlog_formatは、機械処理(日付でのソートやパース)がしづらい上に、人の目にもあまり見やすいフォーマットとはいえないと思っています。 なので自宅のサーバーでは、 日付は ISO8601 にする sortコマンドとかで簡単にそぉーっとソートできるようになる 日付、レスポンスコード、所要時間とか固定長的なフィールドは左に寄せる URLとかUAとか可変長で長いのは右に寄せる リクエスト(%r)も右に寄せた方ががいいような気がしてきた。。。 数値だけだとわかりづらいのでなんとなくわかるようにフィールド名も添える フィールド名を長くするとわかりやすくなる反面、ログサイズが大きくなるので注意 という観点で次のようなログフォーマットにしています、 # Apache LogFormat
慣習を気にせずsyslog-ngの設定をしてみた - （ひ）メモ
たいていのsyslogのデフォルトの設定だと、 同じログが結構な量、複数のファイルに記録されて(IO負荷的、ディスクサイズ的に)無駄だなぁ 日付のフォーマットが機械処理しづらいなぁ ローテートがめんどいなぁ と思ってたので、今つくってる環境では慣習を気にせずに syslog-ng (v2.0.9) の設定をしてみたのでそのメモです。 不要なログは記録しない options { ... mark_freq(0); stats_freq(0); ... } 日付の形式を変える options { ... ts_format(iso); ... }これで、こんなの Dec 19 16:44:20 HOST ...から、こんなの 2008-12-19T14:07:52+09:00 HOST ...に変わります。 facilityごとにわける facilityごとのfilterを作る。 destic
実録MySQLのチューニング 春の陣 - （ひ）メモ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
dstatの万能感がハンパない - （ひ）メモ
サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47
垂れ流されるログのおしりを追いかける - （ひ）メモ
滝のように流れるログは見ていて楽しいのですが、見ているばかりでは仕事にならないので、 https://github.com/hirose31/chase-tail というスクリプトを書きました。 機能はこんな感じで、 ログ中のきわどいキーワードに色をつけて目立たせる HTTPステータスの「50[0-9]」とかMySQLの「Lock wait timeout exceeded」とか 秒間にある一定行数以上ログが流れたら「NOTIFY_FLOOD」と出力する iTerm 2のPreferences→Profiles→AdvancedタブのTriggersにキーワードを登録しておくとGrowlで通知できるので、「NOTIFY_FLOOD」を登録しておけば、いつよりログがビャービャー流れたときにGrowlで知ることができます ちなみに、iTerm以外のアプリがフォアグラウンドでも、chase-ta
memcached(プロトコル)のデータレプリケーション - （ひ）メモ
国内だけでなく国外(なぜか主に中国語)でもまだrepcachedについて言及してるのをちらほら見かけるのですが、repcachedはmemcached 1.2.8ベースですし(memcached 1.4.5に対応してる人もいるようですが)いまならKyoto Tycoon使えばいいんじゃないかと思うのです。 Kyoto Tycoonなら: memcachedプロトコルプラグインを使えば、Kyoto Tycoonがそのままmemcachedの代替になる（memcachedプロトコルを喋るクライアントコードはそのままでよい） Tokyo Tyrantと違ってexpireもOK memcachedの代替が目的なら、速いオンメモリDB(StashDBとか)でOK 非同期レプリケーションもできる ホットスタンバイ側のサーバリソースが無駄に思うなら、keyに応じてmodとかでリクエストするサーバを2台の
Kyoto Tycoonの運用TIPSなどなど - （ひ）メモ
チャオ！みんな、Kyoto Tycoonライフをエンジョイしてるかい！？ 今日はKTライフを満喫してるミーからの運用TIPSアンドソーオンをお届けするＹＯ！ kchashmgrとktremotemgrコマンドの補完 人間の脳活動のピークは22歳の今日このごろ、みなさんいかがおすごし？ もうね、ミーは全然コマンドオプションとか覚えられないからシェル(bash)で補完しまくってるＹＯ！ kchashmgrとktremotemgrだけだしオプション網羅してないし補完ルールもアレだけどオープン＆シェアなマインドとガッツで気になる人はfork & push！ Nagiosで死活監視 ナギオス！みんな使ってるよね？ ミーはcheck_httpでKTのHTTP RPCのechoにアクセスしてデッドオアアライブの監視してる！ define command { command_name check_kyot
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
