Metrics Advisor に関してよく寄せられる質問

2023 年 9 月 20 日以降は、新しい Metrics Advisor リソースを作成できなくなります。 Metrics Advisor サービスは、2026 年 10 月 1 日に廃止されます。

用語集で、多次元メトリックの定義を参照してください。

データ ポイントが 1 つ以上あれば、異常検出をトリガーできます。 ただし、これによって最適な精度が得られるわけではありません。 このサービスでは、データ フィードの作成時に "fill-gap" ルールとして指定した値を使用する、以前のデータ ポイントのウィンドウがあるものと想定されています。

検出対象のタイムスタンプの前にデータがあるようにすることをお勧めします。 データの細分性に基づく、推奨されるデータ量は次のようにさまざまです。

• Metrics Advisor は、顧客のデータソースから収集された時系列データを処理します。モデルの選択には履歴データが使用され、予想されるデータの境界を決定します。
• 顧客の時系列データと推論結果は、サービス内に格納されます。 顧客がサービス インスタンスをデプロイしたリージョンの外部で、Metrics Advisor によって、顧客データの格納または処理が行われることはありません。

Metrics Advisor は、ライブ ストリーミング データの検出を目的に設計されています。 このサービスによって検索および異常検出が実行される履歴データの最大長には、制限があります。 これは、特定の最も古いタイムスタンプより後のデータ ポイントに対してのみ、異常検出の結果が示されることを意味します。 最も古いタイムスタンプは、データの細分性によって異なります。

データの細分性に基づく、異常検出の結果が含まれる履歴データの長さは次のとおりです。

1. データ保持。 Metrics Advisor では、使用可能なデータがあるかどうかにかかわらず、現在のタイムスタンプから最大で 10,000 個分の時間間隔 (間隔とは) が保持されます。 この時間枠外のデータは削除されます。 さまざまなメトリック細分性で換算したデータ保持期間の日数。

2. 1 つのメトリック内の最大時系列数に関する制限。

1 つのメトリック内に複数のディメンションが含まれます。各ディメンションには複数の値が含まれます。 1 つのメトリックにおけるディメンションの組み合わせ最大数は、100,000 を超えないようにしてください。

• データ フィードの詳細ページで 80% の制限に達すると、Metrics Advisor リソース管理者とデータ フィード所有者に通知されます。
• メトリックが制限を超えた場合、データ フィードは一時停止され、顧客がフォローアップのアクションを実行するのを待ちます。 フィルター処理により、データ フィードを複数のデータ フィードに分割することをお勧めします。

3. 1 つの Metrics Advisor インスタンスに格納されるデータ ポイントの最大数に関する制限

Metrics Advisor により、最初のインジェストのタイムスタンプから開始して、インスタンスにオンボードされたすべてのデータ フィードからの合計データ ポイント数がカウントされます。 1 つの Metrics Advisor インスタンスに格納されるデータ ポイントの最大数は 20 億です。

• データ フィードの一覧ページと新しいデータ フィードの追加ページで 80% の制限に達すると、Metrics Advisor リソース管理者とすべてのユーザーに通知されます。
• 合計データ ポイント数が制限を超えた場合、すべてのデータ フィードは一時停止され、新しいフィードのオンボードもブロックされます。 使用されていないデータ フィードを削除するか、サブスクリプション内に新しい Metrics Advisor データ フィードを作成することをお勧めします。

リソースが使用停止になるケースは 2 つあります。

• Metrics Advisor リソースが作成され、データ フィードが 90 日以内にオンボードされていない場合。 非アクティブ状態であるため、このリソースは 90 日後に使用停止になります。
• 1 つまたは複数のデータ フィードが作成され、新しいデータが Metrics Advisor に取り込まれない場合は、サービスがアイドル モードになり、データが処理されません。 システムでは、メトリック細分性に従って、ソースからのデータの取得を引き続き定期的に試行します。 ただし、90 日間連続して使用できるデータがない場合や、処理される時系列が 1 つもない場合、リソースは使用停止になります。 リソースが使用停止になると、そのリソースに関連付けられている履歴データはすべて失われます。

使用を再開する場合は、新しいリソースを作成し、古いリソースを削除することをお勧めします。

ハードしきい値が事前に定義されている場合は、[Anomaly Detection Configurations] (異常検出の構成) で "ハードしきい値" を手動で設定できます。 しきい値がない場合は、AI を利用した "スマート検出" を使用できます。 詳細については、検出構成の調整に関する記事を参照してください。

"スマート検出" には、季節のパターンなど、データのパターンを学習する機能があります。 学習すると、通常のパターンに準拠していない、そのようなデータ ポイントを、異常として検出します。 詳細については、検出構成の調整に関する記事を参照してください。

いいえ。現在、Metrics Advisor では VNET の背後にあるデータ ソースがサポートされていません。

データが通常は非常に不安定で変動が大きく、非常に安定したり直線になってしまったりするときには警告を表示したい場合、変化が非常にわずかであれば、そのようなデータ ポイントが検出されるように "しきい値の変更" を構成することができます。 詳細については、異常検出の構成に関する記事を参照してください。

1. サブスクリプション管理者またはリソース グループ管理者の権限を持つユーザーが、Azure portal に作成された Metrics Advisor リソースに移動し、 [アクセス制御 (IAM)] タブを選択する必要があります。

2. [ロールの割り当ての追加] を選択します

3. Cognitive Services Metrics Advisor 管理者のロールを選択し、下の画像のように自分のアカウントを選択します。

4. [保存] ボタンを選択すると、Metrics Advisor リソースの管理者として追加されます。 上記のアクションはすべて、サブスクリプション管理者またはリソース グループ管理者が実行する必要があります。

   

5. アクセス許可が反映されるまでに最大で 1 分かかる場合があります。 次に、自分の Metrics Advisor ワークスペースを選択し、左側のナビゲーション パネルで [電子メール設定] オプションを選択します。 必須の項目 (特に SMTP 関連の情報) を入力します。

6. [保存] を選択すると、電子メールの構成がすべて設定されます。 新しいフックを作成してメトリックの異常をサブスクライブし、準リアルタイムのアラートを受け取れます。

メトリックは、ディメンションによって複数の時系列に分割できます。 たとえば、メトリック Response latency は、チームが所有するすべてのサービスに対して監視されます。 Service カテゴリをディメンションとして使用してメトリックを強化し、Service1、Service2 などによって Response latency を分割することができます。 各サービスは複数のデータ センター内の異なるコンピューターに展開できるので、メトリックは Machine や Data center によってさらに分割される可能性があります。

合計の Response latency から始めて、Service、Data center、Machine でメトリックにドリルダウンできます。 ただし、サービス所有者にとってはパス Service ->Data center ->Machine を使用する方が意味がある場合、またインフラストラクチャ エンジニアにとってはパス Data Center ->Machine ->Service を使用する方が意味がある場合もあります。 これはすべて、ユーザーの個々のビジネス要件に依存します。

Metric Advisor を使用すると、階層トポロジの 1 つのノードからドリルダウンまたはロール アップする任意のパスをユーザーが指定できます。 より正確には、階層のトポロジは、ツリー構造ではなく有向非巡回グラフです。 次のように、可能性のあるすべてのディメンションの組み合わせで構成される完全な階層トポロジがあります。

理論的には、ディメンション Service に Ls 個の個別値があり、ディメンション Data center に Ldc 個の個別値があり、ディメンション Machine に Lm 個の個別値がある場合、階層トポロジには (Ls + 1) * (Ldc + 1) * (Lm + 1) 個のディメンションの組み合わせが存在する可能性があります。

ただし、通常は、すべてのディメンションの組み合わせが有効であることはないので、複雑さを大幅に軽減できます。 現在、ユーザー自身がメトリックを集計している場合、ディメンションの数は制限されません。 Metrics Advisor によって提供されるロールアップ機能を使用する必要がある場合、ディメンションの数を 6 より大きくすることはできません。 ただし、メトリックのディメンションによって展開される時系列の数は、10,000 未満に制限されています。

診断ページの診断ツリー ツールには、トポロジ全体ではなく、異常が検出されたノードのみが表示されます。 これは、現在の問題に注目できるようにするためです。 また、メトリック内の異常がすべて表示されるとは限らず、代わりに寄与度に基づいて上位の異常が表示されます。 このようにして、異常なデータの影響、スコープ、分散パスをすばやく確認できます。 これにより、注目する必要がある異常の数が大幅に減り、ユーザーが重要な問題を把握して見つけるのに役立ちます。

たとえば、Service = S2 | Data Center = DC2 | Machine = M5 で異常が発生した場合、異常の偏差はやはり異常が検出された親ノード Service= S2 に影響を与えますが、異常は DC2 のデータ センター全体と M5 のすべてのサービスには影響しません。 インシデント ツリーは次のスクリーンショットのように構築されます。最上位の異常は Service = S2 でキャプチャされ、根本原因はどちらも Service = S2 | Data Center = DC2 | Machine = M5 に至る 2 つのパスで分析できます。

次のステップ

• Metrics Advisor の概要