Condividi tramite

Creare e configurare un database watcher (anteprima)

  • Articolo

Si applica a: Database SQL di Azure Istanza gestita di SQL di Azure

Questo articolo contiene passaggi dettagliati per creare, configurare e avviare un watcher di database nel portale di Azure per database SQL di Azure e Istanza gestita di SQL di Azure.

Il database watcher non richiede la distribuzione e la gestione di agenti di monitoraggio o di altre infrastrutture di monitoraggio. È possibile abilitare il monitoraggio approfondito del database delle risorse di Azure SQL in pochi minuti.

Per un esempio semplificato di creazione e configurazione di un database watcher, vedere Avvio rapido: Creare un database watcher per monitorare Azure SQL.

Per informazioni su come creare e configurare un watcher di database con Bicep o un modello di ARM, vedere l’esempio di codice Creare un watcher del database.

Per gestire watcher a livello di codice, vedere la documentazione dell'API REST del database watcher.

Nota

Il database watcher è attualmente in anteprima.

Prerequisiti

Per usare il database watcher, sono necessari i seguenti prerequisiti.

  • È necessaria una sottoscrizione di Azure attiva. Se non se ne ha una, creare un account gratuito. Per poter creare risorse è necessario essere membri del ruolo Collaboratore o del ruolo Proprietario della sottoscrizione o di un gruppo di risorse.

  • Per configurare e avviare un database watcher, è necessaria una destinazione SQL esistente: un database SQL di Azure, un pool elastico o un'istanza gestita di SQL.

  • I provider di risorse Microsoft.DatabaseWatcher, Microsoft.Kusto, e Microsoft.Network devono essere registrati nella sottoscrizione Azure.

    La registrazione del provider di risorse è automatica se si dispone dell'appartenenza al ruolo di controllo degli accessi in base al ruolo di Proprietario o Collaboratore a livello di sottoscrizione. In caso contrario, un utente in uno di questi ruoli deve registrare i provider di risorse prima di poter creare e configurare un watcher. Per maggiori informazioni, consultare la sezione Registrare il provider di risorse.

  • L'utente che crea e configura il watcher e le risorse cluster di Esplora dati di Azure deve essere membro del ruolo Controllo degli accessi in base al ruolo di Proprietario o Collaboratore per il gruppo di risorse o per la sottoscrizione in cui vengono create queste risorse.

    Inoltre, se si usa l'autenticazione SQL, l'utente deve essere un membro del ruolo di Proprietario per il gruppo di risorse oppure un membro del ruolo di amministratore di accesso utente per l’insieme di credenziali delle chiavi in cui sono archiviate le credenziali di autenticazione SQL.

  • L'utente che configura il watcher deve avere accesso come amministratore alle destinazioni di Azure SQL. Un amministratore concede al watcher un accesso limitato e specifico alle destinazioni di SQL Monitoring. Per ulteriori informazioni, vedere Concedere l'accesso alle destinazioni.

  • Per concedere a un watcher l'accesso a una destinazione SQL, un amministratore deve eseguire script T-SQL usando SQL Server Management Studio (SSMS), Azure Data Studio o Visual Studio Code con l'estensione mssql di SQL Server.

  • Per usare il Collegamento privato di Azure per la connettività privata alle risorse di Azure, l'utente che approva l'endpoint privato deve essere membro del ruolo Controllo degli accessi in base al ruolo di Proprietario o deve avere le autorizzazioni di controllo degli accessi in base al ruolo necessarie. Per altre informazioni, vedere Approvazione del controllo degli accessi in base al ruolo per l'endpoint privato.

Creare un watcher

  1. Nel portale di Azure, nel menu di spostamento, selezionare Tutti i servizi. Selezionare Monitoraggio come categoria e in Strumenti di monitoraggio selezionare Database watcher. In alternativa, è possibile digitare database watcher nella casella di Ricerca nella parte superiore della pagina del portale e selezionare i database watcher.

    Dopo aver aperto la visualizzazione Database watcher, selezionare Crea.

  2. Nella scheda Informazioni di base, selezionare la sottoscrizione e il gruppo di risorse per watcher, immettere il nome del watcher e selezionare un'area di Azure.

    Suggerimento

    Durante l'anteprima, se il database watcher non è ancora disponibile nell'area, è possibile crearlo in un'area diversa. Per ulteriori informazioni, vedere Disponibilità regionale.

  3. Nella scheda Identità l'identità gestita assegnata dal sistema del watcher è abilitata per impostazione predefinita. Se invece si vuole che il watcher usi un'identità gestita assegnata dall'utente, selezionare il pulsante Aggiungi , trovare l'identità da usare e selezionare il pulsante Aggiungi . Per rendere effettiva l'identità assegnata dall'utente per il watcher, disabilitare l'identità gestita assegnata dal sistema.

    Per altre informazioni sulle identità gestite in Database Watcher, vedere Modificare l'identità watcher.

  4. Scegliere un archivio dati per il watcher.

    Per impostazione predefinita, la creazione di un watcher crea anche un cluster di Esplora dati di Azure e aggiunge un database in tale cluster come archivio dati per i dati di monitoraggio raccolti.

    • Per impostazione predefinita, il nuovo cluster di Esplora dati di Azure usa lo SKU extra small con ottimizzazione per il calcolo. Si tratta dello SKU più economico che fornisce ancora un contratto di servizio. È possibile ridimensionare questo cluster in un secondo momento, in base alle esigenze.

    • Oppure, è possibile usare un database in un cluster di Esplora dati di Azure, in un cluster Esplora dati di Azure gratuito o in Analisi in tempo reale.

      1. Nella scheda Archivio dati, scegliere l'opzione Seleziona un archivio dati e selezionare Aggiungi.
      2. Selezionare un database di Analisi in tempo reale o un cluster di Esplora dati di Azure.
      3. Se si usa un cluster di Esplora dati di Azure esistente, è necessario abilitare l'inserimento in streaming.
      4. Creare un nuovo database o usarne uno esistente.

      Nota

      Qualsiasi database esistente selezionato deve essere vuoto o deve essere un database usato in precedenza come archivio dati del database watcher. La selezione di un database che contiene oggetti non creati dal database watcher non è supportata.

    • In alternativa, è possibile ignorare l'aggiunta di un archivio dati in questo momento e aggiungerlo in un secondo momento. Per avviare il watcher, è necessario un archivio dati.

  5. Nella scheda Destinazioni SQL, aggiungere una o più risorse di Azure SQL da monitorare. È possibile ignorare l'aggiunta di destinazioni SQL durante la creazione del watcher e aggiungerle in un secondo momento. È necessario aggiungere almeno una destinazione prima di avviare il watcher.

  6. Nella scheda Rivedi e crea, esaminare la configurazione del watcher e selezionare Crea. Se si seleziona l'opzione predefinita per creare un nuovo cluster di Esplora dati di Azure, la distribuzione richiede in genere 15-20 minuti. Se si seleziona un database in un cluster di Esplora dati di Azure, in un cluster Esplora dati di Azure gratuito o in Analisi in tempo reale, la distribuzione richiede in genere fino a 5 minuti.

  7. Al completamento della distribuzione, concedere l'accesso alle destinazioni SQL al watcher.

  8. Potrebbe anche essere necessario concedere all'watcher l'accesso all'archivio dati.

    • L'accesso a un database o a un cluster di Esplora dati di Azure esistente viene concesso automaticamente durante la creazione del watcher se l'utente che crea il watcher è membro del ruolo Controllo degli accessi in base al ruolo di Proprietario per il cluster.
    • Tuttavia, è necessario concedere l'accesso all'archivio dati usando un comando KQL se si seleziona un database in:
      • Analisi in tempo reale in Microsoft Fabric.
      • Un cluster azure Esplora dati gratuito.

  9. Creare e approvare endpoint privati gestiti se si vuole usare la connettività privata.

    • Se l'accesso pubblico nelle destinazioni SQL, l'archivio dati e l'insieme di credenziali delle chiavi sono abilitati e si vuole usare la connettività pubblica, assicurarsi che tutti i prerequisiti di connettività pubblica siano soddisfatti.

Avviare e arrestare un watcher

Quando viene creato un watcher, non viene avviato automaticamente perché potrebbe essere necessaria una configurazione aggiuntiva.

Affinché un watcher venga avviato, deve avere:

Dopo aver configurato completamente un watcher, nella pagina Panoramica, usare il pulsante Start per avviare la raccolta di dati. In pochi minuti, i nuovi dati di monitoraggio vengono visualizzati nell'archivio dati e nelle dashboard. Se non vengono visualizzati nuovi dati entro cinque minuti, vedere Risoluzione dei problemi.

È possibile arrestare il watcher con il pulsante Arresta se non è necessario monitorare le risorse di Azure SQL per un certo periodo di tempo.

Per riavviare un watcher, arrestarlo e quindi riavviarlo.

Modificare un watcher

Nella portale di Azure è possibile aggiungere o rimuovere destinazioni, creare o eliminare endpoint privati, usare un archivio dati diverso per un watcher esistente o modificare l'identità gestita del watcher.

Nota

Se non diversamente specificato, le modifiche apportate alla configurazione del watcher diventano effettive dopo l'arresto e il riavvio del watcher.

Aggiungere destinazioni SQL a un watcher

Per abilitare il monitoraggio del database watcher per un database SQL di Azure, un pool elastico o un'istanza gestita di SQL, è necessario aggiungere questa risorsa come destinazione SQL.

  1. Per aggiungere una destinazione, nella pagina Destinazioni SQL, selezionare Aggiungi.
  2. Trovare la risorsa di Azure SQL da monitorare. Selezionare il tipo di risorsa e la sottoscrizione, poi selezionare la destinazione SQL dall'elenco delle risorse. Le destinazioni SQL possono essere in qualsiasi sottoscrizione all'interno dello stesso tenant di Microsoft Entra ID del watcher.
  3. Per monitorare la replica primaria e una replica secondaria a disponibilità elevata di un database, un pool elastico o un'istanza gestita di SQL, aggiungere due destinazioni SQL separate per la stessa risorsa e selezionare la casella Finalità di lettura per una di esse. Analogamente, creare due destinazioni SQL separate per una replica geografica e la relativa replica secondaria a disponibilità elevata, se presenti.
    • Se si seleziona la casella Finalità di lettura, l’obiettivo SQL viene configurato per monitorare solo la replica secondaria a disponibilità elevata.
    • Non selezionare la casella Finalità di lettura se si vuole monitorare solo la replica primaria o solo la replica geografica oppure se non esiste una replica secondaria a disponibilità elevata per questa risorsa o se la funzionalità di scalabilità orizzontale in lettura è disabilitata.

Per impostazione predefinita, il database watcher usa l'autenticazione di Microsoft Entra per la connessione alle destinazioni SQL. Se si desidera che il watcher usi l'autenticazione SQL, spuntare la casella Usa autenticazione SQL e immettere i dettagli richiesti. Per altre informazioni, vedere Configurazione aggiuntiva per l'uso dell'autenticazione SQL.

Rimuovere le destinazioni SQL da un watcher

Per rimuovere una o più destinazioni, aprire la pagina Destinazioni SQL, selezionare le destinazioni da rimuovere nell'elenco e selezionare Elimina.

La rimozione di una destinazione interrompe il monitoraggio per una risorsa di Azure SQL dopo il riavvio del watcher, ma non elimina la risorsa effettiva.

Se si elimina una risorsa di Azure SQL monitorata dal database watcher, è necessario rimuovere anche la destinazione corrispondente. Poiché vi è un limite al numero di destinazioni SQL che un watcher può avere, mantenere le destinazioni obsolete potrebbe impedire l'aggiunta di nuove destinazioni.

Creare un endpoint privato gestito

È necessario creare endpoint privati gestiti se si desidera usare la connettività privata per la raccolta di dati dalle destinazioni SQL, per l'inserimento nell'archivio dati e per la connessione a un insieme di credenziali delle chiavi. Se non si creano endpoint privati, il database watcher usa per impostazione predefinita la connettività pubblica.

Nota

Database Watcher richiede che i propri endpoint privati gestiti si connettano alle risorse di Azure. Qualsiasi endpoint privato già esistente per un server logico SQL di Azure, un'istanza gestita di SQL, un cluster di Esplora dati di Azure o un insieme di credenziali delle chiavi non può essere usato da un watcher.

Per creare un endpoint privato gestito per un watcher:

  1. Se è presente un blocco di sola lettura per la risorsa, il gruppo di risorse o la sottoscrizione della risorsa per cui si sta creando un endpoint privato gestito, rimuovere il blocco. È possibile aggiungere di nuovo il blocco dopo la creazione dell'endpoint privato.

  2. Passare a un database watcher in portale di Azure, aprire la pagina Endpoint privati gestiti e selezionare Aggiungi.

  3. Immettere un nome per l'endpoint privato.

  4. Selezionare la sottoscrizione della risorsa di Azure per la quale si crea l'endpoint privato.

  5. A seconda del tipo di risorsa per cui si vuole creare un endpoint privato, selezionare il tipo di risorsa e la sotto-risorsa di destinazione come indicato di seguito:

    Conto risorse Tipo di risorsa Risorsa secondaria di destinazione
    Server logico Microsoft.Sql/servers sqlServer
    Istanza gestita di SQL Microsoft.Sql/managedInstances managedInstance
    Cluster di Esplora dati di Azure Microsoft.Kusto/clusters cluster
    Insieme di credenziali delle chiavi Microsoft.KeyVault/vaults vault

  6. Selezionare la risorsa per la quale si desidera creare l'endpoint privato. Può trattarsi di un server logico SQL di Azure, di un'istanza gestita di SQL, di un cluster di azure Esplora dati o di un insieme di credenziali delle chiavi.

    • La creazione di un endpoint privato per un server logico database SQL di Azure consente la connettività privata del database watcher per tutte le destinazioni del database e del pool elastico in tale server.

  7. Facoltativamente, immettere la descrizione per l'endpoint privato. Ciò consente al proprietario della risorsa di approvare la richiesta.

  8. Seleziona Crea. La creazione di un endpoint privato può richiedere alcuni minuti. Un endpoint privato viene creato una volta che lo stato provisioning cambia da Accettato o In esecuzione a Riuscito. Aggiornare la visualizzazione per visualizzare lo stato provisioning corrente.

    Importante

    L'endpoint privato viene creato nello stato In sospeso. Deve essere approvato dal proprietario della risorsa prima che il database watcher possa usarlo per connettersi alla risorsa.

    Per consentire ai proprietari delle risorse di controllare la connettività di rete, gli endpoint privati del database watcher non vengono approvati automaticamente.

  9. Il proprietario della risorsa deve approvare la richiesta dell'endpoint privato.

Se un watcher è già in esecuzione quando viene approvato un endpoint privato, è necessario riavviarlo per iniziare a usare la connettività privata.

Suggerimento

È necessario creare un endpoint privato aggiuntivo per il cluster Esplora dati di Azure se la connettività pubblica del cluster è disabilitata. Per altre informazioni, vedere Connessione privata all’archivio dati.

Eliminare un endpoint privato gestito

  1. Se è presente un blocco di eliminazione o di sola lettura per la risorsa, il gruppo di risorse o la sottoscrizione della risorsa per cui si sta cancellando un endpoint privato gestito, rimuovere il blocco. È possibile aggiungere di nuovo il blocco dopo l'eliminazione dell'endpoint privato.
  2. Nella pagina portale di Azure del database watcher, aprire la pagina Endpoint privati gestiti.
  3. Selezionare l'endpoint privato da eliminare.
  4. Selezionare Elimina.

L'eliminazione di un endpoint privato gestito arresta la raccolta di dati dalle destinazioni SQL che usano questo endpoint privato. L'eliminazione dell'endpoint privato gestito per il cluster Esplora dati di Azure arresta la raccolta di dati per tutte le destinazioni. Per riprendere la raccolta dei dati, ricreare l'endpoint privato o abilitare la connettività pubblica e riavviare il watcher.

Modificare l'archivio dati per un watcher

Un watcher può avere un solo archivio dati.

Per modificare l'archivio dati attuale, rimuovere l'archivio dati esistente e quindi aggiungere un nuovo archivio dati.

  • Per rimuovere l'archivio dati attuale, aprire la pagina Archivio dati, selezionare l'archivio dati nella griglia e selezionare Elimina.

    • La rimozione di un archivio dati non elimina il database effettivo dell'archivio dati in un cluster di Esplora dati di Azure o in Analisi in tempo reale in Microsoft Fabric.
    • Per arrestare la raccolta di dati in un archivio dati rimosso, arrestare il watcher.
    • Se si rimuove un archivio dati, dovrà essere aggiunto un nuovo archivio dati prima di poter riavviare il watcher.

  • Per aggiungere un archivio dati, selezionare Aggiungi nella pagina Archivio dati, poi selezionare o creare un database in un cluster di Esplora dati di Azure o in Analisi in tempo reale.

    • Il database selezionato deve essere vuoto o deve essere un database usato in precedenza come archivio dati del database watcher. La selezione di un database che contiene oggetti non creati dal database watcher non è supportata.
    • Dopo aver aggiunto un archivio dati, è necessario concedere l'accesso al watcher per usarlo. Per ulteriori informazioni, vedere Concedere l'accesso all’archivio dati.
    • Il nuovo archivio dati viene usato dopo il riavvio del watcher.

Modificare l'identità watcher

Un watcher deve avere un'identità gestita per l'autenticazione nelle destinazioni SQL, negli insiemi di credenziali delle chiavi e nell'archivio dati. È possibile usare un'identità gestita assegnata dal sistema o un'identità gestita assegnata dall'utente. Per altre informazioni sulle identità gestite in Azure, vedere Che cosa sono le identità gestite per le risorse di Azure?

Le considerazioni seguenti consentono di scegliere il tipo di identità gestita per un watcher:

  • Assegnata dal sistema

    • Abilitato per impostazione predefinita quando si crea un watcher.
    • Sempre associato a un singolo watcher.
    • Creato ed eliminato con watcher.
    • Se si disabilita un'identità assegnata dal sistema per un watcher, qualsiasi accesso concesso a tale identità viene perso. Riabilitare l'identità assegnata dal sistema per lo stesso watcher crea una nuova identità diversa con un ID oggetto (entità) diverso. È necessario concedere l'accesso alle destinazioni SQL, all'insieme di credenziali delle chiavi e all'archivio dati a questa nuova identità.

  • Assegnata dall'utente

    • È attivo solo se l'identità assegnata dal sistema è disabilitata per il watcher.
    • La stessa identità assegnata dall'utente può essere assegnata a più watcher per semplificare la gestione degli accessi, ad esempio durante il monitoraggio di grandi proprietà SQL di Azure. Anziché concedere l'accesso alle identità assegnate dal sistema di più watcher, è possibile concedere l'accesso a un'unica identità assegnata dall'utente.
    • Per supportare la separazione dei compiti, la gestione delle identità può essere separata dalla gestione watcher. Un'identità assegnata dall'utente può essere creata e concessa l'accesso da un utente diverso, prima o dopo la creazione del watcher.
    • Viceversa, quando un watcher viene eliminato, l'identità assegnata dall'utente e il relativo accesso rimangono invariati. La stessa identità può quindi essere usata per un nuovo watcher.
    • La specifica di più identità assegnate dall'utente per un watcher non è supportata.

Per modificare l'identità gestita per un watcher, aprire la pagina Identità di un watcher.

  • Per usare un'identità assegnata dal sistema, abilitare l'interruttore Identità assegnata dal sistema.

  • Per usare un'identità assegnata dall'utente, disabilitare l'interruttore Identità assegnata dal sistema. Selezionare il pulsante Aggiungi per trovare e aggiungere un'identità assegnata dall'utente esistente.

    Per creare una nuova identità assegnata dall'utente, vedere Creare un'identità gestita assegnata dall'utente.

  • Per rimuovere un'identità assegnata dall'utente da un watcher, selezionarla nell'elenco e selezionare Rimuovi. Dopo aver rimosso un'identità assegnata dall'utente, è necessario aggiungere un'identità assegnata dall'utente diversa o abilitare l'identità assegnata dal sistema.

    L'identità assegnata dall'utente rimossa non viene eliminata dal tenant microsoft Entra ID.

Selezionare il pulsante Salva per salvare le modifiche all'identità. Non è possibile salvare le modifiche all'identità se ciò comporta l'assenza di identità da parte del watcher. I watcher senza un'identità gestita valida non sono supportati.

Suggerimento

È consigliabile che il nome visualizzato dell'identità gestita watcher sia univoco all'interno del tenant di Microsoft Entra ID. È possibile scegliere un nome univoco durante la creazione di un'identità assegnata dall'utente per i watcher.

Il nome visualizzato dell'identità assegnata dal sistema corrisponde al nome del watcher. Se si usa l'identità assegnata dal sistema, assicurarsi che il nome watcher sia univoco all'interno del tenant di Microsoft Entra ID.

Se il nome visualizzato dell'identità gestita non è univoco, lo script T-SQL per concedere l'accesso al watcher alle destinazioni SQL ha esito negativo e viene visualizzato un errore di nome visualizzato duplicato. Per altre informazioni e per una soluzione alternativa, vedere Account di accesso e utenti di Microsoft Entra con nomi visualizzati non univoci.

Poco dopo il salvataggio delle modifiche all'identità, il watcher si riconnette alle destinazioni SQL, agli insiemi di credenziali delle chiavi (se usati) e all'archivio dati usando l'identità gestita corrente.

Eliminare un watcher

Se è presente un blocco di eliminazione o di sola lettura sul watcher, sul relativo gruppo di risorse o sulla relativa sottoscrizione, rimuovere il blocco. È possibile aggiungere di nuovo il blocco dopo l'eliminazione del watcher.

Quando si elimina un watcher con l'identità gestita assegnata dal sistema abilitata, viene eliminata anche l'identità. In questo modo viene rimosso qualsiasi accesso concesso a questa identità. Se si ricrea il watcher in un secondo momento, è necessario concedere l'accesso all'identità gestita assegnata dal sistema del nuovo watcher per l'autenticazione a ogni risorsa. Valuta gli ambiti seguenti:

Si dovrà concedere l'accesso a un watcher ricreato, anche se viene usato lo stesso nome del watcher.

Quando si elimina un watcher, le risorse di Azure a cui si fa riferimento come destinazioni SQL e l'archivio dati non vengono eliminati. I dati di monitoraggio SQL raccolti sono conservati nell'archivio dati ed è possibile usare lo stesso database Esplora dati di Azure o Analisi in tempo reale dell'archivio dati se si crea un nuovo watcher in un secondo momento.

Concedere l'accesso alle destinazioni SQL

Per consentire a un watcher di raccogliere dati di monitoraggio SQL, è necessario eseguire uno script T-SQL che concede autorizzazioni SQL specifiche e limitate al watcher.

  • Per eseguire lo script in database SQL di Azure, è necessario l'accesso da amministratore del server al server logico contenente i database e i pool elastici da monitorare.

    • In database SQL di Azure, è necessario eseguire lo script una sola volta per ogni server logico per ogni watcher creato. In questo modo, si concede al watcher l'accesso a tutti i database nuovi ed esistenti, e ai pool elastici in tale server.

  • Per eseguire lo script in Istanza gestita di SQL di Azure, è necessario essere un membro del ruolo del server sysadmin o securityadmin, oppure disporre dell'autorizzazione server CONTROL per l'istanza gestita di SQL.

    • In Istanza gestita di SQL di Azure, è necessario eseguire lo script in ogni istanza da monitorare.

  1. Passare al watcher nel portale di Azure, selezionare Destinazioni SQL, selezionare uno dei collegamenti di Concedi accesso per aprire lo script T-SQL e copiare lo script. Assicurarsi di scegliere il collegamento corretto per il tipo di destinazione e il tipo di autenticazione da usare.

    Importante

    Lo script di autenticazione di Microsoft Entra in portale di Azure è specifico di un watcher perché include il nome dell'identità gestita del watcher. Per una versione generica di questo script che è possibile personalizzare per ogni watcher, vedere Concedere l'accesso alle destinazioni SQL con script T-SQL.

  2. In SQL Server Management Studio, Azure Data Studio o qualsiasi altro strumento client SQL, aprire un nuovo intervallo di query e connetterlo al database master in un server logico di Azure SQL contenente la destinazione, oppure al database master in una destinazione dell'istanza gestita di SQL.

  3. Incollare ed eseguire lo script T-SQL per concedere l'accesso al watcher. Lo script crea un account di accesso che verrà usato dal watcher per connettersi e concede autorizzazioni specifiche e limitate per raccogliere i dati di monitoraggio.

    1. Se si usa uno script di autenticazione di Microsoft Entra e il watcher usa l'identità gestita assegnata dal sistema, è necessario che il watcher sia già stato creato quando si esegue lo script. Se il watcher userà un'identità gestita assegnata dall'utente, è possibile eseguire lo script prima o dopo la creazione del watcher.

    È necessario essere connessi con l'autenticazione di Microsoft Entra durante l'esecuzione degli script di accesso T-SQL che concedono l'accesso a un'identità gestita.

Se si aggiungono nuove destinazioni a un watcher in un secondo momento, è necessario concedere l'accesso a queste destinazioni in modo analogo, a meno che queste destinazioni non si trovino in un server logico in cui è già stato concesso l'accesso.

Concedere l'accesso alle destinazioni SQL con script T-SQL

Esistono script diversi per l'autenticazione di Microsoft Entra e l'autenticazione SQL e per le destinazioni database SQL di Azure e Istanza gestita di SQL di Azure.

Importante

Usare sempre gli script forniti per concedere l'accesso a un database watcher. Concedere l'accesso in modo diverso può bloccare la raccolta di dati. Per altre informazioni, vedere Autorizzazione a Watcher.

Prima di eseguire uno script, sostituire tutte le istanze di segnaposto che potrebbero essere presenti nello script, ad esempio login-name-placeholder e password-placeholder con i valori effettivi.

Concedere l'accesso ai watcher autenticati di Microsoft Entra

Questo script crea un account di accesso di autenticazione di Microsoft Entra (noto in precedenza come Azure Active Directory) in un server logico in database SQL di Azure. L'account di accesso viene creato per l'identità gestita di un watcher. Lo script concede al watcher le autorizzazioni necessarie e sufficienti per raccogliere i dati di monitoraggio da tutti i database e i pool elastici nel server logico.

Se il watcher usa l'identità gestita assegnata dal sistema, è necessario usare il nome watcher come nome di accesso. Se il watcher usa un'identità gestita assegnata dall'utente, è necessario usare il nome visualizzato dell'identità come nome di accesso.

Lo script deve essere eseguito nel database master nel server logico. Occorre essere connessi usando un account di accesso per l'autenticazione di Microsoft Entra che è un amministratore del server.

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];

Concedere l'accesso a watcher autenticati di SQL

Si rendono necessari alcuni passaggi aggiuntivi quando si usa l'autenticazione SQL. Vedere Configurazione aggiuntiva per l'uso dell'autenticazione SQL.

Questo script crea un account di accesso di autenticazione SQL in un server logico nel database SQL di Azure. Concede le autorizzazioni necessarie e sufficienti all'account di accesso per raccogliere i dati di monitoraggio da tutti i database e i pool elastici in tale server logico.

Lo script deve essere eseguito nel database master nel server logico, usando un account di accesso che è un amministratore del server logico.

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];

Configurazione aggiuntiva per l'uso dell'autenticazione SQL

Per archiviare le credenziali di autenticazione in modo sicuro, l'uso dell'autenticazione SQL nel database watcher richiede una configurazione aggiuntiva.

Suggerimento

Per una configurazione più sicura, più semplice e meno soggetta a errori, è consigliabile abilitare l'autenticazione di Microsoft Entra per le risorse SQL di Azure e usarla invece dell'autenticazione SQL.

Per configurare il database watcher per connettersi a una destinazione tramite l'autenticazione SQL, seguire questa procedura:

  1. Creare un insieme di credenziali in Azure Key Vault o identificare un insieme di credenziali esistente che è possibile usare. L'insieme di credenziali deve usare il modello di autorizzazione Controllo degli accessi in base al ruolo. Il modello di autorizzazione Controllo degli accessi in base al ruolo è l'impostazione predefinita per i nuovi insiemi di credenziali. Se si desidera usare un insieme di credenziali esistente, assicurarsi che non sia configurato per l'uso del modello di criteri di accesso precedente.

    Se si desidera usare la connettività privata all'insieme di credenziali, creare un endpoint privato nella pagina Endpoint privati gestiti. Selezionare Microsoft.KeyVault/vaults come Tipo di risorsa e vault come Sotto-risorsa di destinazione. Verificare che l'endpoint privato sia nello stato Approvato prima di avviare il watcher.

    Se si desidera usare la connettività pubblica, l'insieme di credenziali deve consentire accesso pubblico da tutte le reti abilitate. La limitazione della connettività dell'insieme di credenziali pubblico a reti specifiche non è supportata nel database watcher.

  2. Creare un account di accesso per l'autenticazione SQL in ogni server logico di Azure SQL o in un'istanza gestita da monitorare e concedere le specifiche autorizzazioni limitate usando script di accesso forniti. Nello script sostituire i segnaposto nome di accesso e password con i valori effettivi. Usare una password complessa.

  3. Nell'insieme di credenziali, creare due segreti: un segreto per il nome dell'account di accesso, e un segreto separato per la password. Usare qualsiasi nome valido come nome segreto e immettere il nome di accesso e la password usati nello script T-SQL come valore del segreto per ogni segreti.

    Ad esempio, i nomi dei due segreti potrebbero essere database-watcher-login-name e database-watcher-password. I valori dei segreti sarebbero un nome di accesso e una password complessa.

    Per creare segreti, è necessario essere membri del ruolo Controllo degli accessi in base al ruolo del Responsabile dei segreti dell'insieme di credenziali delle chiavi.

  4. Aggiungere una destinazione SQL a un watcher. Quando si aggiunge una destinazione, spuntare la casella Usa autenticazione SQL e selezionare il vault in cui sono memorizzati il nome e la password di accesso segreti. Inserire i nomi segreti per il nome di login e la password nei campi corrispondenti.

    Quando si aggiunge una destinazione SQL, non immettere il nome di accesso e la password effettivi. Usando l'esempio precedente, immettere i nomi dei segreti database-watcher-login-name e database-watcher-password.

  5. Quando si aggiunge una destinazione SQL nel portale di Azure, all'identità gestita del watcher viene concesso automaticamente l'accesso necessario ai segreti dell'insieme di credenziali delle chiavi se l'utente corrente è membro del ruolo Proprietari o amministratore accesso utente per l'insieme di credenziali delle chiavi. In caso contrario, seguire il passaggio successivo per concedere manualmente l'accesso richiesto.

  6. Nella pagina Controllo di accesso (IAM) di ogni segreto, aggiungere un'assegnazione di ruolo per l'identità gestita del watcher nel ruolo Controllo degli accessi in base al ruolo dell'Utente dei segreti dell'insieme di credenziali delle chiavi. Per seguire il principio dei privilegi minimi, aggiungere questa assegnazione di ruolo per ogni segreto, anziché per l'intero insieme di credenziali. La pagina Controllo di accesso (IAM) viene visualizzata solo se l'insieme di credenziali è configurato per l'uso del modello di autorizzazione di Controllo degli accessi in base al ruolo.

Se si desidera usare diverse credenziali di autenticazione SQL in destinazioni SQL diverse, è necessario creare diverse coppie di segreti. È possibile usare lo stesso insieme di credenziali o insiemi di credenziali diversi per archiviare i segreti per ogni destinazione SQL.

Nota

Se si aggiorna il valore del segreto per un nome di accesso o una password nell'insieme di credenziali delle chiavi durante l'esecuzione di un watcher, il watcher si riconnette alle destinazioni usando le nuove credenziali di autenticazione SQL entro 15 minuti. Per iniziare subito a usare le nuove credenziali, arrestare e riavviare il watcher.

Concedere l'accesso all'archivio dati

Per creare e gestire lo schema del database nell’archivio dati e per inserire i dati di monitoraggio, il database watcher richiede l'appartenenza al ruolo controllo degli accessi in base al ruolo come Amministrazione nel database dell'archivio dati in un cluster di Esplora dati di Azure o in Analisi in tempo reale. Il database watcher non richiede l'accesso a livello di cluster al cluster di Esplora dati di Azure o qualsiasi accesso ad altri database che potrebbero trovarsi nello stesso cluster.

Se si usa un database in un cluster di Azure Esplora dati come archivio dati, questo accesso viene concesso automaticamente se si è membri del ruolo Controllo degli accessi in base al ruolo proprietario per il cluster. In caso contrario, l'accesso deve essere concesso come descritto in questa sezione.

Se si usa un database in Analisi in tempo reale o in un cluster di Azure Esplora dati gratuito, è necessario concedere l'accesso usando KQL.

Concedere l'accesso a un database Esplora dati di Azure usando il portale di Azure

Si può usare il portale di Azure per concedere l'accesso a un database nel cluster di Esplora dati di Azure:

  1. Per un database in un cluster di Esplora dati di Azure, nel menu delle risorse in Sicurezza e rete selezionare Autorizzazioni. Non usare la pagina Autorizzazioni del cluster.
  2. Selezionare Aggiungi, poi Amministrazione.
  3. Nella pagina Nuove entità selezionare Applicazioni aziendali. Se il watcher usa l'identità gestita assegnata dal sistema, digitare il nome del watcher nella casella Cerca . Se il watcher usa un'identità gestita assegnata dall'utente, digitare il nome visualizzato di tale identità nella casella Cerca .
  4. Selezionare l'applicazione aziendale per l'identità gestita del watcher.

Concedere l'accesso a un database Esplora dati di Azure usando KQL

Anziché usare il portale di Azure, è anche possibile concedere l'accesso al database usando un comando KQL. Usare questo metodo per concedere l'accesso a un database in Analisi in tempo reale o in un cluster di Esplora dati di Azure gratuito.

  1. Connessione a un database nel cluster di Esplora dati di Azure usando Kusto Explorer o l'interfaccia utente Web di Esplora dati di Azure.

  2. Nel seguente comando KQL di esempio, sostituire tre segnaposto come indicato nella tabella:

    .add database [adx-database-name-placeholder] admins ('aadapp=identity-principal-id-placeholder;tenant-primary-domain-placeholder');
    Segnaposto Sostituzione
    adx-database-name-placeholder Nome di un database in un cluster di Esplora dati di Azure o in Analisi in tempo reale.
    identity-principal-id-placeholder Valore ID entità di un'identità gestita (GUID), disponibile nella pagina Identity del watcher. Se l'identità assegnata dal sistema è abilitata, usare il relativo valore ID entità. In caso contrario, usare il valore ID entità dell'identità assegnata dall'utente.
    tenant-primary-domain-placeholder Nome di dominio del tenant microsoft Entra ID dell'identità gestita watcher. È disponibile nella pagina Panoramica di Microsoft Entra ID nel portale di Azure. Anziché il dominio primario del tenant, è possibile usare anche il valore GUID ID tenant.

    Questa parte del comando è necessaria se si usa un database in Analisi in tempo reale o in un cluster azure Esplora dati gratuito.

    Il valore del nome di dominio o dell'ID tenant (e il punto e virgola precedente) può essere omesso per un database in un cluster di Azure Esplora dati perché il cluster si trova sempre nello stesso tenant id di Microsoft Entra ID dell'identità gestita watcher.

    Ad esempio:

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

Per altre informazioni, vedere Controllo degli accessi in base al ruolo di Kusto.

Concedere l'accesso all'archivio dati a utenti e gruppi

È possibile usare il portale di Azure o un comando KQL per concedere a utenti e gruppi l'accesso a un database su un cluster di Esplora dati di Azure o Analisi in tempo reale. Per concedere l'accesso, è necessario essere membri del ruolo controllo degli accessi in base al ruolo Amministrazione nel database.

Usare un comando KQL concedere l'accesso a un database nel cluster gratuito di Esplora dati di Azure o in Analisi in tempo reale. Per seguire il principio dei privilegi minimi, è consigliabile non aggiungere utenti e gruppi a un ruolo controllo degli accessi in base al ruolo diverso da Visualizzatore per impostazione predefinita.

Importante

Considerare attentamente i requisiti di privacy e sicurezza dei dati quando si concede l'accesso per visualizzare i dati di monitoraggio SQL raccolti dal database watcher.

Anche se il database watcher non ha la possibilità di raccogliere dati archiviati nelle tabelle utente nei database SQL, alcuni set di dati, ad esempio sessioni attive, metadati di indice, indici mancanti, statistiche dei runtime di query, statistiche dell'attesa di query, statistiche di sessione e metadati di tabella potrebbero contenere dati potenzialmente sensibili, ad esempio nomi di tabella e indice, testo della query, valori dei parametri di query, nomi di accesso e così via.

Concedendo l'accesso alla visualizzazione all'archivio dati a un utente che non ha accesso per visualizzare questi dati in un database SQL, è possibile abilitarli per visualizzare i dati sensibili che non sarebbero in grado di visualizzare in altro modo.

Concedere l'accesso all'archivio dati tramite il portale di Azure

Si può usare il portale di Azure per concedere a utenti e gruppi l'accesso a un database in un cluster di Esplora dati di Azure:

  1. Per un database in un cluster di Esplora dati di Azure, nel menu delle risorse in Sicurezza e rete, selezionare Autorizzazioni. Non usare la pagina Autorizzazioni del cluster.
  2. Selezionare Aggiungi, poi Spettatori.
  3. Nella pagina Nuove entità di sicurezza, digitare il nome dell'utente o del gruppo nella casella di Ricerca.
  4. Selezionare l'utente o il gruppo.

Concedere l'accesso all'archivio dati usando KQL

Anziché usare il portale di Azure, si può anche concedere l'accesso al database a utenti e gruppi usando un comando KQL. I seguenti comandi KQL esemplificativi concedono l'accesso in lettura ai dati all'utente mary@contoso.com e al gruppo SQLMonitoringUsers@contoso.com in un tenant di Microsoft Entra ID con un valore ID tenant specifico:

.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');

Per altre informazioni, vedere Controllo degli accessi in base al ruolo di Kusto.

Per concedere l'accesso all'archivio dati a utenti e gruppi da un altro tenant, è necessario abilitare l'autenticazione tra tenant nel cluster di Esplora dati di Azure. Per altre informazioni, vedere Consentire query e comandi tra tenant.

Suggerimento

Per concedere l'accesso a utenti e gruppi nel tenant di Microsoft Entra ID, l'autenticazione tra tenant è abilitata in Analisi in tempo reale e nei cluster Esplora dati di Azure.

Gestire l'archivio dati

Questa sezione descrive come gestire l'archivio dati di monitoraggio, che include scalabilità, conservazione dei dati e altre configurazioni. Le considerazioni sul ridimensionamento del cluster in questa sezione sono rilevanti se si usa un database nel cluster di Esplora dati di Azure. Se si usa un database in Analisi in tempo reale in Fabric, il ridimensionamento viene gestito automaticamente.

Ridimensionamento del cluster di Esplora dati di Azure

È possibile ridimensionare il cluster di Esplora dati di Azure in base alle esigenze. Ad esempio, è possibile ridurre il cluster allo SKU di sviluppo/test extra small se non è necessario un contratto di servizio e se le prestazioni di query e inserimento dati rimangono accettabili.

Per molte distribuzioni del database watcher, lo SKU predefinito Extra small, Con ottimizzazione per il calcolo con 2 istanze del cluster sarà sufficiente per un periodo illimitato. In alcuni casi, a seconda della configurazione e delle modifiche del carico di lavoro nel tempo, potrebbe essere necessario ridimensionare il cluster per garantire prestazioni di query adeguate e mantenere bassa latenza di inserimento dati.

Esplora dati di Azure supporta il ridimensionamento verticale e orizzontale del cluster. Con il ridimensionamento verticale, si modifica lo SKU del cluster, alterando quindi il numero di vCPU, memoria e cache per ogni istanza (nodo). Con il ridimensionamento orizzontale, lo SKU rimane invariato, ma il numero di istanze nel cluster viene aumentato o diminuito.

È necessario aumentare il numero di istanze del cluster (orizzontalmente) o aumentare (verticalmente) se si notano uno o più dei sintomi seguenti:

  • Le prestazioni della dashboard o delle query ad hoc diventano troppo lente.
  • Si eseguono molte query simultanee nel cluster e si osservano gli errori di limitazione.
  • La latenza di inserimento dati diventa costantemente superiore a quella accettabile.

In generale, non è necessario ridimensionare il cluster man mano che la quantità di dati nell'archivio dati aumenta nel tempo. Ciò è dovuto al fatto che le query della dashboard e le query analitiche più comuni usano solo i dati più recenti, memorizzati nella cache nell'archiviazione SSD locale nei nodi del cluster.

Tuttavia, se si eseguono query analitiche che si estendono su intervalli di tempo più lunghi, potrebbero risultare più lente nel corso del tempo, man mano che la quantità totale di dati raccolti aumenta e non rientra più nell'archiviazione SSD locale. In tal caso, potrebbe essere necessario ridimensionare il cluster per mantenere prestazioni di query adeguate.

  • Se è necessario ridimensionare il cluster, è consigliabile ridimensionarlo dapprima orizzontalmente per aumentare il numero di istanze. In questo modo, il cluster viene mantenuto disponibile per le query e l'inserimento durante il processo di ridimensionamento.

    • È possibile abilitare la scalabilità automatica ottimizzata per ridurre o aumentare automaticamente il numero di istanze in risposta alle modifiche apportate al carico di lavoro o alle tendenze stagionali.

  • È possibile che, anche dopo aver ridimensionato il cluster orizzontalmente, alcune query non vengano comunque eseguite come previsto. Ciò può verificarsi se le prestazioni delle query sono associate alle risorse disponibili in un'istanza (nodo) del cluster. In tal caso, aumentare le prestazioni del cluster verticalmente.

    • Il ridimensionamento verticale del cluster richiede svariati minuti. Durante tale processo, si verifica un periodo di tempo inattivo che può interrompere la raccolta di dati da parte del watcher. In tal caso, arrestare e riavviare il watcher al termine dell'operazione di ridimensionamento.

Cluster azure Esplora dati gratuito

Il cluster gratuito di Azure Esplora dati ha determinati limiti di capacità, incluso un limite di capacità di archiviazione per i dati non compressi originali. Non è possibile ridimensionare un cluster di Azure Esplora dati gratuito per aumentare la capacità di calcolo o archiviazione. Quando il cluster è vicino a raggiungere la capacità di archiviazione o è in fase di capacità, viene visualizzato un messaggio di avviso nella pagina del cluster gratuito.

Se si raggiunge la capacità di archiviazione, i nuovi dati di monitoraggio non vengono inseriti, ma i dati esistenti rimangono accessibili nei dashboard di Watcher del database e possono essere analizzati usando KQL o query SQL.

Se si ritiene che le specifiche del cluster gratuito non siano sufficienti per i requisiti, è possibile eseguire l'aggiornamento a un cluster completo di Azure Esplora dati e conservare tutti i dati raccolti. Poiché potrebbe verificarsi un periodo di tempo inattivo durante l'aggiornamento, potrebbe essere necessario arrestare e riavviare il watcher per riprendere la raccolta di dati al termine dell'aggiornamento.

Per continuare a usare il cluster gratuito di Azure Esplora dati, gestire la conservazione dei dati per eliminare automaticamente i dati meno recenti e liberare spazio per i nuovi dati. Quando lo spazio di archiviazione è disponibile, potrebbe essere necessario arrestare e riavviare il watcher per riprendere la raccolta dei dati.

Gestire la conservazione dei dati

Se non sono necessari dati meno recenti, è possibile configurare i criteri di conservazione dei dati per rimuoverli automaticamente in modo definitivo. Per impostazione predefinita, in un nuovo database su un cluster di Esplora dati di Azure o in Analisi in tempo reale, la conservazione dei dati è impostata su 365 giorni.

  • È possibile ridurre il periodo di conservazione dei dati a livello di database o per singole tabelle del database.
  • Si può anche aumentare la conservazione se è necessario archiviare i dati di monitoraggio per più di un anno. Non esiste alcun limite massimo per il periodo di conservazione dei dati.
  • Se si configurano diversi periodi di conservazione dei dati per tabelle diverse, le dashboard potrebbero non funzionare come previsto per gli intervalli di tempo precedenti. Ciò può verificarsi se i dati sono ancora presenti in alcune tabelle, ma sono già stati rimossi definitivamente in altre tabelle per lo stesso intervallo di tempo.

La quantità di dati di monitoraggio SQL inseriti nell'archivio dati dipende dai carichi di lavoro SQL e dalle dimensioni dell'ambiente SQL di Azure. È possibile usare la query KQL seguente per visualizzare la quantità media di dati inseriti al giorno, stimare il consumo di archiviazione nel tempo e gestire i criteri di conservazione dei dati.

.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));

Modifiche dello schema e dell'accesso nell'archivio dati del database watcher

Nel corso del tempo, Microsoft potrebbe introdurre nuovi set di dati del database watcher o espandere i set di dati esistenti. Ciò significa che è possibile aggiungere automaticamente nuove tabelle nell'archivio dati o nuove colonne nelle tabelle esistenti.

A tale scopo, l'identità gestita attuale di un database watcher deve essere un membro del ruolo controllo degli accessi in base al ruolo di Amministrazione nell'archivio dati. La revoca dell'appartenenza a questo ruolo o la sostituzione con l'appartenenza a qualsiasi altro ruolo controllo degli accessi in base al ruolo può influire sulla raccolta dei dati e sulla gestione dello schema del database watcher e non è supportata.

Analogamente, la creazione di nuovi oggetti, ad esempio tabelle, tabelle esterne, viste materializzate, funzioni e così via, nell'archivio dati del database watcher non è supportata. Si possono usare query tra cluster e tra database per eseguire query sui dati nell'archivio dati da altri cluster di Esplora dati di Azure, o da altri database nello stesso cluster.

Importante

Se si modifica l'accesso del database watcher al suo archivio dati o si apportano modifiche alla configurazione o allo schema del database che influiscono sull'inserimento dati, potrebbe essere necessario modificare l'archivio dati per tale watcher in un nuovo database vuoto e concedere al watcher l'accesso a questo nuovo database per riprendere la raccolta di dati e ripristinare una configurazione supportata.

Cluster di Esplora dati di Azure arrestati

Si può arrestare un cluster di Esplora dati di Azure, ad esempio, per risparmiare sui costi. Per impostazione predefinita, un cluster creato nel portale di Azure viene arrestato automaticamente dopo svariati giorni di inattività. Ad esempio, ciò può verificarsi se si arresta il watcher che inserisce i dati nell'unico database nel cluster e non si eseguono query in questo database.

Se si usa l'opzione predefinita per creare un nuovo cluster di Esplora dati di Azure durante la creazione di un nuovo watcher, il comportamento di arresto automatico è disabilitato per consentire la raccolta di dati senza interruzioni.

Se il cluster viene arrestato, anche la raccolta dei dati del watcher del database viene arrestata. Per riprendere la raccolta di dati, è necessario avviare il cluster. Quando il cluster è in esecuzione, riavviare il watcher.

È possibile disattivare il comportamento di arresto automatico se si vuole che il cluster rimanga disponibile anche quando è inattivo. Ciò potrebbe aumentare il costo del cluster.

Inserimento del flusso

Il database watcher richiede che il cluster di Esplora dati di Azure contenente il database dell'archivio dati abbia abilitato l'inserimento in streaming. L'inserimento in streaming viene abilitato automaticamente per il nuovo cluster di Esplora dati di Azure creato quando si crea un nuovo watcher. L'autenticazione tra tenant è abilitata in Analisi in tempo reale e nei cluster di Esplora dati di Azure gratuiti.

Se si usa un cluster di Esplora dati di Azure esistente, è necessario abilitare l'inserimento in streaming. L'operazione richiede alcuni minuti e riavvia il cluster.

Connettività privata all'archivio dati

Se l'accesso pubblico in un cluster di Esplora dati di Azure è disabilitato, è necessario creare un endpoint privato per connettersi al cluster dal browser e visualizzare i dati di SQL Monitoring nelle dashboard o per eseguire query direttamente sui dati. Questo endpoint privato è oltre all'endpoint privato gestito creato per consentire al watcher di inserire i dati di monitoraggio in un database nel cluster di Esplora dati di Azure.

  • Se ci si connette a un cluster di Esplora dati di Azure da una macchina virtuale di Azure, creare un endpoint privato per il cluster Esplora dati di Azure nella rete virtuale di Azure in cui viene distribuita la macchina virtuale di Azure.

  • Se ci si connette a un cluster Esplora dati di Azure da un computer locale, è possibile:

    1. Usare il Gateway VPN di Azure o Azure ExpressRoute per stabilire una connessione privata dalla rete locale alla rete virtuale di Azure.
    2. Creare un endpoint privato per il cluster Esplora dati di Azure nella rete virtuale di Azure in cui termina la connessione VPN o ExpressRoute o in un’altra rete virtuale di Azure raggiungibile tramite il traffico dal computer locale.
    3. Configurare DNS per l'endpoint privato.

La connettività privata non è disponibile gratuitamente per i cluster di Esplora dati di Azure o per l'analisi in tempo reale in Microsoft Fabric.

Monitorare ambienti di grandi dimensioni

Per monitorare un ambiente Azure SQL di grandi dimensioni, potrebbe essere necessario creare più watcher.

Ogni watcher richiede un database in un cluster di Esplora dati di Azure o in Analisi in tempo reale come archivio dati. I watcher creati possono usare un database singolo come archivio dati comune o database separati come archivi dati separati. Le seguenti considerazioni consentono di fare una scelta di progettazione ottimale per gli scenari e i requisiti di monitoraggio.

Considerazioni per un archivio dati comune:

  • È disponibile una visualizzazione a riquadro singolo dell'intero ambiente Azure SQL.
  • Le dashboard di qualsiasi watcher mostrano tutti i dati nell'archivio dati, anche se i dati vengono raccolti da altri watcher.
  • Gli utenti con accesso all'archivio dati hanno accesso ai dati di monitoraggio per l'intero ambiente SQL di Azure.

Considerazioni per archivi dati separati:

  • I sottoinsiemi dell'ambiente Azure SQL vengono monitorati in modo indipendente. Le dashboard del watcher di database nel portale di Azure mostrano i dati da un singolo archivio dati.
  • Gli utenti con accesso a più archivi dati possono usare query KQL tra cluster o tra database per accedere ai dati di monitoraggio in più archivi dati usando una singola query.
  • Poiché l'accesso ai dati in Esplora dati di Azure e in Analisi in tempo reale viene gestito per ogni database, è possibile gestire l'accesso ai dati di monitoraggio per i sottoinsiemi dell'ambiente in modo granulare.
  • È possibile posizionare più database nello stesso cluster di Esplora dati di Azure per condividere le risorse del cluster e risparmiare sui costi, mantenendo comunque i dati isolati in ogni database.
  • Se è necessaria una separazione completa degli ambienti, incluso l'accesso di rete ai cluster di Esplora dati di Azure, è possibile posizionare database diversi in cluster diversi.

Contenuto correlato