知っている人には当たり前、けど本業じゃないし開発１年生なのでそんな知りません的な人には
有用かなと思い書いてみます。
思いつきで書いていくので読みづらかったらすいません。
後、しょうもない内容もあるのであまり為にならないかもしれません。
#サーバ監視って？
まず、サーバ監視っていっても定常的な監視を人がやることはほぼありません。
基本はZabbixなどで監視を仕掛けて検知したアラートを電話なりメールで受け取ります。
それを人が見て、
###やばいかも？
###出ちゃいけないエラーが出てる!
などと冷や汗をかいた経験はあると思います。
そんな中でも比較的厄介（アプリの不具合も十分厄介ですが）なのが
###負荷すごい高いんだけど？？サーバが瀕死？？
という状態です。
そんなときインフラ屋さんへ頼るのが正解ですが、
インフラ屋さんは全部のサービス、システムの仕様、アクセスのされ方、
機能を理解していないケースの方が多い（主観）と思うのと、
場合によってはもう帰っちゃいました、電話つながりません、
という時もあると思います。
そんなとき本番へアクセスできる開発者（いいかどうかは別として）が
出来ることをちょっとだけ書きます。
#なんかした人がいないか確認する
初歩的ながら割と重要で、役割分担が難しい会社であれば（じゃなくても）必然的に
いつか起きることですが、なんかやっちゃった人がいる可能性があります。
何度かやっちゃった会社なら全体に周知するよう通達が出ていることでしょう。
#サーバへログインできない（SSH接続すら出来ないとき）
書くまでもありません、データセンターへGO!です。
てのは言い過ぎですが、LB、FWの問題でなければサーバをなんとかするしかありません。
AWSを使っていれば追加でインスタンスを立てるなどの方法があります。
状況が許せばオンプレミスでの管理はなるべく避けるべきです。
※会社の体力があって人員が整っていればその限りではありません。
#サーバへログイン出来た！なんか重い
まず、ここで重要なのは
###ネットワークが重いのかDBが重いのかサーバのリソース不足なのかの切り分けです。
topコマンドなどは比較的知っている方も多いと思いますが、
こんなコマンドがあります。
###mpstat
もしコマンドが叩けない場合は、インフラ屋さんへ文句を言ってもいいレベルです。
※ yum install sysstat とか叩けば入ったりしますが。
使い方、見方はこんな感じです。
$ mpstat -P ALL 1
Linux 3.2.22-35.60.amzn1.x86_64 (xxx) 2013年11月08日 _x86_64_ (2 CPU)
00時51分11秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
00時51分12秒 all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00時51分12秒 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
00時51分12秒 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
ぶっちゃけ見るべきは
###%usrと%iowait%idleだけだったりします。
※一応誤解がないようにいうと、殆どの場合は、CPU、DISK I/O、DB、ネットワークが問題になる為、
CPUの割り込み回数などで問題になるケースはまれです。
そこまで追うのであれば素直にインフラ屋さんへ押し付けるべきです。（怒られそうだけど）
ただし、あーもしかしたらあの処理かなってことがあれば素直に相談してください。
一応見方も書いておくと、
- CPU：マルチコアの場合でもコア毎の使用率が全て出てきます。
- %usr：userプロセスのCPU使用率です。簡単に言うとミドルウェアやアプリケーションの使用率です。
- %iowait：ディスクへの書き込み待ちによるCPUの処理待ちです。
- %idle：CPUの待機率です。100%ってことは仕事がない状態です。
※仮想マシンを利用していると、%stealや%guestも変わることがあります。
これは左から、仮想マシン（複数運用）からのCPU割当率、%idleの代わりになったりします。
ここまででCPU使用率だったりtopコマンドで見たloadaverageが高ければ
ほぼアプリケーションだったりDISKアクセスの問題となります。
※ちなみに、topコマンドで見た方がいいですが、uptimeコマンドでも見れたりします。
- loadaverageが高くてiowaitが高ければほぼDISK（DBや書き込みが多い）アクセスの問題、
- loadaverageが高くiowaitが低くidleが低ければほぼアプリケーション、ミドルウェアの問題です。
- loadaverageが低くても、CPUが高ければアプリケーション、ミドルウェアの問題です。
※まれにNFSでbig kernel lock などでアプリが高負荷状態に見える場合があります。
ps -aux | grep <プロセス名>
だったりtopコマンドでどのプロセスの負荷が高いか見てください。
apacheだったりしたらアプリの可能性もあります。
というか、ちゃんとapacheの設定が出来ていて、急にアクセスの多くなるサービスでなければ
ほぼアプリの問題です。
謝る心構えが必要です。
Tips：コマンドとしては、vmstat , dstat , iostat など目的に応じて様々なコマンドがあります。
ここまでで問題なければ次は
#Database
すいません、長くなるのでここはいつか書きます。
事例だけあげると、
###重いクエリが走っていてロックが発生していたり、
###最大同時接続数に達していたり、、
###接続失敗が続いてDBにアクセスを拒否されていたり、、、
一度は通る道ですので言わずもがなかもしれません。
DBつながんないなーって状態であれば、上記のいずれかの可能性が高いので
即刻インフラ屋さんへ連絡です。
次は
#ネットワーク
ちなみに、SSHで接続した時に重くなければNW構成にもよりますが、
全体が遅延している可能性は低いです。
sar -n DEV コマンドで情報は見れますが、多分見てもよくわからないし
一開発者では対処の仕様もないので割愛です。素直にインフラ屋さんへ相談です。
あとは、
#Memory
ですが、
$ free -m
total used free shared buffers cached
Mem: 7455 6480 975 0 116 4933
-/+ buffers/cache: 1430 6025
Swap: 10239 35 10204
でSwapのusedがひどい状態（この例では35MB swap落ちしています。。。）
でなければ、問題ありません。
ひどい状態というのは、何百MBも落ちちゃっている場合です。
DBのチューニングやミドルウェアのチューニングが適当になっていなければ
殆ど発生しません。
#最後
かなりざっくりした内容ですが、サーバ監視についての雰囲気を少しでも感じてもらえたら幸いです。
出来れば見た内容をインフラ屋さんへ整理して伝えられるとなお良いです。
後、一番重要なことを書き忘れましたが、
###ちょっと知ってるからってDBいじったりプログラムを直接書き換えたり勝手に再起動をしないこと
です。
トラブル発生時にありがちなのが、２次災害です。
しかも人的な。
システムが落ちる程度ならまだしも、データアクセスが思いからってデータを消そうとして
間違ってテーブル毎消しちゃったり、point time リカバリなど勝手にやろうとして
失敗して戻しようがなくなったり、などは極稀だと思いますが、余計にやらなければ
ならないことが増えたりします。
落ちてもちゃんと管理者と連絡をとって対処をしましょう。
本当にあせる必要があるのか今一度踏みとどまって考えてください。
インフラ屋さんへ電話が繋がらないのはあなたのせいではありません。
それでもやらなければならない事情があればその時はしょうがないんだと思います。
今回はこれで終わりですが、次は真面目にDBチューンング周りだったり、
スタックトレースの解析だったりも
気が向いたら書き記したいと思います。（忘れてきてるので残したいってのもあります）