Azure Monitor の診断設定

  • [アーティクル]

この記事では、Azure プラットフォームのメトリックとログを異なる宛先に送信するための診断設定を作成し、構成する方法について詳しく説明します。

プラットフォームのメトリックは、既定では、構成なしで Azure Monitor のメトリックに自動的に送信されます。

プラットフォーム ログにより、Azure リソースとそれらが依存している Azure プラットフォームの詳細な診断情報と監査情報が提供されます。

  • リソース ログは、宛先にルーティングされるまで収集されません。
  • アクティビティ ログは単独で存在しますが、他の場所にルーティングすることができます。

各 Azure リソースには、次の条件を定義する独自の診断設定が必要です。

  • ソース: 設定に定義された宛先に送信するメトリックとログ データの種類。 使用可能な種類は、リソースの種類によって異なります。
  • 宛先: 1 つ以上の宛先。

1 つの診断設定では、各宛先を 1 つだけ定義することができます。 特定の種類の複数の宛先 (たとえば、2 つの異なる Log Analytics ワークスペース) にデータを送信する場合は、複数の設定を作成します。 各リソースには、最大 5 つの診断設定を作成できます。

警告

リソースを削除する必要がある場合は、まずその診断設定を削除する必要があります。 そうしないと、このリソースを再作成した場合に、各リソースのリソース構成によっては、削除されたリソースの診断設定が新しいリソースに含まれる可能性があります。 診断設定が新しいリソースに含まれている場合、診断設定で定義されているリソース ログの収集が再開され、該当するメトリックとログ データが以前に構成された宛先に送信されます。

また、環境をきれいな状態に保つためにも、削除するリソースの診断設定を削除し、再使用を計画しないようにするのはよいことです。

次のビデオでは、診断設定を使用してリソース プラットフォーム ログをルーティングする手順について説明します。 ビデオは以前に行なわれたものです。 次の変更点に注意してください。

  • 現在は 4 つの宛先があります。 プラットフォームのメトリックとログを、特定の Azure Monitor パートナーに送信できます。
  • カテゴリ グループと呼ばれる新機能が 2021 年 11 月に導入されました。

これらの新しい機能に関する情報が、この記事に記載されています。

ソース

ソース オプションを次に示します。

メトリック

AllMetrics 設定を使用すると、リソースのプラットフォームのメトリックが他の宛先にルーティングされます。 このオプションは、すべてのリソース プロバイダーに存在するとは限りません。

リソース ログ

ログについては、個別にルーティングするログ カテゴリを選択するか、カテゴリ グループを選択できます。

Note

カテゴリ グループは、メトリックには適用されません。 すべてのリソースに利用可能なカテゴリ グループがあるとは限りません。

"カテゴリ グループ" を使用すると、個別のログ カテゴリを選択する代わりに、定義済みのグループに基づいてリソース ログを動的に収集できます。 Microsoft が、すべての Azure サービスで特定のユース ケースを監視するのに役立つグループを定義しています。

時間の経過と共に、新しいログが展開されたり、評価が変更されたりして、グループ内のカテゴリが更新される可能性があります。 ログ カテゴリがカテゴリ グループに追加または削除されると、診断設定を更新しなくても、ログ コレクションが自動的に変更されます。

カテゴリ グループを使用する場合、次のようになりました。

  • 個々のカテゴリの種類に基づいてリソース ログを個別に選択できなくなりました。
  • Azure Storage に送信されたログに保持設定を適用できなくなりました。

現時点では、次の 2 つのカテゴリグループがあります。

  • すべて: リソースによって提供されるすべてのリソース ログ。
  • 監査: データまたはサービスの設定に対する顧客の操作を記録するすべてのリソース ログ。 監査ログは、最も関連性の高い監査データを提供するための各リソース プロバイダーが試みることですが、監査基準の観点からは十分に検討されていない場合があることに注意してください。

注: Azure SQL Database の監査を有効にしても、Azure SQL Database の監査は有効になりません。 データベース監査を有効にするには、Azure Database の監査ブレードから有効にする必要があります。

アクティビティ ログ

「アクティビティ ログの設定」セクションを参照してください。

変換先

プラットフォーム ログとメトリックは、次の表に一覧表示されている宛先に送信できます。

転送中のデータのセキュリティを確保するため、トランスポート層セキュリティ (TLS) を構成することを強くお勧めします。 すべての宛先エンドポイントで TLS 1.2 がサポートされています。

到着地 説明
Log Analytics ワークスペース メトリックは、ログ形式に変換されます。 このオプションは、すべてのリソースの種類で使用できるとは限りません。 Azure Monitor ログ ストア (Log Analytics から検索可能) に送信すると、既存のログ データを使用してクエリ、アラート、および視覚化に統合できます。
Azure Storage アカウント ストレージ アカウントにログとメトリックをアーカイブすると、監査、スタティック分析、またはバックアップに役立ちます。 Azure Monitor ログや Log Analytics ワークスペースを使用する場合と比較すると、ストレージはコストが低く、ログを無期限に保持することができます。
Azure Event Hubs Event Hubs にログとメトリックを送信すると、サードパーティ製の SIEM やその他の Log Analytics ソリューションなどの外部システムにデータをストリームできます。
Azure Monitor パートナーとの統合 Azure Monitor と Microsoft 以外のその他の監視プラットフォームとの間で特殊な統合を行うことができます。 統合はパートナーのいずれかを既に使用している場合に便利です。

アクティビティ ログの設定

アクティビティ ログでは診断設定が使用されますが、個々のリソースではなくサブスクリプション全体に適用されるため、独自のユーザー インターフェイスがあります。 ここに示されている宛先情報は引き続き適用されます。 詳細については、「Azure アクティビティ ログ」をご覧ください。

要件と制限事項

このセクションでは、要件と制限事項について説明します。

テレメトリが宛先に到達するまでの時間

診断設定を行うと、90 分以内にデータが選択した宛先に流れ始めます。 24 時間以内に情報が届かない場合は、次のいずれかです。

  • ログが生成されていない。
  • 基盤のルーティング メカニズムに問題が発生している。 構成を無効にしてから、再度有効にしてみてください。 問題が引き続き発生する場合は、Azure portal から Azure サポートにお問い合わせください。

ソースとしてのメトリック

メトリックのエクスポートには特定の制限があります。

  • 診断設定を介した多次元メトリックの送信は現在サポートされていません: ディメンションのあるメトリックは、ディメンション値全体が集計され、フラット化された一次元メトリックとしてエクスポートされます。 たとえば、ブロックチェーンに関する IOReadBytes メトリックは、ノード レベルごとに探索してグラフ化できます。 ところが、診断設定を介してエクスポートすると、エクスポートされたメトリックには、すべてのノードに対するすべての読み取りバイト数が表示されます。
  • すべてのメトリックが診断設定でエクスポート可能であるとは限りません: 内部の制限により、すべてのメトリックが Azure Monitor ログまたは Log Analytics にエクスポートできるわけではありません。 詳細については、サポートされるメトリックのリストのエクスポート可能な列を参照してください。

特定のメトリックについてこれらの制限を回避するには、メトリック REST API を使用して手動でそれらを抽出できます。 その後、Azure Monitor Data Collector API を使用して、Azure Monitor ログにインポートできます。

宛先の制限事項

診断設定の宛先は、診断設定の作成前に作成する必要があります。 設定を構成するユーザーが両方のサブスクリプションに対して適切な Azure ロールベースのアクセス制御アクセス権を持っている場合、宛先はログを送信するリソースと同じサブスクリプションに属している必要はありません。 Azure Lighthouse を使用して、別の Azure Active Directory テナントのワークスペース、ストレージ アカウント、またはイベント ハブに診断設定を送信することも可能です。

次の表では、リージョン制限など、宛先別の固有要件をまとめてあります。

宛先 要件
Log Analytics ワークスペース このワークスペースは、監視対象のリソースと同じリージョンにする必要はありません。
ストレージ アカウント データへのアクセスをより適切に制御できるように、他の非監視データが格納されている既存のストレージ アカウントは使用しないでください。 アクティビティ ログとリソース ログを一緒にアーカイブする場合は、中央の場所にすべての監視データを保持するために、同じストレージ アカウントを使用できます。

データを不変ストレージに送信するには、Azure Blob Storage の不変ポリシーの設定と管理の説明に従って、ストレージ アカウントの不変ポリシーを設定します。 保護された追加 BLOB 書き込みの有効化を含め、このリンク先の記事のすべての手順に従う必要があります。

ストレージ アカウントは、リソースがリージョン別の場合、監視対象のリソースと同じリージョンにする必要があります。

仮想ネットワークが有効になっている場合、診断設定からストレージ アカウントにアクセスできません。 ストレージ アカウント で、このファイアウォール設定をバイパスするように [信頼された Microsoft サービスを許可する] を有効にして、Azure Monitor 診断設定サービスに ストレージ アカウントへのアクセス権が付与されるようにする必要があります。

Azure DNS ゾーン エンドポイント (プレビュー) と Azure Premium LRS (ローカル冗長ストレージ) ストレージ アカウントは、ログまたはメトリックの宛先としてサポートされていません。
Event Hubs 名前空間の共有アクセス ポリシーでは、ストリーミング メカニズムが保有するアクセス許可が定義されます。 Event Hubs にストリーミングするには、管理、送信、リッスンの各アクセス許可が必要です。 ストリーミングを含めるように診断設定を更新するには、その Event Hubs の承認規則に対する ListKey アクセス許可が必要です。

イベント ハブ名前空間は、リソースがリージョン別の場合、監視対象のリソースと同じリソースにする必要があります。

仮想ネットワークが有効になっている場合、診断設定からストレージ リソースにアクセスできません。 Event Hub で、このファイアウォール設定をバイパスするように [信頼された Microsoft サービスを許可する] を有効にして、Azure Monitor 診断設定サービスにストレージ リソースへのアクセス権が付与されるようにする必要があります。
パートナー統合 ソリューションはパートナーによって異なります。 詳細については、Azure Monitor パートナー統合に関するドキュメントを参照してください。

コストの制御

Log Analytics ワークスペースでデータを収集するにはコストがかかるため、各サービスに必要なカテゴリのみを収集する必要があります。 リソース ログのデータ量はサービスによって大きく異なります。

また、プラットフォーム メトリックはすでにメトリックで収集されているため、Azure リソースからは収集しないことをお勧めします。 ログ クエリを使用してより複雑な分析を行うためにワークスペースにメトリック データが必要な場合にのみ、診断データを構成してメトリックを収集するようにしてください。

診断設定では、リソース ログを細かくフィルター処理することはできません。 しかし、特定のカテゴリの特定のログだけが必要で、他のログは必要ないこともあるでしょう。 また、不要な列をデータから削除したい場合もあるかもしれません。 そのような場合には、ワークスペースで変換を使用して、不要なログをフィルター処理します。

また、変換を使用して、有用な情報を持たない列を削除することで、必要なレコードのストレージ要件を減らすこともできます。 たとえば、リソース ログの中のエラー イベントはアラートのために必要となるでしょう。 しかし、これらのレコードの中の特定の列は必要ないのに、大量のデータが含まれているかもしれません。 これらの列を削除するテーブルの変換を作成できます。

ヒント

Azure Monitor のコストを削減するための戦略については、コストの最適化と Azure Monitor に関するページを参照してください。

診断設定の作成

診断設定は、複数の方法を使用して作成および編集できます。

Azure portal では、Azure Monitor メニューから、またはリソースのメニューから診断設定を構成できます。

  1. Azure portal で診断設定を構成する場所は、リソースによって異なります。

    • リソースが 1 つの場合は、リソースのメニューで、[監視] の [診断設定] を選びます。

      Azure portal のリソース メニューの [監視] セクションが示されたスクリーンショット。[診断設定] が強調表示されています。

    • リソースが 1 つまたは複数の場合は、Azure Monitor メニューで、[設定] で [診断設定] を選んでから、リソースを選びます。

      [Azure Monitor] メニューの [設定] セクションが示されたスクリーンショット。[診断設定] が強調表示されています。

    • アクティビティ ログの場合は、[Azure Monitor] メニューで [アクティビティ ログ] を選び、[診断設定] を選びます。 アクティビティ ログのレガシ構成が無効になっていることを確認してください。 手順については、既存の設定を無効にするに関するページを参照してください。

      [Azure Monitor] メニューが示されたスクリーンショット。アクティビティ ログが選択されており、[監視 - アクティビティ ログ] メニュー バーで [診断設定] が強調表示されています。

  2. 選択したリソースの設定が存在しない場合は、設定を作成するように求められます。 [診断設定の追加] を選択します。

    既存の設定がなく、[診断設定の追加] が示されたスクリーンショット。

    リソースに対する既存の設定が存在する場合は、構成済みの設定の一覧が表示されます。 [診断設定を追加する] を選び、新しい設定を追加します。 または、[設定の編集] を選び、既存の設定を編集します。 各設定には、各送信先の種類を 1 つだけ含めることができます。

    既存の設定への診断設定の追加を示すスクリーンショット。

  3. 設定にまだ名前がない場合は、名前を付けます。

    診断設定の名前が示されたスクリーンショット。

  4. ルーティングするログとメトリック: ログの場合は、カテゴリ グループを選ぶか、後で指定した宛先に送信するデータのカテゴリごとに個々のチェックボックスをオンにします。 カテゴリの一覧は、Azure サービスごとに異なります。 メトリックを Azure Monitor ログにも保存する場合は、[AllMetrics] を選びます。

  5. 宛先の詳細: 各宛先のチェックボックスをオンにします。 詳細情報を追加できるように、オプションが表示されます。

    [Log Analytics への送信] と [イベント ハブへのストリーミング] が示されたスクリーンショット。

    1. Log Analytics: サブスクリプションとワークスペースを入力します。 ワークスペースがない場合は、先に進む前に作成する必要があります。

    2. Event Hubs: 次の条件を指定します。

      • サブスクリプション: イベント ハブが含まれるサブスクリプション。
      • イベント ハブ名前空間: 存在しない場合は、作成する必要があります。
      • イベント ハブの名前 (省略可能): すべてのデータの宛先の名前。 名前を指定しない場合は、ログ カテゴリごとにイベント ハブが作成されます。 複数のカテゴリを送信する場合は、名前を指定して、作成するイベント ハブの数を制限することができます。 詳細については、「Azure Event Hubs のクォータと制限」をご覧ください。
      • イベント ハブ ポリシー名 (同じく省略可能): ポリシーによってストリーミング メカニズムのアクセス許可が定義されます。 詳細については、Event Hubs の機能に関するページを参照してください。

    3. ストレージ: [サブスクリプション]、[ストレージ アカウント]、[保持] ポリシーを選びます。

      ストレージ カテゴリと宛先の詳細が示されたスクリーンショット。

      ヒント

      アイテム保持ポリシーは 0 に設定し、Azure Storage のライフサイクル ポリシーを使用するか、またはスケジュールされたジョブを使用してストレージからデータを削除することを検討してください。 このような方針を用いることで、多くの場合、動作の一貫性が向上します。

      まず、ストレージをアーカイブ用に使用している場合は、一般的にデータを 365 日以上保持する必要があります。

      2 つ目の方法として、0 より大きいアイテム保持ポリシーを選択すると、保存時に有効期限日がログに付加されます。 保存後にこれらのログの日付を変更することはできません。

      たとえば、WorkflowRuntime のアイテム保持ポリシーを 180 日に設定し、24 時間後に 365 日に設定した場合、最初の 24 時間の間に保存されたログは 180 日後に自動的に削除されます。 その種類の後続のすべてのログは、365 日後に自動的に削除されます。 後でアイテム保持ポリシーを変更しても、最初の 24 時間のログが 365 日間保持されるようにはなりません。

    4. パートナー統合: まず、サブスクリプションにパートナー統合をインストールする必要があります。 構成オプションはパートナーによって異なります。 詳細については、「Azure Monitor パートナーとの統合」を参照してください。

  6. [保存] を選択します。

しばらくすると、このリソースに対する設定のリストに新しい設定が表示されます。 ログは、新しいイベント データが生成されると、指定された宛先にストリーミングされます。 イベントが生成されてから、それが Log Analytics ワークスペースに表示されるまで、最大で 15 分ほどかかる場合があります。

トラブルシューティング

トラブルシューティングのいくつかのヒントを次に示します。

メトリック カテゴリがサポートされていない

診断設定をデプロイすると、"メトリック カテゴリ 'xxxx' はサポートされていません" のようなエラー メッセージが表示されます。このエラーは、前のデプロイが成功した場合でも発生する可能性があります。

この問題は、Resource Manager テンプレート、REST API、Azure CLI、または Azure PowerShell を使用するときに発生します。 サポートされているカテゴリ名のみが表示されるため、Azure portal を介して作成された診断設定は影響を受けません。

この問題は、基になる API の最近の変更が原因で発生します。 AllMetrics 以外のメトリック カテゴリはサポートされておらず、いくつかの特定の Azure サービスの場合を除き、サポートされていませんでした。 以前は、診断設定のデプロイ時に他のカテゴリ名は無視されていました。 これらのカテゴリは、Azure Monitor バックエンドによって AllMetrics にリダイレクトされました。 2021 年 2 月の時点で、提供されたメトリック カテゴリが正確であることを明確に確認するためにバックエンドが更新されました。 この変更が原因で一部のデプロイに失敗しました。

このエラーが発生した場合は、メトリック カテゴリ名をすべて AllMetrics に置き換えるようにデプロイを更新して問題を解決してください。 以前にデプロイで複数のカテゴリを追加していた場合は、AllMetrics 参照を持つものを 1 つだけ保持します。 問題が引き続き発生する場合は、Azure portal から Azure サポートにお問い合わせください。

resourceID の 非 ASCII 文字が原因で設定が消える

診断設定では、非 ASCII 文字のリソース ID はサポートされていません。 たとえば、Preproducción という用語を考えてみましょう。 Azure でリソースの名前を変更することはできないため、唯一のオプションは、非 ASCII 文字を使用せずに新しいリソースを作成することです。 文字がリソース グループ内にある場合は、その下のリソースを新しいリソースに移動できます。 それ以外の場合は、リソースを再作成する必要があります。

重複または削除されたデータの可能性

すべてのログ データが宛先に正しく送信されるようにするためのすべての作業が行われていますが、エンドポイント間でのログのデータ転送を 100% 保証することはできません。 これらの問題を回避し、ログ データがエンドポイントに確実に到着するよう、再試行やその他のメカニズムが用意されています。

次のステップ

Azure でのプラットフォーム ログの詳細について読む