2

AWS CloudWatchログで面白いシナリオがあります。私は現在、log4netを使用し、CloudWatchログエージェントを使用してすべてのログをCloudWatchログにポンピングします。私はCloudWatchのメトリックを持っています。これは基本的に[ERROR]エントリをスキャンし、アラームは、発生したdev通知の別のサービスにそれらを渡します(しきい値> = 1、期間 - 1分)。このすべてがうまくいっています。AWS CloudWatch処理された例外と未処理の例外のメトリックをログに記録します

ここでは、特定のエラーを異なる方法で処理したいと考えています。たとえば、例外タイプに基づいて、N分の間にX個の発生が発生したときにのみアラームをトリガーします。だからこの場合、私はこの条件のメトリックを作成し、それにアラームを割り当てます。問題は、この質問の最初の部分で説明した一般的なエラーメトリックですが、個々のエラーの発生をまだ追跡しています。だから私は複数の通知を取得しています。各エラーごとに1つ、Xの発生後に1つ

一般的なエラーメトリックを無効にすることはできますが、未処理の例外を追跡する機能は失われます。私はそれぞれの可能な例外ごとにメトリックを持っていなければならない。何か不足していますか?これを処理する最善の方法は何ですか?

+0

log4netを使ってCloudWatchにログをプッシュする方法について詳しく説明できますか? –

+1

@ andrew.w.lane、私はEC2上で動作するCloudWatch Logs Agentを実行しており、特定の場所からCloudWatchに定期的にログを転送しています。 –

答えて

2

通知を受ける前に、いくつかの追加処理を行う関数を作成することで、これを処理できます。これを行う最も簡単な方法は、未処理エラーアラームのSNSトピックにAWSラムダ関数を登録することです。トピックから自分自身の登録を解除し、定義した条件が満たされた後にのみラムダ機能にSNSの代わりに通知するようにしてください。

この状況では、アグリゲートメトリックがアラーム状態にあるときに、アグリゲートメトリックと一致する未処理のエラーに関する個々のメトリックからの通知を抑制するように思えます。

擬似コード:あなたの集計未処理の例外アラームの状態を取得する

  • 使用DescribeAlarms API。集計アラームが「アラーム」状態の場合は、続行します。期間
  • - アラームのタイムスタンプ:
    • あなたのログイングループ
    • ログストリーム
    • FilterPattern:あなたの個々の未処理の例外アラームのメトリックフィルタ
    • のStartTimeに
    • 使用FilterLogEvents APIは、取得イベントが一致するログに記録しますEndTime:アラームタイムスタンプ
  • アラームのタイムスタンプ
  • 'すべてのイベント' の場合: - :
    • あなたのログイングループ
    • ログストリーム
    • のStartTime:期間
    • 終了時間アラームのタイムスタンプに一致するすべてのログイベントを取得するための0 APIカウントされ、「フィルタリングされたイベント」カウントが一致し、集約アラームがアラーム状態にある場合、通知を送信しません。それ以外の場合は、SES APIまたはSNS APIを使用して通知を送信します。

    SNS経由で通知を継続する場合は、アラームがラムダをトリガするために使用しているのと同じトピックを再利用しないでください。モバイル/ SMS通知に対して別のものを作成してください。


    私は、これはlog4netのより容易になるだろうかどうかわからないんだけど、あなたはログに後処理のこの種をやって上の意図している場合、直接SNSへの投稿を未処理の例外を送信する方が良いかもしれまずlambdaのプロセスを実行してから、ラムダ関数のクラウドウォッチログに書き出します。この変更により、SNSメッセージペイロードを介して未処理の例外を検査し、重複する懸案事項をどのように抑制するかをさらに制御することができます。

  • +0

    優れた答え!ありがとうございました! –