標準アラートの設定

標準アラートは、ログの変更によってトリガーされるアラートです。 特定のログの設定された量のしきい値を超えるとトリガーされるこの機能により、システムのパフォーマンスを監視し、変更が発生したときに通知を受け取り、潜在的な原因を突き止めることができます。 これらのアラートは、特定のインシデントの発生件数を測定しようとする場合に有用である。

前提条件

  • アラートについては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" を入力します。 クエリーは、値 403 と POST を含むログを探す。

    特定のフィールドがクエリの値と一致するログをフィルタリングするクエリを定義できます。 例えば、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]/

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

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

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

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

    有効な値は、Debug、Verbose、Info、Warning、Error、および Critical です。

トリガー条件の指定

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

Conditionsセクションで、Alert When と Group By のフィールドを設定する必要があります。

Alert When（アラート発生時）」では、アラートを即座に発生させるか、指定した時間ウィンドウ内の発生回数に基づいてルールを定義するか、または異常な動作を自動的に検出する動的アラートを構成するかを選択する必要があります。

  • Notify Immediately 選択すると、1つのログレコードがフィルタリング条件に一致すると評価された時点で、即座に通知されます。

    Notify Immediately によるアラートの場合、1行がクエリ条件を満たすとすぐにアラートが送信されます。 IBM Cloud Logs は、同じクエリ条件を満たす追加の Notify Immediately によるアラートが送信される前に、1分間待機します。 アラートが解決されない場合、 Notify の状態は、アラートがトリガーされた後に、新しいイベントとともに同じアラートが通知される頻度を示します。

  • アラート定義に一致するエントリーのカウントが選択したしきい値以上になった場合に通知を受けるには、More Than を選択します。

    More Than アラートが一定期間内に0行に設定されている場合、1行がクエリ条件を満たすとすぐにアラートが送信されます。 アラートは、設定された時間閾値に達するまでアラートを発生させません。

  • アラート定義に一致するエントリーのカウントが選択したしきい値より小さい場合に通知されるように Less Than を選択します。

  • 固定されたしきい値を設定することなく、自動的に異常な動作を検出するダイナミックアラートをトリガーして即座に通知する More Than Usual を選択します。 しきい値の最小値のみを定義する必要があります。 このタイプを選択した場合、アルゴリズムがトラフィックパターンを学習し、システムを流れるデータに基づいてトリガーをかけるまでに1週間かかることに注意してください。

次の表は、このタイプのアラートを設定するためのオプションの一覧です：

標準的な警戒条件
警告 発生件数 時間枠
Notify Immediately オプション不可 オプション不可
More than threshold [*] 番号を設定する 有効なオプション5分、10分、15分、20分、30分、1時間、2時間、4時間、6時間、12時間、24時間、36時間
Less than threshold 番号を設定する 有効なオプション5分、10分、15分、20分、30分、1時間、2時間、4時間、6時間、12時間、24時間、36時間
More Than Usual 番号を設定する 有効なオプション5分、10分、15分、20分、30分、1時間、2時間、4時間、6時間、12時間、24時間

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

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

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

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のトリガーされたアラートの管理 を参照してください。

ダイナミック・アラート制限

ダイナミックアラートとは、「 通常より多い 」または「 通常より少ない」という条件を持つアラートである。 各ダイナミック・アラートには500の順列が割り当てられ、どの IBM Cloud Logs インスタンスに対しても最大10,000の順列が許可される。

並べ替えの制限は、 IBM Cloud Logs インスタンスに対して最大20のダイナミック・アラートを設定できることを意味する。

動的アラートが20件に達した場合でも、他の非動的アラートを作成することができます。