Azure Monitor のカスタム メトリック (プレビュー)
Azure には、すぐに利用できるいくつかのメトリックがあります。 これらのメトリックは標準またはプラットフォームと呼ばれます。 カスタム メトリックは、アプリケーションのテレメトリ、Azure Monitor エージェント、Azure リソースで実行される診断拡張機能、または外部監視システムを介して収集できるパフォーマンス インジケーターまたはビジネス固有のメトリックです。 カスタム メトリックが Azure Monitor に発行されると、標準の Azure メトリックと共に、それらに対して参照、クエリ、アラートを実行できます。
Azure Monitor のカスタム メトリックは現在、パブリック プレビューの段階にあります。
カスタム メトリックを送信する方法
カスタム メトリックは複数の方法で Azure Monitor に送信できます。
- Azure Application Insights SDK を使用して、カスタム テレメトリを Azure Monitor に送信することで、アプリケーションをインストルメント化する。
- Windows または Linux Azure 仮想マシンまたは Azure 仮想マシン スケール セットに Azure Monitor エージェントをインストールし、データ収集ルールを使用してパフォーマンス カウンターを Azure Monitor メトリックに送信する。
- Azure VM、Virtual Machine Scale Sets、クラシック VM、またはクラシック クラウド サービスに Azure Diagnostics 拡張機能をインストールします。 次に、パフォーマンス カウンターを Azure Monitor に送信します。
- Azure Linux VM に InfluxData Telegraf エージェント をインストールします。 Azure Monitor 出力プラグインを使用してメトリックを送信します。
- カスタム メトリックを Azure Monitor REST API に直接送信する。
価格モデルと保持期間
一般に、標準メトリック (プラットフォーム メトリック) を Azure Monitor メトリック ストアに取り込むためにコストは発生しませんが、カスタム メトリックは一般提供されると、コストが発生します。 メトリック API に対するクエリではコストが発生します。 カスタム メトリックとメトリック クエリに対する課金が有効になる場合の詳細については、Azure Monitor の価格ページを参照してください。
カスタム メトリックは、プラットフォーム メトリックと同じ時間保持されます。
Note
エクスペリエンスを向上させるために、Application Insights Classic API (SDK) から Azure Monitor に送信されるカスタム メトリックは、常に Log Analytics とメトリック ストアの両方に格納されます。 これらのメトリックを格納するコストは、Log Analytics によって取り込まれたボリュームにのみ基づいています。 メトリック ストアに格納されているデータに対して追加コストは発生しません。
カスタム メトリック定義
発行される各メトリック データ ポイントには、名前空間、名前、ディメンションの情報が含まれています。 カスタム メトリックが Azure Monitor に最初に出力されたときに、メトリックの定義が自動的に作成されます。 この新しいメトリック定義はその後、メトリック定義によってメトリックが出力される任意のリソースで検出可能になります。 出力される前に Azure Monitor でカスタム メトリックを事前定義する必要はありません。
Note
Application Insights、診断拡張機能、および InfluxData Telegraf エージェントは、正しいリージョンのエンドポイントに対するメトリック値を出力し、各出力で上記のプロパティをすべて保持するよう、既に構成されています。
カスタム メトリックの使用
カスタム メトリックが Azure Monitor に送信されたら、Azure portal を使ってそれらを参照し、Azure Monitor REST API を使ってクエリを実行できます。 また、アラートを作成して、特定の条件が満たされたときに通知が送られるようにすることもできます。
Note
カスタム メトリックを表示するには、閲覧者または共同作成者ロールである必要があります。 「監視閲覧者」を参照してください。
Azure portal からカスタム メトリックを参照する
- Azure ポータルにアクセスします。
- [監視] ウィンドウを選択します。
- [メトリック] を選びます。
- カスタム メトリックを出力した対象のリソースを選択します。
- カスタム メトリックのメトリック名前空間を選択します。
- カスタム メトリックを選択します。
Azure portal でメトリックを表示する方法の詳細については、「Azure Monitor メトリック ス エクスプローラーを使用したメトリックの分析」を参照してください。
待機時間とストレージのリテンション期間
新しく追加されたメトリックまたはメトリックに新しく追加されたディメンションが表示されるには、最大で 3 分かかる場合があります。 データがシステムに入った後、99% の場合 30 秒未満で表示されます。
メトリックを削除するかディメンションを削除した場合、変更が反映されてシステムから削除されるまでに 1 週間から 1 か月かかることがあります。
クォータと制限
Azure Monitor では、カスタム メトリックの使用に次の制限があります。
| カテゴリ | 制限 |
|---|---|
| リージョンごとのサブスクリプションのアクティブな時系列の合計 | 50,000 |
| メトリックあたりのディメンション キー | 10 |
| メトリック名前空間、メトリック名、ディメンション キー、およびディメンション値の文字列の長さ | 256 文字 |
| utf-8 エンコードを使用した、すべてのカスタム メトリック名の合計長 | 64 KB |
アクティブ時系列は、メトリック、ディメンション キー、またはディメンション値の任意の一意な組み合わせであり、過去 12 時間以内にメトリック値が発行されたものとして定義されます。
50,000 という時系列の制限を理解するために、次のメトリックについて考えてみましょう。
"サーバーの応答時間" と、Region、Department、CustomerID というディメンション
このメトリックの場合、10 個のリージョン、20 個の部門、100 人の顧客がある場合、10 x 20 x 100 = 20,000 という時系列が得られます。
100 個のリージョン、200 個の部門、2,000 人の顧客がある場合、100 x 200 x 2000 = 40,000,000 の時系列となり、このメトリックだけでも制限をはるかに超えています。
繰り返しになりますが、この制限は個々のメトリック用ではありません。 これは、サブスクリプションとリージョン全体のすべてのメトリックの合計に対するものです。
次の手順に従って、現在のアクティブな時系列メトリックの合計と、トラブルシューティングに役立つ詳細情報を確認します。
- Azure portal の Monitor セクションに移動します。
- 左側で [メトリック] を選択します。
- [スコープの選択] で、該当するサブスクリプションとリソース グループにチェックマークを付けます。
- [Refine scope] (スコープの絞り込み) で、[カスタム メトリック使用量] と目的の場所を選択します。
- [適用] ボタンを選択します。
- [Active Time Series] (アクティブな時系列)、[Active Time Series Limit] (アクティブな時系列の制限)、または [Throttled Time Series] (調整された時系列) のいずれかを選択します。
すべてのカスタム メトリック名の合計長には 64 KB の制限があります (utf-8 または 1 文字あたり 1 バイトの前提)。 64 KB の制限を超えた場合、追加のメトリックのメタデータは使用できません。 追加のカスタム メトリックのメトリック名は、Azure portal で選択フィールドに表示されません。また、メトリック定義の要求で API によって返されません。 メトリック データは引き続き使用でき、クエリを実行できます。
制限を超えた場合は、送信するメトリックの数を減らすか、名前の長さを短くします。 その後、新しいメトリックの名前が表示されるまでに最大 2 日かかります。
制限に達しないようにするには、メトリック名に変数やディメンションの側面を含めないようにしてください。
たとえば、サーバーの CPU 使用率のメトリック CPU_server_12345678-319d-4a50-b27e-1234567890ab と CPU_server_abcdef01-319d-4a50-b27e-abcdef012345 は、メトリック CPU として、Server ディメンションを使用して定義する必要があります。
設計の制限と考慮事項
監査の目的で Application Insights を使用する。 Application Insights テレメトリ パイプラインは、パフォーマンスへの影響を最小限に抑え、ネットワーク トラフィックによるアプリケーションの監視を制限するために最適化されています。 そのため、初期データセットが大きくなりすぎると、スロットルまたはサンプリング (テレメトリの一部のみを取得し、残りは無視する) が行われます。 この動作により、一部のレコードがドロップされる可能性があるため、監査目的で使用することはできません。
名前に変数を持つメトリック。 メトリック名の一部として変数を使用しないでください。 代わりに定数を使用してください。 変数の値が変わるたびに、Azure Monitor によって新しいメトリックが生成されます。 すると、Azure Monitor のメトリック数の制限にすぐに達します。 一般に、開発者がメトリック名に変数を含めるのは、1 つのメトリック内で複数の時系列を追跡することがどうしても必要な場合ですが、変数のメトリック名ではなくディメンションを使用する必要があります。
カーディナリティが高いメトリック ディメンション。 ディメンション内の有効な値が多すぎる (カーディナリティが高い) メトリックは、50,000 の制限に達する可能性がはるかに高くなります。 通常は、常に変化する値をディメンジョンの名前に使用しないでください。 たとえば、タイムスタンプは決してディメンションにしないでください。 サーバー、顧客、または製品 ID を使用できますが、これらの型のそれぞれの数が少ない場合に限られます。
試しに、そのようなデータを本当にグラフに描画したいかを考えてみてください。 サーバーが 10 台、場合によっては 100 台ある場合は、比較のためにそれらすべてをグラフで確認すると便利な場合があります。 しかし、1,000 台の場合、結果のグラフを読むことは難しい、または不可能でしょう。 ベスト プラクティスは、有効な値を 100 未満に抑えることです。 300 までは、どちらとも言えない領域です。 この数を超える必要がある場合は、代わりに Azure Monitor カスタム ログを使用してください。
名前またはカーディナリティの高いディメンションに変数がある場合、次の問題が起こります。
- 調整が原因でメトリックの信頼性が低下します。
- メトリック エクスプローラーが機能しない。
- アラートと通知が予測不能になる。
- コストが予期せずに増える。 Microsoft は、この機能がパブリック プレビュー段階にある間、ディメンションを使用したカスタム メトリックに対して課金しません。 将来的に課金が開始されると、予期しないコストが発生します。 計画では、監視された時系列の数と行われた API 呼び出しの数に基づいて、メトリックの消費に対して課金されます。
メトリック名またはディメンション値に識別子またはカーディナリティの高いディメンションが誤って設定されている場合は、変数部分を削除することで簡単に修正できます。
ただし、シナリオに高いカーディナリティが不可欠な場合、集計されたメトリックはおそらく適切な選択肢にはなりません。 カスタム ログの使用 (つまり、trackEvent を使用した trackMetric API 呼び出し) に切り替えます。 ただし、ログでは値が集計されないので、すべてのエントリが格納されます。 その結果、短い期間に大量のログ (たとえば 1 秒間に 100 万件) がある場合は、調整やインジェストの遅延が発生する可能性があります。
次のステップ
以下のさまざまなサービスのカスタム メトリックを使用する。