Partilhar via

Criar e configurar um inspetor de banco de dados (visualização)

  • Artigo

Aplica-se a:Banco de Dados SQL do AzureInstância Gerenciada SQL do Azure

Este artigo contém etapas detalhadas para criar, configurar e iniciar um inspetor de banco de dados no portal do Azure para o Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure.

O inspetor de banco de dados não exige que você implante e mantenha agentes de monitoramento ou outra infraestrutura de monitoramento. Você pode habilitar o monitoramento detalhado do banco de dados de seus recursos SQL do Azure em minutos.

Para obter um exemplo passo a passo simplificado para criar e configurar um inspetor de banco de dados, consulte Guia de início rápido : criar um inspetor de banco de dados para monitorar o SQLdo Azure.

Para ver como você pode criar e configurar um inspetor de banco de dados com Bicep ou um modelo ARM, consulte o Criar um inspetor de banco de dados exemplo de código.

Para gerir vigilantes de bases de dados programaticamente, consulte a documentação da API REST do observador de bases de dados .

Observação

O observador de banco de dados está atualmente em pré-visualização.

Pré-requisitos

Para usar o inspetor de banco de dados, os seguintes pré-requisitos são necessários.

  • Você precisará de uma assinatura ativa do Azure. Se tu não tens uma, cria uma conta gratuita. Você precisa ser membro da função de Colaborador de ou da função de Proprietário de para a assinatura ou para um grupo de recursos, para poder criar recursos.

  • Para configurar e iniciar um inspetor de banco de dados, você precisará de um destino SQL existente: um banco de dados SQL do Azure, pool elástico ou instância gerenciada SQL.

  • Os provedores de recursos Microsoft.DatabaseWatcher, Microsoft.Kustoe Microsoft.Network devem ser registrados em sua assinatura do Azure.

    O registro do provedor de recursos é automático se você tiver o de Proprietário ou ColaboradorRBAC associação de função no nível da assinatura. Caso contrário, um utilizador numa destas funções deve registar fornecedores de recursos antes de poder criar e configurar um observador. Para obter mais informações, consulte Registrar provedor de recursos.

  • O utilizador que cria e configura o observador e os recursos de cluster do Azure Data Explorer deve ser membro do papel RBAC Proprietário ou Colaborador para o grupo de recursos ou subscrição onde esses recursos são criados.

    Além disso, se estiver a usar a autenticação SQL, o utilizador deverá ser membro do papel Proprietário para o grupo de recursos, ou membro do papel Proprietário ou do papel administrador de acesso de utilizador para o cofre de chaves que armazena credenciais de autenticação SQL.

  • O usuário que configura o inspetor deve ter acesso de administrador aos destinos SQL do Azure. Um administrador concede ao observador acesso limitado e específico aos destinos de monitoramento SQL. Para obter mais informações, consulte Conceder acesso a destinos.

  • Para conceder a um observador acesso a um destino SQL, um administrador precisa executar scripts T-SQL usando SQL Server Management Studio (SSMS), Azure Data Studioou Visual Studio Code com a extensão SQL Server mssql.

  • Para usar de Link Privado do Azure para conectividade privada com recursos do Azure, o usuário que aprova o ponto de extremidade privado deve ser membro da função Proprietário RBAC do ou deve ter as permissões RBAC necessárias. Para mais informações, consulte Aprovação RBAC para endpoint privado.

Criar um observador

  1. No portal do Azure, no menu de navegação, selecione Todos os serviços. Selecione Monitor como a categoria e, em Ferramentas de monitoramento, selecione Observadores de banco de dados. Como alternativa, pode digitar inspetor de banco de dados na caixa de Pesquisa no topo da página do portal e selecionar Observadores de banco de dados.

    Quando a visualização de Observadores do Banco de Dados abrir, selecione Criar.

  2. Na guia Noções básicas, selecione a assinatura e o grupo de recursos para o monitor, insira o nome do monitor e selecione uma região do Azure.

    Dica

    Durante a pré-visualização, se o observador de banco de dados ainda não estiver disponível na sua região, poderá criá-lo numa região diferente. Para obter mais informações, consulte Disponibilidade regional.

  3. Na guia Identidade , a identidade gerida atribuída pelo sistema do observador é habilitada por padrão. Se você quiser que o observador use uma identidade gerenciada atribuída ao usuário, selecione o botão Adicionar , localize a identidade que deseja usar e selecione o botão Adicionar. Para tornar a identidade atribuída ao usuário efetiva para o observador, desative a identidade gerenciada atribuída ao sistema.

    Para obter mais informações sobre identidades geridas no observador de base de dados, consulte Modificar identidade do observador.

  4. Escolha um armazenamento de dados para o observador.

    Por padrão, a criação de um observador também cria um Azure Data Explorer cluster e adiciona um banco de dados nesse cluster como o repositório de dados para os dados de monitorização recolhidos.

    • Por padrão, o novo cluster do Azure Data Explorer usa a opção Extra Pequeno, otimizado para computação, SKU. Este é o SKU mais econômico que ainda fornece um Acordo de Nível de Serviço (SLA). Você pode dimensionar esse cluster posteriormente, conforme necessário.

    • Ou, você pode usar um banco de dados em um cluster existente do Azure Data Explorer, em um cluster do Azure Data Explorer gratuitoou no Real-Time Analytics.

      1. Na guia de armazenamento de dados, escolha a opção Selecione um de armazenamento de dados e selecione Adicionar.
      2. Selecione um banco de dados do Real-Time Analytics ou um cluster do Azure Data Explorer.
      3. Se estiver usando um cluster existente do Azure Data Explorer, você deverá habilitar ingestão de streaming.
      4. Crie um novo banco de dados ou use um banco de dados existente.

      Observação

      Qualquer banco de dados existente que selecione deve estar vazioou ser um banco de dados que tenha utilizado anteriormente como armazenador de dados do monitor de bases de dados. Não há suporte para a seleção de um banco de dados que contenha objetos não criados pelo inspetor de banco de dados.

    • Ou, você pode ignorar a adição de um armazenamento de dados neste momento e adicioná-lo mais tarde. É necessário um armazenamento de dados para iniciar o observador.

  5. Na guia Objetivos SQL, adicione um ou mais recursos SQL do Azure para monitorar. Você pode ignorar a adição de destinos SQL ao criar o observador e adicioná-los mais tarde. Você precisa adicionar pelo menos um alvo antes de iniciar o observador.

  6. No separador Rever + criar, reveja a configuração do observador e selecione Criar. Se você selecionar a opção padrão para criar um novo cluster do Azure Data Explorer, a implantação normalmente leva de 15 a 20 minutos. Se você selecionar um banco de dados em um cluster existente do Azure Data Explorer, em um cluster gratuito do Azure Data Explorer ou no Real-Time Analytics, a implantação normalmente leva até cinco minutos.

  7. Quando a implantação for concluída, conceda acesso aos destinos SQLao observador .

  8. Também pode ser necessário conceder ao observador acesso ao armazenamento de dados.

    • O acesso a um banco de dados no cluster novo ou existente do Azure Data Explorer é concedido automaticamente quando o monitorizador é criado se o utilizador que cria o monitorizador for membro da função RBAC de Proprietário para o cluster.
    • No entanto, você deve conceder acesso ao repositório de dados usando um comando KQL ao selecionar uma base de dados em:
      • Real-Time Analytics no Microsoft Fabric.
      • Um cluster gratuito do Azure Data Explorer.

  9. Crie e aprove pontos de extremidade privados gerenciados se quiser usar conectividade privada.

    • Se o acesso público em seus destinos SQL, o armazenamento de dados e o cofre de chaves estiver habilitado e você quiser usar a conectividade pública, verifique se todos os pré-requisitos de conectividade pública estão satisfeitos.

Iniciar e interromper um observador

Quando um observador é criado, ele não é iniciado automaticamente porque uma configuração adicional pode ser necessária.

Para iniciar um observador, ele deve ter:

  • Um armazenamento de dados.
  • Pelo menos um alvo.
  • O acesso ao de armazenamento de dados e destinos.
    • O acesso a um cofre de chaves também é necessário se a autenticação SQL tiver sido selecionada para qualquer destino.
  • O privado ou conectividade de pública para destinos, cofre de chaves (se estiver usando autenticação SQL) e armazenamento de dados.

Quando um observador estiver totalmente configurado, use o botão Iniciar na página Visão Geral para iniciar a coleta de dados. Em poucos minutos, novos dados de monitorização de aparecem no repositório de dados e nos painéis . Se não vir novos dados no espaço de cinco minutos, consulte Resolução de problemas.

Você pode parar o observador com o botão Parar se não precisar monitorar seus recursos SQL do Azure por algum tempo.

Para reiniciar um observador, pare-o e inicie-o novamente.

Modificar um observador

No portal do Azure, pode adicionar ou remover alvos, criar ou excluir pontos de extremidade privados, usar um armazenamento de dados diferente para um observador existente ou modificar a identidade gerida do observador.

Observação

A menos que indicado de outra forma, as alterações feitas na configuração do observador entram em vigor depois de parar e reiniciar o observador.

Adicionar destinos SQL a um observador

Para habilitar o monitoramento do inspetor de banco de dados para um banco de dados SQL do Azure, pool elástico ou instância gerenciada SQL, você precisa adicionar esse recurso como um destino SQL.

  1. Para adicionar um destino, na página Destinos SQL , selecione Adicionar .
  2. Encontre o recurso SQL do Azure que você deseja monitorar. Selecione o tipo de recurso e a assinatura e, em seguida, selecione o destino SQL na lista de recursos. O destino SQL pode estar em qualquer subscrição dentro do mesmo locatário do Microsoft Entra ID que o watcher.
  3. Para monitorar a réplica primária e uma réplica secundária de alta disponibilidade de um banco de dados, pool elástico ou instância gerenciada SQL, adicione dois destinos SQL separados para o mesmo recurso e marque a caixa Intenção de leitura para um deles. Da mesma forma, crie dois destinos SQL separados para uma réplica geográfica e sua réplica secundária de alta disponibilidade, se houver.
    • Marcar a caixa de intenção de leitura configura o destino SQL apenas para a réplica secundária de alta disponibilidade.
    • Não marque a caixa de intenção de leitura se quiser monitorizar apenas a réplica primária ou apenas a réplica geográfica, ou se uma réplica secundária de alta disponibilidade não existir para este recurso, ou se a funcionalidade de expansão de leitura estiver desativada.

Por padrão, o inspetor de banco de dados usa a autenticação do Microsoft Entra ao se conectar a destinos SQL. Se desejar que o observador utilize a autenticação SQL, marque a caixa Usar autenticação SQL e insira os detalhes necessários. Para obter mais informações, consulte Configuração adicional para usar a autenticação SQL.

Remover destinos SQL de um observador

Para remover um ou mais destinos, abra a página de destinos SQL , selecione os destinos que deseja remover na lista e selecione Eliminar.

A remoção de um destino interrompe o monitoramento de um recurso SQL do Azure depois que o inspetor é reiniciado, mas não exclui o recurso real.

Se você excluir um recurso SQL do Azure monitorado pelo inspetor de banco de dados, deverá remover o destino correspondente também. Como há um limite no número de destinos SQL que um observador pode ter, manter destinos obsoletos pode impedir que você adicione novos destinos.

Criar um ponto de extremidade privado gerenciado

Você deve criar pontos de extremidade privados geridos se quiser usar conectividade privada para a recolha de dados a partir de alvos SQL, para a ingestão no armazenamento de dados e para a conexão com cofres de chaves. Se não criares pontos de extremidade privados, o monitor de base de dados utilizará por padrão a conectividade pública.

Observação

O inspetor de banco de dados requer seus próprios pontos de extremidade privados gerenciados para se conectar aos recursos do Azure. Qualquer ponto de extremidade privado que já possa existir para um servidor lógico SQL do Azure, uma instância gerida SQL, um cluster do Azure Data Explorer ou um cofre de chaves não pode ser utilizado por um monitorizador.

Para criar um endpoint privado gerenciado para um observador:

  1. Se houver um bloqueio de somente leitura no recurso, grupo de recursos ou assinatura do recurso para o qual está a criar um ponto de extremidade privado gerido, remova o bloqueio. Você pode adicionar o bloqueio novamente depois que o ponto de extremidade privado for criado com êxito.

  2. Navegue até um observador de banco de dados no portal do Azure, abra a página Pontos de extremidade privados geridos e selecione Adicionar.

  3. Insira um nome para o ponto de extremidade privado.

  4. Selecione a assinatura do recurso do Azure para o qual você deseja criar o ponto de extremidade privado.

  5. Dependendo do tipo de recurso para o qual você deseja criar um ponto de extremidade privado, selecione o Tipo de recurso e subrecurso de destino da seguinte maneira:

    Recurso Tipo de recurso Subrecurso de destino
    Servidor lógico Microsoft.Sql/servers sqlServer
    Instância gerenciada SQL Microsoft.Sql/managedInstances managedInstance
    Cluster do Azure Data Explorer Microsoft.Kusto/clusters cluster
    Cofre da chave Microsoft.KeyVault/vaults vault

  6. Selecione o recurso para o qual você deseja criar um ponto de extremidade privado. Pode ser um servidor lógico SQL do Azure, uma instância gerenciada pelo SQL, um cluster do Azure Data Explorer ou um cofre de chaves.

    • A criação de um ponto de extremidade privado para um servidor lógico do Banco de Dados SQL do Azure habilita a conectividade privada do inspetor de banco de dados para todos os destinos de banco de dados e pool elástico nesse servidor.

  7. Insira, opcionalmente, a descrição para o ponto de extremidade privado. Isso pode ajudar o proprietário do recurso a aprovar a solicitação.

  8. Selecione Criar. Pode levar alguns minutos para criar um endereço de rede privado. Um ponto de extremidade privado é criado quando o seu estado de provisionamento muda de Aceito ou Executando para Bem-sucedido. Atualize o modo de exibição para ver o estado de provisionamento atual.

    Importante

    O ponto de extremidade privado é criado no estado Pendente. Ele deve ser aprovado pelo proprietário do recurso antes que o inspetor do banco de dados possa usá-lo para se conectar ao recurso.

    Para permitir que os proprietários de recursos controlem a conectividade de rede, os pontos de extremidade privados dos observadores de banco de dados não são aprovados automaticamente.

  9. O proprietário do recurso deve aprovar a solicitação de endpoint privado.

    • No portal do Azure, o proprietário do recurso pode procurar por Link Privado para abrir o Private Link Center. Em Conexões pendentes, encontre o endpoint privado que você criou, confirme sua descrição e detalhes e selecione Aprovar.
    • Você também pode aprovar solicitações de endpoint privado usando a CLI do Azure.

Se um observador já estiver em execução quando um ponto de extremidade privado for aprovado, ele deverá ser reiniciado para começar a usar a conectividade privada.

Dica

Você precisará criar um ponto de extremidade privado adicional para seu cluster do Azure Data Explorer se a conectividade pública do cluster estiver desabilitada. Para obter mais informações, consulte Conectividade privada para o armazenamento de dados.

Excluir um ponto de extremidade privado gerenciado

  1. Se houver uma exclusão ou um bloqueio de somente leitura no recurso, grupo de recursos ou assinatura do recurso para o qual você está excluindo um ponto de extremidade privado gerenciado, remova o bloqueio. Você pode adicionar o bloqueio novamente depois que o ponto de extremidade privado for excluído com êxito.
  2. Na página do portal do Azure para o seu observador de bases de dados, abra a página Pontos de extremidade privados geridos.
  3. Selecione os pontos de extremidade privados que deseja excluir.
  4. Selecione Excluir.

A exclusão de um ponto de extremidade privado gerenciado interrompe a coleta de dados de destinos SQL que usam esse ponto de extremidade privado. A eliminação do ponto final privado gerido para o cluster do Azure Data Explorer interrompe a recolha de dados para todos os destinos. Para retomar a recolha de dados, recrie o endpoint privado ou ative a conectividade pública , e reinicie o observador.

Alterar o armazenamento de dados de um observador

Um observador pode ter apenas um armazenamento de dados.

Para alterar o armazenamento de dados atual, remova o armazenamento de dados existente e adicione um novo armazenamento de dados.

  • Para remover o armazenamento de dados atual, abra a página Armazenamento de dados, selecione o armazenamento de dados na grelha e selecione Eliminar.

    • A remoção de um armazenamento de dados não exclui o banco de dados de armazenamento de dados real em um cluster do Azure Data Explorer ou no Real-Time Analytics no Microsoft Fabric.
    • Para interromper a recolha de dados num armazenamento de dados removido, pare o monitor.
    • Se remover um armazenamento de dados, terá de adicionar um novo armazenamento de dados antes de poder reiniciar o monitor novamente.

  • Para adicionar um armazenamento de dados, selecione Adicionar na página Armazenamento de Dados e, em seguida, selecione ou crie uma base de dados num agrupamento do Azure Data Explorer ou na funcionalidade Real-Time Analytics.

    • O banco de dados selecionado deve estar vazio ou deve ser um banco de dados que você tenha usado anteriormente como um armazenamento de dados do inspetor de banco de dados. Não há suporte para a seleção de um banco de dados que contenha objetos não criados pelo inspetor de banco de dados.
    • Depois de adicionar um armazenamento de dados, você deve conceder ao observador acesso para usá-lo. Para obter mais informações, consulte Concessão de acesso ao armazenamento de dados.
    • Depois que o observador é reiniciado, ele começa a usar o novo armazenamento de dados.

Modificar a identidade do observador

Um observador deve ter uma identidade gerenciada para se autenticar em destinos SQL, cofres de chaves e no armazenamento de dados. Pode ser usada uma identidade gerida designada pelo sistema ou designada pelo utilizador. Para obter mais informações sobre identidades gerenciadas no Azure, consulte O que são identidades gerenciadas para recursos do Azure?

As considerações a seguir ajudam a escolher o tipo de identidade gerenciada para um observador:

  • Atribuído pelo sistema

    • Ativado por padrão quando você cria um observador.
    • Sempre associado a um único observador.
    • Criado e eliminado juntamente com o observador.
    • Se você desabilitar uma identidade atribuída ao sistema para um observador, qualquer acesso concedido a essa identidade será perdido. A reativação da identidade atribuída ao sistema para o mesmo observador cria uma identidade nova e diferente com um ID de objeto (principal) diferente. Você precisa conceder acesso aos destinos SQL, ao cofre de chaves , e ao armazenamento de dados a essa nova identidade.

  • Utilizador atribuído

    • Está em vigor apenas se a identidade atribuída ao sistema estiver desativada para o observador.
    • A mesma identidade atribuída ao usuário pode ser atribuída a vários observadores para simplificar o gerenciamento de acesso, por exemplo, ao monitorar grandes propriedades SQL do Azure . Em vez de conceder acesso às identidades atribuídas ao sistema de vários observadores, o acesso pode ser concedido a uma única identidade atribuída ao usuário.
    • Para apoiar a separação de funções, o gerenciamento de identidade pode ser separado do gerenciamento de observadores. Uma identidade atribuída a um utilizador pode ser criada e o acesso pode ser concedido por um utilizador diferente, antes ou depois da criação do observador.
    • Por outro lado, quando um observador é excluído, a identidade atribuída ao usuário e seu acesso permanecem inalterados. A mesma identidade pode ser usada para um novo observador.
    • Não há suporte para a especificação de mais de uma identidade atribuída ao usuário para um observador.

Para modificar a identidade gerida de um observador, abra a página de identidade de um observador.

  • Para usar uma identidade atribuída ao sistema, ative o alternador de Identidade atribuída ao sistema.

  • Para usar uma identidade atribuída ao usuário, desative a alternar de identidade atribuída pelo sistema . Selecione o botão Adicionar para localizar e adicionar uma identidade atribuída ao usuário existente.

    Para criar uma nova identidade atribuída ao usuário, consulte Criar uma identidade gerenciada atribuída ao usuário.

  • Para remover uma identidade atribuída ao usuário de um observador, selecione-a na lista e selecione Remover. Depois que uma identidade atribuída ao usuário é removida, você precisa adicionar uma identidade atribuída ao usuário diferente ou habilitar a identidade atribuída ao sistema.

    A identidade atribuída ao utilizador removido não é eliminada do inquilino do Microsoft Entra ID.

Selecione o botão Salvar para salvar as alterações de identidade. Não é possível salvar alterações de identidade se isso resultar na ausência de identidade do observador. Não há suporte para observadores sem uma identidade gerenciada válida.

Dica

Recomendamos que o nome de exibição da identidade gerida do inspetor seja único dentro do tenant Microsoft Entra ID. Você pode escolher um nome exclusivo ao criar uma identidade atribuída ao usuário para observadores.

O nome de exibição da identidade atribuída ao sistema é o mesmo que o nome do inspetor. Se utilizar a identidade atribuída ao sistema, certifique-se de que o nome do observador é exclusivo dentro do cliente do Microsoft Entra ID.

Se o nome de exibição da identidade gerenciada não for exclusivo, o script T-SQL para conceder ao inspetor acesso aos destinos SQL falhará com um erro de nome de exibição duplicado. Para obter mais informações e uma solução alternativa, consulte logins do Microsoft Entra e usuários com nomes de exibição não exclusivos.

Logo após as alterações de identidade serem salvas, o observador se reconecta aos destinos SQL, aos cofres de chaves (se usados) e ao armazenamento de dados usando sua identidade gerenciada atual.

Excluir um observador

Se houver uma exclusão ou um bloqueio de somente leitura no observador, seu grupo de recursos ou sua assinatura, remova o bloqueio. Da mesma forma, se houver um bloqueio no recurso, grupo de recursos ou assinatura do recurso para o qual você criado um ponto de extremidade privado gerenciado, remova o bloqueio. Você pode adicionar os bloqueios novamente depois que o observador for excluído com êxito.

Quando você exclui um observador que tem sua identidade gerenciada atribuída ao sistema habilitada, a identidade também é excluída. Isso remove qualquer acesso concedido a essa identidade. Se você recriar o inspetor mais tarde, precisará conceder acesso à identidade gerenciada atribuída ao sistema do novo inspetor para autenticar cada recurso. Isto inclui:

  • Alvos
  • O armazenamento de dados
  • E o chaveiro (se usado)

Você deve conceder acesso a um observador recriado, mesmo que use o mesmo nome de observador.

Quando você exclui um observador, os recursos do Azure referenciados como seus destinos SQL e o armazenamento de dados não são excluídos. Você retém os dados de monitorização SQL coletados no armazenamento de dados, e pode usar o mesmo banco de dados do Azure Data Explorer ou do Real-Time Analytics como armazenamento de dados caso crie um novo observador mais tarde.

Conceder acesso a destinos SQL

Para permitir que um observador colete dados de monitoramento SQL, você precisa executar um script T-SQL que conceda permissões SQL específicas e limitadas ao inspetor.

  • Para executar o script no Banco de Dados SQL do Azure, você precisa de acesso de administrador do servidor ao servidor lógico que contém bancos de dados e pools elásticos que deseja monitorar.

    • No Banco de Dados SQL do Azure, você só precisa executar o script uma vez por servidor lógico para cada observador criado. Isso concede ao observador acesso a todos os bancos de dados e pools elásticos novos e existentes nesse servidor.

  • Para executar o script na Instância Gerenciada SQL do Azure, você precisa ser membro da função de servidor sysadmin ou securityadmin ou ter a permissão de servidor CONTROL na instância gerenciada do SQL.

    • Na Instância Gerenciada SQL do Azure, você precisa executar o script em cada instância que deseja monitorar.

  1. Navegue até o vigia no portal do Azure, selecione os destinos SQL, escolha um dos links Conceder acesso para abrir o script T-SQL e, em seguida, copie o script. Certifique-se de escolher o link correto para o tipo de destino e o tipo de autenticação que deseja usar.

    Importante

    O script de autenticação do Microsoft Entra no portal do Azure é destinado a um observador porque inclui o nome da identidade gerida do observador. Para obter uma versão genérica desse script que você pode personalizar para cada observador, consulte Conceder acesso a destinos SQL com scripts T-SQL.

  2. No SQL Server Management Studio, Azure Data Studio ou qualquer outra ferramenta de cliente SQL, abra uma nova janela de consulta e conecte-a ao banco de dados master em um servidor lógico SQL do Azure que contém o destino ou ao banco de dados master em um destino de instância gerenciada SQL.

  3. Cole e execute o script T-SQL para conceder acesso ao observador. O script cria um login que o observador usará para se conectar e concede permissões específicas e limitadas para coletar dados de monitoramento.

    1. Se você usar um script de autenticação do Microsoft Entra e o inspetor usar a identidade gerenciada atribuída ao sistema, o inspetor já deverá estar criado quando você executar o script. Se o observador usar uma identidade gerida atribuída a um utilizador, poderá executar o script antes ou depois de o observador ser criado.

    Você deve estar conectado com a autenticação do Microsoft Entra ao executar os scripts de acesso T-SQL que concedem acesso a uma identidade gerenciada.

Se você adicionar novos destinos a um observador mais tarde, precisará conceder acesso a esses destinos de maneira semelhante, a menos que esses destinos estejam em um servidor lógico onde o acesso já tenha sido concedido.

Conceder acesso a destinos SQL com scripts T-SQL

Há scripts diferentes para autenticação Microsoft Entra e autenticação SQL, e para destinos Azure SQL Database e Azure SQL Managed Instance.

Importante

Sempre use os scripts fornecidos para conceder acesso ao observador do banco de dados. Conceder acesso de uma forma diferente pode bloquear a recolha de dados. Para obter mais informações, consulte autorização do observador.

Antes de executar um script, substitua todas as instâncias de espaços reservados que possam estar presentes no script, como login-name-placeholder e password-placeholder, pelos valores reais.

Conceder acesso aos observadores autenticados do Microsoft Entra

Esse script cria um logon de autenticação do Microsoft Entra (anteriormente conhecido como Azure Ative Directory) em um servidor lógico no Banco de Dados SQL do Azure. O login é criado para a identidade gerenciada de um observador. O script concede ao observador as permissões necessárias e suficientes para coletar dados de monitoramento de todos os bancos de dados e pools elásticos no servidor lógico.

Se o inspetor usar a identidade gerenciada atribuída ao sistema, você deverá usar o nome do inspetor como o nome de login. Se o observador usar uma identidade gerenciada atribuída ao usuário, você deverá usar o nome para exibição da identidade como o nome de login.

O script deve ser executado no banco de dados master no servidor lógico. Você deve estar conectado usando um logon de autenticação do Microsoft Entra que seja um administrador do servidor.

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

Conceder acesso a observadores autenticados SQL

Etapas adicionais são necessárias ao usar a autenticação SQL, consulte Configuração adicional para usar a autenticação SQL.

Esse script cria um logon de autenticação SQL em um servidor lógico no Banco de Dados SQL do Azure. Ele concede ao login as permissões necessárias e suficientes para coletar dados de monitoramento de todos os bancos de dados e pools elásticos nesse servidor lógico.

O script deve ser executado no banco de dados master no servidor lógico, usando um login que seja um administrador de servidor lógico.

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

Configuração adicional para usar a autenticação SQL

Para armazenar credenciais de autenticação com segurança, usar a autenticação SQL no inspetor de banco de dados requer configuração adicional.

Dica

Para uma configuração mais segura, mais simples e menos propensa a erros, recomendamos habilitar a autenticação do Microsoft Entra para seus recursos SQL do Azure e usá-la em vez da autenticação SQL.

Para configurar o inspetor de banco de dados para se conectar a um destino usando a autenticação SQL, siga estas etapas:

  1. Crie um cofre no Azure Key Vault ou identifique um cofre existente que possa utilizar. O cofre deve usar o modelo de permissões RBAC . O modelo de permissão RBAC é o padrão para novos cofres. Se você quiser usar um cofre existente, certifique-se de que ele não esteja configurado para usar o modelo de de política de acesso mais antigo.

    Se pretender utilizar conectividade privada com o cofre, crie um ponto de extremidade privado na página Pontos de extremidade privados geridos. Selecione Microsoft.KeyVault/vaults como Tipo de recursoe vault como Subrecurso de destino. Certifique-se de que o ponto de extremidade privado está aprovado antes de iniciar o monitor.

    Se você quiser usar a conectividade pública, o cofre deve permitir o acesso público de todas as redes. Não há suporte para restringir a conectividade do cofre público a redes específicas no inspetor de banco de dados.

  2. Crie um logon de autenticação SQL em cada servidor lógico SQL do Azure ou instância gerenciada que você deseja monitorar e conceda as permissões específicas e limitadas usando scripts de acesso fornecidos. No script, substitua os espaços reservados para nome de login e senha pelos valores reais. Use uma senha forte.

  3. No cofre, crie dois segredos: um segredo para o nome de login e um segredo separado para a palavra-passe. Use quaisquer nomes válidos como o nome secreto e digite o nome de logon e a senha usados no script T-SQL como o valor secreto para cada segredo.

    Por exemplo, os nomes dos dois segredos podem ser database-watcher-login-name e database-watcher-password. Os valores secretos seriam um nome de login e uma senha forte.

    Para criar segredos, você precisa ser membro do Key Vault Secrets Officer função RBAC.

  4. Adicione um destino SQL para um observador. Ao adicionar o alvo, marque a caixa Use autenticação SQL e selecione o cofre onde os segredos de senha e nome de logon estão armazenados. Digite os nomes secretos para nome de login e senha nos campos correspondentes.

    Ao adicionar um destino SQL, não insira o nome de utilizador e a senha reais. Usando o exemplo anterior, introduziria os nomes secretos database-watcher-login-name e database-watcher-password.

  5. Quando você adiciona um destino SQL no portal do Azure, a identidade gerenciada do observador recebe automaticamente o acesso necessário aos segredos do cofre de chaves se o usuário atual for membro da função Proprietários do ou da função de administrador de acesso de usuário para o cofre de chaves. Caso contrário, siga a próxima etapa para conceder o acesso necessário manualmente.

  6. Na página de controle de acesso (IAM) de cada segredo, adicione uma atribuição de função para a identidade gerida do observador na função RBAC Usuário Segredos do Cofre de Chaves. Para seguir o princípio de menor privilégio, adicione essa atribuição de função para cada segredo, em vez de para todo o cofre. A página de de controle de acesso (IAM) aparecerá somente se o cofre estiver configurado para usar o modelo de permissão RBAC .

Se você quiser usar credenciais de autenticação SQL diferentes em destinos SQL diferentes, precisará criar vários pares de segredos. Você pode usar o mesmo cofre ou cofres diferentes para armazenar os segredos para cada destino SQL.

Observação

Se atualizar o valor secreto de um nome de logon ou senha no cofre de chaves enquanto um observador estiver em execução, o observador se reconectará aos destinos usando as novas credenciais de autenticação SQL dentro de 15 minutos. Se pretender começar a usar as novas credenciais imediatamente, pare e reinicie o observador.

Conceder acesso ao armazenamento de dados

Para criar e gerir o esquema de base de dados no repositório de dados, ou para ingerir dados de monitorização, o monitor de base de dados requere uma associação à função de Administradores RBAC na base de dados de armazenamento de dados num cluster do Azure Data Explorer ou no Real-Time Analytics. O inspetor de banco de dados não requer nenhum acesso em nível de cluster ao cluster do Azure Data Explorer ou qualquer acesso a outros bancos de dados que possam existir no mesmo cluster.

Se você usar um banco de dados em um cluster do Azure Data Explorer como armazenamento de dados, esse acesso será concedido automaticamente se você for membro da função RBAC de Proprietário para o cluster. Caso contrário, o acesso deve ser concedido conforme descrito nesta seção.

Se você usar um banco de dados no Real-Time Analytics ou em um cluster gratuito do Azure Data Explorer, precisará conceder acesso usando o KQL.

Conceder acesso a um banco de dados do Azure Data Explorer usando o portal do Azure

Você pode usar o portal do Azure para conceder acesso a um banco de dados no cluster do Azure Data Explorer:

  1. Para um banco de dados em um cluster do Azure Data Explorer, no menu de recursos em Segurança + rede, selecione Permissões. Não use a página de Permissões do cluster .
  2. Selecione Adicionare selecione Admin.
  3. Na página Novos Diretores, selecione aplicações empresariais. Se o observador usar a identidade gerida atribuída ao sistema, digite o nome do observador na caixa Pesquisar. Se o observador usar uma identidade gerida atribuída ao utilizador, digite o nome de exibição dessa identidade na caixa Pesquisa.
  4. Selecione o aplicativo corporativo para a identidade gerenciada do inspetor.

Conceder acesso a um banco de dados do Azure Data Explorer usando o KQL

Em vez de usar o portal do Azure, você também pode conceder acesso ao banco de dados usando um comando KQL. Use esse método para conceder acesso a um banco de dados no Real-Time Analytics ou em um cluster gratuito do Azure Data Explorer.

  1. Conecte-se a um banco de dados no cluster do Azure Data Explorer usando Kusto Explorer ou o Azure Data Explorer da interface do usuário da Web.

  2. No comando KQL de exemplo a seguir, substitua os três espaços reservados conforme observado na tabela:

    .add database [adx-database-name-placeholder] admins ('aadapp=identity-principal-id-placeholder;tenant-primary-domain-placeholder');
    Marcador de posição Substituição
    adx-database-name-placeholder O nome de um banco de dados em um cluster do Azure Data Explorer ou no Real-Time Analytics.
    identity-principal-id-placeholder O ID principal valor de uma identidade gerenciada (um GUID), encontrado na página Identity do observador. Se a identidade atribuída ao sistema estiver habilitada, use o seu ID principal valor. Caso contrário, use o valor de ID principal da identidade atribuída ao utilizador.
    tenant-primary-domain-placeholder O nome de domínio do locatário do Microsoft Entra ID da identidade gerenciada do inspetor. Encontre isso na página Visão Geral do do Microsoft Entra ID no portal do Azure. Em vez do domínio principal do locatário, o valor ID do Locatário GUID também pode ser usado.

    Esta parte do comando é necessária se você usar um banco de dados no Real-Time Analytics ou em um cluster gratuito do Azure Data Explorer.

    O nome de domínio ou o valor da ID do locatário (e o ponto-e-vírgula anterior) pode ser omitido para um banco de dados em um cluster do Azure Data Explorer porque o cluster está sempre no mesmo locatário do Microsoft Entra ID que a identidade gerenciada pelo inspetor.

    Por exemplo:

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

Para obter mais informações, consulte controle de acesso baseado em função Kusto.

Conceder aos usuários e grupos acesso ao armazenamento de dados

Você pode usar o portal do Azure ou um comando KQL para conceder aos usuários e grupos acesso a um banco de dados em um cluster do Azure Data Explorer ou no Real-Time Analytics. Para conceder acesso, você deve ser membro da função Admin RBAC no banco de dados.

Use um comando KQL para conceder acesso a um banco de dados no cluster gratuito do Azure Data Explorer ou no Real-Time Analytics. Para seguir o princípio de menor privilégio, recomendamos que você não adicione usuários e grupos a nenhuma função RBAC que não seja Viewer por padrão.

Importante

Considere cuidadosamente seus requisitos de privacidade e segurança de dados ao conceder acesso para exibir dados de monitoramento SQL coletados pelo inspetor de banco de dados.

Embora o inspetor de banco de dados não tenha a capacidade de coletar dados armazenados em tabelas de usuário em seus bancos de dados SQL, determinados conjuntos de dados como de sessões ativas, de metadados de índice, de índices ausentes, de estatísticas de tempo de execução de consulta, de estatísticas de espera de consulta, de estatísticas de sessão e metadados de tabela podem conter dados potencialmente confidenciais, tais como nomes de tabelas e índices, texto de consulta, valores de parâmetros de consulta, nomes de início de sessão, etc.

Ao conceder acesso de exibição ao armazenamento de dados a um usuário que não tem acesso para exibir esses dados em um banco de dados SQL, você pode permitir que eles vejam dados confidenciais que não seriam capazes de ver de outra forma.

Conceder acesso ao armazenamento de dados usando o portal do Azure

Você pode usar o portal do Azure para conceder aos usuários e grupos acesso a um banco de dados no cluster do Azure Data Explorer:

  1. Para um banco de dados em um cluster do Azure Data Explorer, no menu de recursos em Segurança + rede, selecione Permissões. Não use a página de Permissões do cluster .
  2. Selecione Adicionare selecione Visualizadores.
  3. Na página Novos Principais, digite o nome do utilizador ou grupo na caixa Pesquisa.
  4. Selecione o usuário ou grupo.

Conceder acesso ao armazenamento de dados usando o KQL

Em vez de usar o portal do Azure, você também pode conceder aos usuários e grupos acesso ao banco de dados usando um comando KQL. Os seguintes comandos de exemplo KQL concedem acesso de leitura de dados ao usuário mary@contoso.com e ao grupo SQLMonitoringUsers@contoso.com em um tenant do Microsoft Entra ID com um valor de ID de tenant específico:

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

Para obter mais informações, consulte controle de acesso baseado em função Kusto.

Para conceder acesso ao armazenamento de dados a usuários e grupos de outro locatário, você precisa habilitar a autenticação entre locatários em seu cluster do Azure Data Explorer. Para obter mais informações, consulte Permitir consultas e comandos entre inquilinos.

Dica

Para permitir que você conceda acesso a usuários e grupos em seu locatário do Microsoft Entra ID, a autenticação entre locatários é habilitada no Real-Time Analytics e em clusters gratuitos do Azure Data Explorer.

Gerenciar armazenamento de dados

Esta seção descreve como você pode gerenciar o armazenamento de dados de monitoramento, incluindo dimensionamento, retenção de dados e outras configurações. As considerações de dimensionamento de cluster nesta seção serão relevantes se você usar um banco de dados no cluster do Azure Data Explorer. Se você usar um banco de dados no Real-Time Analytics no Fabric, o dimensionamento será gerenciado automaticamente.

Dimensionar o cluster do Azure Data Explorer

Você pode dimensionar seu cluster do Azure Data Explorer conforme necessário. Por exemplo, você pode reduzir seu cluster para o Extra pequeno, Desenvolvimento/teste SKU se um contrato de nível de serviço (SLA) não for necessário e se o desempenho de consulta e ingestão de dados permanecer aceitável.

Para muitas implantações do inspetor de banco de dados, o padrão Extra pequeno, otimizado para computação SKU de cluster de 2 instâncias será suficiente indefinidamente. Em alguns casos, dependendo da configuração e das alterações da carga de trabalho ao longo do tempo, talvez seja necessário dimensionar o cluster para garantir o desempenho adequado da consulta e manter baixa latência de ingestão de dados.

O Azure Data Explorer dá suporte a escalonamento vertical de cluster e escalonamento horizontal de cluster. Com o dimensionamento vertical, você altera a SKU do cluster, que altera o número de vCPUs, memória e cache por instância (nó). Com o dimensionamento horizontal, a SKU permanece a mesma, mas o número de instâncias no cluster é aumentado ou diminuído.

Você precisa dimensionar o cluster para fora (horizontalmente) ou para cima (verticalmente) se notar um ou mais dos seguintes sintomas:

  • O desempenho do dashboard ou da consulta ad hoc torna-se muito lento.
  • Você executa muitas consultas simultâneas no seu cluster e observa erros de restrição.
  • A latência de ingestão de dados torna-se consistentemente maior do que o aceitável.

Em geral, você não precisa dimensionar seu cluster à medida que a quantidade de dados no armazenamento de dados aumenta com o tempo. Isso ocorre porque as consultas de painel e as consultas analíticas mais comuns usam apenas os dados mais recentes, que são armazenados em cache no armazenamento SSD local em nós de cluster.

No entanto, se você executar consultas analíticas abrangendo intervalos de tempo mais longos, elas podem se tornar mais lentas ao longo do tempo à medida que a quantidade total de dados coletados aumenta e não cabe mais no armazenamento SSD local. Nesse caso, pode ser necessário dimensionar o cluster para manter o desempenho adequado da consulta.

  • Se você precisar dimensionar seu cluster, recomendamos dimensioná-lo horizontalmente primeiro para aumentar o número de instâncias. Isso mantém o cluster disponível para consultas e ingestão durante o processo de dimensionamento.

    • Você pode habilitar o dimensionamento automático otimizado para automaticamente reduzir ou aumentar o número de instâncias em resposta a alterações na carga de trabalho ou a tendências sazonais.

  • Você pode achar que, mesmo depois de dimensionar o cluster horizontalmente, algumas consultas ainda não têm o desempenho esperado. Isso pode acontecer se o desempenho da consulta estiver limitado pelos recursos disponíveis em uma instância (nó) do cluster. Nesse caso, aumente a escala do cluster verticalmente.

    • O dimensionamento vertical do cluster leva vários minutos. Durante esse processo, há um período de inatividade, que pode interromper a coleta de dados pelo observador. Se isso acontecer, pare e reinicie o seu observador após a conclusão da operação de dimensionamento.

Cluster gratuito do Azure Data Explorer

O cluster gratuito do Azure Data Explorer tem determinados limites de capacidade , incluindo um limite de capacidade de armazenamento nos dados não compactados originais. Não é possível dimensionar um cluster gratuito do Azure Data Explorer para aumentar sua capacidade de computação ou armazenamento. Quando o cluster está perto de atingir a sua capacidade de armazenamento, ou já a atingiu, uma mensagem de aviso aparece na página do cluster livre .

Se você atingir a capacidade de armazenamento, novos dados de monitoramento não serão ingeridos, mas os dados existentes permanecerão acessíveis no observador de banco de dados painéis e poderão ser analisados usando consultas KQL ou SQL.

Se você achar que as especificações do cluster livre são insuficientes para seus requisitos, poderá atualizar para um cluster completo do Azure Data Explorer. A atualização retém todos os dados coletados.

Para garantir que o observador continue a trabalhar após a atualização, siga estas etapas:

  1. Pare o observador.
  2. Siga as etapas para atualizar para um cluster completo do Azure Data Explorer e aguarde a conclusão da atualização.
  3. Alterar o armazenamento de dados do inspetor, selecionando o cluster e o banco de dados atualizados do Azure Data Explorer.
  4. Comece o observador.

Para continuar usando o cluster gratuito do Azure Data Explorer, gerenciar a retenção de dados excluir os dados mais antigos automaticamente e liberar espaço para novos dados. Quando houver espaço de armazenamento disponível, talvez seja necessário parar e reiniciar observador para retomar a coleta de dados.

Gerenciar a retenção de dados

Se você não precisar de dados mais antigos, poderá configurar políticas de retenção de dados para limpá-los automaticamente. Por padrão, a retenção de dados está definida para 365 dias num novo banco de dados num cluster do Azure Data Explorer ou no Real-Time Analytics.

  • Você pode reduzir o período de retenção de dados no nível do banco de dados ou para tabelas individuais no banco de dados.
  • Você também pode aumentar a retenção se precisar armazenar dados de monitoramento por mais de um ano. Não existe um limite máximo para o período de conservação dos dados.
  • Se você configurar períodos de retenção de dados diferentes para tabelas diferentes, painéis podem não funcionar como esperado para os intervalos de tempo mais antigos. Isso pode acontecer se os dados ainda estiverem presentes em algumas tabelas, mas já estiverem apagados em outras tabelas para o mesmo intervalo de tempo.

A quantidade de dados de monitoramento SQL que são ingeridos no armazenamento de dados depende de suas cargas de trabalho SQL e do tamanho do seu patrimônio SQL do Azure. Você pode usar a seguinte consulta KQL para exibir a quantidade média de dados ingeridos por dia, estimar o consumo de armazenamento ao longo do tempo e gerenciar políticas de retenção de dados.

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

Alterações de esquema e acesso no armazenamento de dados do monitor de banco de dados

Com o tempo, a Microsoft pode introduzir novos conjuntos de dados para monitorização de banco de dados ou expandir conjuntos de dados existentes. Isso significa que novas tabelas no armazenamento de dados ou novas colunas em tabelas existentes podem ser adicionadas automaticamente.

Para fazer isso, a identidade gerenciada atual de um observador de banco de dados deve ser membro da função Administradores de RBAC no armazenamento de dados. Revogar esta associação de função ou substituí-la por associação em qualquer outra função RBAC poderá afetar a recolha de dados do monitor de base de dados e a gestão do esquema, o que não é permitido.

Da mesma forma, não há suporte para a criação de novos objetos, como tabelas, tabelas externas, exibições materializadas, funções, etc., no armazenamento de dados do inspetor de banco de dados. Você pode usar consultas entre clusters e entre bases de dados para consultar dados no seu repositório de dados a partir de outros clusters do Azure Data Explorer ou de outras bases de dados no mesmo cluster.

Importante

Se você alterar o acesso do inspetor de banco de dados ao seu armazenamento de dados ou fizer alterações de esquema ou configuração de banco de dados que afetem a ingestão de dados, talvez seja necessário alterar o de armazenamento de dados desse inspetor para um novo banco de dados vazio e conceder ao inspetor acesso a esse novo banco de dados para retomar a coleta de dados e reverter para uma configuração suportada.

Clusters do Azure Data Explorer interrompidos

Um cluster do Azure Data Explorer pode ser interrompido, por exemplo, para economizar custos. Por padrão, um cluster do Azure Data Explorer criado no portal do Azure é interrompido automaticamente após vários dias de inatividade. Por exemplo, isso pode acontecer se você parar o observador que ingere dados no único banco de dados do cluster e não executar nenhuma consulta nesse banco de dados.

Se você usar a opção padrão para criar um novo cluster do Azure Data Explorer ao criar um novo observador, o comportamento de parada automática será desabilitado para permitir a coleta de dados ininterrupta.

Se o cluster for interrompido, a coleta de dados do inspetor de banco de dados também será interrompida. Para retomar a coleta de dados, você precisa iniciar o cluster. Quando o cluster estiver em execução, reinicie o inspetor.

Você pode desativar o comportamento de parada automática se quiser que o cluster permaneça disponível mesmo quando estiver inativo. Isso pode aumentar o custo do cluster.

Ingestão de streaming

O inspetor de banco de dados requer que o cluster do Azure Data Explorer que contém o banco de dados de armazenamento de dados tenha ingestão de streaming habilitada. A ingestão de streaming é habilitada automaticamente para o novo cluster do Azure Data Explorer criado quando você cria um novo observador. Ele também é habilitado no Real-Time Analytics e no cluster gratuito do Azure Data Explorer.

Se você quiser usar um cluster existente do Azure Data Explorer, certifique-se de habilitar a ingestão de streaming primeiro. Isso leva alguns minutos e reinicia o cluster.

Conectividade privada com o armazenamento de dados

Se o acesso público em um cluster do Azure Data Explorer estiver desabilitado, você precisará criar um endpoint privado para se conectar ao cluster a partir do seu navegador e ver os dados de monitorização SQL nos painéis ou consultar os dados diretamente. Esse ponto de extremidade privado é além de o ponto de extremidade privado gerenciado criado para permitir que o observador ingira dados de monitoramento em um banco de dados no cluster do Azure Data Explorer.

  • Se você estiver se conectando a um cluster do Azure Data Explorer a partir de uma VM do Azure, crie um ponto de extremidade privado para o cluster do Azure Data Explorer na rede virtual do Azure onde sua VM do Azure está implantada.

  • Se você estiver se conectando a um cluster do Azure Data Explorer a partir de uma máquina local, poderá:

    1. Use Gateway de VPN do Azure ou Rota Expressa do Azure para estabelecer uma conexão privada da sua rede local com uma rede virtual do Azure.
    2. Criar um ponto de extremidade privado para o cluster do Azure Data Explorer na rede virtual do Azure onde a conexão VPN ou ExpressRoute termina, ou em outra rede virtual do Azure alcançável pelo tráfego da sua máquina localizada no local.
    3. Configure o DNS para esse private endpoint.

A conectividade privada não está disponível para clusters gratuitos do Azure Data Explorer ou para o Real-Time Analytics no Microsoft Fabric.

Monitore grandes propriedades

Para monitorar um grande patrimônio SQL do Azure, talvez seja necessário criar vários observadores.

Cada observador requer um banco de dados em um cluster do Azure Data Explorer ou no Real-Time Analytics como armazenamento de dados. Os observadores que você cria podem usar um único banco de dados como um armazenamento de dados comum ou bancos de dados separados como armazenamentos de dados separados. As considerações a seguir podem ajudá-lo a fazer uma escolha de projeto ideal para seus cenários e requisitos de monitoramento.

Considerações para um armazenamento de dados comum:

  • Existe uma visão integrada de todo o seu portfólio do SQL no Azure.
  • Os painéis de qualquer observador mostram todos os dados no armazenamento de dados, mesmo que os dados sejam coletados por outros observadores.
  • Os usuários com acesso ao armazenamento de dados têm acesso aos dados de monitoramento de todo o seu patrimônio SQL do Azure.

Considerações para armazenamentos de dados separados:

  • Os subconjuntos do seu conjunto de propriedades SQL do Azure são monitorados independentemente. Os painéis do inspetor de banco de dados no portal do Azure sempre mostram os dados de um único armazenamento de dados.
  • Os usuários com acesso a vários armazenamentos de dados podem usar consultas KQL entre clusters ou bancos de dados para acessar dados de monitoramento em vários armazenamentos de dados usando uma única consulta.
  • Como o acesso a dados no Azure Data Explorer e no Real-Time Analytics é gerenciado por banco de dados, você pode gerenciar o acesso aos dados de monitoramento para os subconjuntos de seu patrimônio de forma granular.
  • Você pode colocar vários bancos de dados no mesmo cluster do Azure Data Explorer para compartilhar recursos de cluster e economizar custos, mantendo os dados isolados em cada banco de dados.
  • Se você precisar de uma separação completa de ambientes, incluindo acesso de rede a clusters do Azure Data Explorer, poderá colocar bancos de dados diferentes em clusters diferentes.

Conteúdo relacionado