Azure Monitor のカスタム メトリック (プレビュー)
Azure でリソースやアプリケーションをデプロイしたら、それらのパフォーマンスや正常性についての分析情報を得るために、テレメトリの収集を開始します。 Azure には、すぐに利用できるいくつかのメトリックがあります。 これらのメトリックは標準またはプラットフォームと呼ばれます。
より詳細な分析情報を得るためには、カスタムのパフォーマンス指標またはビジネス固有のメトリックを収集します。 これらのカスタム メトリックは、アプリケーション テレメトリ、Azure リソース上で実行されるエージェント、またはアウトサイドイン型の監視システムによって収集できます。 その後、これらのファイルを直接 Azure Monitor に送信できます。 カスタム メトリックが Azure Monitor に発行されると、標準の Azure メトリックと共に、それらに対して参照、クエリ、アラートを実行できます。
Azure Monitor のカスタム メトリックは現在、パブリック プレビューの段階にあります。
カスタム メトリックを送信する方法
カスタム メトリックは複数の方法で Azure Monitor に送信できます。
- Azure Application Insights SDK を使用してアプリケーションをインストルメント化し、カスタム テレメトリを Azure Monitor に送信する。
- Windows または Linux Azure VM に 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 にカスタム メトリックを直接送信する (
https://<azureregion>.monitoring.azure.com/<AzureResourceID>/metrics)。
価格モデルと保持期間
カスタム メトリックとメトリック クエリに対する課金が有効になる場合の詳細については、Azure Monitor の価格ページを参照してください。 要約すると、標準メトリック (プラットフォーム メトリック) を Azure Monitor メトリック ストアに取り込むためにコストは発生しませんが、カスタム メトリックは一般提供されると、コストが発生します。 メトリック API に対するクエリではコストが発生します。
カスタム メトリックは、プラットフォーム メトリックと同じ時間保持されます。
Note
Application Insights SDK を介して Azure Monitor に送信されたメトリックは、取り込まれたログ データとして課金されます。 追加のメトリック料金が発生するのは、Application Insights 機能の [カスタム メトリック ディメンションに関するアラートを有効にします] が選択されている場合のみです。 このチェックボックスにより、カスタム メトリック API を使用して Azure Monitor メトリック データベースにデータが送信され、より複雑なアラートが実行可能になります。 詳細については、Application Insights の価格モデルと、お客様のリージョンでの価格に関するページを参照してください。
カスタム メトリックを送信する方法
Azure Monitor にカスタム メトリックを送信するときは、メトリックで報告する各データ ポイント (または値) に次の情報が含まれている必要があります。
認証
Azure Monitor にカスタム メトリックを送信するには、メトリックを送信する側のエンティティで、要求の Bearer ヘッダーに有効な Azure Active Directory (Azure AD) トークンが存在する必要があります。 有効なベアラー トークンを取得するには、次の方法がサポートされています。
Azure リソースの管理 ID。 マネージド ID を使用して、特定の操作を実行するためのアクセス許可をリソースに付与できます。 たとえば、自身に関するメトリックをリソースが出力できるようにします。 リソース (またはそのマネージド ID) には、別のリソースに対する "メトリックの発行元の監視" アクセス許可を付与することもできます。 このアクセス許可を付与すると、そのマネージド ID で他のリソースのメトリックも生成できるようになります。
Azure AD のサービス プリンシパル。 このシナリオでは、Azure リソースについてのメトリックを出力するためのアクセス許可を Azure AD アプリケーション (またはサービス) に割り当てることができます。 要求を認証するために、Azure Monitor は Azure AD 公開キーを使用してアプリケーション トークンを検証します。 既存の "メトリックの発行元の監視" ロールには、既にこのアクセス許可が付与されています。 これは Azure portal で入手できます。
サービス プリンシパルには、どのようなリソースについてのカスタム メトリックをそれが出力するのかに応じて、必要なスコープで "メトリックの発行元の監視" ロールを付与することができます。 (たとえば、サブスクリプション、リソース グループ、または特定のリソース)。
ヒント
カスタム メトリックを出力するための Azure AD トークンを要求する場合は、トークンの要求対象であるユーザーやリソースが、https://monitoring.azure.com/ であることを確認してください。 必ず、末尾のスラッシュを含めるようにしてください。
サブジェクト
サブジェクト プロパティは、どの Azure リソース ID についてのカスタム メトリックが報告されるのかを表します。 この情報は、API 呼び出しの URL にエンコードされます。 各 API は、単一の Azure リソースのみのメトリック値を送信できます。
Note
リソース グループまたはサブスクリプションのリソース ID に対してカスタム メトリックを出力することはできません。
リージョン
リージョン プロパティは、メトリックを出力する対象のリソースがデプロイされている Azure リージョンを表します。 メトリックは、リソースがデプロイされているリージョンと同じリージョンの Azure Monitor エンドポイントに出力される必要があります。 たとえば、米国西部にデプロイされている VM についてのカスタム メトリックは、WestUS リージョンの Azure Monitor エンドポイントに送信される必要があります。 リージョン情報は API 呼び出しの URL にもエンコードされます。
Note
パブリック プレビュー期間中、カスタム メトリックは一部の Azure リージョンでのみ利用できます。 サポートされているリージョンの一覧は、この記事の後半のセクションに示しています。
Timestamp
Azure Monitor に送信されるデータ ポイントには、それぞれタイムスタンプが記録されている必要があります。 このタイムスタンプはメトリック値が測定または収集された日時を表します。 Azure Monitor は、現在から 20 分前までの、および現在から 5 分後までのタイムスタンプが付いたメトリック データを受け付けます。 タイムスタンプは、ISO 8601 形式である必要があります。
名前空間
名前空間は類似のメトリックを分類またはグループ化する方法です。 名前空間を使用すると、収集する情報またはパフォーマンス指標に基づいてメトリックのグループを分離できます。 たとえば、contosomemorymetrics という名前空間では、アプリをプロファイリングするメモリ使用量メトリックを追跡し、 contosoapptransaction という別の名前空間では、アプリケーション内のユーザー トランザクションに関するすべてのメトリックを追跡するといったことが可能です。
名前
名前プロパティは、報告されるメトリックの名前です。 通常は、測定内容を識別するのに十分なほど説明的な名前です。 たとえば、VM で使用されるメモリのバイト数を測定するメトリックです。 Memory Bytes In Use などのようなメトリック名になります。
ディメンション キー
ディメンションは、収集されているメトリックに関する他の特性を説明するのに役立つキーと値のペアです。 他の特性を使用することで、より多くの情報をメトリックについて収集し、より深い洞察を得ることが可能になります。
たとえば、Memory Bytes In Use メトリックに Process というディメンション キーを追加して、VM 上の各プロセスが消費するメモリのバイト数を取得することもできます。 このキーを使用すれば、メトリックをフィルタリングし、メモリ固有のプロセスが使用する容量を確認したり、メモリ使用量で上位 5 つのプロセスを識別したりすることが可能になります。
ディメンションは省略可能です。すべてのメトリックがディメンションを持つとは限りません。 カスタム メトリックは最大 10 個のディメンションを持つことができます。
ディメンション値
メトリックのデータ ポイントを報告するとき、報告されるメトリックのディメンション キーごとに、対応するディメンション値が存在します。 たとえば、VM で ContosoApp によって使用されているメモリを報告する場合以下のようになります。
- メトリック名は Memory Bytes in Use、
- ディメンション キーは Process、
- ディメンション値は ContosoApp.exe のようになります。
メトリック値を発行するとき、ディメンション キーごとに 1 つのディメンション値しか指定できません。 VM 上の複数のプロセスについて同じメモリ使用率を収集する場合、そのタイムスタンプで複数のメトリック値を報告できます。 各メトリック値は、Process ディメンション キーに異なるディメンション値を指定します。
ディメンションは省略可能ですが、メトリックの投稿にディメンション キーが定義されている場合、対応するディメンション値は必須です。
メトリックの値
Azure Monitor では、すべてのメトリックが 1 分刻みの間隔で保存されます。 場合によっては、メトリックを 1 分間に複数回サンプリングする必要があります。 たとえば、CPU 使用率などがそうです。 または、サインイン トランザクションの待機時間など、多くの不連続イベントに対してメトリックを測定する必要がある場合があります。
出力して Azure Monitor に送信し、費用を支払う必要がある未処理値の数を制限するには、ローカルで事前に集計して集計値を出力します。
- Min:1 分間のすべてのサンプルと測定値からの最小観測値。
- Max:1 分間のすべてのサンプルと測定値からの最大観測値。
- Sum:1 分間のすべてのサンプルと測定値からのすべての観測値の合計。
- Count:1 分間に取得されたサンプルと測定値の数。
たとえば、1 分の間に、アプリへのサインイン トランザクションが 4 件あり、それぞれについて測定された待機時間の結果が次のとおりであったとします。
| トランザクション 1 | トランザクション 2 | トランザクション 3 | トランザクション 4 |
|---|---|---|---|
| 7 ミリ秒 | 4 ミリ秒 | 13 ミリ秒 | 16 ミリ秒 |
この結果として Azure Monitor に送信されるメトリックは次のようになります。
- 最小:4
- 最大:16
- 合計:40
- カウント:4
アプリケーションにおいて、ローカルでの事前集計ができず、収集してすぐに個別のサンプルまたはイベントを出力する必要がある場合、未処理の測定値を出力することができます。 たとえば、アプリでサインイン トランザクションが発生するたびに、ただ 1 つの測定値と共にメトリックを Azure Monitor に発行することもできます。 その場合、サインイン トランザクションに要した時間が 12 ミリ秒だとすると、送信されるメトリックは次のようになります。
- 最小:12
- 最大:12
- 合計:12
- カウント:1
このプロセスでは、ある 1 分の間に、同じメトリックとディメンションの組み合わせに対して複数の値を出力できます。 その場合は、Azure Monitor によって、ある 1 分の間に出力されたすべての未処理値が集計されます。
カスタム メトリックの送信例
次の例では、仮想マシン用のメトリック名前空間 Memory Profile の下に Memory Bytes in Use というカスタム メトリックを作成します。 このメトリックは Process という 1 つのディメンションを持ちます。 タイムスタンプについては、メトリック値は 2 つのプロセスに対して出力されます。
{
"time": "2018-08-20T11:25:20-7:00",
"data": {
"baseData": {
"metric": "Memory Bytes in Use",
"namespace": "Memory Profile",
"dimNames": [
"Process"
],
"series": [
{
"dimValues": [
"ContosoApp.exe"
],
"min": 10,
"max": 89,
"sum": 190,
"count": 4
},
{
"dimValues": [
"SalesApp.exe"
],
"min": 10,
"max": 23,
"sum": 86,
"count": 4
}
]
}
}
}
Note
Application Insights、診断拡張機能、および InfluxData Telegraf エージェントは、正しいリージョンのエンドポイントに対するメトリック値を出力し、各出力で上記のプロパティをすべて保持するよう、既に構成されています。
カスタム メトリック定義
発行される各メトリック データ ポイントには、名前空間、名前、ディメンションの情報が含まれています。 カスタム メトリックが Azure Monitor に最初に出力されたときに、メトリックの定義が自動的に作成されます。 この新しいメトリック定義はその後、メトリック定義によってメトリックが出力される任意のリソースで検出可能になります。 出力される前に Azure Monitor でカスタム メトリックを事前定義する必要はありません。
Note
Azure Monitor では、カスタム メトリックの単位の定義はサポートされていません。
カスタム メトリックの使用
カスタム メトリックが Azure Monitor に送信されたら、Azure portal を使ってそれらを参照し、Azure Monitor REST API を使ってクエリを実行できます。 また、アラートを作成して、特定の条件が満たされたときに通知が送られるようにすることもできます。
Note
カスタム メトリックを表示するには、閲覧者または共同作成者ロールである必要があります。 「監視閲覧者」を参照してください。
Azure portal からカスタム メトリックを参照する
- Azure ポータルにアクセスします。
- [監視] ウィンドウを選択します。
- [メトリック] を選びます。
- カスタム メトリックを出力した対象のリソースを選択します。
- カスタム メトリックのメトリック名前空間を選択します。
- カスタム メトリックを選択します。
Azure portal でメトリックを表示する方法の詳細については、「Azure メトリックス エクスプローラーの概要」を参照してください。
サポートされているリージョン
パブリック プレビュー期間中、カスタム メトリックを発行する機能は一部の Azure リージョンでのみ利用できます。 つまりメトリックは、サポートされているいずれかのリージョンにあるリソースに対してしか発行できません。 Azure リージョンの詳細については、「Azure リージョン」を参照してください。
次の表は、カスタム メトリックがサポートされている Azure リージョンを示したものです。 この表には、それらのリージョンにあるリソースのメトリックが発行される、対応エンドポイントも示してあります。 エンドポイントのプレフィックスで使用される Azure リージョン コードは、空白が削除されただけのリージョンの名前です。
| Azure リージョン | リージョンのエンドポイントのプレフィックス |
|---|---|
| すべてのパブリック クラウド リージョン | https://<azure_region_code>.monitoring.azure.com |
待機時間とストレージのリテンション期間
新しく追加されたメトリックまたはメトリックに新しく追加されたディメンションが表示されるには、最大で 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 万件) がある場合は、調整やインジェストの遅延が発生する可能性があります。
次のステップ
以下のさまざまなサービスのカスタム メトリックを使用する。