※4/6 その後調べた情報などを記事末尾に追記 前提となるニーズ サーバの負荷情報とか、アクセス状況のような KPI を取得・保存し、可視化(参照してグラフ化)したい。 リアルタイム性が要求される。5分以上前のデータしか見れませんみたいなのはお呼びでない。 古いデータはそんなに精度は気にしないけど、ロングスパンで俯瞰して見れたら便利。 最近はビッグデータ環境の時系列データ解析もビジネスではけっこうニーズがありそうだけど、そっちはもう少し要求が多そう。 ここでは考えないことにする。 選択肢になりそうなもの 古きよき RRDtool Elasticsearch + Kibana Graphite + Grafana InfluxDB + Grafana 等 Zabbix 他に、現実的には SaaS に任せるという手段もあるだろうけど、そう言うと話が終わってしまいそうなので、ここでは考えないこと

こんにちは、@key_amb です。ご無沙汰しています。 最近ブログの更新が遅れてまして、なんとなく申し訳ない気持ちになっている今日このごろです。 なんと、2ヶ月も更新してなかったんですね。*1 さて、前回の Gotanda.pm #5 では、テーマ(「高速化」でした)ガン無視の LT をしましたが、今回はちゃんと「障害」というテーマに沿って発表をしました。 障害を防ぎ、サービスを守るために #gotandapm from IKEDA Kiyoshi 時間がかなり余ったようで、もう少しネタを用意しておけばよかったなと思いました。 今回はこれまで仕事上、いろいろと障害やアラートの対応をやってきた中で、自分なりに大事だと思っている考え方をまとめてみました。 で、その中でどういうツールを使っているかなどの紹介をしました。 どちらかといえば概論的な話で、各論にはあまり踏み込んでいないのですが、何か

カーネルの I/O Accounting 機能を利用する Linuxでカーネルのバージョンが 2.6.20 以降であれば、IO Accounting機能を使うとよい。 これが有効になっていれば、プロセス毎のI/O統計情報が /proc/${pid}/io に出力される。 …が、全プロセスについて、これを自前で分析するのは疲れるので、pidstat や dstat のようなツールを使うのが楽。 参考 IO Accounting 機能で I/O 負荷の高いプロセスを特定 :: drk7jp dstatの万能感がハンパない - (ひ)メモ iodump 2.6.19 以前のカーネルではどうすればいいか。 例えば、iodump というツールがある。 これは以前 Maatkit に含まれていた Perl スクリプトである。 使い方としては、以下の通り。 # download iodump wget