タグ

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

  • 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の日記
  • 負荷低すぎはもはや障害じゃないのか - mikedaの日記

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

    負荷低すぎはもはや障害じゃないのか - mikedaの日記
  • サーバの電源って冗長化してますか? - mikedaの日記

    実は自分はあんましてないです。 理由について書くと。。。 例えばこんなラック、サーバが前提で、 電源コンセントは2系統で、それぞれ25A(100V, 2.5kva)でブレーカ落ちる サーバは平均2A(100V, 0.2kva)の電力を消費する 片系20Aで合計40Aまで使うとして、サーバは20台突っ込みたい、と思ったとする。 最初はこうしてたんですが、 これだと片系電源に障害があった時とか、ミスってブレーカ落とした時、 もう片系に40Aの全電力がかかって共倒れして、全サーバが停止してしまう。 でもサーバ搭載数を半分にするのはお金的にムリ過ぎる。 ※DCと調整して片系50kvaまで使える2系統にしてもらって、実効電力ベースの契約にするとか、いろいろ手はありそうだけど。 というわけで、 こっちのほうがまだマシか、と次はこうしました。 これだと片系落ちても半分のサーバは生き残るので、サービスは維

    サーバの電源って冗長化してますか? - mikedaの日記
    yogasa
    yogasa 2015/01/17
    片方落としたら全断するの,冗長化されてないし設計がアホなだけでは……
  • インフラコストを削減する その1 - mikedaの日記

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

    インフラコストを削減する その1 - mikedaの日記
  • 歳は気にするな。という自戒 - mikedaの日記

    自分はLinuxは社会人になった26歳(新卒研修中に27歳になってたけど)から、WEB系技術は最初の転職の29歳から、と全体的にスタートが遅かった。 ※ちなみにプログラムは大学院の24歳から。CとC++とVBを少々。 なのでずっと、歳相応の能力がない点についてそれを言い訳的に使うことが多かったし、 個人に関する何かの決断について、もうけっこういい歳だしなぁみたいなことを考えることも多かった。 ※この業界はすんごく若くて優秀なやつがいっぱいいるからね! まぁでも、 CAのoranieさんは26歳までアパレル店員だったし、 ペパボだと四天王の黒田さんは30歳まで郵便局員で、 技術責任者のあんちぽさんは32歳まで役場職員だった。 うろ覚えだけど。 少なくともWEB系のエンジニアとしてなら何をするにせよ、ビジネス的な成果を出すために最低限必要なスキルを身につけることに関して、そんなに長大な時間を要

    歳は気にするな。という自戒 - mikedaの日記
    yogasa
    yogasa 2015/01/11
  • サーバのリソース使用状況レポートを作る - mikedaの日記

    数百台のサーバに対して CPU メモリ HDD の使用状況をサクッとチェックしたいなーと思ったのですが、さすがにmuninのグラフで見るのはダルすぎる。 というわけで日次でこういうページを作ってチェックするようにしました。 上記の情報が数字でダーっと並んでて、ついでに簡単に色付けとか、muninへのリンク張りとか、各項目でのソート機能付けたりとかをやってます。 CPUとメモリの使用率は前日の平均、ディスク使用率はバッチ実行時の値です。 最初はmuninのRRDファイルから作ろうかと思ったのですが(gist)、この程度の情報ならsysstatやdfの結果から作るほうが簡単なので、sshで集めてくることにしました。 とりあえずHTMLに出力してますが、CSVで出したりDBに突っ込んだりすれば各種調査に便利ですよ! ソースコード Ruby1.9版です #!/usr/local/bin/ruby

    サーバのリソース使用状況レポートを作る - mikedaの日記
  • twilogからリア充度グラフを作る - mikedaの日記

    先日、友人結婚パーティでLTをすることになり、 『リア充化(奥さんと付き合い始めた)前後で、その友人Twitterのツイートにどのような変化があったか』 について語って来ました。 メインはこの2つのグラフでした。 Tweet数の推移 リア充度の推移 ※ちょっと茶化し過ぎたかと反省したので名前はふせます(´・ω・`) 今回はこのグラフ(主に下側)をどうやって作ったかについて、簡単に説明します。 リア充度について 元ネタは@namikawaさんのブログエントリ、 『俺流、リア充・ネト充の見分け方』 です。 詳細は上記ブログを見てもらうとして、ポイントはここで提唱されている、 『リア充ほど休日のtweet率が低くなる』(リア充は休日はリア充活動が忙しくてTwitterなんてやってられん) という理論です。 これもとに、『リア充度=平日ツイートの割合』と定義すると リア充(@namikawaさ

    twilogからリア充度グラフを作る - mikedaの日記
  • inotify-toolsでファイルの更新を監視 - mikedaの日記

    Linuxでファイル更新の監視というと、inotifyという機能を使います。 実際はPHPPerlのラッパーライブラリを使うことが多くて、コレがけっこうめんどくさかったのですが、 inotify-toolsというCLIツールがあることに最近気が付きました。 『特定ディレクトリ下の更新ファイル名をリアルタイム出力する』、などがとても簡単にできます。 inotifywait -m -e modify --format %w%f -r /tmp動作や発行されるイベントは事前に確認しましょう。↑はファイルのmoveなどは拾えません。 inotifywait -m -r /tmp/js/ 例えば『JavaScriptの更新を監視し、自動でYUI-Compresserで圧縮する』、ならこんな感じでできそうです。 簡単ですね! daemontools等でデーモン化しちゃいましょう。 RedHat系なら

    inotify-toolsでファイルの更新を監視 - mikedaの日記
    yogasa
    yogasa 2012/08/06
  • 1