タグ

ブックマーク / mikeda.hatenablog.com (7)

  • WEB系各社で使われている監視ツールまとめ - mikedaの日記

    次世代 Web カンファレンスで監視について話すことになったので、ネタとしてWEB系各社で使っている監視ツールを調査中。 うちはこれ使ってるよ!!!ってのがあったら@mikedaにメンションください! Cookpad Zabbix 昔はNagios+muninだけど台数増えて性能的に破綻した ビューはそのままじゃ辛いのでmunin風に表示するのを自作 StatusCake DataDog。サービス系、サーバに紐付かない系の監視に。DashBoard便利 waker。通知用。PagerDuty高い、と言ってryot_a_raiが秒で作ったらしい Kibana imon。独自のリアルタイムなサービス稼働状況表示ツール NewRelic 試し中なもの Real-User Monitoring : JSでbeacon飛ばしてfluentd -> BigQuery。Google SpreadShee

    WEB系各社で使われている監視ツールまとめ - mikedaの日記
  • InnoDBのウォームアップに別サーバでdumpしたib_buffer_poolを使ってみる - mikedaの日記

    MySQLでスレーブを複数台並べている。 負荷増加やサーバ障害で新規スレーブを追加したい。 で、構築したばかりのMySQLスレーブをいきなりサービスに突っ込むとどうなるか。 それなりの規模のサービスであれば、buffer_poolが空っぽのDBだとIOがつまって応答遅延が発生します。 というわけでサービス投入前にbuffer_poolのウォームアップが必要で、方法としてはいくつか考えられます。 クエリを実行して主要テーブルのIndexをロードする 低い振り分け比率でサービスに投入してしばらく待つ tcpdump + (mk|pt)-query-digest等で既存スレーブのクエリを流し込む 基的にサービス投入前の完璧なウォームアップは無理ゲーなので、 普段は主要テーブルのIndexを読み込んでから、低い振り分け比率でサービス投入、ディスクIO見ながら徐々に振り分け比率を上げていく、という

    InnoDBのウォームアップに別サーバでdumpしたib_buffer_poolを使ってみる - mikedaの日記
  • GoogleスプレッドシートからAWSを操作する

    最近、TerraformやCloudFormationみたいに、JSONや独自DSLなどでかっこよくAWSを管理するツールがいろいろ出てきてます。 こういうツールは便利そうだなとは思うんですが、なんかふと、ユーザがホントに求めているものはコレなんだろうか?と思いました。 なんだかんだ言って、一番多く使われているサーバ管理ツールは『Excelサーバ一覧』なのではw? じゃあExcelで同じようなことが出来ればそれが一番いいのでは?と。 というわけで、Excelは手元になくてキツイので、今回はGoogleスプレッドシートでAWSのサーバ構成管理をやってみました。 使い方 事前準備 サンプルのスプレッドシートをコピーする 『ツール』 -> 『スクリプトエディタ』 -> config.gsを編集 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYにAWSのアクセスキーを

    GoogleスプレッドシートからAWSを操作する
  • もにかじ7 & nagiosとmuninをChrome拡張で合体させる - mikedaの日記

    昨日、Monitoring Casual Talks #7に参加してきました。 もにかじは2年ぶりに参加したのでまず感想 2年前はサーバ監視はだいたいZabbixかnagios+muninのどっちかだったけど、今回はDataDog、Mackerel、PagerDutyみたいな外部サービス使ってますって事例が多かった。 そしてPacker+AutoScaling、Docker、ConsolやSensuみたいなものを使って、動的に変化するインフラをどう管理していくかという議論が多かった。 この辺りはみんな絶賛試行錯誤中でぜんぜん話まとまらないんだけど、いろんな技術や考え方がバンバン出てカオスってて面白い。 長いことぜんぜん追えてなかったので、いろいろ話が聞けて良かった。 そして若い人が増えたなー。平均年齢すんごい下がってる。クラウド化と並行してこの傾向も進んでいきそう。 自分はというと、こうい

    もにかじ7 & nagiosとmuninをChrome拡張で合体させる - mikedaの日記
  • 負荷低すぎはもはや障害じゃないのか - mikedaの日記

    前のブログの続きで、もにかじ7で話した小ネタその2。 実際にサービスでなんかやったというのじゃなく、こういうこと考えてるんだけどみんなどうしてます?って話です。 まずオンプレ時代はサーバのスペックダウンはけっこう大変だったし、頑張ってメモリやCPU引っこ抜いてもそんなに節約にならなかった。 ※CPUやメモリはサーバ価格の一部でしかないし、ラック費用(消費電力)もあるし。 でもクラウド前提だとスペックダウンはとても簡単で、スペック半分にすると価格も半分になる。 そうすると、 『イベントで一時的にc4.4xlarge(8万/月)にして、そのまま最大CPU使用率10%とかで数ヶ月放置されている』 みたいなのはビジネス的な損失という意味で明らかに障害で、監視すべきじゃないだろうか? みんななんかやってますか? というようなことを参加者に聞いてみました。 参加者の中では、AutoScalingしてい

    負荷低すぎはもはや障害じゃないのか - mikedaの日記
  • インフラコストを削減する その1 - mikedaの日記

    過去2回ほど、20%~30%程度のサーバ削減をやったことがあって、 その時のメモが出てきたので、考え方とかやったことをザックリまとめてみる。 まず例えば、不要なサーバを削減してインフラコストを月額10万円減らしたらどうなるか。 これは運用コストも解約リスクも無い、恒久的な利益になる。 裏返すと以前は恒久的な損失が発生していたということなんだけど、情報をまとめないとだれも気づかない。 なのでどこまでやるかは状況次第だけど、情報をまとめることは最低限必須だと思う。 ということで、『効率化する』、『安く買う』についてはまた次回にして、 今回は『情報をまとめる』、『ポリシーを決める』、『適切なサーバ台数を維持する』ことについて。 基的にオンプレ環境を前提として考えます。 情報をまとめる まずは最初に言ったように、必要な情報をまとめる。 そしてだれでも見れるようにする。 これをしないと自分が思いつ

    インフラコストを削減する その1 - mikedaの日記
  • innotopでMySQL状態をtop風に表示(グループ単位で!) - mikedaの日記

    innotopMySQLの状態をtop風に表示するコマンドです。 DBを1台ずつ見ていくぶんには特に使う必要性を感じなかったのですが、 サーバのグルーピング&一括表示機能があることを知ってこれはけっこう便利なのでは?と思いなおしたので インストールからグループ設定までについて書いてみます。 サンプルイメージ グループ単位でクエリーリストを表示 グループ単位でレプリケーション状態を表示 インストール ここからダウンロードしてインストールします。 ※今回使ったのはinnotop1.8 & CentOS5.Xです。 依存モジュールのインストール # yum install perl-DBI perl-DBD-mysql # rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.r

    innotopでMySQL状態をtop風に表示(グループ単位で!) - mikedaの日記
  • 1