CloudWatch Logs のメトリクスフィルターでレスポンスタイムを監視する方法 ── エージェントでログを送りアラームを出す

前提条件

1. リージョン: ap-northeast-1（東京）
2. 以下のリソースが作成済みであること

まだ用意していない場合は、「作り方の参考」の記事の手順で作れます。リソース名は、この記事の名前に読み替えてください。

作成するリソース一覧

手順 1: CloudWatch エージェントでログを送る

AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。EC2 のコンソールで dva-cwlogs-app を選択し、「接続」→「Session Manager」タブ →「接続」をクリックします。

ターミナルで、アプリのログが書かれていることを確かめます。

tail -n 3 /var/log/dva-app/access.log

技術解説の設定ファイルを /opt/aws/amazon-cloudwatch-agent/etc/dva-config.json として保存し、エージェントに読み込ませて起動します。

sudo tee /opt/aws/amazon-cloudwatch-agent/etc/dva-config.json > /dev/null <<'EOF'
{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/dva-app/access.log",
            "log_group_name": "/dva/app/access",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}
EOF
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/dva-config.json
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status

status の結果で "status": "running" になっていれば、エージェントが動いています。

上部の検索バーに CloudWatch と入力し、「CloudWatch」を選択します。左側ナビゲーションの「ログ」→「ロググループ」で /dva/app/access を開くと、インスタンス ID の名前のログストリームに、アプリのログが届いています。

手順 2: メトリクスフィルターを作る

ロググループ /dva/app/access の画面で「メトリクスフィルター」タブを選択し、「メトリクスフィルターを作成」をクリックします。

1. フィルターパターン: { $.latency_ms = * }
2. 「パターンをテスト」: 「カスタムログデータ」の欄に {"path": "/items", "status": 200, "latency_ms": 123} を貼り、「パターンをテスト」をクリックして 1 件一致することを確認する

「次へ」をクリックし、「メトリクスの割り当て」で以下を設定します。

1. フィルター名: dva-app-latency
2. メトリクス名前空間: DVA/App
3. メトリクス名: ResponseTime
4. メトリクス値: $.latency_ms
5. 単位: ミリ秒

「次へ」をクリックし、「プレビューと作成」の画面で「メトリクスフィルターを作成」をクリックします。

手順 3: 平均と最大をグラフで見る

フィルターを作ってから値がメトリクスに出始めるまで数分かかります。数分待ってから、左側ナビゲーションの「メトリクス」→「クラシックメトリクス」を選択し、「カスタム名前空間」の DVA/App →「メトリクスのディメンションなし」→ ResponseTime を選択します。「グラフ化したメトリクス」タブで、統計を「平均」、期間を「1 分」にします。同じメトリクスをもう 1 行追加し、統計を「最大」にすると、平均と最大が並んで表示されます。

手順 4: アラームを作る

平均のメトリクスの行の「アクション」から、ベルのアイコン（アラームを作成）をクリックします。アラームの作成は 4 ステップで、名前空間・メトリクス名・統計（平均値）・期間（1 分）は入力済みの状態で始まります。以下を設定します。

1. 統計: 平均値、期間: 1 分（入力済み）
2. 条件: 「静的」、「より大きい」（どちらもデフォルト）、しきい値 300
3. 「その他の設定」の「アラームを実行するデータポイント」: 1 / 1（デフォルト）
4. 通知: アラーム状態トリガーで「既存の SNS トピックを選択」し、送信先に dva-latency-alarm-topic のトピックの ARN（arn:aws:sns:ap-northeast-1:<アカウントID>:dva-latency-alarm-topic）を入力（名前で候補が出ない場合があります。サブスクリプションが無いので「トピックにエンドポイントがありません」と表示されますが、そのまま進めます）
5. アラーム名: dva-app-latency-high

最後のステップで「アラームの作成」をクリックします。しばらくすると、アラームの状態は OK になります。

手順 5: 遅くして、アラーム状態になることを確かめる

Session Manager のターミナルで、疑似アプリを遅くします。

sudo touch /tmp/slow

数分すると、平均のレスポンスタイムが 300 ms を超え、アラーム dva-app-latency-high の状態が「アラーム状態」に変わります。アラームの「履歴」タブには、状態の変更と、SNS トピックへのアクションが実行された記録が残ります。

今回の SNS トピックにはサブスクリプションを付けていないので、通知はどこにも届きません。実際の運用では、トピックにメールアドレスなどのサブスクリプションを追加して、通知を受け取ります。

確認が終わったら、sudo rm /tmp/slow で元に戻します。数分後にアラームは OK に戻ります。