Site24x7の直観的な異常検出フレームワークでは、要求時間、CPU利用率(CPU Utilization)、メモリ利用率(%)など、リソース属性の緩慢な増大をとらえています。さらには、これらのスパイク(突出値)を詳細に、Webクライアントに表とグラフの形式で提示。リソースのパフォーマンスを精密に調整し、インフラの問題を見逃さず対応可能となっています。異常が発生すれば、チーム内で、PDFやメールで共有できます。
監視メトリックのアノマリ検知を使用して、異常なスパイクや差を検知できます。アノマリ検知の監視を有効化すると、一定間隔で監視が行われます。一定のしきい値を用いると、長期的に一貫した監視を行えません。そのため、AIによりアノマリを検知して、即座にアラートを発生させます。
AIベースの監視で、次のようなメリットがあります。
異常エンジンのサイクルは、さまざまなステージからなります。そこには、コレクターからの流入データの処理や、異常の確認・発生が含まれます。異常エンジンは、検出にあたり、定量・定性比較モデルを採用します。メトリックの収集は15分ごとに行い、最新データをベースラインと比較します。監視の異常ベースライン値は、リソースの履歴データを継続監視して、Site24x7自身が決定します。
異常エンジンは、2項目で予測を行います。
この項目の目的は、負荷の重い処理を行い「イベント」を起動することです。1データのアノマリ検知の場合、1週間および2週間前の日の1時間ごとの95パーセンタイルデータが比較対象となります。例えば、金曜日にアノマリ検知が行われた場合、1週間前と2週間前の金曜日の値が、比較対象のデータとなります。比較対象のスパイクを取り除くために、ここでは95パーセンタイルデータが比較対象に利用されています。
複数データのアノマリ検知の場合、15分毎にSite24x7がデータをプッシュします。過去2週間における1時間ごとの95パーセンタイルデータが比較対象となります。アノマリ検知が行われた場合、検知対象のパフォーマンス属性が特定されます。
対象の比較を基に、レベルL1、L2,、L3での、イベントが生成されます。ここでのL3が、重大度の最も高いアノマリとなります。
このステージでは、依存監視に見られる異常を考慮して、定性モデルの性格が、異常の生成に加わります。イベントの合算により、「異常の重要度」のスコア基準が決まります。アノマリ発生で、スコアリングタスクが行われる際、依存監視の過去30分でアノマリが発生しているか、エンジンが確認します。スコアは個々の監視のデータ属性に基づいて決められ、ベースラインからの偏差のパーセンテージが該当します。
最終スコア決定には、次の手法を用います。
最後に、検出した異常のドメインスコア、依存性、重大度などの要素にもとづき、異常の重要度は3つに分類されます。
AIベースのしきい値プロファイルは、監視ステータスにおけるアノマリ検知で使用されます。一定のしきい値とは異なり、動的なしきい値を設定します。一定のしきい値プロファイルでは、ユーザー自身でしきい値を設定して、監視ステータスを判別する必要があります。問題が発生し、しきい値違反があった場合に通知を行います。
AIベースのしきい値の場合、しきい値の設定を行う必要がありません。監視のふるまいに基づいて、動的なしきい値が設定されます。これにより、ポーリング設定を行う必要がなくなります。ポーリング設定は異常なスパイク検知するのに重要ですが、アノマリ検知の場合は、スパイク発生時に即座にその報告が行われます。
しくみ
しきい値プロファイルの設定画面より、一定しきい値またはAIベースしきい値の選択が行えます。AIベースしきい値を選択した場合、アノマリ属性を有効にする重大度選択オプションが表示されます。アノマリが有効となっていない属性では、プロファイルタイプの選択は行えず、一定のしきい値設定オプションのみ表示されます。一定およびAIベースしきい値の両方を選択することはできません。
AIベースしきい値プロファイルについて:
異常ダッシュボードにより、ITインフラのネガティブなトレンドは、容易に事前分析が可能となります。異常のフィルターは、監視か監視グループの選定で、可能です。
次の手順で異常ダッシュボードを表示します。
ダッシュボードの内訳ビューでは、監視と監視グループすべてが、ダッシュボード左側に表示されます。ダッシュボードの右端では、異常サマリ グラフを、検出した異常ごとに、期間と理由に応じて表示できます(異常は 異常履歴に表示されています)。異常は、監視や監視グループ名で検索したり、重要度レベルでフィルターしたりして、並べ替え可能です。 異常サマリグラフでは、選択期間内の、監視/監視グループ名の異常の件数を表示します。監視の異常件数は、積み重ね棒グラフで表示します。それぞれの異常は、異常履歴セクションに、詳細メッセージとあわせて示します。表示される異常には、それぞれ異常メッセージごとに重要度フラグが立ちます。この異常の説明により、異常トレンドの詳細情報が収集できます。パフォーマンスの問題について、根本原因をさらに追及するには、異常の説明に付随するハイパーリンクをクリックしてください。
メッセージを指定して根本原因を知るをクリックすると、モーダル ダイアログで指示を求められ、過去4週間追跡したメトリックで線グラフを作成することが可能です。グラフにマウスカーソルをあてると、指定日時の実際の値が表示されます。メトリックのデフォルト値は、監視ごとに異なることがあります。すべての監視に、異常検出用に有効化された デフォルト属性があります。他方、これに加えて、線グラフ上のドロップダウンを利用し、監視を選択して、同じ期間について、他のパフォーマンス属性を見ることもできます。
次の監視で、デフォルトでアノマリ検出が有効となっています。
監視タイプ | パフォーマンス属性 |
Webサイト | 応答時間 |
DNSサーバー | 応答時間 |
FTP転送 | 応答時間 |
Webページ(ブラウザー) | 応答時間 |
ping | 応答時間 |
FTPサーバー | 応答時間 |
ポート(カスタム プロトコル) | 応答時間 |
POPサーバー | 応答時間 |
SMTPサーバー | 応答時間 |
Webトランザクション(ブラウザー) | 応答時間 |
Webトランザクション | 応答時間 |
メール配信監視 | 応答時間 |
REST API監視 | 応答時間 |
SOAP Webサービス監視 | 応答時間 |
Microsoft Hyper-Vサーバー |
正常性重大VM |
Microsoftフェールオーバークラスター |
未処理のメッセージ |
Microsoft Office 365 |
作成されたグループ |
プラグイン |
すべての属性 |
APMインサイト - アプリケーション |
応答時間 個々のコンポーネントの応答時間、リクエスト数と失敗数 個々の例外数 |
APMインサイトインスタンス |
応答時間 個々のコンポーネントの応答時間、リクエスト数と失敗数 個々の例外数 |
RUM |
アプリケーションスループット |
クラシックロードバランサー |
レイテンシー |
アプリケーションロードバランサー |
レイテンシー |
ネットワークロードバランサー |
処理済みバイト |
Simple Notification Service |
公開されたメッセージ数 |
Simple Storage Service (S3) |
バケットサイズ |
AWS Lambda |
呼び出し(合計) |
Elastic MapReduce |
失敗したジョブ |
Web Application Firewall (WAF) |
許可されたリクエスト |
Neptuneインスタンス |
CPU使用率 |
Neptuneクラスター |
CPU使用率 |
Lightsailインスタンス |
CPU使用率 |
Amazon GuardDuty |
1日ごとのFinding |
監視タイプ | パフォーマンス属性 |
EC2インスタンス |
CPU使用量 |
RDSインスタンス |
CPU使用量 |
Microsoft IISサーバー |
キュー済みリクエスト |
Microsoft Exchangeサーバー |
DBキャッシュサイズ |
Microsoft SQLサーバー |
接続 |
サーバー監視 |
CPU使用量 |
Microsoft Sharepointサーバー Server |
アクティブリクエスト |