次の方法で共有

データベース ウォッチャーを作成して構成する (プレビュー)

  • [アーティクル]

適用対象:Azure SQL DatabaseAzure SQL Managed Instance

この記事では、Azure SQL Database と Azure SQL Managed Instance の Azure portal でデータベース ウォッチャーを作成し、構成し、開始するための詳細な手順について説明します。

データベース ウォッチャーでは、監視エージェントやその他の監視インフラストラクチャをデプロイして維持する必要はありません。 Azure SQL リソースのデータベースの詳細な監視を数分で有効にすることができます。

データベース ウォッチャーの作成と構成の詳細な操作手順の例については、「クイック スタート: Azure SQL を監視するデータベース ウォッチャーを作成する」を参照してください。

Bicep または ARM テンプレートを使用してデータベース ウォッチャーを作成および構成する方法については、「データベース ウォッチャーを作成する」のコード サンプルを参照してください。

コードとしてのインフラストラクチャ (Bicep、ARM テンプレート、Terraform AzAPI) を使用してウォッチャーを定義するには、Azure リソース リファレンスのドキュメントを参照してください。

プログラムでデータベース ウォッチャーを管理するには、データベース ウォッチャー REST API のドキュメントを参照してください。

この記事の手順に従ってウォッチャーを作成して構成したら、Azure Monitor アラートを使用できます。 詳細については、「データベース監視ツールのアラート」を参照してください。

メモ

データベース ウォッチャーは現在プレビュー段階です。

前提条件

データベース ウォッチャーを使用するには、次の前提条件が必要です。

  • アクティブな Azure サブスクリプションが必要です。 アカウントがない場合は、無料アカウントを作成してください。 リソースを作成できるようにするには、サブスクリプションまたはリソース グループの共同作成者ロールまたは所有者ロールのメンバーである必要があります。

  • データベース ウォッチャーを構成して開始するには、既存の SQL ターゲット (Azure SQL データベース、エラスティック プール、または SQL マネージド インスタンス) が必要です。

  • Microsoft.DatabaseWatcher、Microsoft.Kusto、および Microsoft.Network のリソース プロバイダーを、Azure サブスクリプションに登録する必要があります。

    • Azure SQL リソースへの接続に SQL 認証を使用するには、Microsoft.KeyVault リソース プロバイダーも登録する必要があります。 「SQL 認証を使用するための追加の構成」を参照してください。
    • アラート ルールを作成するには、Microsoft.Insights リソース プロバイダーも登録する必要があります。

    サブスクリプション レベルで所有者ロールまたは共同作成者 RBAC ロールのメンバーシップをお持ちの場合、リソース プロバイダーの登録は自動的に行われます。 それ以外の場合は、ウォッチャーを作成して構成する前に、これらのロールのいずれかのユーザーがリソース プロバイダーを登録する必要があります。 詳細については、「リソース プロバイダーを登録する」 を参照してください。

  • ウォッチャーと Azure Data Explorer クラスター リソースを作成および構成するユーザーは、これらのリソースが作成されるリソース グループまたはサブスクリプションの所有者ロールまたは共同作成者 RBAC ロールのメンバーである必要があります。

    さらに、SQL 認証を使用する場合、ユーザーはリソース グループの所有者ロールのメンバーであるか、SQL 認証資格情報を格納するキー コンテナーの所有者ロールまたはユーザー アクセス管理者ロールのメンバーである必要があります。

  • ウォッチャーを構成するユーザーは、Azure SQL ターゲットへの管理者アクセス権を持っている必要があります。 管理者は、ウォッチャーに SQL 監視対象への制限付きの特定のアクセス権を付与します。 詳細については、「ターゲットへのアクセス権を付与する」を参照してください。

  • SQL ターゲットへの監視アクセスを許可するには、管理者は、SQL Server Management Studio (SSMS)、SQL Server mssql 拡張機能を使用した Visual Studio Code、またはその他の SQL クライアント ツールを使用して T-SQL スクリプトを実行する必要があります。

  • Azure リソースへのプライベート接続に Azure Private Link を使用するには、プライベート エンドポイントを承認するユーザーが所有者 RBAC ロールのメンバーであるか、必要な RBAC アクセス許可を持っている必要があります。 詳細については、「プライベート エンドポイントの RBAC 承認」を参照してください。

ウォッチャーを作成する

  1. Azure Portal の ナビゲーション メニュー で [すべてのサービス] を選択します。 カテゴリとして [監視] を選択し、[監視ツール] で [データベース ウォッチャー] を選択します。 または、ポータル ページの上部にある [検索] ボックスに「データベース ウォッチャー」と入力し、[データベース ウォッチャー] を選択することもできます。

    [データベース ウォッチャー] ビューが開いたら、[作成] を選択します。

  2. [基本] タブで、ウォッチャーのサブスクリプションとリソース グループを選択し、ウォッチャーの名前を入力して、Azure リージョンを選択します。

    ヒント

    プレビュー期間中に、データベース ウォッチャーがリージョンでまだ使用できない場合は、別のリージョンで作成できます。 詳細については、リージョン別の提供状況に関するページをご覧ください。

  3. [ID] タブでは、ウォッチャーのシステム割り当てマネージド ID が既定で有効になっています。 代わりにウォッチャーでユーザー割り当てマネージド ID を使用する必要がある場合は、[追加] ボタンを選択し、使用する ID を見つけて、[追加] ボタンを選択します。 ウォッチャーに対してユーザー割り当て ID を有効にするには、システム割り当てマネージド ID を無効にします。

    データベース ウォッチャーのマネージド ID の詳細については、「ウォッチャー ID を変更する」を参照してください。

  4. ウォッチャーのデータ ストアを選択します。

    既定では、ウォッチャーを作成すると Azure Data Explorer クラスターも作成され、収集された監視データのデータ ストアとしてそのクラスターにデータベースが追加されます。

    • 既定では、新しい Azure Data Explorer クラスターでは、極小のコンピューティング最適化 SKU が使用されます。 これは、引き続きサービス レベル アグリーメント (SLA) が提供される最も経済的な SKU です。 このクラスターは、必要に応じて後でスケーリングできます。

    • または、既存の Azure Data Explorer クラスター、無料の Azure Data Explorer クラスター、またはリアルタイム分析でデータベースを使用することもできます。

      1. [データ ストア] タブで、[データ ストアの選択] オプションを選択し、[追加] を選択します。
      2. リアルタイム分析データベースまたは Azure Data Explorer クラスターを選択します。
      3. 既存の Azure Data Explorer クラスターを使用する場合は、ストリーミング インジェストを有効にする必要があります。
      4. 新しいデータベースを作成するか、既存のデータベースを使用します。

      メモ

      選択する既存のデータベースは、空である必要があります。または、データベース ウォッチャー データ ストアとして以前に使用したデータベースである必要があります。 データベース ウォッチャーによって作成されていないオブジェクトを含むデータベースの選択はサポートされていません。

    • または、この時点でデータ ストアの追加をスキップして、後で追加することもできます。 ウォッチャーを開始するには、データ ストアが必要です。

  5. [SQL ターゲット] タブで、監視する 1 つ以上の Azure SQL リソースを追加します。 ウォッチャーの作成時に SQL ターゲットの追加をスキップし、後で追加することができます。 ウォッチャーを開始する前に、1 つ以上のターゲットを追加する必要があります。

  6. [確認と作成] タブで、ウォッチャー構成を確認し、[作成] を選択します。 新しいAzure Data Explorer クラスターを作成する既定のオプションを選択した場合、通常、デプロイには 15 分から 20 分かかります。 既存の Azure Data Explorer クラスター、無料の Azure Data Explorer クラスター、またはリアルタイム分析でデータベースを選択する場合、通常、デプロイにかかる時間は最大 5 分です。

  7. デプロイが完了したら、ウォッチャーに SQL ターゲットへのアクセス権を付与します。

  8. また、ウォッチャーにデータ ストアへのアクセス権を付与しなければならない場合もあります。

    • ウォッチャー作成するユーザーがクラスターの所有者 RBAC ロールのメンバーである場合は、ウォッチャーの作成時に、新規または既存の Azure Data Explorer クラスターでのデータベースへのアクセス権が自動的に付与されます。
    • ただし、次のデータベースを選択する場合は、KQL コマンドを使用してデータ ストアへのアクセス権を付与する必要があります。
      • Microsoft Fabric のリアルタイム分析。
      • 無料の Azure Data Explorer クラスター。

  9. プライベート接続を使用する必要がある場合は、マネージド プライベート エンドポイントを作成して承認します。

    • SQL ターゲット、データ ストア、およびキー コンテナーに対するパブリック アクセスが有効で、パブリック接続を使用する必要がある場合は、パブリック接続の前提条件がすべて満たされていることを確認します。

ウォッチャーを開始および停止する

ウォッチャーが作成されると、追加の構成が必要になる可能性があるため、自動的に開始されません。

ウォッチャーを開始するには、次が必要です。

ウォッチャーが完全に構成されたら、[概要] ページで [スタート] ボタンを使用してデータ コレクションを開始します。 数分後に、新しい監視データがデータ ストアとダッシュボードに表示されます。 5 分以内に新しいデータが表示されない場合は、「トラブルシューティング」を参照してください。

Azure SQL リソースをしばらく監視する必要がない場合は、[停止] ボタンを使用してウォッチャーを停止できます。

ウォッチャーを再起動するには、停止してからもう一度起動します。

ウォッチャーを変更する

Azure portal では、ターゲットの追加または削除、プライベート エンドポイントの作成または削除が可能です。既存のウォッチャーに別のデータ ストアを使用したり、ウォッチャーのマネージド ID を変更したりすることもできます。

メモ

特にメモがない限り、ウォッチャーの構成に加えた変更は、ウォッチャーを停止して再起動した後に有効になります。

ウォッチャーに SQL ターゲットを追加する

Azure SQL データベース、エラスティック プール、または SQL マネージド インスタンスを監視するデータベース ウォッチャーを有効にするには、このリソースを SQL ターゲットとして追加する必要があります。

  1. ターゲットを追加するには、[SQL ターゲット] ページで [追加] を選択します。
  2. 監視する Azure SQL リソースを検索します。 リソースの種類とサブスクリプションを選択し、リソースの一覧から SQL ターゲットを選択します。 SQL ターゲットは、ウォッチャーと同じ Microsoft Entra ID テナント内の任意のサブスクリプションに配置できます。
  3. データベース、エラスティック プール、または SQL マネージド インスタンスのプライマリ レプリカと高可用性セカンダリ レプリカを監視するには、同じリソースに対して "2 つの個別の SQL ターゲット" を追加し、"そのいずれか" の [読み取り目的] ボックスをオンにします。 同様に、geo レプリカとその高可用性セカンダリ レプリカ (存在する場合) に対して 2 つの個別の SQL ターゲットを作成します。
    • [読み取りインテント] ボックスをオンにすると、高可用性セカンダリ レプリカのみに SQL ターゲットが構成されます。
    • プライマリ レプリカのみを監視するか、geo レプリカのみを監視する場合、またはこのリソース用の高可用性セカンダリ レプリカが存在しない場合、または読み取りスケールアウト機能が無効になっている場合は、[読み取り目的] ボックスをオンにしないでください。

既定では、データベース ウォッチャーは、SQL ターゲットへの接続時に Microsoft Entra 認証を使用します。 ウォッチャーで SQL 認証を使用する場合は、[SQL 認証の使用] ボックスをオンにして、必要な詳細を入力します。 詳細については、「SQL 認証を使用するための追加の構成」を参照してください。

ウォッチャーから SQL ターゲットを削除する

1 つ以上のターゲットを削除するには、[SQL ターゲット] ページを開き、一覧から削除するターゲットを選択して、[削除] を選択します。

ターゲットを削除すると、ウォッチャーの再起動時に Azure SQL リソースの監視は停止しますが、実際のリソースは削除されません。

データベース ウォッチャーで監視されている Azure SQL リソースを削除する場合は、対応するターゲットも削除する必要があります。 ウォッチャーにある SQL ターゲットの数には制限があるため、古いターゲットを維持すると、新しいターゲットを追加できなくなる可能性があります。

マネージド プライベート エンドポイントを作成する

SQL ターゲットからのデータ収集、データ ストアへの取り込み、およびキー コンテナーへの接続にプライベート接続を使用する場合は、マネージド プライベート エンドポイントを作成する必要があります。 プライベート エンドポイントを作成しない場合、データ ウォッチャーは既定でパブリック接続を使用します。

メモ

データベース ウォッチャーでは、Azure リソースに接続するための独自のマネージド プライベート エンドポイントが必要です。 ウォッチャーは、Azure SQL 論理サーバー、SQL マネージド インスタンス、Azure Data Explorer クラスター、またはキー コンテナーに既に存在するプライベート エンドポイントを使用することはできません。

ウォッチャー用のマネージド プライベート エンドポイントを作成するには、次の操作を行います。

  1. マネージド プライベート エンドポイントを作成したリソース、リソース グループ、またはそのリソースのサブスクリプションに読み取り専用ロックがある場合は、そのロックを削除します。 プライベート エンドポイントが正常に作成された後は、もう一度ロックを追加できます。

  2. Azure portal でデータベース ウォッチャーに移動し、[マネージド プライベート エンドポイント] ページを開き、[追加] を選択します。

  3. プライベート エンドポイントの名前を入力します。

  4. プライベート エンドポイントを作成する Azure リソースのサブスクリプションを選択します。

  5. プライベート エンドポイントを作成するリソースの種類に応じて、次のように [リソースの種類] と [ターゲット サブリソース] を選択します。

    リソース リソースの種類 ターゲット サブリソース
    論理サーバー Microsoft.Sql/servers sqlServer
    SQL マネージド インスタンス Microsoft.Sql/managedInstances managedInstance
    Azure Data Explorer クラスター Microsoft.Kusto/clusters cluster
    キー コンテナー Microsoft.KeyVault/vaults vault

  6. プライベート エンドポイントを作成するリソースを選択します。 これは、Azure SQL 論理サーバー、SQL マネージド インスタンス、Azure Data Explorer クラスター、またはキー コンテナーです。

    • Azure SQL Database 論理サーバーのプライベート エンドポイントを作成すると、そのサーバー上のすべてのデータベースおよびエラスティック プール ターゲットに対するデータベース ウォッチャーにプライベート接続できるようになります。

  7. 必要に応じて、プライベート エンドポイントの説明を入力します。 これは、リソース所有者が要求を承認するのに役立ちます。

  8. [作成] を選択します。 プライベート エンドポイントの作成には数分かかる場合があります。 プライベート エンドポイントは、プロビジョニングの状態が [承認済み] または [実行中] から [成功] に変わると作成されます。 ビューを更新して、現在のプロビジョニングの状態を確認します。

    重要

    プライベート エンドポイントは、[保留中] 状態で作成されます。 データベース ウォッチャーがプライベート エンドポイントを使用してリソースに接続できるようにするには、リソース所有者がプライベート エンドポイントを承認する必要があります。

    リソース所有者がネットワーク接続を制御できるようにするために、データベース ウォッチャー プライベート エンドポイントは自動的には承認されません。

  9. リソース所有者は、プライベート エンドポイント要求を承認する必要があります。

プライベート エンドポイントが承認されたときにウォッチャーが既に実行されている場合は、プライベート接続の使用を開始するために再起動する必要があります。

ヒント

クラスターのパブリック接続が無効になっている場合は、Azure Data Explorer クラスター用の追加のプライベート エンドポイントを作成する必要があります。 詳細については、「データ ストアへのプライベート接続」を参照してください。

マネージド プライベート エンドポイントを削除する

  1. マネージド プライベート エンドポイントを削除したリソース、リソース グループ、またはそのリソースのサブスクリプションに削除または読み取り専用ロックがある場合は、そのロックを削除します。 プライベート エンドポイントが正常に削除された後は、もう一度ロックを追加できます。
  2. データベース ウォッチャーの Azure portal ページで、[マネージド プライベート エンドポイント] ページを開きます。
  3. 承認するプライベート エンドポイントを選択します。
  4. [削除]を選択します。

マネージド プライベート エンドポイントを削除すると、このプライベート エンドポイントを使用する SQL ターゲットからのデータ収集が停止します。 Azure Data Explorer クラスターのマネージド プライベート エンドポイントを削除すると、すべてのターゲットのデータ収集が停止します。 データ コレクションを再開するには、プライベート エンドポイントを再作成するか、パブリック接続を有効にして、ウォッチャーを再起動します。

ウォッチャーのデータ ストアを変更する

ウォッチャーは、データ ストアを 1 つだけ持つことができます。

現在のデータ ストアを変更するには、既存のデータ ストアを削除してから新しいデータ ストアを追加します。

  • 現在のデータ ストアを削除するには、[データ ストア] ページを開き、グリッドでデータ ストアを選択してから、[削除] を選択します。

    • データ ストアを削除しても、Azure Data Explorer クラスターまたは Microsoft Fabric のリアルタイム分析の実際のデータ ストア データベースは削除されません。
    • 削除されたデータ ストアへのデータ収集を停止するには、ウォッチャーを停止します。
    • データ ストアを削除する場合は、ウォッチャーをもう一度起動する前に、新しいデータ ストアを追加する必要があります。

  • データ ストアを追加するには、[データ ストア] ページで [追加] を選択し、Azure Data Explorer クラスターまたはリアルタイム分析でデータベースを選択または作成します。

    • 選択するデータベースは空である必要があります。または、データベース ウォッチャー データ ストアとして以前に使用したデータベースである必要があります。 データベース ウォッチャーによって作成されていないオブジェクトを含むデータベースの選択はサポートされていません。
    • データ ストアを追加したら、それを使用するためのアクセス権をウォッチャーに付与する必要があります。 詳細については、「データ ストアへのアクセス権を付与する」を参照してください。
    • ウォッチャーが再起動されると、新しいデータ ストアの使用が開始されます。

ヒント

有料の Azure Data Explorer クラスターから無料の Azure Data Explorer クラスターにデータ ストアを切り替える場合は、有料クラスターが不要になった場合、有料クラスターを停止または削除することを検討してください。 これにより、不要なコストを回避できます。

ウォッチャー ID を変更する

ウォッチャーには、SQL ターゲット、キー コンテナー、およびデータ ストアに対して認証するためのマネージド ID が必要です。 システム割り当て ID またはユーザー割り当てマネージド ID のいずれかを使用します。 Azure のマネージド ID の詳細については、「Azure リソース用マネージド ID とは」を参照してください。

ウォッチャーのマネージド ID の種類を選択する際に役立つ考慮事項を次に示します。

  • システム割り当て

    • ウォッチャーは作成時に既定で有効になっています。
    • 常に 1 つのウォッチャーに関連付けられています。
    • ウォッチャーを使用して作成および削除されました。
    • ウォッチャーのシステム割り当て ID を無効にすると、その ID に付与されたアクセス権は失われます。 同じウォッチャーに対してシステム割り当て ID を再度有効にすると、異なるオブジェクト (プリンシパル) ID を持つ別の ID が新しく作成されます。 この新しい ID に、SQL ターゲット、キー コンテナー、およびデータ ストアへのアクセス権を付与する必要があります。

  • ユーザー割り当て

    • ウォッチャーに対してシステム割り当て ID が無効の場合にのみ有効です。
    • 同じユーザー割り当て ID を複数のウォッチャーに割り当てて、アクセス管理を簡略化できます。たとえば、大規模な Azure SQL 資産を監視する場合などです。 複数のウォッチャーのシステム割り当て ID にアクセス権を付与するのではなく、1 つのユーザー割り当て ID にアクセス権を付与できます。
    • 職務の分離に対応するために、ID の管理とウォッチャーの管理を別にすることができます。 ウォッチャーが作成される前または後に、別のユーザーが、ユーザー割り当て ID を作成し、アクセス権を付与できます。
    • 逆に、ウォッチャーが削除されても、ユーザー割り当て ID とそのアクセス権はそのまま残ります。 その後、同じ ID を新しいウォッチャーに使用できます。
    • ウォッチャーに対して複数のユーザー割り当て ID を指定することはサポートされていません。

ウォッチャーのマネージド ID を変更するには、ウォッチャーの [ID] ページを開きます。

  • システム割り当て ID を使用するには、[システム割り当て ID] トグルを有効にします。

  • ユーザー割り当て ID を使用するには、[システム割り当て ID] トグルを無効にします。 [追加] ボタンを選択して、既存のユーザー割り当て ID を検索して追加します。

    新しいユーザー割り当て ID を作成するには、「ユーザー割り当てマネージド ID を作成する」を参照してください。

  • ウォッチャーからユーザー割り当て ID を削除するには、それを一覧から選択し、[削除] を選択します。 ユーザー割り当て ID が削除されたら、別のユーザー割り当て ID を追加するか、システム割り当て ID を有効にする必要があります。

    削除されたユーザー割り当て ID は、Microsoft Entra ID テナントからは削除されません。

[保存] ボタンを選択して変更を保存します。 これによりウォッチャーが ID を持たないことになる場合、ID の変更は保存できません。 有効なマネージド ID がないウォッチャーはサポートされていません。

ヒント

ウォッチャーのマネージド ID の表示名は、Microsoft Entra ID テナント内で一意にすることをお勧めします。 ウォッチャーのユーザー割り当て ID を作成するときに、一意の名前を選択できます。

システム割り当て ID の表示名は、ウォッチャー名と同じです。 システム割り当て ID を使用する場合は、ウォッチャー名が Microsoft Entra ID テナント内で一意であることを確認します。

マネージド ID の表示名が一意でない場合、ウォッチャーに SQL ターゲットへのアクセス権を付与する T-SQL スクリプトが、表示名の重複エラーで失敗します。 詳細と回避策については、「Microsoft Entra ログインと一意ではない表示名を持つユーザー」を参照してください。

ID の変更が保存されるとすぐに、ウォッチャーは、現在のマネージド ID を使用して、SQL ターゲット、キー コンテナー (使用されている場合)、およびデータ ストアに再接続します。

ウォッチャーを削除する

ウォッチャー、そのリソース グループ、またはそのサブスクリプションに削除または読み取り専用ロックがある場合は、そのロックを削除します。 同様に、マネージド プライベート エンドポイントを作成したリソース、リソース グループ、またはそのリソースのサブスクリプションにロックがある場合は、そのロックを削除します。 ウォッチャーが正常に削除されたら、ロックを再度追加できます。

システム割り当てマネージド ID が有効になっているウォッチャーを削除すると、その ID も削除されます。 これにより、この ID に付与されたアクセス権が削除されます。 ウォッチャーを後で再作成する場合は、各リソースへの認証を行うために、新しいウォッチャーのシステム割り当てマネージド ID へのアクセス権を付与する必要があります。 これには次のものが含まれます

同じウォッチャー名を使用する場合でも、再作成されたウォッチャーへのアクセス権を付与する必要があります。

ウォッチャーを削除しても、その SQL ターゲットおよびデータ ストアとして参照されている Azure リソースは削除されません。 収集された SQL 監視データはデータ ストアに保持され、後で新しいウォッチャーを作成する場合は、データ ストアと同じ Azure Data Explorer またはリアルタイム分析データベースを使用できます。

SQL ターゲットへのアクセス権を付与する

ウォッチャーが SQL 監視データを収集できるようにするには、ウォッチャー固有の制限付き SQL アクセス許可を付与する T-SQL スクリプトを実行する必要があります。

  • Azure SQL データベースでスクリプトを実行するには、監視するデータベースとエラスティック プールを含む論理サーバーへのサーバー管理者アクセス権が必要です。

    • Azure SQL データベースでは、作成するすべてのウォッチャーに対して論理サーバーごとに 1 回だけスクリプトを実行する必要があります。 これにより、ウォッチャーには、そのサーバー上のすべての既存および新しいデータベースとエラスティック プールへのアクセス権が付与されます。

  • Azure SQL Managed Instance でスクリプトを実行するには、sysadmin または securityadmin サーバー ロールのメンバーであるか、SQL Managed Instance に対する CONTROL SERVER アクセス許可を持っている必要があります。

    • Azure SQL Managed Instance では、監視する各インスタンスでスクリプトを実行する必要があります。

  1. Azure portal でウォッチャーに移動し、SQL ターゲットを選択し、[アクセス権の付与] リンクのいずれかを選択して T-SQL スクリプトを開き、スクリプトをコピーします。 ターゲットの種類と使用する認証の種類に適したリンクを選択してください。

    重要

    Azure portal の Microsoft Entra 認証スクリプトは、ウォッチャーに固有です。これにはウォッチャーのマネージド ID の名前が含まれているためです。 ウォッチャーごとにカスタマイズできるこのスクリプトの汎用バージョンの場合は、「T-SQL スクリプトを使用して SQL ターゲットへのアクセス権を付与する」を参照してください。

  2. SQL Server Management Studio またはその他の SQL クライアント ツールで、新しいクエリ ウィンドウを開き、ターゲットを含む Azure SQL 論理サーバー上の master データベース、または SQL マネージド インスタンス ターゲット上の master データベースに接続します。

  3. T-SQL スクリプトを貼り付けて実行し、ウォッチャーへのアクセス権を付与します。 このスクリプトを使用すると、ウォッチャーが接続に使用するログインを作成し、監視データを収集することに限定したアクセス許可を付与できます。

    1. Microsoft Entra 認証スクリプトを使用する場合、ウォッチャーでシステム割り当てマネージド ID が使用されているときは、そのウォッチャーは、スクリプトの実行時に既に作成されている必要があります。 ウォッチャーによってユーザー割り当てマネージド ID が使用される場合は、ウォッチャーの作成前または後にスクリプトを実行できます。

    マネージド ID へのアクセス権を付与する T-SQL アクセス スクリプトを実行するときは、Microsoft Entra 認証に接続する必要があります。

後で新しいターゲットをウォッチャーに追加する場合は、これらのターゲットが既にアクセスが許可されている論理サーバー上にある場合を除き、同様の方法でこれらのターゲットへのアクセス権を付与する必要があります。

T-SQL スクリプトを使用して SQL ターゲットへのアクセス権を付与する

Microsoft Entra 認証および SQL 認証、Azure SQL データベースおよび Azure SQL Managed Instance のターゲットには、さまざまなスクリプトがあります。

重要

表示されたスクリプトを常に使用して、データベース ウォッチャーへのアクセス権を付与します。 別の方法でアクセス権を付与すると、データ収集がブロックされる可能性があります。 詳細については、ウォッチャーの認可に関する記事をご覧ください。

スクリプトを実行する前に、login-name-placeholder、password-placeholder などのスクリプトに存在する可能性があるプレースホルダーのすべてのインスタンスを実際の値に置き換えます。

Microsoft Entra 認証済みウォッチャーへのアクセス権を付与する

このスクリプトでは、Azure SQL データベースの論理サーバーに Microsoft Entra (旧称 Azure Active Directory) 認証ログインが作成されます。 ウォッチャーのマネージド ID に対してログインが作成されます。 スクリプトでは、論理サーバー上のすべてのデータベースとエラスティック プールから監視データを収集するために必要かつ十分なアクセス許可がウォッチャーに付与されます。

ウォッチャーによってシステム割り当てマネージド ID が使用されている場合は、ウォッチャー名をログイン名として使用する必要があります。 ウォッチャーによってユーザー割り当てマネージド ID が使用されている場合は、ID の表示名をログイン名として使用する必要があります。

スクリプトは、論理サーバー上の master データベースで実行する必要があります。 サーバー管理者である Microsoft Entra 認証ログインを使用してログインする必要があります。

CREATE LOGIN [identity-name-placeholder] FROM EXTERNAL PROVIDER;

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [identity-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [identity-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [identity-name-placeholder];

SQL 認証済みウォッチャーへのアクセス権を付与する

SQL 認証を使用する場合は追加の手順が必要です。「SQL 認証を使用するための追加の構成」を参照してください。

このスクリプトでは、Azure SQL データベースの論理サーバーに SQL 認証ログインを作成します。 また、論理サーバー上のすべてのデータベースとエラスティック プールから監視データを収集するために必要かつ十分なアクセス許可がログインに付与されます。

スクリプトは、論理サーバー管理者であるログインを使用して、論理サーバー上の master データベースで実行する必要があります。

CREATE LOGIN [login-name-placeholder] WITH PASSWORD = 'password-placeholder';

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [login-name-placeholder];

SQL 認証を使用するための追加の構成

認証資格情報を安全に格納するために、データベース ウォッチャーで SQL 認証を使用するには、追加の構成が必要です。

ヒント

より安全で、シンプルで、エラーが発生しにくい構成を実現するには、Azure SQL リソースに対して Microsoft Entra 認証を有効にし、SQL 認証の代わりに使用することをお勧めします。

SQL 認証を使用してターゲットに接続するようにデータベース ウォッチャーを構成するには、次の手順に従います。

  1. Azure Key Vault にコンテナーを作成するか、使用できる既存のコンテナーを特定します。 コンテナーでは、RBAC アクセス許可モデルを使用する必要があります。 RBAC アクセス許可モデルは、新しいコンテナーの既定値です。 既存のコンテナーを使用する場合は、古いアクセス ポリシー モデルを使用するように構成されていないことを確認します。

    コンテナーへのプライベート接続を使用する場合は、[マネージド プライベート エンドポイント] ページでプライベート エンドポイントを作成します。 Microsoft.KeyVault/vaults を [リソースの種類] として選択し、vault を [ターゲット サブリソース] として選択します。 ウォッチャーを開始する前に、プライベート エンドポイントが承認されていることを確認します。

    パブリック接続を使用する場合は、コンテナーですべてのネットワークからのパブリック アクセスが有効になっている必要があります。 パブリック コンテナーの接続を特定のネットワークに制限することは、データ ウォッチャーではサポートされていません。

  2. 監視する Azure SQL 論理サーバーまたはマネージド インスタンスごとに SQL 認証ログインを作成し、指定されたアクセス スクリプトを使用する特定の制限されたアクセス許可を付与します。 スクリプトで、ログイン名とパスワードのプレースホルダーを実際の値に置き換えます。 強力なパスワードを使用してください。

  3. コンテナーで、ログイン名用のシークレットとパスワード用の別のシークレットの 2 つのシークレットを作成します。 任意の有効な名前をシークレット名として使用し、T-SQL スクリプトで使用したログイン名またはパスワードをシークレット用のシークレット値として入力します。

    たとえば、2 つのシークレットの名前は database-watcher-login-name および database-watcher-password である可能性があります。 シークレット値は、ログイン名と強力なパスワードになります。

    シークレットを作成するには、Key Vault Secrets Officer RBAC ロールのメンバーである必要があります。

  4. ウォッチャーに SQL ターゲットを追加します。 ターゲットを追加するときに、[SQL 認証の使用] ボックスをオンにし、ログイン名とパスワード シークレットが格納されているコンテナーを選択します。 ログイン名とパスワードのシークレット名を対応するフィールドに入力します。

    SQL ターゲットを追加するときは、実際のログイン名とパスワードを入力しないでください。 前の例を使用して、database-watcher-login-name シークレット名と database-watcher-password シークレット名を入力します。

  5. Azure portal で SQL ターゲットを追加すると、現在のユーザーがキー コンテナーの所有者ロールまたはユーザー アクセス管理者ロールのメンバーである場合、ウォッチャーのマネージド ID に、キー コンテナー シークレットへの必要なアクセス権が自動的に付与されます。 それ以外の場合は、次の手順に従って、必要なアクセス権を手動で付与します。

  6. 各シークレットの [アクセスの制御 (IAM)] ページで、Key Vault Secrets User RBAC ロールにウォッチャーのマネージド ID のロールの割り当てを追加します。 最小限の特権の原則に従うには、コンテナー全体ではなく、シークレットごとにこのロールの割り当てを追加します。 [アクセスの制御 (IAM)] ページは、コンテナーが RBAC アクセス許可モデルを使用するように構成されている場合にのみ表示されます。

異なる SQL ターゲットでさまざまな SQL 認証資格情報を使用する場合は、複数のペアのシークレットを作成する必要があります。 同じコンテナーまたは異なるコンテナーを使用して、各 SQL ターゲットのシークレットを格納できます。

メモ

ウォッチャーの実行中に、キー コンテナーのログイン名またはパスワードのシークレット値を更新すると、ウォッチャーは 15 分以内に新しい SQL 認証資格情報を使用してターゲットに再接続されます。 新しい資格情報の使用をすぐに開始する場合は、ウォッチャーを停止して再起動します。

データ ストアへのアクセス権を付与する

データベース スキーマをデータ ストアで作成および管理し、監視データを取り込むには、データベース ウォッチャーで Azure Data Explorer クラスターのデータ ストア データベースまたはリアルタイム分析で管理者 RBAC ロールのメンバーシップが必要です。 データベース ウォッチャーでは、Azure Data Explorer クラスターへのクラスター レベルのアクセスや、同じクラスターに存在する可能性がある他のデータベースへのアクセスは必要ありません。

クラスターの所有者 RBAC ロールのメンバーで、Azure Data Explorer クラスター上のデータベースをデータ ストアとして使用している場合、このアクセス権は自動的に付与されます。 それ以外の場合は、このセクションの説明に従ってアクセス権を付与する必要があります。

リアルタイム分析または無料の Azure Data Explorer クラスターでデータベースを使用する場合は、KQL を使用してアクセス権を付与する必要があります。

Azure portal を使用して Azure Data Explorer データベースへのアクセス権を付与する

Azure portal を使用して、Azure Data Explorer クラスター上のデータベースへのアクセス権を付与することができます。

  1. Azure Data Explorer クラスター上のデータベースの場合は、リソース メニューの [セキュリティとネットワーク] で [アクセス許可] を選択します。 クラスターの [アクセス許可] ページは使用しないでください。
  2. [追加]、[管理者] の順に選択します。
  3. [新しいプリンシパル] ページで、[エンタープライズ アプリケーション] を選択します。 ウォッチャーによってシステム割り当てマネージド ID が使用されている場合は、[検索] ボックスにウォッチャーの名前を入力します。 ウォッチャーによってユーザー割り当てマネージド ID が使用されている場合は、[検索] ボックスにその ID の表示名を入力します。
  4. ウォッチャーのマネージド ID のエンタープライズ アプリケーションを選択します。

KQL を使用して Azure Data Explorer データベースへのアクセス権を付与する

Azure portal を使用する代わりに、KQL コマンドを使用してデータベースへのアクセス権を付与することもできます。 このメソッドを使用して、リアルタイム分析または無料の Azure Data Explorer クラスターでデータベースへのアクセス権を付与します。

  1. Kusto エクスプローラー または Azure Data Explorer Web UI を使用する Azure Data Explorer クラスター上のデータベースに接続します。

  2. 次のサンプル KQL コマンドでは、テーブルに記載されているように 3 つのプレースホルダーを置き換えます。

    .add database [adx-database-name-placeholder] admins ('aadapp=identity-principal-id-placeholder;tenant-primary-domain-placeholder');
    プレースホルダー 置換
    adx-database-name-placeholder Azure Data Explorer クラスターまたはリアルタイム分析のデータベースの名前。
    identity-principal-id-placeholder ウォッチャーの [ID] ページにあるマネージド ID (GUID) のプリンシパル ID 値。 システム割り当て ID が有効になっている場合は、その プリンシパル ID 値を使用します。 それ以外の場合は、ユーザー割り当て ID のプリンシパル ID 値を使用します。
    tenant-primary-domain-placeholder ウォッチャー マネージド ID の Microsoft Entra ID テナントのドメイン名。 これは、Azure portal の Microsoft Entra ID の [概要] ページで確認できます。 テナントのプライマリ ドメインの代わりに、テナント ID GUID 値も使用できます。

    コマンドのこの部分は、Real-Time Analytics または無料の Azure Data Explorer クラスターでデータベースを使用する場合に必要です。

    Azure Data Explorer クラスター上のデータベースでは、ドメイン名またはテナント ID 値 (およびその前のセミコロン) を省略できます。クラスターは常にウォッチャー マネージド ID と同じ Microsoft Entra ID テナントにあるためです。

    次に例を示します。

    .add database [watcher_data_store] admins ('aadapp=9da7bf9d-3098-46b4-bd9d-3b772c274931;contoso.com');

詳細については、Kusto ロールベースのアクセス制御に関するページを参照してください。

データ ストアにユーザーおよびグループのアクセス権を付与する

Azure portal または KQL コマンドを使用して、Azure Data Explorer クラスターまたはリアルタイム分析のデータベースへのアクセス権をユーザーとグループに付与することができます。 アクセス権を付与するには、データベースの 管理者 RBAC ロールのメンバーである必要があります。

KQL コマンドを使用して、無料の Azure Data Explorer クラスターまたはリアルタイム分析のデータベースへのアクセス権を付与します。 最小限の特権の原則に従うには、既定では閲覧者以外の RBAC ロールにユーザーとグループを追加しないことをお勧めします。

重要

データベース ウォッチャーによって収集された SQL 監視データを表示するためのアクセス権を付与する場合は、データ プライバシーとセキュリティの要件を慎重に検討してください。

データベース ウォッチャーには、SQL データベースのユーザー テーブルに格納されているデータを収集する機能はありませんが、アクティブ セッション、インデックス メタデータ、欠落したインデックス、クエリ ランタイム統計、クエリ待機統計、セッション統計、テーブル メタデータなどの特定のアクティブ セッションには、テーブル名やインデックス名、クエリ テキスト、クエリ パラメーター値、ログイン名など、機密性の高いデータが含まれている可能性があります。

SQL データベースでこのデータを表示するアクセス権のないユーザーにデータ ストアへの表示アクセス権を付与することで、他の方法では確認できない機密データを確認できるようになる場合があります。

Azure portal を使用してデータ ストアへのアクセス権を付与する

Azure portal を使用して、ユーザーとグループに Azure Data Explorer クラスター上のデータベースへのアクセス権を付与することができます。

  1. Azure Data Explorer クラスターのデータベースの場合は、リソース メニューの [セキュリティとネットワーク] で [アクセス許可] を選択します。 クラスターの [アクセス許可] ページは使用しないでください。
  2. [追加]、[ビューアー] の順に選択します。
  3. [新しいプリンシパル] ページで、[検索] ボックスにユーザーまたはグループの名前を入力します。
  4. ユーザーまたはグループを選択します。

KQL を使用してデータ ストアへのアクセス権を付与する

Azure portal を使用する代わりに、KQL コマンドを使用してデータベースへのアクセス権をユーザーおよびグループに付与することもできます。 次の KQL コマンドの例では、特定のテナント ID 値を持つ Microsoft Entra ID テナントの mary@contoso.com ユーザーと SQLMonitoringUsers@contoso.com グループにデータ読み取りアクセス権を付与します。

.add database [watcher_data_store] viewers ('aaduser=mary@contoso.com');

.add database [watcher_data_store] viewers ('aadgroup=SQLMonitoringUsers@contoso.com;8537e70e-7fb8-43d3-aac5-8b30fb3dcc4c');

詳細については、Kusto ロールベースのアクセス制御に関するページを参照してください。

データ ストアへのアクセス権を別のテナントからユーザーとグループに付与するには、Azure Data Explorer クラスターでテナント間認証を有効にする必要があります。 詳細については、「テナント間のクエリとコマンドを許可する」を参照してください。

ヒント

Microsoft Entra ID テナントのユーザーとグループへのアクセス権を付与できるように、テナント間認証はリアルタイム分析と無料の Azure Data Explorer クラスターで有効になっています。

データ ストアを管理する

このセクションでは、スケーリング、データ保持、その他の構成など、監視データ ストアを管理する方法について説明します。 このセクションのクラスター スケーリングに関する考慮事項は、Azure Data Explorer クラスターでデータベースを使用する場合に関連します。 データベース を Fabric のリアルタイム分析で使用する場合、スケーリングは自動的に管理されます。

Azure Data Explorer クラスターをスケーリングする

Azure Data Explorer クラスターは、必要に応じてスケーリングできます。 たとえば、サービス レベル アグリーメント (SLA) が必要ない場合や、クエリとデータ インジェストのパフォーマンスが許容範囲内である場合は、クラスターを 極小の Dev/Test SKU にスケールダウンできます。

データベース ウォッチャーの多くのデプロイでは、既定の極小のコンピューティング最適化の 2 インスタンス クラスター SKU で十分です。 場合によっては、構成とワークロードの経時変化に応じて、適切なクエリ パフォーマンスを確保し、データ インジェストの待機時間を短縮し続けるためにクラスターのスケーリングが必要になる場合があります。

Azure Data Explorer では、垂直方向と水平方向のクラスター スケーリングがサポートされています。 垂直方向のスケーリングでは、クラスター SKU を変更します。これによって、インスタンス (ノード) あたりの vCPU、メモリ、キャッシュの数が変更されます。 水平方向のスケーリングでは、SKU は同じままですが、クラスター内のインスタンスの数が増減します。

次の症状が 1 つ以上見られる場合は、クラスターを (水平方向に) スケール アウトするか (垂直) スケール アップする必要があります。

  • ダッシュボードまたはアドホック クエリのパフォーマンスが非常に遅くなります。
  • クラスターで多数の同時クエリを実行し、調整エラーを監視します。
  • データ インジェストの待機時間は、一貫して許容時間より長くなります。

一般に、データ ストアのデータ量が経時的に増加しても、クラスターをスケーリングする必要はありません。 これは、ダッシュボード クエリと最も一般的な分析クエリでは、クラスター ノードのローカル SSD ストレージにキャッシュされた最新のデータのみが使用されるためです。

ただし、より長い時間範囲にわたって分析クエリを実行すると、収集されたデータの総量が増加し、ローカル SSD ストレージに収まらなくなると、時間の経過とともに遅くなる可能性があります。 その場合、適切なクエリ パフォーマンスを維持するために、クラスターのスケーリングが必要になる場合があります。

  • クラスターをスケーリングする必要がある場合は、最初にクラスターを水平方向にスケーリングして、インスタンス数を増やすことをお勧めします。 これにより、クラスターは、スケーリング プロセス中にクエリとインジェストで利用可能な状態に維持されます。

  • クラスターを水平方向にスケール アウトした後でも、一部のクエリは期待どおりに実行されない場合があります。 これは、クラスターのインスタンス (ノード) で使用可能なリソースによってクエリのパフォーマンスがバインドされている場合に発生する可能性があります。 その場合は、クラスターを垂直方向にスケールアップします。

    • クラスターの垂直スケーリングには数分かかります。 そのプロセス中にダウンタイムが発生し、ウォッチャーによってデータ収集が中止される可能性があります。 その場合は、スケーリング操作の完了後にウォッチャーを停止して再起動します。

無料の Azure Data Explorer クラスター

無料の Azure Data Explorer クラスターには、元の圧縮されていないデータのストレージ容量制限など、特定の容量制限があります。 無料の Azure Data Explorer クラスターをスケーリングして、コンピューティング容量またはストレージ容量を増やすことはできません。 クラスターがストレージ容量に近づくか、容量に達すると、 無料クラスター ページに警告メッセージが表示されます。

ストレージ容量に達している場合、新しい監視データは取り込まれませんが、既存のデータにはデータベース ウォッチャー ダッシュボードで引き続きアクセス可能です。KQL または SQL クエリを使用して分析することもできます。

無料のクラスターの仕様が要件に対して不十分であることが判明した場合は、完全な Azure Data Explorer クラスターにアップグレードできます。 アップグレードでは、収集されたすべてのデータが保持されます。

アップグレード後もウォッチャーが引き続き機能することを確認するには、次の手順を実行する必要があります。

  1. ウォッチャー を止めろ。
  2. これらの手順に従って、完全な Azure Data Explorer クラスターにアップグレードし、アップグレードが完了するまで待ちます。
  3. アップグレードされた Azure Data Explorer クラスターとデータベースを選択して、ウォッチャーのデータ ストアを変更します。
  4. ウォッチャーを開始します。

無料の Azure Data Explorer クラスターを引き続き使用するには、データ保持の管理機能によって古いデータを自動的に削除し、新しいデータのための領域を確保します。 ストレージ スペースが使用可能になった後、データ収集を再開するには、ウォッチャーの停止と再起動が必要になる場合があります。

データ保有期間を管理する

古いデータが不要である場合は、データ保持ポリシーを構成して自動的に消去できます。 既定では、Azure Data Explorer クラスターまたはリアルタイム分析の新しいデータベースのデータ保持期間は 365 日に設定されます。

  • データベース レベルで、またはデータベースの個々のテーブルに対して、データ保持期間を短縮できます。
  • 監視データを 1 年以上格納する必要がある場合は、保持期間を増やすこともできます。 データ保持期間に上限はありません。
  • 異なるテーブルに対して異なるデータ保持期間を構成した場合、古い時間範囲ではダッシュボードが期待どおりに機能しない可能性があります。 これは、一部のテーブルにデータが引き続き存在するものの、同じ期間の他のテーブルで既に消去されている場合に発生する可能性があります。

データ ストアに取り込まれる SQL 監視データの量は、SQL ワークロードと Azure SQL 資産のサイズによって異なります。 次の KQL クエリを使用すると、1 日に取り込まれたデータの平均量を表示し、ストレージ消費量の推移を見積もり、データ保持ポリシーを管理することができます。

.show database extents
| summarize OriginalSize = sum(OriginalSize),
            CompressedSize = sum(CompressedSize)
            by bin(MinCreatedOn, 1d)
| summarize DailyAverageOriginal = format_bytes(avg(OriginalSize)),
            DailyAverageCompressed = format_bytes(avg(CompressedSize));

データ ウォッチャー データ ストアのスキーマとアクセスの変更

時間の経過と同時に、Microsoft は新しいデータベース ウォッチャー データセットを導入したり、既存のデータセットを拡張したりする可能性があります。 つまり、データ ストアに新しいテーブルが自動的に追加されたり、既存のテーブルに新しい列が自動的に追加されたりする可能性があります。

これを行うには、データベース ウォッチャー のマネージド ID がデータ ストアの 管理者 RBAC ロールのメンバーである必要があります。 このロール メンバーシップを取り消すか、他の RBAC ロールのメンバーシップに置き換えると、データベース ウォッチャーのデータ収集とスキーマ管理に影響を与える可能性があるため、サポートされていません。

同様に、データベース ウォッチャー データ ストアでのテーブル、外部テーブル、具体化されたビュー、関数などの新しいオブジェクトの作成はサポートされていません。 複数のクラスターと複数のデータベース クエリを使用して、他の Azure Data Explorer クラスターまたは同じクラスターの他のデータベースから、データ ストアのデータに対してクエリを実行できます。

重要

データ ストアへのデータベース ウォッチャーのアクセスを変更する場合、またはデータ インジェストに影響するデータベース スキーマまたは構成の変更を行う場合は、新しい空のデータベースにそのウォッチャーのデータ ストアを変更し、ウォッチャーにこの新しいデータベースへのアクセス権を付与してデータ収集を再開し、サポートされている構成に戻す必要がある場合があります。

停止状態にある Azure Data Explorer クラスター

Azure Data Explorer クラスターは、コスト削減などの目的で停止できます。 既定では、Azure portal で作成された Azure Data Explorer クラスターは、数日間非アクティブになった後に自動的に停止されます。 たとえば、クラスター上の唯一のデータベースにデータを取り込むウォッチャーを停止し、このデータベースでクエリを実行しない場合に発生する可能性があります。

新しいウォッチャーの作成時に、新しい Azure Data Explorer クラスターを作成する既定のオプションを使用すると、自動停止動作が無効になり、データ収集が中断されなくなります。

クラスターが停止すると、データベース ウォッチャーのデータ収集も停止します。 データ収集を再開するには、クラスターを開始する必要があります。 クラスターが実行されたら、ウォッチャーを再起動します。

クラスターが非アクティブでも引き続き利用可能にする場合、自動停止動作を無効にすることができます。 これにより、クラスター コストが増加する可能性があります。

ストリーミング インジェスト

データベース ウォッチャーでは、データ ストア データベースを含む Azure Data Explorer クラスターでストリーミング インジェストが有効になっている必要があります。 ストリーミング インジェストは、新しいウォッチャーの作成時に作成された新しい Azure Data Explorer クラスターに対して自動的に有効になります。 これは、リアルタイム分析と無料の Azure Data Explorer クラスターでも有効になります。

既存の Azure Data Explorer クラスターを使用する場合は、最初にストリーミング インジェストを有効にしてください。 これには数分かかり、クラスターが再起動されます。

データ ストアへのプライベート接続

Azure Data Explorer クラスターでパブリック アクセスが無効になっている場合は、ブラウザーからクラスターに接続し、ダッシュボードで SQL 監視データを表示したり、データに直接クエリを実行したりするためのプライベート エンドポイントを作成する必要があります。 このプライベート エンドポイントは、ウォッチャーが監視データを Azure Data Explorer クラスター上のデータベースに取り込むために作成されたマネージド プライベート エンドポイントに加えて作成されます。

  • Azure VM から Azure Data Explorer クラスターに接続する場合は、Azure VM がデプロイされている Azure Virtual Network 内の Azure Data Explorer クラスターのプライベート エンドポイントを作成します。

  • オンプレミスのマシンから Azure Data Explorer クラスターに接続する場合は、次のようなことができます。

    1. Azure VPN Gateway または Azure ExpressRoute を使用して、オンプレミス ネットワークから Azure Virtual Network への接続を確立する。
    2. VPN または ExpressRoute 接続が終了するか、他の Azure Virtual Network でオンプレミスのマシンからトラフィックが到達可能な別の Azure Virtual Network の Azure Data Explorer クラスター用の別のプライベート エンドポイントを作成する。
    3. そのプライベート エンドポイントの DNS を構成する。

プライベート接続は、無料の Azure Data Explorer クラスターや Microsoft Fabric のリアルタイム分析では使用できません。

大規模な資産を監視する

大規模な Azure SQL 資産を監視するには、複数のウォッチャーを作成することが必要な場合があります。

各ウォッチャーには、Azure Data Explorer クラスターのデータベース、またはデータ ストアとしてのリアルタイム分析が必要です。 作成するウォッチャーは、単一データベースを共通のデータ ストアとして使用することも、個別のデータベースを個別のデータ ストアとして使用することもできます。 次の考慮事項は、監視シナリオと要件に最適な設計を選択するに役立ちます。

一般的なデータ ストアに関する考慮事項:

  • Azure SQL 資産全体を 1 つのウィンドウで表示できます。
  • ウォッチャーのダッシュボードには、データが他のウォッチャーによって収集された場合でも、データ ストアのすべてのデータが表示されます。
  • データ ストアにアクセスできるユーザーは、Azure SQL 資産全体の監視データにアクセスできます。

個別のデータ ストアに関する考慮事項:

  • Azure SQL 資産のサブセットは個別に監視されます。 Azure portal のデータベース ウォッチャー ダッシュボードには、常に単一データ ストアからのデータが表示されます。
  • 複数のデータ ストアにアクセスできるユーザーは、複数のクラスターまたは複数のデータベースに対する KQL クエリを使用して、単一クエリを使用する複数のデータ ストアの監視データにアクセスできます。
  • Azure Data Explorer とリアルタイム分析のデータ アクセスはデータベースごとに管理されるため、資産のサブセットの監視データへのアクセスをきめ細かく管理できます。
  • 複数のデータベースを同じ Azure Data Explorer クラスターに配置してクラスター リソースを共有し、コストを節約しながら、各データベースでデータを分離することができます。
  • Azure Data Explorer クラスターへのネットワーク アクセスなど、環境を完全に分離する必要がある場合は、異なるクラスターに異なるデータベースを配置できます。

関連コンテンツ