アラート

IBM Cloud Logs アラートにより、異常のタイムリーな検出、プロアクティブなインシデント対応、平均解決時間 (MTTR) の改善、手動によるモニターの労力の削減、カスタマイズ、柔軟性が可能になります。機械学習を採用したアラートは、潜在的な問題をチームに事前に通知し、インシデントを相互に関連付け、根本原因分析を提供します。

アラートの仕組み

アラートは、それらがどのように生成され、トリガーされ、ユーザーに配信されるかについての一般的なワークフローに従います。

アラート・ルールの設定

管理者、開発者、または DevOps は、可観測性プラットフォーム内でアラート・ルールを定義します。これらのルールは、アラートがトリガーされる条件を指定します。例えば、ログに特定のエラー・メッセージが表示された場合にアラートを出すルールを設定することができます。
データの収集と分析

IBM Cloud Logs は、ログやメトリックなどのデータをシステムから継続的に収集します。定義されたアラート・ルールに対してこのデータを処理および分析します。
アラート・トリガー

モニター対象データがアラート・ルールで指定された条件を満たすと、アラートがトリガーされます。トリガーは、エラー率の突然の急上昇、待ち時間の増加、リソースの可用性の低下、またはその他の事前定義された異常の結果である可能性があります。
アラートの集約と重複排除

アラート・システムは、複数の類似したアラートを単一の通知に集約して、大量のユーザーが冗長な通知を受け取るのを防ぐことができます。また、ユーザーに繰り返し情報が送信されないように、アラートが重複しないようにすることもできます。
通知とエスカレーション

アラートがトリガーされて処理されると、システムは指定されたユーザーまたはチームに通知を送信します。通知は、E メール、Slack、SMS、または統合インシデント管理プラットフォームなどのさまざまなチャネルを介して配信できます。シチュエーションが未解決のままになっている場合は、上位レベルのチームまたは個人にアラートをエスカレートさせることができます。
アラートの解決と確認応答

アラートの受信者がアラートを確認し、問題に対処するための適切なアクションを実行します。問題が解決されると、アラートに「完了」のマークが付けられます。
モニターおよびレポート

アラート・プロセス全体を通して、 IBM Cloud Logs はシステムの状況を継続的にモニターします。確認状況、解決時間、およびその他のメトリックを追跡して、レポートを生成し、インシデント後の分析と改善に役立てることができます。

アラート・タイプ

IBM Cloud Logs には、構成可能な 6 つのタイプのアラートが用意されています。

アラートの設定方法の詳細については、アラートアイコンアラートの設定を参照してください。

標準アラート

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

標準アラート機能を使用して、以下を行うことができます。

システム・パフォーマンスをリアルタイムでモニターします。選択した基準に基づいてリアルタイムの洞察を得ることができます。
特定のニーズに合わせて照会を構成します。検査するログをキャプチャーする照会を定義し、アプリケーション、サブシステム、および重大度でフィルタリングすることによって、その照会をより具体的にします。次に、アラートをトリガーする条件の範囲を選択します。例えば、特定の時間フレームに 10 個を超えるログが受信された場合にアラートをトリガーするように設定できます。
機械学習ベースのアプローチを使用します。この設定を使用して、 IBM Cloud Logs はデータのプロファイルを作成し、異常な動作を自動的に検出します。
パーソナライズされた通知を受け取ります。任意の通信チャネルへのリアルタイム・プッシュ通知を受信します。

標準アラートは、 IBM Cloud Logsによって提供される最も単純なアラートです。これらは、可観測性システムの基盤として、最も明らかなユース・ケースをカバーするために使用できます。

時間相対アラート

時間相対アラートを使用して、システム内の異常動作を自動的に検出します。過去の時間フレームと比較して、固定比率が設定されたしきい値に達すると、アラートがトリガーされます。

時間相対アラートを使用して、以下を行います。

時間の経過に伴うシステムのセキュリティー、運用、またはビジネス行動の変化に関する自動アラートを受け取ります。
異なる期間にわたる行動を比較します。以下に例を示します。

セキュリティー

疑わしい振る舞いを比較する自動アラートを受け取ります。例えば、日単位または週単位の NX ドメイン・ネーム応答または管理者ログインの数を比較します。

操作

アプリケーション内のエラー率とページ・ロード時間に関する自動アラートを受け取ります。例えば、過去 1 日または 1 時間のエラー率とページ・ロード時間を比較します。

ビジネス

販売またはユーザーのサインアップのシフトが発生したときに自動的にアラートを受け取ります。例えば、先週の同じ曜日の購入数や、先月のユーザー・サインアップ数などを比較します。

固有のカウント・アラート

データ量が増加し、ログ、メトリック、およびセキュリティー・システムによって生成されるアラートの数が急増するにつれて、アラートの重要度を示す最も強力な指標の 1 つは、アラートによって影響を受けるエレメントの数です。例えば、API の呼び出し時に 5XX エラーを検出したユーザーの数、エラーを返した Kafka コンシューマー・グループの数、現在サイトを 3 秒を超えてロードしている CDN ロケーションの数、または単一ユーザーがクラウド・サービス・コンソールにログインしようとした異なるパスワードの数などが考えられます。

ほとんどのアラートの問題は、それらのアラートが問題を説明していることです。ただし、問題の重大度または広範囲を理解するには、ユーザーはデータを詳しく調べるか、ダッシュボードに依存する必要があります。

「固有カウント」アラートは、特定の検索基準に一致する、選択されたキー内の固有値の数に対してトリガーされます。つまり、特定のキーのカーディナリティーが検索に一致したということです。

比率アラート

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

この比率のアラートを使用して、以下をモニターします。

操作の正常性: 着信要求に対する発信応答の数、またはエラーの総数に対する特定のエラー・コードの比率をモニターします。
マーケティング: 特定の地域からのトラフィックと、地域キャンペーンに続く全体的なトラフィックとの間の比率をモニターします。
セキュリティー: すべての要求に対する、拒否された要求、特定の管理操作、またはブロックされたネットワーク・ドメインから発信された要求の比率をモニターします。

新しい値のアラート

新しい値のアラートは、ある時間間隔内に新しい値が最初に発生したときにトリガーされます。すべての値は、アラートがアクティブである間に動的に作成されたリストに対してテストされます。アラートは、ログのサブセットを識別する特定の照会によって設定され (必要な場合)、必要な間隔内で新しい値を追跡するためのキーを使用して定義されます。

このアラートは、システム内で発生する可能性のある異常動作を自動的に検出するのに役立ちます。

このアラート・タイプの使用例を以下に示します。

セキュリティー: 新規ドメイン接続によってアラートをトリガーできます。 IBM Cloud Logs セキュリティーはすべてのネットワーク・トラフィックにわたってすべてのセキュリティー情報をログに記録するため、新しいドメイン接続の結果として、フィールド security.highest_registered_domain に新しい値が設定される可能性があります。新しいドメイン接続は、潜在的なセキュリティー攻撃を指すことができます。
モニター: 新しいアプリケーション・エラー・コードによってアラートをトリガーできます。多くのアプリケーションが error_code フィールドを送信します。このフィールドの新しい値は、アプリケーションの新しい問題を示している可能性があります。

フロー・アラート

フロー・アラートは、定義された時間フレーム内に特定のシーケンスでアラート・イベントの任意の組み合わせが発生した場合に通知するように設計されています。

例えば、CPU 使用率が高いことによる HTTP エラー率の増加を通知するために、定義された時間フレーム内で CPU 使用率が高いアラートの後に HTTP エラー率が高いアラートが続く場合にトリガーするようにフロー・アラートを構成できます。

以下に、フロー・アラートを使用する利点をいくつか示します。

包括的なデータ相関: フロー・アラートを使用して、ログ、メトリック、およびセキュリティー・イベントに関するアラートを相関させることができます。この方法では、システムのパフォーマンスを全体的に把握することができ、情報を分離することはできません。相関情報は、情報に基づいて意思決定を行うために必要なすべてのデータを取得するのに役立ちます。
高度な根本原因分析: 問題の根本原因を特定するようにフロー・アラートを構成できます。問題の根本原因を特定するアラートを定義できるため、問題に迅速に対応して、システムのダウン時間を短縮し、運用効率を向上させることができます。
アラート疲労の軽減: 従来のモニタリング・システムでは、多くの場合、冗長なアラートでユーザーがあふれ、アラートの疲労や重大な問題を見逃す可能性があります。フロー・アラートは、順序付けられたタイム・バウンド基準フィルターを適用することで、誤ったアラートを減らすことができます。これは、設定されたすべての条件が満たされるとアラートが出されるため、不要な通知ノイズが削減されることを意味します。
カスタマイズ可能なアラート・シーケンス: このフロー・アラート固有の機能を使用すると、単純なドラッグ・アンド・ドロップ・インターフェースでアラート・シーケンスを定義できます。すべての基準が注文と時刻によって満たされた場合にのみトリガーされるフローを作成します。
効率的なトラブルシューティング: キャンバス上でアラートのシーケンスを視覚化する機能により、トラブルシューティングがより効率的になります。パターンを容易に識別し、アラートにつながるイベントのチェーンを理解し、問題を修正するために迅速に対処することができます。
リソース使用率の最適化: 誤ったアラートを削減し、根本原因を特定できるようにすることで、時間とリソースを節約できます。最適化により、チームは、誤ったアラートの絶え間ないストリームに集中するのではなく、より戦略的なタスクに集中することができます。

IBM Cloud Logs には、フロー・アラートをトリガーするユーザー定義アラートを視覚的に結合してチェーニングするためのフロー・ビルダー・ツールが用意されています。フロー・アラートの基本的なビルディング・ブロックは、ステージとグループです。

グループは、個々のユーザー定義アラートの論理的な組み合わせを表します。このグループは、複数の個々のアラートを結合するために OR、AND、および NOT 論理演算子をサポートします。

ステージは、指定された時間フレーム内にトリガーする必要があるアラート・グループを表します。 1 つのステージに複数のグループを含めることができます。

フロー・アラートには、以下の制限があります。

フロー・アラートには少なくとも 2 つのステージが必要です。
フロー・アラートの最初のステージには、1 つのグループのみを含めることができます。
すべてのステージの時間フレームの期間は 36 時間を超えることはできません。
最大 30 個のアラートを単一のフロー・アラートに結合できます。
以下のフロー・アラート・アラート・タイプは、NOT 論理演算子をサポートしていません。
- 新しい値のアラート
- 固有のカウント・アラート
- 即時通知
- 標準アラート