WebとかIoTのブログ

なぜ必要なのか

システムを公開するだけではなく、継続的に機能改善していけるかが重要

機能改善にリソースを割くためにも、まず日々の安定稼働が必要

安定稼働のためには定期的にAWSリソースの状態を取得し、問題があれば通知する仕組みが必要

どうやるのか

Amazon CloudWatchを利用する

• 何を持って「問題がある」かを定義
  • メトリクスという単位をセットする
• どの問題が起きた際に、どこに通知するかを定義

AWS CloudTrailを利用する

• マネジメントコンソールやログインなどの操作を記録する
• S3にログを溜める

Amazon CloudWatchとは

運用監視を支援するマネージドサービス

CloudWatch

• 各AWSリソースの状態を定期的に取得する
  • メトリクスを定期的に取得する
    • 各AWSリソースの「状態」のことを「メトリクス」と呼ぶ
    • メトリクスには2種類ある
      • 標準メトリクス
      • カスタムメトリクス
  • メトリクスに対してアラームをセットする
    • 「システムのよくない状況をすぐに検知する」
    • 例：Webサーバ用のEC2インスタンスのCPU利用率が80%を上回った時、SNSへ通知する。SNSは、運用担当者にメールを送信する。

CloudWatch Logs

• アプリケーションログやApacheなどのログをモニタリングするサービス
• 独自のエージェントを介して収集
• 収集したログに対してアラームをセットすることができる
  • 例えば戦闘に「[ERROR]」で始まる行があったら何かしらの通知処理をトリガーするなど

CloudWatch Events

• 独自のトリガーと何かしらの後続アクションの組み合わせを定義するサービス
  • イベントソース
    • スケジュール
    • イベント（AWSリソースの「イベント」）
      • 例：「Auto Scalingがインスタンスを増減させたら」等
  • ターゲット
    • Lambda
    • CodePipeline
    • などなど・・・
• 将来的にはEventBridgeに統合される予定

AWS CloudTrailとは

CloudTrailで取得できるログの種類

• 管理イベント
• データイベント

CloudWatch Logsとの連携

• 例えば戦闘に「LOGIN」で始まる行があったら管理者へログインが行われたことを通知するなど