リソース監視について
今回はサーバー監視について書いていこうと思う。 先輩から教わった基本的なリソースの監視項目はCPU, memory使用率、IOPS、ロードアベレージをとのこと。
CPU使用率
文字通り、CPUがどれだけ使用されているかを監視している。 基本的にtopコマンドで確認ができる。 us + syを合わせたものがCPU使用率になる。 cloudwotchだとよしなに、値を取得してくれている。 現場ではCPUが80%とかでアラート設定している。ただし、CPUが80%だからといってすぐに対応しないといけない訳ではない。実際にはアラート踏んでオートスケール発火しそうだけど。 というのも、この状態にサイトに影響があるかを把握することが大事。レスポンスタイムが低下していないか、スループットに影響していないかを見極めることが大切。 逆に言えば、リソースを上手く使ってくれている状態であるということ。(いつまでも高値に張り付いていたら、さすがに対応必要だけど。) 逆に低すぎるのも、リソースを上手く使ってくれてない証拠。（となるとロードアベレージの値が上昇するのかな？？）
メモリ使用率
文字通りメモリ使用している割合をさす。 上昇の原因としてはGCがうまくいってない。かなり大きい プロセスをヒープに割り当てた。などなど。 こうなっては、カーネルさんはディスクを使ってスワップアウトしちゃいます。 アプリケーションとして高レイテンシーでサイトがカクカク状態になります。 javaなんかは注意が必要だと、先輩はおっしゃってました。GCの影響で上手くメモリを解放できなかったパターンとかよくあると。 直近ではEC2に自前で立てた、elasticsearchがメモリ使用率が高値に張り付いて障害が発生しました。 elasticsearchはjava で動いていてます。
ディスク監視
ディスクの空き容量を監視したり、IOPSを監視したりします。 IOPSとは秒間あたりディスクへの書き込み読み込みがどれくらい行えているかを見る指標になります。IOPSのメトリックスが急に下がり始めたら、ディスクへのアクセスが低下し何らかの問題があると考えられます。
ロードアベレージ
現在のCPUコアに割り当てられていない、待ちプロセス数を表している。(1分の平均、５分平均、１５分平均からなる) 物理コア分の待ちプロセスがあったとしたら、それは全然問題ない。上手くコアに割り当てられている証拠。 １５分平均のロードが500を超えているWebサーバーがサイトには影響がないパターンもあるらしい。なので、サイトに影響があるかをアセスメントが必要。
以上が学んだことです〜 elasticsearchの監視をDataDogで早く設定しなきゃ〜 最後に参考にした本を記載しておきます〜
ではまた〜
