【手順】
- EC2インスタンスにCloudWatchエージェントをインストール
- Let's Encrypt で SSL/TLS 証明書を発行し、HTTPS（セキュアな通信）を実現
- CPU使用率などのメトリクスをCloudWatchに送信
- CloudWatchダッシュボードを作成し、視覚的にリソースを監視
- アラームを設定（CPU使用率が一定値を超えたら発報）
- SNSトピックを作成し、アラーム時に通知が届くよう設定
- 通知先にメールアドレスを登録し、サブスクリプションを確認
【実施したこと】
CloudWatchエージェントをAmazon Linuxにインストールし、必要な設定ファイルを作成。CPU使用率を監視するメトリクスをCloudWatchに送信しました。
エージェントの設定を通じて、指定したメトリクスをCloudWatchに送信し、 リアルタイムでリソースを監視できるようにしました。
CloudWatchダッシュボードを作成して、EC2 CPUUtilizationを追加。ec2インスタンスのcpu使用率を視覚的に確認できるようにしました。
CPU使用率が指定したしきい値を超えたときにアラームが発報されるように設定しました。
アラームが発報された際に通知を送るため、SNS（Simple Notification Service）トピックを作成しました。
SNSトピックにメールアドレスをサブスクライブし、アラーム通知が届くことを確認しました。
【結果】
CloudWatchでのリソース監視を通じて、CPU使用率のグラフ表示やアラームの発報が可能になりました。 SNSとの連携により、異常時にはメール通知が届く仕組みを構築できました。
【苦戦したこと】
Nginx設定ファイルはrootユーザーによって管理されているため、一般ユーザーとしては直接編集できませんでした。 VSCodeを使ってリモート編集を試みましたが、権限の問題でうまくいかず、ターミナル上での作業を強いられました。
VSCodeのリモート開発機能を利用してEC2に接続し、編集を試みましたが、エディタでの保存時に権限エラーが発生しました。 sudoで権限を付与しても、VSCode側での操作が難航しました。
sudoでnginx.confを編集しようとした際に、ファイルの権限がどこで問題になっているのかが分かりづらく、最初はスムーズにいきませんでした。
最初、アラームが発報しても通知メールが届かず困惑しました。SNSの設定を見直し、サブスクリプションを承認したことで解決しました。
CloudWatchエージェントの設定を行う際、 sudo nginx -t コマンドで設定ファイルの文法チェックを試みましたが、 server ブロック内に server ディレクティブが重複して記述されていたため、 何度もエラーが発生して設定が通りませんでした。
エラーが発生するたびに、構文エラーの箇所を見つけるのに時間がかかり、苦労しました。
また、
エラー箇所はわかりましたが、ターミナル上での編集作業が不便で、編集を終えるまでの操作が難航しました。
特に、vi エディタに慣れていなかったため、うまく編集できず、時間がかかりました。 しかし、最終的にはエラーを修正し、無事に設定を適用することができました。
【今後の活用】
今後は、VSCodeのRemote-SSH機能を活用して、リモートでEC2インスタンスにアクセスし、設定ファイルを効率的に編集できる環境を整えてみようと思いました。
これにより、ターミナルでの操作に慣れていない自分でも、直感的に作業を進めやすくなり、エラー修正や設定ファイルの管理がスムーズに行えるようになると考えています。
VSCodeを利用することで、複数のファイルを管理しやすくなり、作業の効率が向上するだけでなく、エラーメッセージの視覚的確認やデバッグ機能の活用もできるため、今後の作業において大きな助けとなると期待しています。
この経験を通じて、単なるエージェントの設定作業以上に、**開発環境の最適化やツール選定の重要性も学ぶことができました。