Database Watcher の作成と構成 (プレビュー)

  • [アーティクル]

適用対象:Azure SQL データベースAzure SQL Managed Instance

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

この記事には、Azure portal で Database Watcher を作成、構成、開始するための詳細な手順が含まれています。

Database Watcher の作成と構成の詳細な例については、「クイック スタート: Azure SQL を監視する Database Watcher を作成する」を参照してください。

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

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

Note

Database Watcher は現在プレビューの段階です。 プレビュー機能は、限定された機能でリリースされますが、お客様が早期アクセスをしてフィードバックを提供できるように、プレビュー ベースで利用できます。 プレビュー機能は別の補足プレビュー条項の対象であり、SLA の対象ではありません。 サポートは特定の場合にベスト エフォートとして提供されます。 ただし、Microsoft サポートはプレビュー機能に関するフィードバックを必要としているため、場合によってはベスト エフォートのサポートを提供する場合があります。 プレビュー機能には、制限された機能または制限付き機能があり、選択した地理的領域でのみ使用できる場合があります。

前提条件

Database Watcher を使用するには、次の前提条件が必要です。

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

  • Database Watcher を構成するには、既存の SQL ターゲット (Azure SQL データベース、エラスティック プール、またはSQL Managed Instance) が必要です。

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

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

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

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

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

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

  • Watcher に SQL ターゲットへのアクセス権を付与するには、T-SQL スクリプトを実行する必要があります。 SQL Server Management Studio (SSMS)、Azure Data Studio、Visual Studio Code と SQL Server mssql 拡張機能を使用できます。

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

Watcher を作成する

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

    [Database Watcher] ビューが開いたら、[作成] を選択します。

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

    ヒント

    プレビュー期間中に、Database Watcher がリージョンでまだ使用できない場合は、別のリージョンに作成できます。 詳細については、「リージョン別の提供状況」に関するページをご覧ください。

  3. [ID] タブで、システム割り当てマネージド ID の状態が [オン] に設定されます。 現時点では、システム割り当てマネージド ID を持たない Watcher の作成はサポートされていません。

  4. Watcher のデータ ストアを選択します。

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

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

    • または、既存の Azure Data Explorer クラスター、無料の Azure Data Explorer クラスター、または Real Time Analytics でデータベースを使用できます。

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

      Note

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

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

  6. [確認と作成] タブで、Watcher 構成を確認して、[作成] を選択します。 新しいAzure Data Explorer クラスターを作成する既定のオプションを選択した場合、通常、デプロイには 15 分から 20 分かかります。 既存の Azure Data Explorer クラスター、無料の Azure Data Explorer クラスター、または Real Time Analytics でデータベースを選択する場合、通常、デプロイには最大で 5 分かかります。

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

    • Watcher が作成されると、新規または既存の Azure Data Explorer クラスター上のデータベースへのアクセス権が自動的に付与されます。
    • ただし、次のデータベースを選択する場合は、KQL コマンドを使用してデータ ストアへ権利を与える必要があります。
      • Microsoft Fabric の Real Time Analytics
      • 無料の Azure Data Explorer クラスター

  8. プライベート接続を使用する場合は、マネージド プライベート エンドポイントを作成します。

Watcher を開始および停止する

Watcher が作成されると、追加の構成が必要になる可能性があるため、自動的には起動されません。

Watcher を起動するには、次が必要です。

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

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

Watcher を再起動するには、停止してから、もう一度起動します。

Watcher を変更する

Azure portal では、ターゲットを追加または削除したり、プライベート エンドポイントを作成または削除したり、既存の Watcher に別のデータ ストアを使用したりできます。

Note

別の方法で説明しない限り、Watcher の構成に加えた変更は、Watcher を停止して再起動した後に有効になります。

Watcher に SQL ターゲットを追加する

Azure SQL データベース、エラスティック プール、または SQL Managed Instanceを監視する Database Watcher を有効にするには、このリソースを SQL ターゲットとして追加する必要があります。

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

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

Watcher から SQL ターゲットを削除する

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

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

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

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

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

マネージド プライベート エンドポイントを作成するには、次を実行します。

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

  2. Azure portal で Database Watcher に移動し、[マネージド プライベート エンドポイント] ページを開き、[追加] を選択します。

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

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

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

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

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

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

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

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

    重要

    プライベート エンドポイントは、保留中の状態で作成されます。 Database Watcher がリソースへの接続に使用する前に、リソース所有者が承認する必要があります。

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

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

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

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

  1. リソース、リソース グループ、またはマネージド プライベート エンドポイントを作成するリソースのサブスクリプションに対して削除ロックがある場合は、ロックを削除します。 プライベート エンドポイントが正常に削除された後、ロックを再度追加できます。
  2. Database Watcher の Azure portal ページで、[マネージド プライベート エンドポイント] ページを開きます。
  3. 削除するプライベート エンドポイントを選択します。
  4. 削除を選択します。

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

Watcher のデータ ストアを変更する

Watcher は、データ ストアを 1 つだけ持つことができます。

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

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

    • データ ストアを削除しても、Azure Data Explorer クラスターまたは Microsoft Fabric の Real Time Analytics の実際のデータ ストア データベースは削除されません。
    • 削除されたデータ ストアへのデータ コレクションを停止するには、Watcher を停止します。
    • データ ストアを削除する場合は、Watcher をもう一度起動する前に、新しいデータ ストアを追加する必要があります。

  • データ ストアを追加するには、[データ ストア] ページで [追加] を選択し、Azure Data Explorer クラスターまたは Real Time Analytics でデータベースを選択または作成します。

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

Watcher を削除する

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

同じ Watcher 名を使用する場合でも、再作成された Watcher への権利を与える必要があります。

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

SQL ターゲットへの権利を与える

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

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

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

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

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

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

    重要

    Azure portal の Microsoft Entra 認証スクリプトには Watcher 名が含まれているため、Watcher に固有です。 Watcher ごとにカスタマイズできるこのスクリプトの汎用バージョンについては、「T-SQL スクリプトを使用して SQL ターゲットへの権利を与える」を参照してください。

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

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

    1. Microsoft Entra 認証スクリプトを使用する場合は、スクリプトの実行時に Watcher が既に作成されている必要があります。 さらに、Microsoft Entra 認証に接続されている必要があります。

後で Watcher に新しいターゲットを追加する場合は、これらのターゲットが既にアクセスが許可されている論理サーバー上に存在しない限り、同様の方法でこれらのターゲットへの権利を与える必要があります。

T-SQL スクリプトを使用して SQL ターゲットへの権利を与える

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

重要

指定されたスクリプトを常に使用して、Database Watcher への権利を与えます。 別の方法でアクセスを許可すると、データ コレクションがブロックされる可能性があります。 詳細については、「Watcher 認可」を参照してください。

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

Microsoft Entra 認証済み Watcher への権利を与える

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

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

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

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

SQL 認証済み Watcher への権利を与える

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 認証を使用するための追加の構成

認証資格情報を安全に格納するために、Database Watcher で SQL 認証を使用するには、追加の構成が必要です。

ヒント

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

SQL 認証を使用してターゲットに接続するように Database Watcher を構成するには、次の手順に従います。

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

    コンテナーへのプライベート接続を使用する場合は、[マネージド プライベート エンドポイント] ページでプライベート エンドポイントを作成します。 [リソースの種類] として Microsoft.KeyVault/vaults を、[ターゲット サブリソース] として vault 選択します。 Watcher を起動する前に、プライベート エンドポイントが承認済みの状態であることを確認します。

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

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

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

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

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

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

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

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

異なる SQL ターゲットで異なるログインを使用する場合は、同じコンテナーを使用してすべてのシークレットを格納できます。

Note

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

データ ストアへの権利を与える

データベース スキーマを時間の経過と同時に作成および管理し、監視データを取り込むには、Database Watcher は、データ ストア データベースの管理 RBAC ロールのメンバーシップを必要とします。 Database Watcher では、Azure Data Explorer クラスターへのクラスター レベルのアクセスや、同じクラスターに存在する可能性がある他のデータベースへのアクセスは必要ありません。

Watcher の作成時に新しい Azure Data Explorer クラスターとデータベースを作成するか、既存のクラスターでデータベースを選択した場合、Watcher を作成するユーザーがクラスターの所有者 RBAC ロールのメンバーである場合、このアクセス権は自動的に付与されます。

既存の Watcher のデータ ストアを変更する場合、または Real Time Analytics または無料の Azure Data Explorer クラスターでデータベースを使用する場合は、このセクションの説明に従ってアクセス権を付与する必要があります。

Azure portal を使用して Azure Data Explorer データベースへの権利を与える

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

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

KQL を使用して Azure Data Explorer データベースへの権利を与える

Azure portal を使用する代わりに、KQL コマンドを使用してデータベースへの権利を与えることもできます。

  1. Kusto エクスプローラー または Azure Data エクスプローラー Web UI を使用して、Azure Data Explorer クラスター上のデータベースに接続します。 この方法を使用して、Real Time Analytics または無料の Azure Data Explorer クラスター上のデータベースへの権利を与えます。

  2. 次のサンプル KQL コマンドでは、次の 3 つのプレースホルダーを置き換えます。

    .add database [adx-database-name-placeholder] admins ('aadapp=watcher-object-id-placeholder;tenant-primary-domain-placeholder');
    プレースホルダー 代替
    adx-database-name-placeholder Azure Data Explorer クラスターまたは Real Time Analytics のデータベースの名前。
    watcher-object-id-placeholder Watcher の [ID] ページにあるオブジェクト (プリンシパル) ID 値 (GUID)。
    tenant-primary-domain-placeholder Watcher の Microsoft Entra ID テナントのドメイン名。 これは、Azure portal の Microsoft Entra ID [概要] ページで確認できます。 テナント プライマリ ドメインの代わりに、テナント ID の GUID 値も使用できます。

    Watcher と Azure Data Explorer クラスターが同じ Microsoft Entra ID テナント内にある場合は、コマンドのこの部分 (および上記のセミコロン) を省略できます。

    次に例を示します。

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

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

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

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

この方法を使用して、無料の Azure Data Explorer クラスター上、または Real Time Analyticsのデータベースへの権利を与えます。 最小限の権限の原則に従うには、閲覧者 以外の RBAC ロールにユーザーとグループを追加しないことをお勧めします。

重要

Database Watcher によって収集された SQL 監視データを表示する権利を与える場合は、データのプライバシーとセキュリティの要件を慎重に検討してください。

Database Watcher には、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 クラスターでテナント間認証を有効にする必要があります。 詳細については、「テナント間のクエリとコマンドの許可」を参照してください。

ヒント

テナント間認証は、Real Time Analytics と無料の Azure Data Explorer クラスターで有効になります。 これにより、Microsoft Entra ID テナント内のユーザーとグループに権利を与えて、これらのデータベース内のデータを表示できます。

データ ストアの管理

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

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

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

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

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

次の現象の 1 つ以上に気付いた場合は、クラスターをスケール アウト (水平方向に) または スケール アップ(垂直方向に) する必要があります。

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

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

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

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

    • 最適化されたオートスケールを有効にして、ワークロードの変化や季節的な傾向に応じてインスタンスの数を自動的に減らすか、増やすことができます。

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

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

無料の Azure Data Explorer クラスターをスケーリングすることはできません。 無料のクラスターの仕様が要件に不十分である場合は、完全な Azure Data Explorer クラスターにアップグレードします。 アップグレード プロセスでは、収集されたすべてのデータが保持されます。 アップグレード中にダウンタイムが発生する可能性があるため、アップグレードが完了したら、Watcher を停止して再起動し、データ コレクションを再開する必要がある場合があります。

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

古いデータを必要としない場合は、データ アイテム保持ポリシーを構成して自動的に消去できます。 デフォルトでは、Azure Data Explorer クラスターまたは Real Time Analytics の新しいデータベースのデータ保持期間は 365 日に設定されます。

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

Database Watcher データ ストアのスキーマとアクセスの変更

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

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

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

重要

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

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

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

クラスターが停止すると、データベース Watcher の データ コレクションも停止し、監視データはダッシュボードに表示されません。 データ コレクションを再開し、ダッシュボード経由でデータにアクセスできるようにするには、クラスターを手動で再開する必要があります。 クラスターが実行されたら、Watcher を再起動します。

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

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

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

既存の Azure Data Explorer クラスターを使用する場合は、まずストリーミング インジェストを有効にする必要があります。 これには数分かかるので、クラスターを再起動する必要があります。

大規模な資産を監視する

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

各 Watcher には、Azure Data Explorer クラスター上のデータベース、またはデータ ストアとしての Real Time Analytics が必要です。 作成する Watcher は、単一データベースを共通のデータ ストアとして使用することも、個別のデータベースを個別のデータ ストアとして使用することもできます。 次の考慮事項は、監視シナリオと要件に最適な設計選択を行うのに役立ちます。

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

  • Azure SQL 資産全体を 1 つのウィンドウで表示できます。
  • ただし、データ ストアにアクセスできるユーザーは、すべての監視データにアクセスできます。

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

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

関連するコンテンツ