2

AWS CloudWatch Logs に関する興味深いシナリオがあります。現在、log4net を使用しており、CloudWatch Logs エージェントを使用してすべてのログを CloudWatch Logs に送り込んでいます。基本的に [ERROR] エントリをスキャンするメトリックが CloudWatch にあり、アラームが発生すると、開発者通知のためにそれらを別のサービスに渡します (しきい値 >= 1、期間 - 1 分)。これらすべてがうまく機能しています。

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

一般的なエラー メトリックを無効にすることはできますが、未処理の例外を追跡する機能が失われます。考えられるすべての例外のメトリックが必要です。何か不足していますか？これを処理する最良の方法は何ですか?

4

1 に答える 1

2

通常、通知を受ける前に追加の処理を行う関数を作成することで、これを処理できます。これを行う最も簡単な方法は、未処理のエラー アラームの SNS トピックに AWS Lambda 関数をサブスクライブすることです。トピックから自分自身を購読解除し、定義した条件が渡された後にのみ、ラムダ関数が SNS の代わりに通知するようにします。

この状況では、集計メトリクスがアラーム状態にある間、集計メトリクスに一致する未処理のエラーについて、個々のメトリクスからの通知を抑制したいと思われます。

擬似コード:

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

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

これが log4net よりも簡単かどうかはわかりませんが、ログに対してこの種の後処理を行うことに意図がある場合は、未処理の例外を SNS に直接送信し、最初にラムダで後処理し、次に、ラムダ関数から cloudwatch ログに書き出します。この変更により、SNS メッセージ ペイロードを介して未処理の例外を検査できるようになり、重複する懸念を抑制する方法をさらに制御できるようになります。

于 2016-12-06T19:33:14.550 に答える