本記事は
【Advent Calendar 2025】
14日目の記事です。
🌟🎄
13日目
▶▶ 本記事 ▶▶
15日目
🎅🎁
はじめに
こんにちは！アドベントカレンダー14日目担当の山本です！
いきなりですがシステムの運用中にログやメトリクスを監視していると、「一時的なエラーは検知したいけど、すぐに復旧するケースをいちいち検知してしまうのは面倒だ」と感じたことはありませんか？
たとえば、「ある処理でエラーが発生しても、すぐに成功ログが出る場合にはアラームを抑止したい」という状況です。
このようなケースでは、Amazon CloudWatch の複合アラームとメトリクスフィルターを組み合わせることで、柔軟に条件を設定して誤検知を防ぎながら監視することが可能です。
本記事では、特定のログ条件に応じてアラームを発火させる複合アラームの設定例を紹介します。
前提条件
今回の例では、以下の前提条件を置きます。
- EC2 インスタンス（Amazon Linux 2023）を起動
- CloudWatch エージェントで対象ログを収集済み
- 収集対象ログは /var/log/messages に出力
この状態から、複数のメトリクス条件を組み合わせてアラームを作る流れを紹介します。
ユースケースの整理
今回のユースケースは次の通りです。
「ログ A とログ B が一定時間内に両方出たらアラームを抑止」
「ログ A が出た後、ログ B が出ない場合はアラームを発火」
例えば、サービスの異常と復旧ログを同時に確認したい場合や、複数処理の同時失敗を検知したい場合に有効です。
簡単な図で表すと以下のようになります。
| 条件1 | 条件2 | アラーム状態 |
|---|---|---|
| ログA検出 | ログB検出 | OK |
| ログA検出 | ログB未検出 | アラーム発火 |
作成手順
① メトリクスフィルターの作成
まず、CloudWatch Logs で対象ログからメトリクスを作成します。
今回は例として「CONNECTION ERROR」(ログA）、「CONNECTION SUCCESS」(ログB）の2つの文字列をフィルターパターンとして設定します。
これにより、ログ出力が CloudWatch メトリクスとして扱えるようになります。
②子アラームの作成
次に、メトリクスごとに子アラームを作成します。先ほどの手順で設定した文字列を検知したときに発火するようにします。
※初期状態ではデータ状態が INSUFFICIENT_DATA になることがあります。少し時間を置くと正常状態に変わります。
③ 複合アラームの設定
複合アラームでは、子アラームの状態を論理式で組み合わせて条件を作れます。
今回の条件の場合:
「子アラームA が ALARM 状態で、かつ子アラームB が OK 状態のときにのみ複合アラームを発火」
CloudWatch の論理式で表すと以下のようになります。
ALARM("CONNECTION ERROR ALERT") AND
NOT ALARM("CONNECTION SUCCESS ALERT")
この設定により、片方のエラーが発生した後、すぐにもう一方のログが出た場合はアラームを抑止できます。 名前空間は CWAgent や任意のサービス名を使うと管理しやすいです。
また、同じ評価期間で子アラームの発火タイミングが微妙にずれるため、一時的に複合アラームの発火条件を満たしてしまうことになります。
意図しない発火を防ぐためにサプレッサーを設定することで、適切なタイミングで複合アラームを発火させるようにしておきます。
複合アラームのアクションの抑制 - Amazon CloudWatch
動作確認
最後に、テストログを出力して複合アラームが正しく発火するか確認します。
- ログ A を出力 → 複合アラーム発火
EC2インスタンスにSSMで接続し、意図的にログを出力し確認します。
[root@ip-10-0-0-4 ~]# echo "$(date '+%b %d %H:%M:%S') TEST LOG CONNECTION ERROR" >> /var/log/messages
- ログ A → ログ B を出力 → アラーム抑止
上と同様に疑似的なログを出力し確認します。
[root@ip-10-0-0-4 ~]# echo "$(date '+%b %d %H:%M:%S') TEST LOG CONNECTION ERROR" >> /var/log/messages
[root@ip-10-0-0-4 ~]# echo "$(date '+%b %d %H:%M:%S') TEST LOG CONNECTION SUCCESS" >> /var/log/messages
以上で、ユースケース通りの動作を確認できます。
アラーム評価の注意点
CloudWatch アラームを利用する際に知っておきたい点として、アラーム単体では“ログイベントの正確な時系列関係”を扱えないという制約があります。CloudWatch の評価はあくまで設定した評価期間ごとの状態を判断するため、ログ A とログ B の厳密な発生順や、「A が出てから 5 分以内に B が出たか」のような時間差をそのまま判定できるわけではありません。
今回紹介した方法は、「同じ評価期間内で両方のログが出たかどうか」というレベルの検知には有効ですが、評価ウィンドウをまたいでしまうケースや秒単位の厳密な時系列制御までは対応できません。
もしより精密に「A の後に B が出たら OK／出なければ NG」といった判定が必要な場合は、CloudWatch アラームだけでは不十分で、EventBridge + Lambda、Step Functions、DynamoDB などを使ってログ間の関係性や待機時間を自前で管理する仕組みが必要になります。
おわりに
CloudWatch の複合アラームを使うことで、単体のログやメトリクスでは検知できない複雑な条件も監視できるようになります。
子アラームの状態を組み合わせた論理式を設定することで、特定のエラーが発生した場合だけアラームを出し、直後に復旧ログが出た場合にはアラームを抑止するといった柔軟な運用が可能です。
実際の運用では、子アラームの評価期間やデータ不足時の扱いに注意することで、誤検知を避けつつ正確に監視が行えるようになります。
これらの設定や考え方を活用すれば、サービスの異常検知の精度を高め、不要なアラートを減らすことができます。
ぜひ今回紹介した内容を参考に、実際の運用に役立てていただければと思います。
執筆者 ： 山本将望
食べることが生きがいのインフラエンジニア
執筆記事一覧 ：
https://tech.nri-net.com/archive/author/m4-yamamoto
