クックパッドにおけるサーバ監視と運用の工夫 - クックパッド開発者ブログ
こんにちは。インフラストラクチャー部の加藤(@EugeneK)です。 今回はWebサービスを運用する上で欠かせない、モニタリングをクックパッドでどうしているかという話をします。 死活監視と性能監視 Webサービスを運用している以上、そのサービスを稼働しているサーバがあり、サーバには故障やトラブルが発生します。 また、どれくらいのパフォーマンスが出ているか、リソースをどのくらい消費しているかなどのトレンドを把握することは、成長するサービスを支えていく上で欠かせません。 故障やトラブルにいち早く気づくための仕組みを死活監視と言います。 また、サーバリソースの時系列での推移を知るために、グラフとしてトレンドを可視化する仕組みを性能監視と言います。 ポーリング監視の限界とZabbixのアクティブ監視 クックパッドでは死活監視にNagios、性能監視にMuninを使用してきましたが、サーバ台数の増加
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
Munin プロセスごとのスワップサイズを監視するMuninプラグインを作ってみた - ぱち ブログ
Muninについて今まで書いてきた記事。 Munin ことはじめ Munin インストール Munin 既存のプラグインの導入( 概要編 ） Munin 既存のプラグインの導入( Apacheプラグインの追加編 ） Munin 既存のプラグインの導入( MySQLプラグインの追加編 ） Munin アラート通知機能を試す（ファイル記録、メール通知） 今回は、Muninプラグインの書き方について書いていきます。また、自分も１から勉強しているところなので、１つMuninプラグインを書き上げようと思います。 Muninプラグインは誰でも作れる 『そもそもMuninプラグインは誰にでも作れるの？』 という疑問の答えは、『誰でも作れます！』です。 Muninプラグインはmunin-nodeに対して特定のフォーマットで(RRDの構成に基づく)グラフ情報とリソース値を返すことが出来ればいい
プラスαなサーバ監視
ちわっす！インフラ担当の池田（@mikeda）です。 今日はサーバ監視周りの話です。 まずNaviPlusでは、サーバ監視にNagiosとMuninを使っています。 普通ですね！ 気をつけていることは、ちゃんとサービスも監視する（正常なHTTP応答、応答速度など）ということでしょうか。 まぁこのへんは今日の本題ではないので別の機会に話します。 システム運用してると、こんな情報も見たいなーというのが出てきます。 例えば、今回紹介するのはこんなのです。 障害発生時（例えば昨日のXX時XX分）の全サーバのプロセスリスト 全サーバのリソース使用状況のザックリとしたレポート あのDBでXX時ごろに流れてたクエリはどんなのか 去年のセール時のアクセス数やサーバ負荷の状況が見たい 本番サーバでtmuxを起動しっぱなしの人がいないか こういう既存ツール（うちだとNagios/Munin）にマッチしないもの
MuninとZABBIXで効率的トラブルシューティング
第3回『いまさら聞けない！システム運用・管理のコツ』 ～システム監視ツールバトル2013！～ @zembutsu の発表スライドです。 前半は、これまでのお復習い。後半は、現在の取り組みです。 2013/07/11(木) 19:00 ～ 22:30 http://everevo.com/event/6342 様々な監視ツールがあるなかで、Munin はリソースの変化を識るためのツール。サーバ上のありとあらゆる情報を集めることが出来るので、日常の利用状況の把握や、障害時のトラブルシューティングにも最適です。そこで、Munin を使えばトラブルシューティングがどのように変わるのか、実例とグラフを交えてご紹介します。 おまけ、スライド冒頭は、本当はこんな無駄アニメーションでした。。 （頑張るところが間違ってるだろうと反省しています） http://youtu.be/YNJ-Mn0IOpI
serf-muninを導入してmunin-nodeの監視追加、削除を自動化した - Glide Note
前回の続きでSerfを触ってる。前回のエントリを見て、@zembutsuさんが作ってくれたserf-muninが素晴らしかったので、弊社仕様に若干修正して導入した。 serf-muninでmunin-nodeの監視自動追加/削除 | Pocketstudio.jp log3 Serf-muninが自動生成、削除するファイルは/etc/munin/conf.d/配下で、 既存のmunin環境(/etc/munin/munin.confとか)を壊すことがないと思うので、すぐに試すことが出来ると思う。 導入環境は CentOS 6.4 Serf 0.2.0 munin-2.0.17 で、Serfの起動コマンドや生成されるmuninのconfの関係上、Serf 0.2.0とmunin 2.0以上は必須条件になります。 serf-muninの仕組みの説明 1. web server1がmuninサー
muninサーバのチューニングの考え方 - 元RX-7乗りの適当な日々
色々見ていたら、ちょっと思うところがあったので、tweetしようと書き始めたんだけど、長くなってしまったのでブログに残しておこうと思う。 muninのサーバは、対象ノードが多くなってきたりして、処理が増えてくると、多くのケースでネックになってくるのはCPUとディスクI/Oで、それらの有限なリソースをcronの定期実行が走る5分間隔の間々でいかに効率よくリソースを使うかがmuninサーバのチューニングのポイントだと思っている。 リソースを使いきった＝サーバが重い、という図式が成り立つのであれば、リソースを完全に使い切る時間帯を作らない努力/調節をすれば良いわけです。要件によっては、パフォーマンスを最大限出し切る設定(チューニング)が正とは限らないわけです。 つまり、muninのようにビューを提供していて、(バックグラウンドの処理以外の)その表示自体にもそれなりにリソースを食われる前提だとした
【Munin】rrdcachedでIOを取り戻せ！ | Pocketstudio.jp log3
Munin の監視ノードが増えてくると、ストレージの IO がボトルネックになりがち。Munin によるランダムなファイルの読み書きが主な原因。改善するためには、 rrdcached と Munin を連携する方法が手軽で確実な方法です。Muninサーバの処理が重いなと思ったら、SSD など高速ストレージを導入する前に、まずは rrdcached の導入がおすすめです。 記事内容は、rrdcached のメリット（1台で300ノードまでの監視に対応）と、RHEL5 で導入したときの手順メモ、そして rrdcached の効果を知る為の rrdcached プラグインの導入方法です。 ■rrdcached を何故使うのか？ Munin は収集データを RRD ファイルに格納し、グラフ描画時に再び参照します。このとき、ストレージに対する読み書き(IO)が増えます。 とりわけ、負荷になりがちなの
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
httpingとmuninでWebサーバのレスポンスをグラフ化した - Glide Note
Webサーバのレスポンスの計測をしたくて、Webサーバにはfluentdを導入済みなので、 Fluentd+GrowthForecastでやろうと思ったんですが、 Webサーバは全台muninでモニタリングしてて、muninとGrowthForecastでページが 分かれてしまうと視認性が下がるので、muninでグラフ化することにした。 munin自体はエンジニア以外の人も閲覧して、サーバの状態を判断しているので、 確認するページが複数にまたがるのもちょっと嫌だった。 計測にはzembutsuさんのpluginを利用することに。 導入に際してwarningとcriticalの値を設定出来るようにpull reqを出してmergeもしてもらった。 導入したサーバはCentOS4,CentOS5,CentOS6とSL6。 導入方法 httpingの導入 httpinのrpmは下記にあるので、そ
muninの表示がクソ重くなっていたのを劇的に改善した話 - 元RX-7乗りの適当な日々
某所の"munin"がびっくりするくらい画面表示が重くなっていて、ひょんなことから改善することになった話。 前提条件として、このmuninが動いているサーバは数百台のノード(サーバ)を管理している状態で、muninのバージョンは2.0系でした。 本当は、後学のためにも作ってくれた人に直してもらうべきと思いつつ、あまり悠長なことも言ってられない感じだったので、一人チューニンガソンを敢行。・・・要望があったのでログを残しておきます。(遅くなってごめんなさい) 最初の状態(before) まず、muninのトップページですが、開いてみると、、、 うほっ、19.61秒かかっておりました。これはなかなかのストレスです。 特にHTML部分の出力に19.4秒かかっている。ここをなんとかせねばなるまい。 次に4台分のサーバの各リソースの負荷状況が確認できるページを表示してみると ズラズラと出ております。各
サーバーリソースの監視
サーバーリソース監視の必要性 サーバーへのアクセスが増えてくるとサーバーリソースが不足してきます。サーバーリソースを増強する手段として最も容易に思いつくのがサーバー自体を増強することです。VPSではサーバー増強が容易なので、サーバーリソースが不足してくるとすぐにVPSをもう1契約増やしたくなる気持ちは分からなくもありません。 しかし一口にサーバーリソースと言っても、CPU、メモリ、ディスクI/O、そしてネットワークといったハードウエアリソース要素があります。サーバーリソース全体が不足なように見えて実はメモリが不足しているだけなので、サーバー自体を増強せずともメモリだけ増やしてあげれば済むということは多いです。もしくは不良プログラムがハードウエアリソースを浪費させていたので、むしろプログラムを直した方がよい、ということもよく起こります。 このようにサーバーリソースの各要素を正確に把握できるよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://paperboy-all.github.io/docs/nagios/learning.html
俺の Munin がこんなに軽いわけがない #監視ツール勉強会