12
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

[EC2]サーバのリソース監視入門

Last updated at Posted at 2019-03-03

■概要

  • AWSでEC2を使う際に、見ておく必要があるであろう項目を、洗い出して監視を実践する。

■取っておきたいメトリクスについて

◆EC2を建てると標準で取得されるメトリクス一覧

(公式)インスタンスの利用可能な CloudWatch メトリクスのリスト表示」に詳細が書いてあるが、一般的なアプリケーション監視に使う項目が標準ですべてとれるわけではない。

※自分が運用/監視で標準メトリクスから使っている項目は下記くらい。

 1. CPU使用率
 2. ディスクのRead/Write
 3. ネットワークのIn/Out

◆追加で必要であろうリソース情報

 1. CPU使用率の詳細(user/system/iowait/idle)
  ※nice,irq,softは特に気にしていない
 2. メモリ使用量の詳細(swpd/free/buff/cache)
 3. ロードアベレージ
 4. ディスク使用率

◆Webアプリケーションなら取っておきたい情報(Cloudfront/ELBなどを使うと標準で取れる)

 1. 総リクエスト数
 2. 5xx系のエラーレート
 3. 5xxのエラーリクエスト数
 4. レスポンスタイム
 5. ミドルウェアのプロセス/スレッド数(psコマンドで取得)
 6. サーバ間のTCP接続数(netstatコマンドで取得)

■サーバからメトリクスをどうやってcloudwatchメトリクスに送るか

サーバ上のリソース情報をどうやってCloudwatchメトリクスに登録するかという事だが、fluentd(td-agent)を使うのが吉。
自身の環境に合わせて何秒に一回上記の情報をメトリクスに登録するか、検討するのが良い。 
Cloudwatch以外のSaasサービスを利用する際にも同じように実装が可能である。

※fluentd(td-agent)の実装例を記事化する要望があれば乗せるのでご要望を寄せていただけるとありがたいです。

■取得したメトリクスを便利に見る方法

結論、CloudWatchのダッシュボードにまとめるのが一番良い。

  • 下記のようなメリットがある。
 1. 一つのダッシュボードに上手くまとめればコスパが最高
 2. 見たい時間へのスケールがとても楽ちん
 3. グラフにカーソルを合わせると他のグラフ上にも線が出るので相関が見やすい
 4. 編集もポチポチで簡単

■最後に

入門 監視(O'REILLY)」にも書いてありますが、今の時代オンプレミスのサーバに監視基盤を作る時代は過ぎたと思います。(当然堅牢性など仕方ない場合はありますが。)
監視の為の監視に大切な人的コストを浪費し、本来の仕事が出来ていない状況にあるのであれば、是非Saasサービス(CloudWatchがおすすめ)を検討しましょう。

 以上、フィードバックやご指摘等いただけると大変ありがたいです!!よろしくお願いいたします!!

12
12
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?