パフォーマンスの問題を自動的に検知するために、アプリケーションおよびインフラストラクチャのエンティティタイプの異常検知を構成できます。この機能により、正常性ルールのように複雑な評価条件を作成した経験がなくても、パフォーマンスの問題を簡単に検知できます。構成が完了すると、異常検知は機械学習機能を使用して、アプリケーション内の指定したエンティティが許容可能なパフォーマンス制限内で実行しているかどうかを自動的に判断します。

この機能を使用すると、次のことが可能になります。

  • 異常検知を構成するタグと属性によって、特定のエンティティをフィルタ処理します。
  • 選択に従って HTTP リクエストアクションをリンクし、パフォーマンスが許容範囲を逸脱した場合に自動応答を取得します。
  • ビジネスニーズに基づいて、異常検知アルゴリズムの感度レベル（高、中、または低）を選択します。
  • 開発環境またはステージング環境にあるエンティティの異常検知構成をテストします。

構成の作成方法

異常検知を構成するには

  1. [Configure] [> Anomaly Detection] をクリックします。
  2. [Create configuration ] をクリックして、構成ウィザードを開きます。

または、[Observe] ページからエンティティタイプの異常検知を構成できます。次の手順を実行します。

  1. [Observe] をクリックします。
  2. 次のいずれかのドメインに移動します。
    • アプリケーション パフォーマンス モニタリング
    • インフラストラクチャ
    • Kubernetes を利用）

  3. ドメインのエンティティ タイプをクリックします。

    ドメインエンティティ タイプ
    アプリケーション パフォーマンス モニタリングサービス、サービス インスタンス、サービス エンドポイント、またはビジネス トランザクション
    インフラストラクチャ

    [ホスト（Hosts）]

    異常検出は AWS ホストでのみサポートされています。
    Kubernetes を利用）クラスタ、名前空間、ポッド、またはワークロード

  4. [Entity Name] をクリックして詳細を表示します。

    Application Performing Monitoring ドメインの場合、クリックしてエンティティ名のリストを表示します。List
  5. [HEALTH AND ALERTING] セクションの [Anomaly Detection] をクリックします。
  6. [Create configuration ] をクリックして、選択したエンティティタイプに対応する構成ウィザードを開きます。

この構成プロセスには次の 3 つの手順が含まれます。

  1. エンティティと検出感度の選択
  2. リンクアクション
  3. 設定の確認

エンティティと検出感度の選択

次のドメインとそのエンティティタイプに対して異常検知を設定できます。

ドメインエンティティタイプモニター対象のメトリック
アプリケーション パフォーマンス モニタリング
  • ビジネストランザクション
  • サービス
  • サービスエンドポイント
  • サービスインスタンス
メトリック説明

Average Response Time

各リクエストがグローバルリソースを許可されるまで待機する必要がある時間。すべてのリクエストについて足し合わせてから、リクエストの総数で割り、ナノ秒はミリ秒に変換されます。

Call Per Minute

1 分間に報告されたコールの数。

Errors Per Minute

1 分間に報告されたエラーの数。
インフラストラクチャ

  • AWS EC2
メトリック説明
CPU Used Utilizationシステムまたはユーザの要求の処理のために CPU がビジー状態になってた時間のパーセンテージ。
Disk Avg IO Utilizationすべてのディスクとパーティションでの読み取りおよび書き込み要求の処理にかかった平均時間（レポート対象の合計期間のパーセンテージとして）。多くの場合、データベースは、読み取り/書き込み要求が頻繁に発生するため、高いディスク I/O 使用率をレポートします。
Memory Used Utilizationアプリケーションで使用されているメモリの量。
Network Incoming Errors/minネットワークで発生する着信パケットエラーの 1 分あたりの数。
Network Incoming Packets Droppedモニター対象のすべてのネットワークデバイスでドロップした 1 秒あたりの着信データパケットの数。
Network Outgoing Errors/minネットワークで発生する発信パケットエラーの 1 分あたりの数。
Network Outgoing Packets Droppedモニター対象のすべてのネットワークデバイスでドロップした 1 秒あたりの発信データパケットの数。
Page Faults/secシステムの 1 秒あたりのページフォールトの数。
AWS Application Load Balancer
メトリック説明

Target Response Time

リクエストがロードバランサを離れてから、ターゲットからの応答を受信するまでに経過した時間。

Target Connection Errors

ロードバランサとターゲットの間で正常に確立されなかった接続の数。
AWS Classic Load Balancer
メトリック説明

Backend Response Time

ロードバランサが登録済みインスタンスにリクエストを送信してから、インスタンスがレスポンスヘッダーの送信を開始するまでに経過した合計時間。
Backend Connection Errorsロードバランサと登録済みインスタンス間の失敗した接続の数。

Surge Queue Length

正常なインスタンスへのルーティングを保留しているリクエスト（HTTP リスナー）または接続（TCP リスナー）の総数。
Kubernetes を利用）Cluster
メトリック説明
CPU Usedクラスタで使用されている CPU の合計。
CPU Requestsクラスタ内のポッドからの CPU リクエストの合計。
Memory Usedクラスタ内のポッドによって使用されているメモリの合計。
Memory Requestsクラスタ内のポッドによって要求されたメモリの合計。
Memory Pressure使用可能なメモリの減少が原因でノードで発生したメモリ負荷の量。
Disk Pressure使用可能なディスク容量の減少が原因でノードで発生したディスク負荷の量。
Pods in Pending Stateクラスタ内のポッドは、リソース不足のためにノードにスケジュールできないため、保留状態になっています。
Pods in Failed Stateクラスタ内のポッドは、いくつかのエラーが原因で機能不全状態になっています。
Pods in Unknown Stateクラスタ内のポッドは、ポッドが実行されているノードが応答しなくなる、切断される、またはその他の問題が発生するため、不明な状態になっています。

名前空間
メトリック説明
CPU Used名前空間で使用されている CPU の合計。
CPU Requests名前空間内のポッドからの CPU リクエストの合計。
Memory Used名前空間内のポッドによって使用されているメモリの合計。
Memory Requests名前空間内のポッドによって要求されたメモリの合計。
Pods in Pending State名前空間内のポッドは、リソース不足のためにノードにスケジュールできないため、保留状態になっています。
Pods in Failed State名前空間内のポッドは、いくつかのエラーが原因で機能不全状態になっています。
Pods in Unknown State名前空間内のポッドは、ポッドが実行されているノードが応答しなくなる、切断される、またはその他の問題が発生するため、不明な状態になっています。

ワークロード
メトリック説明
CPU Usedワークロードで使用されている CPU の合計。
CPU Requestsワークロードからの CPU リクエストの合計。
Memory Usedワークロードによって使用されているメモリの合計。
Memory Requestsワークロードによって要求されたメモリの合計。

ポッド
メトリック説明
CPU Usedポッドで使用されている CPU の合計。
CPU Requestsポッドからの CPU リクエストの合計。
Memory Usedポッドによって使用されているメモリの合計。
Memory Requestsポッドによって要求されたメモリの合計。

ウィザードの Step 1 で、次の手順に従います。

  1. ドメインを選択します。
    • Application Performance Monitoring
    • Infrastructure
    • Kubernetes

  2. [Selected Entities ] で、エンティティタイプを選択します。

    [Observe] ページからエンティティタイプをすでに選択している場合、エンティティタイプは事前に選択されています。

  3. [Filter] セクションで、タグと属性を使用してフィルタ式を入力し、特定のエンティティタイプを絞り込みます。
    属性とタグは、選択したエンティティタイプに基づいて自動入力されます。属性とタグを使用して、特定のエンティティ名、エンティティタイプなどの異常検知を構成できます。たとえば、エンティティタイプ Service を選択し、次のフィルタ式を入力して、特定の条件の異常検知を構成できます。

    attributes(service.name) = 'test' && attributes(status) IN [Normal]
    サポートされているフィルタ操作の詳細については、「フィルタ」を参照してください。

  4. [Detection Sensitivity] セクションで、次の感度レベルのいずれかを選択します。

    感度レベル説明
    Highビジネスに不可欠なサービスにこのレベルを使用して、環境内で問題が確実に検知されるようにします。より多くのアラートをトリガーしますが、統計の信頼性は低くなります。
    Medium

    このレベルは、ビジネスにとって重要だがクリティカルではないサービスに使用します。デフォルトでは、この感度レベルが選択されています。

    Lowビジネスへの影響が少なく、アラートが多すぎるのを避けるために、このレベルを使用します。
  5. [Next] をクリックして HTTP リクエストアクションをリンクします。

ウィザードで、使用可能な HTTP リクエスト アクションを表示できます。Step 2Cisco Cloud Observability テナントを作成し、異常検出構成とリンクします。新しい HTTP リクエストアクションをリンクする場合は、最初にそれを作成する必要があります。「Create HTTP Request Action」を参照してください。

HTTP リクエストアクションをリンクするには、次を実行します。

  1. [+Add] をクリックします。
  2. [HTTP Action] セクションで、次の手順を実行します。
    1. リストからアクションを選択します。

    2. リストからトリガーを選択します。トリガーされるアクションに基づいて、複数のトリガーイベントを選択できます。

      右側の [Preview] ペインには、HTTP リクエストに含まれるモックデータが表示されます。リクエストヘッダーは表示されませんが、実際のリクエストにはヘッダーが含まれます。

  3. [+Add] をクリックしてステップ 2.a と 2.b を繰り返し、複数のアクションをリンクします。
  4. [Next] をクリックして、設定を確認します。

設定の確認

ウィザードの Step 3 で、次の詳細を指定して構成を完了します。

  1. 異常検知構成の名前を入力します。
  2. （オプション）構成の作成後、[Turn on this configuration] の選択を解除して無効にします。デフォルトで、このオプションは有効になっています。監視対象のメトリックでパフォーマンスの問題が検知されたときに自動応答を受信できるように、有効にしておくことをお勧めします。

  3. （オプション）構成をテストする場合は、[Yes, turn on test mode] を選択します。

    テストモードでは、非本番環境での異常検知機能を評価できます。このモードでは、メトリックデータの収集が少ない場合でも、異常検知によってパフォーマンスの問題が正確に検知されます。開発環境またはステージング環境でテストモードを使用できます。

  4. [Submit ] をクリックして、構成を保存します。

ウィザードの Step 1 でフィルタ条件を定義していない限り、構成は、指定されたエンティティタイプのすべての監視対象エンティティに適用されます。

構成の表示

[Configure > Anomaly Detection] ページには、クラウドテナントで使用可能な異常検知構成のリストが表示されます。このリストには、デフォルトの構成セットとユーザー定義の構成の両方が含まれています。要件に応じて、構成を更新、削除、または無効にすることができます。

エンティティの異常検知構成を無効化または削除すると、根本原因分析機能に影響します。根本原因分析機能を使用するには、コールパス内のすべてのエンティティに対して異常検知を常に有効にしておきます。