〜「何を監視すればいいの？」が「工場の計器盤と同じ」に変わった話〜
こんにちは！ハンズオンラボ運営のえむです。
「サーバーが落ちた」と気づいたのがユーザーからの問い合わせだった、という経験はありませんか？
「何を監視すればいいの？」
「アラートがうるさすぎて全部無視してしまう」
「CloudWatchって難しそうで触れない」
実は、CloudWatchの仕組みは**「工場の計器盤」**と全く同じです。計器盤が「温度・圧力・回転数」を常時表示するように、CloudWatchは「CPU・ネットワーク・エラー数」をリアルタイムに見せてくれます。
この記事を読むと、以下のことができるようになります
- CloudWatchが何をするツールかを説明できる
- メトリクス・ログ・アラームの違いがわかる
- EC2の基本的な死活監視をCloudWatchで設定できる
CloudWatchは「工場の計器盤」
工場には壁一面に計器盤があります。
- 温度計：炉の温度が設定値を超えたら警告ランプが点灯する
- 圧力計：配管の圧力が異常なら自動でバルブが閉まる
- 回転数計：モーターが止まったらアラームが鳴る
CloudWatchは、AWSサービスの「温度・圧力・回転数」を常時計測して、異常があれば通知してくれる計器盤です。
3つの主要機能を押さえる
【メトリクス：計器の数値】
CPUやネットワークなど、AWSが自動で収集する数値データです。EC2なら以下が標準で取得できます。
-
CPUUtilization：CPU使用率 -
NetworkIn/NetworkOut：ネットワーク転送量 -
StatusCheckFailed：インスタンスが生きているか
【ログ：作業日報】
アプリやOSが吐き出すテキストログを集約します。CloudWatch Logs Agentをサーバーに入れると、アクセスログやエラーログを一元管理できます。
【アラーム：警告ランプ】
「CPUが5分間80%を超えたらメールを送る」といった閾値を設定します。工場の警告ランプと同じです。
EC2に死活監視アラームを設定する
AWSコンソールの場合：CloudWatch → アラーム → アラームの作成 → EC2メトリクス → StatusCheckFailed を選択します。
# AWS CLIで設定する場合
aws cloudwatch put-metric-alarm \
--alarm-name "EC2-StatusCheck-Failed" \
--metric-name StatusCheckFailed \
--namespace AWS/EC2 \
--dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
--statistic Maximum \
--period 60 \
--evaluation-periods 2 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--alarm-actions arn:aws:sns:ap-northeast-1:123456789:MyAlert
ビフォーアフター
【ビフォー】
- サーバーダウン → 「ユーザーから問い合わせが来て初めて気づく」
- CloudWatch → 「なんか難しそうなAWSのサービス」
- 監視設定 → 「閾値がわからないからとりあえず放置」
【アフター】
- サーバーダウン → 「StatusCheckFailedアラームが即座にSlackに通知してくれる」
- CloudWatch → 「工場の計器盤。メトリクス・ログ・アラームの3つを覚えれば使える」
- まず設定すること → 「EC2のStatusCheckFailedアラーム。これだけで最低限の死活監視になる」
- 今すぐやること → CloudWatchコンソールを開いてEC2のCPUグラフを見てみる
まとめ
- CloudWatch＝「工場の計器盤」。AWSサービスの数値を常時計測して異常を通知する
- 3つの主要機能：メトリクス（数値）・ログ（テキスト）・アラーム（閾値通知）
- まず設定すべきアラーム：
StatusCheckFailed（死活監視）とCPUUtilization（高負荷検知） - EC2の標準メトリクスは追加料金なしで利用できる
- 「問い合わせが来てから気づく」から「自分から先に気づく」運用に変えるのがゴール
AWSコンソールでCloudWatchを開いて、今動いているEC2のCPUグラフを眺めるところから始めてみましょう。
AWSを実際に手を動かしながら学ぶハンズオンイベントを定期開催しています。
面白かったら
「👇いいね」で応援