ログ解析で楽をする話 #qpstudy でしてきました。
ログ解析というのはインフラエンジニアの基礎の基礎です。アプリケーションが定まればそれなりのログ解析ツールは存在します。Debianのstableですら数十のツールがあります。 とはいえ、実際のログというのは往々にしてアプリケーション毎に全然ちがっているのでツールは役に立ちません。結果としてgrepを駆使したり、はたまたRDBに突っ込んだりして試行錯誤することになります。 見事に解析できたとしても、それを可視化することを考えると楽できることを考えておきたいわけです。 そこで役に立つのはログ解析SaaS．Sumologic, SplunkStorm, Logglyなどけっこうありますが、qpstudyではSumoLogicを紹介してみました。GUIでログを横断的に絞り込めますし、その処理構文はいつでも繰り返すことのできるすぐれものです。 無料で使えるサイズでかなりのことができますので、ちょっと
cdn.debian.net と ftp.jp.debian.org の動作に問題があればgithubにおねがいします。
cdn.debian.net と ftp.jp.debian.org の動作に問題があればgithubにおねがいします。 Debianにおけるパッケージ流通はaptが基本的なものになっている。いまどき完全なスタンドアローンで動作しているような例もすくないので、なにかしらaptの御世話になっていることは多いかと思う。 昔のaptの実装ではhttp redirectができないので、http redirectに頼らない誘導方法になっている（現在のaptの実装ではhttp redirectができるので、http.debian.netというサービスが誕生している）。 check_serverの実装自体はRails3.2です。 動作チェック、文句、要望について チェックサーバの動作は http://cdncheck1.araki.net/view/index で確認できます。 https://gith
自分のEvernoteの使い方の変遷
自分は普段Evernoteを使っていていろんなことをメモっている。 ただし、使い方は結構この１年でかなり変わってきていることに気が付き、使い方の変わり方をみてみた。 2009年10月にEvernoteをつかいはじめる。このころはD論真っ最中なこともあってほとんどメモらしきメモはない。 2010年3月、D論がおわってちょっと旅行に行こうかとおもって活用がはじまる。 はじめてWebのClipをした。ゲンダイの記事。 初めてタグをつかいはじめる はじめて画像をクリップした 7月、作業をメモりだす。 2011年3月。地震発生。そのまま在宅作業祭り開始。この日を境に仕事のことをメモりだす。 3月14日はじめてSkypeのChatを保存しておくために、そのまま貼る 4月。他人の名刺を初めてEvernoteに。 5月。Twitter->Evernoteの設定をする。 6月。OutlookからEverno
なぜVPCなのか: それは説明が楽だから。
VPC上でサービスを作成することは、Eコマースサイトにおいて必ずしも必要なことではない。その一方で、VPCでなければ満たせない各種の基準を満たすため、各種のサービスを使うために、VPC上にサービスを作成することはおおきなメリット。 「基準を満たすため」の典型的な例は、国際ペイメント業者5社が共同で作成したクレジット業界におけるグローバスセキュリティ基準であるPCIDSS(Payment Card Industry Data Security Standard)の取得。PCIDSSは情報セキュリティに対する具体的な実装や施策を要求しており、クレジットカード情報と全く関係ない企業や組織ですらPCIDSSを基準とした情報安全対策を求められることが増えています。 その中には、”Build and maintain a secure network” なる条項があり、VPCはinboundだけではな
S3のエラーハンドリングPerl編
S3は作ったばかりのバケットを扱おうとすると、307 redirectを返すことがある。他にも http://docs.amazonwebservices.com/AmazonS3/latest/API/ErrorResponses.htmlにあるように多数のエラーレスポンスは定義されている。が、3xx系は扱えないライブラリであるLWPがメインのperlの場合 CPANに登録されているAmazon::S3とNet-Amazon-S3ではこんな対応がされている。(というかここのコメント100%同じ。ライセンス的にはokだからいいんだろう) cpansearch.perl.org/src/TIMA/Amazon-S3-0.45/lib/Amazon/S3.pm http://cpansearch.perl.org/src/PFIG/Net-Amazon-S3-0.56/lib/Net/Amaz
RDSは1秒未満のスロークエリを記録できない。そこでmin_examined_row_limit
1以上のintegerですね。RT @hiroohi: あれ？RDS(mysql)のParameterGroupって、long_query_timeは1秒以上しか設定できない？ #jawsug — ARAKI Yasuhiroさん (@ar1) 6月 13, 2012 いろんな人に言われることではあるが、RDSは1秒未満のスロークエリを記録できない。 そこで使えるひとつの方法は、 minexaminedrow_limitを使うこと。折角なので超プロのblogから引用。 漢(オトコ)のコンピュータ道: MySQL 5.1のスロークエリログ min_examined_row_limitという変数が追加されたのも見逃せない。この変数を指定すると、「○○○行以上の行をテーブルから読み込んだクエリをスロークエリログに記録する」という指定ができるようになる。多くの行を読み込むクエリは、潜在的にサーバ全
Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。
Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。 鯖管のメモ帳: AWSのELBでHealthyHostCountが0になるという記事の中で ■AWSのELBとApacheを使う際の注意点 ・Timeoutは120以上が推奨 ・ApacheのKeepAliveは有効にすべし。ELBとの接続効率があがる。 という形ですでにやるべきことは書いてあるのが、なぜそうなるか。。(いそがしい人は後は読まなくてok！) 根本的な理由としては、ELBはTCPを単にリレーしているのではなくて、アプリケーションレイヤのプロキシであることによるものが大きい。ELBはバックエンドのEC2との間で無通信の場合でも60秒はセッションを維持する。 ELBはTCP Persistent Connectionを提供し、webサーバとの間のTCP
DevOps Day Tokyo 2012に参加してきた(昨日の話)ので報告と雑感。
昨日DevOps Day (sじゃない)のイベントがセルリアンタワーのGMOであったので参加してきた。 今回は正直誰が何をしゃべるのかもわからなかったので速攻で申しこみだけをしておいた。そうしたら、opscodeもenTRUSTもいるという俺得なイベントでした。積極的に質問もしたら、いろいろ出てきたのがサイコーだった。そんなわけで、いろんな話もできたし、最後に一本締めのときに前に出ることにもなったり、とても楽しい一日でした。講演者の方々、主催、スポンサー、会場のGMOの方々ありがとうございました。 全体の雰囲気は、http://togetter.com/li/310514、隣で取材してた新野さんのpublickeyに出る気がするのでそちらを参照。 以下は自分が体験したこと。 まず、opscodeのGeorge Moberlyさんから、 次のchefバージョンではDry Runがサポートされ
NHNテクノロジーカンファレンスで見たDeNAのMySQL運用の話とAmazon RDSの比較など。
NHNテクノロジーカンファレンスにいってきた。 DeNAでのMySQL運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。 実に実直で正直で手間をかけた運用で、なおかつその手間をなくすためのツールの開発、アプリケーションも一体となったとりくみのすばらしい実例だと思う。 このセッションではAWSならばの話は当然いっさいなかったのだが、AWSのMySQLサービスであるRDSならどうするのかを書いてみる。 サービスが縮小するときの話。スケールバック(スケールイン)時に2つあったマスターDBの数を減らす。その際にはosの上に二つ目のMySQLをたちあげる方法をとっている。二つ目のMySQLは違うIPアドレスで立ちあげて、それをbind-addressを指定している。 RDSを使っているならば、サービスを縮小するならば、大きなインスタンスから、小さなイン
ftp.jp.debian.orgが半日止まっていた件
こんばんは。cdn.debian.net、ftp.jp.debian.orgなどの管理をしている荒木です。 本日未明から14:06まで上記Debianミラーサーバへの到達性が著しく低下する事故が発生しました。 100%ではありませんが、日本からの80%を越えるアクセスについて、到達できない状態が続きました。 本MLに情報をおよせになった、野田様、ご意見ありがとうございます。 おっしゃる通り、「いかがなもの」と感じられたのかと思います。 今回の事は、本来動作しているべき死活監視が意図通り作動しなかったことによるものでした。 死活監視は 1. 死活監視対象情報をキューに蓄積、 2. 死活監視プログラムがキューから取得、死活監視情報をDBにかきこみ、キューから消去 という二つのプログラムで構成されています。 今回の問題は、1は正常動作しているものの、通常2箇所で動作している2のプログラムが停止し
エンジニアが自由に動けるEU
EUはエンジニアがライセンスになって国とか自由にうごけるようになっているらしい。 A new ID card will establish an engineer’s credentials throughout the EU (http://spectrum.ieee.org/at-work/tech-careers/passport-to-engineering ) を見る限り、どうにもドイツが主導でやっているもののようだ。 日本にしろUSにしろAUにしろいろんな国が別個にエンジニアなどに出すビザが違うのはしかたがないけど、外国人からはわかりにくいし、国がそんなに大きくない国だとこういった共通資格があると楽なんだろうなあと思った。 以下、関係したリンクからのメモ． クリックして02500106.pdfにアクセス ドイツで実際はじまるのは4/1らしい。 http://www.jttas.
Elastic Load Balancerをつかってwebsocketを処理する方法
AWSにはElastice Load Balancerというロードバランサがあります。これはとても安いこともあって多くのお客様のwebサービスで使っていただいています。 最近はwebsocketを使いたい!という声もありますが、いくつかの制限により、 ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法がおすすめです。 そもそも問題は、 ELBの場合、HTTPモードだとそもそも同じポートのままではwebsocketに遷移できない。 ELBでTCPモードにした場合でも60秒でタイムアウトする。 の2点が原因です。そのため、2つの方法があります。 解1: ELBは最初のネゴシエーションにだけ使って、ネゴシエーション後のwebsocketにかかわらない方法 C ---------> ELB(HTTPモード) --> S ふつうにHTTPでアクセス。
PVでサーバを見積ることはおすすめしません
「私のサービスは毎月1億PVくらいになりそうなんですけど、どのインスタンスがいいですか?」 こんな質問をときたま受ける。マジレスすると、 1ページあたりの転送量がわからん どれだけのキャッシュをブラウザに効かせるのかわからん そもそもそのページが動的に生成されるとして、その重さがわからん などなどの理由で、ずばっと答えられないので、相手をガッカリさせることがある。 責任のある答えは「試しに作って測定してください。測定して、足りなければ増やせばいいので」というのが私の典型的な回答になる。 もちろん、超ざっくりでいいなら、こんな例えをしてみる。 1ページあたり1MB、ブラウザキャッシュは考慮しないとして、30PV/sec とすると、30MByte/sec == 240Mbit/sec なので余裕もったサーバなら1台あたりはこんなもんじゃないかと。AWSならlargeインスタンスでならなんとかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
easyRoute53: Route53を前提のドメインレジストラ