比率アラートの設定

2つのログクエリ間の比率を計算し、比率が設定されたしきい値に達したときにアラートをトリガーすることができます。

使用例としては以下のようなものがある:

運用の健全性:受信リクエストに対する送信レスポンスの数、またはエラー全体の数に対する特定のエラーコードの比率を監視する。

マーケティング地域キャンペーン後のトラフィック全体に対する特定地域からのトラフィックの比率をモニターする。

セキュリティ全リクエストと比較して、拒否されたリクエスト、特定の管理操作、またはブロックされたネットワークドメインからのリクエストの比率を監視します。

前提条件

  • アラートについてはIBM Cloud Logsを参照してください。 詳細については、アラート を参照してください。
  • Event Notificationsインスタンスが IBM Cloud Logsインスタンスと同じアカウントにあり、Event Notificationsインスタンスにリソースを設定する権限があることを確認してください。
  • IBM Cloud LogsインスタンスとEvent Notificationsインスタンス間のアウトバウンド統合が構成されていることを確認する。 詳細については、接続するアウトバウンドインテグレーションを設定する を参照してください。

起動アラート管理

以下のステップを実行します。

  1. コンソールで、 ナビゲーション・メニュー・アイコン Navigation Menu icon > Resource list をクリックする。
  2. IBM Cloud Logs のインスタンスを選択します。
  3. IBM Cloud Logsナビゲーションで、アラートアイコン >アラー管理をトクリックします。
  4. 新しいアラートをクリックします。

設定するアラートの種類を選択する

以下のステップを実行します。

  1. アラートの種類を選択します。 詳細については、 「アラートの種類」 を参照してください。

  2. Details セクションで、以下のステップを完了する:

    1. 名前を入力します。

      • 名前の最大長は4096文字。
    2. [オプション]説明文を入力します。

      • 説明文の最大長は4096文字です。
    3. [オプション] 1つ以上のラベルを追加する。

      ラベルは、後で簡単に検索するために使用できるキーと値のペアです。

フィルタリング基準に照らして分析されるログを指定します

フィルタリング基準に照らして分析するログを指定するには、以下の手順を実行します:

  1. アラートの一部として返されるログを指定するために、 Lucene 検索クエリを指定します。

    フリー・テキスト文字列に基づいてフィルタリングするクエリを定義できます。 例えば、リターンコードが403のPOSTリクエストが識別されたときにアラートをトリガーするには、検索クエリーとして "POST 403" を入力します。 クエリーは、値 403POST を含むログを探す。

    特定のフィールドがクエリの値と一致するログをフィルタリングするクエリを定義できます。 例えば、environmentフィールドのproductionという値を検索するクエリを定義することができます: environment:"production"

    特定のフィールドが数値の範囲に一致するログをフィルタリングするクエリを、[START_VALUE TO END_VALUE] という書式を使って定義することができます。 例えば、フィールド RC に対して 2xx ステータスコードを持つログを検索するには、クエリーを使用することができる: rc.numeric:[400 TO 499]

    特定のフィールドが正規表現RegEx)に一致するログをフィルタリングするクエリを定義できます。 RegEx式を / で囲む。 たとえば、フィールド領域で west-europe-1, west-europe-2, west-us-1 のような異なる領域を検索するクエリを定義することができます:region:/west-(europe|us)-[12]/

    ブール演算子 ANDORNOT を使用する複雑なクエリーを定義することができます。 たとえば、次のようなクエリーを定義できます environment:"production" AND status.numeric:[400 TO 499] NOT region:/west-(europe|us)-[12]/

  2. 1つ以上のアプリケーションを選択して、ログのフィルタリングを追加します。

  3. 1つ以上のサブシステムを選択して、ログのフィルタリングを追加する。

  4. 1つ以上のログの厳しさを選択して、ログのフィルタリングを追加します。

    有効な値は、DebugVerboseInfoWarningError、および Critical です。

クエリーの指定

比率の計算に使用される2つのクエリを指定します。 それぞれのクエリに対して:

  1. クエリ・エイリアスには、クエリの意味のある名前を指定します。 クエリーエイリアスはアラート通知に含まれます。

  2. クエリを入力してください。 クエリーには正規表現を含めることができます。

  3. クエリを特定のアプリケーションと サブシステムに適用するか、すべてに適用するかを指定します。

  4. クエリを特定の深刻度に適用するか、すべての深刻度に適用するかを指定します。

照会の例

以下はクエリの組み合わせの例である。

例1:エラーコード504と受信したレスポンスコード全体の数の比率を求める。 通常より高い比率は、運営上の問題を示している可能性がある。

  • クエリー1 status:504
  • 照会 2: _exists_:status

例2: 172.xxx.xxx.xxx の外側のアドレスが制限されていると仮定すると、全トラフィックに対する制限トラフィックの比率が異常に高い場合、攻撃を示している可能性がある。

  • クエリー1 NOT client_addr:/172\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}/
  • 照会 2: _exists_:client_addr

例3: 成功したリクエストのうち、成功しなかったリクエストの数を計算する。 通常より高い比率は、運営上の問題を示している可能性がある。

  • クエリー1 request_status:success
  • 照会 2: response_status:rejectrequest

トリガー条件の指定

このアラートの分析に含まれるデータに対して評価されるトリガー条件を指定します。

「アラート条件: クエリ 1 / クエリ 2 が等しい」 では、定義された時間枠内でクエリがしきい値数より多く一致した場合、またはしきい値数より少なく一致した場合にアラートをトリガーするかどうかを選択する必要があります。

  • More than threshold 、クエリ結果の比率がしきい値以上になった場合に通知されます。

  • クエリー結果の比率が選択したしきい値より小さい場合に通知を受けるには、 Less than threshold を選択します。

しきい値未満の条件を使用している場合、未検出の値を管理するオプションがあります。

未検出値は、 閾値未満アラートの順列が送信されなくなり、(送信されなかった時間枠ごとに)複数のアラート・トリガーを引き起こす場合に発生する。

未検出の値を含むアラートを表示する場合、これらの値を手動で消去するか、または未検出の値が自動的に消去される期間を選択するオプションがあります。 また、未検出値のトリガーを無効にして、未検出値が発生したときにアラートの送信を即座に停止することもできます。

無限大でアラートをトリガー

2つ目のクエリー結果がゼロ値を返した場合、計算された比率は無限大となる。

この条件でアラートをトリガーするかどうかは、 Do not tigger on Infinityを選択または選択解除することで指定できます。

Group By では、最大2つのJSONフィールドを設定でき、その値が集計され、アラートがトリガーされるタイミングを決定します。

  • 集計された値のいずれかが、指定された時間枠内にフィルタリング条件セクションで設定されたしきい値を超えて表示された場合、アラートがトリガーされます。

  • アラートは、指定された時間枠内で特定の集計値について条件しきい値を満たした場合にトリガーされます。

  • 2つの値を設定すると、一致するログはまず親フィールドで集計され、次に子フィールドで集計されます。 アラートは、しきい値が親と子の両方のユニークな組み合わせを満たしたときに発せられる。

通知の詳細を設定する

以下のステップを実行します。

  1. Notify every を設定して、アラートがトリガーされた後のイベント取得頻度を定義します。 デフォルトでは0時間10分に設定されている。

  2. Resolve automaticallyを有効にすると、イベントが解決されたときにイベントを取得します。

    アラートの条件がイベントをトリガーしなくなると、最初にトリガーされたイベントは解決済みとしてマークされる。

  3. Enableファントムモードを有効にして、このアラートがファントムアラートであることを示す。

    ファントムアラートは、フローアラートのビルディングブロックとして機能する。

    ファントムアラートは、独立したイベント通知をトリガーしない。

    このオプションを有効にすると、アラート定義から通知セクションが削除されます。

  4. 統合を追加する。

    統合を追加するには、送信統合が定義されている必要があります。 詳細については、Event Notificationsサービスとの統合を設定する を参照してください。

スケジュールと含めるログの内容を設定する

以下のステップを実行します。

  1. *スケジュール]*セクションで、このアラートを有効にするタイミングを制御するスケジュールを設定します。 特定の曜日と時間を選ぶことができる。

  2. *Notification Content(通知内容)*セクションでは、トリガーされたイベントにログ行のサンプルを含めるか、一部のフィールドのみを含めるかを定義します。

    アラート通知に含める特定のJSONキーを選択するか、アラートメッセージにログテキスト全体を含めるには空白のままにします:

    • オプション1:アラートのフィルタリング条件に一致するログ行を1行含めるには、空白のままにします。

    • オプション2:JSONキーを指定し、key:valueのペアの形式で選択したフィールドを含める。 フィールドを追加するには、ログ記録がJSON形式でなければならないことに注意してください。

      名前に . を含む JSON キーは、選択フィールドとして使用できません。

    • オプション3:フィルターとしてJSONパスを指定する。

アラートがトリガーされると、イベントに含まれるデータ量には制限がある。 これらの制限の詳細については、データサイズ を参照。

アラート設定を保存する

以下のステップを実行します。

  1. 警告を確認する。

    Verify(検証)」をクリックしてデータを評価し、過去24時間にアラートが何回条件に一致したかを調べます。

    Verifyは優先順位の洞察パイプラインのデータのみを評価する。 アラートが分析とアラートパイプラインで利用可能なデータでトリガーされるように構成されている場合、この機能は利用できないことに注意してください。

  2. **「アラートの作成」**をクリックします。

アラートの確認

アラートを作動させる。 アラートがトリガーされ処理されると、システムは、電子メール、Slack、SMS、または統合されたインシデント管理プラットフォームなどのさまざまなチャネルを通じて、指定されたユーザーまたはチームに通知を送信します。 その後、*「インシデント」*ページに移動し、トリガーされたアラートに関する情報を見ることができます。 詳細については、IBM Cloud Logsのトリガーされたアラートの管理 を参照してください。