Compartilhar via

Criar e configurar um observador de banco de dados (preview)

  • Artigo

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

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

O observador de banco de dados não requer a implantação ou manutenção de agentes de monitoramento ou de outra infraestrutura de monitoramento. É possível habilitar o monitoramento detalhado do banco de dados dos recursos do SQL do Azure em minutos.

Para obter um exemplo passo a passo simplificado para a criação e configuração de um observador de banco de dados, consulte Início rápido: criar um observador de banco de dados para monitorar o SQL do Azure.

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

Para gerenciar observadores de banco de dados programaticamente, consulte a documentação da API REST do observador de banco de dados.

Observação

No momento, o observador de banco de dados está em preview.

Pré-requisitos

Para usar o observador de banco de dados, é necessários atender os pré-requisitos apresentados a seguir.

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

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

  • Os provedores de recursos Microsoft.DatabaseWatcher, Microsoft.Kusto e Microsoft.Network devem estar registrados em sua assinatura do Azure.

    O registro do provedor de recursos é automático se tiver a subscrição à função RBAC Proprietário ou Contribuidor RBAC ao nível da assinatura. Caso contrário, um usuário em uma dessas funções deverá efetuar o registro de provedores de recursos antes que você possa criar e configurar um observador. Para saber mais, confira Registrar provedores de recursos.

  • O usuário que cria e configura o observador e os recursos do cluster do Azure Data Explorer deve ser membro da função RBAC Proprietário ou Contribuidor para o grupo de recursos ou ter uma assinatura na qual estes recursos são criados.

    Além disso, se usar a autenticação do SQL, o usuário deve ser membro da função Proprietário do grupo de recursos ou membro da função Proprietário ou Administrador de acesso de usuário para o cofre de chaves que armazena credenciais de autenticação do SQL.

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

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

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

Criar um observador

  1. No portal do Azure, no menu de navegação, selecione Todos os Serviços. Selecione Monitorar como a categoria e, em Ferramentas de Monitoramento, escolha Observadores de Banco de Dados. Como alternativa, é possível digitar observador de banco de dados na caixa de Pesquisa na parte superior da página do portal e selecionar Observadores de Banco de Dados.

    Assim que a exibição Observadores de Banco de Dados for aberta, selecione Criar.

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

    Dica

    Durante a preview, se o observador de banco de dados ainda não estiver disponível em sua região, você poderá criá-lo em uma região diferente. Para obter mais informações, confira Regional availability.

  3. Na guia Identidade, a identidade gerenciada atribuída pelo sistema do observador é habilitada por padrão. Se desejar que o observador use uma identidade gerenciada atribuída pelo 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 pelo usuário eficaz para o observador, desabilite a identidade gerenciada atribuída pelo sistema.

    Para obter mais informações sobre identidades gerenciadas no observador de banco 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 cluster do Azure Data Explorer e adiciona um banco de dados nesse cluster como o armazenamento de dados para os dados de monitoramento coletados.

    • Por padrão, o novo cluster do Azure Data Explorer usa o SKU extra pequeno e com computação otimizada. Esta é o SKU mais econômico que ainda oferece um Contrato de Nível de Serviço (SLA). É possível escalar esse cluster posteriormente, conforme necessário.

    • Como alternativa, você pode usar um banco de dados em um cluster do Azure Data Explorer existente, em um cluster do Azure Data Explorer gratuito ou na Análise em Tempo Real.

      1. Na guia Armazenamento de Dados, escolha a opção Selecionar um Armazenamento de Dados e selecione Adicionar.
      2. Selecione um banco de dados da Análise em Tempo Real ou um cluster do Azure Data Explorer.
      3. Se estiver usando um cluster do Azure Data Explorer existente, você deverá habilitar a ingestão de streaming.
      4. Crie um novo banco de dados ou use um banco de dados existente.

      Observação

      O banco de dados existente selecionado deve estar vazio ou deve ser um banco de dados que você usou anteriormente como um armazenamento de dados do observador de banco de dados. Não há suporte para a seleção de um banco de dados que contenha objetos que não foram criados pelo observador de banco de dados.

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

  5. Na guia Destinos do SQL, adicione um ou mais recursos do SQL do Azure para serem monitorados. É possível ignorar a adição de destinos do SQL ao criar o observador e adicioná-los posteriormente. Você precisa adicionar, no mínimo, um destino antes de iniciar o observador.

  6. Na guia Fazer Revisão e Criar, faça a revisão da configuração do observador e selecione Criar. Se você selecionar a opção padrão para criar um novo cluster do Azure Data Explorer, normalmente, a implantação demora de 15 a 20 minutos. Se você selecionar um banco de dados em um cluster do Azure Data Explorer existente, em um cluster gratuito do Azure Data Explorer ou na Análise em Tempo Real, normalmente, a implantação demora até cinco minutos.

  7. Assim que a implantação for concluída, realize a concessão de acesso aos destinos do SQL para o observador.

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

    • O aceso a um banco de dados em um cluster Azure Data Explorer novo ou existente é concedido automaticamente quando o observador é criado se o usuário que cria o observador for membro da função RBAC Proprietário do cluster.
    • No entanto, você deverá permitir acesso para o armazenamento de dados ao usar um comando do KQL se selecionar um banco de dados em:
      • Análise em tempo real no Microsoft Fabric.
      • Um cluster gratuito do Azure Data Explorer.

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

    • Se houver acesso público em destinos SQL, o armazenamento de dados e o cofre de chaves estiverem habilitados e se quiser usar a conectividade pública, verifique se todos os pré-requisitos de conectividade pública foram atendidos.

Iniciar e parar um observador

Quando um observador é criado, ele não é iniciado automaticamente porque pode ser necessário realizar configurações adicionais.

Para iniciar um observador, ele deve ter:

Depois que 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 monitoramento aparecem no armazenamento de dados e nos dashboards. Se você não vir os novos dados em cinco minutos, confira Solução de problemas.

É possível parar o observador com o botão Parar se não precisar monitorar os recursos do SQL do Azure por algum tempo.

Para reiniciar um observador, pare-o e reinicie-o.

Modificar um observador

No portal do Azure, é possível adicionar ou remover destinos, criar ou excluir pontos de extremidade privados, usar um repositório de dados diferente para um observador existente ou modificar a identidade gerenciada do observador.

Observação

A menos que seja indicado de forma diferente, as alterações realizadas na configuração do observador entrarão em vigor após você parar e reiniciar o observador.

Adicionar destinos do SQL a um observador

Para habilitar o monitoramento do observador de banco de dados para um banco de dados SQL do Azure, pool elástico ou instância gerenciada de SQL, é necessário adicionar este recurso como um destino do SQL.

  1. Para adicionar um destino, na página Destinos do SQL, selecione Adicionar.
  2. Localize o recurso do SQL do Azure que você deseja monitorar. Selecione o tipo de recurso e a assinatura e, em seguida, selecione o destino do SQL na lista de recursos. O destino do SQL pode estar em qualquer assinatura no mesmo locatário do Microsoft Entra ID do observador.
  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 de 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 Intenção de Leitura configura o destino do SQL somente para a réplica secundária de alta disponibilidade.
    • Não marque a caixa Intenção de leitura se quiser monitorar 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 esse recurso ou se o recurso de escala de leitura estiver desabilitado.

Por padrão, o observador de banco de dados usa a autenticação do Microsoft Entra ao realizar a conexão com os destinos do SQL. Se desejar que o observador use autenticação do SQL, marque a caixa Usar Autenticação do SQL e insira os detalhes necessários. Para obter mais informações, confira Configuração adicional para usar a autenticação do SQL.

Remover destinos do SQL de um observador

Para remover um ou mais destinos, abra a página Destinos do SQL, selecione os destinos que deseja remover na lista e escolha Excluir.

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

Se você excluir um recurso do SQL do Azure monitorado pelo observador de banco de dados, também deverá remover o destino correspondente. Como há um limite em relação ao número de destinos do SQL que um observador pode ter, manter os destinos obsoletos pode bloquear a adição de novos destinos.

Criar um ponto de extremidade privado gerenciado

Crie pontos de extremidade privados se você quiser usar a conectividade privada para a coleta de dados dos destinos do SQL, para a ingestão no armazenamento de dados e para a conexão com cofres de chaves. Se você não criar pontos de extremidade privados, o observador de banco de dados usará a conectividade pública como padrão.

Observação

O observador do 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 gerenciada de SQL, um cluster do Azure Data Explorer ou um cofre de chaves não pode ser usado por um observador.

Para criar um ponto de extremidade privado e gerenciado para um observador:

  1. Se houver um bloqueio somente leitura no recurso, no grupo de recursos ou na assinatura do recurso para o qual você está criando um ponto de extremidade privado gerenciado, 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 e Gerenciados e selecione Adicionar.

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

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

  5. Dependendo do tipo de recurso para o qual pretende criar um ponto de extremidade privado, selecione o Tipo de Recurso e o Sub-recurso de Destino da seguinte forma:

    Recurso Tipo de recurso Sub-recurso de destino
    Servidor lógico Microsoft.Sql/servers sqlServer
    Instância Gerenciada de SQL Microsoft.Sql/managedInstances managedInstance
    Cluster do Azure Data Explorer Microsoft.Kusto/clusters cluster
    Key vault Microsoft.KeyVault/vaults vault

  6. Selecione o recurso para o qual deseja criar um ponto de extremidade privado. Isso pode ser um servidor lógico do SQL do Azure, uma instância gerenciada de 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 observador de banco de dados para todos os destinos de banco de dados e de pool elástico nesse servidor.

  7. Como opção, insira a descrição do ponto de extremidade privado. Isto pode ajudar o proprietário do recurso a aprovar a solicitação.

  8. Selecione Criar. A criação de um ponto de extremidade privado pode levar alguns minutos. Um ponto de extremidade privado é criado quando o estado de provisionamento sofre alterações de Aceito ou Em Execução para Com Êxito. Atualize a exibição para visualizar 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 observador do banco de dados possa usá-lo para realizar a conexão com o recurso.

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

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

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

Será necessário criar um ponto de extremidade privado adicional para o cluster do Azure Data Explorer se a conectividade pública do cluster estiver desabilitada. Para obter mais informações, veja Conectividade privada ao armazenamento de dados.

Excluir um ponto de extremidade privado e gerenciado.

  1. Se houver um bloqueio de exclusão ou somente leitura no recurso, no grupo de recursos ou na assinatura do recurso do 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 banco de dados, abra a página Pontos de Extremidade Privados e Gerenciados.
  3. Selecione os pontos de extremidade privados que pretende excluir.
  4. Selecione Excluir.

A exclusão de um ponto de extremidade privado gerenciado interrompe a coleção de dados de destinos do SQL que usam esse ponto de extremidade privado. A exclusão do ponto de extremidade privado e gerenciado para o cluster do Azure Data Explorer interrompe a coleção de dados para todos os destinos. Para retomar a coleção de dados, crie o ponto de extremidade privado novamente ou habilite a conectividade pública e reinicie o observador.

Alterar o armazenamento de dados para um observador

Um observador pode ter somente um armazenamento de dados.

Para alterar o armazenamento de dados atual, remova o armazenamento de dados existente e, em seguida, 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 grade e escolha Excluir.

    • A remoção de um armazenamento de dados não exclui o banco de dados real do armazenamento de dados em um cluster do Azure Data Explorer ou na Análise em Tempo Real no Microsoft Fabric.
    • Para interromper a coleção de dados em um armazenamento de dados removido, pare o observador.
    • Se você remover um armazenamento de dados, deverá adicionar um novo armazenamento de dados antes de iniciar o observador novamente.

  • Para adicionar um armazenamento de dados, selecione Adicionar na página Armazenamento de Dados e, em seguida, selecione ou crie um banco de dados em um cluster do Azure Data Explorer ou na Análise em Tempo Real.

    • O banco de dados selecionado deve estar vazio ou deve ser um banco de dados que você usou anteriormente como um armazenamento de dados do observador de banco de dados. Não há suporte para a seleção de um banco de dados que contenha objetos que não foram criados pelo observador de banco de dados.
    • Depois de adicionar um armazenamento de dados, você deverá conceder acesso ao observador para usá-lo. Para obter mais informações, confira Permitir acesso ao armazenamento de dados.
    • Após a reinicialização do observador, ele começará a usar o novo armazenamento de dados.

Modificar a identidade do observador

Um observador deve ter uma identidade gerenciada para autenticar em destinos SQL, cofres de chaves e o armazenamento de dados. É possível usar tanto uma identidade gerenciada atribuída pelo sistema quanto uma atribuída pelo usuário. Para obter mais informações sobre identidades gerenciadas no Azure, confira O que são identidades gerenciadas para recursos do Azure?

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

  • Atribuído pelo sistema

    • Habilitado por padrão quando você cria um observador.
    • Sempre associado a um único observador.
    • Criado e excluído com o observador.
    • Se você desabilitar uma identidade atribuída pelo sistema para um observador, todo acesso concedido a essa identidade será perdido. Habilitar novamente a identidade atribuída pelo sistema para o mesmo observador cria uma identidade nova e diferente com uma ID de objeto (entidade de segurança) diferente. Você precisa conceder acesso aos destinos do SQL, ao cofre de chaves e ao armazenamento de dados para essa nova identidade.

  • Atribuído pelo usuário

    • Só entrará em vigor se a identidade atribuída pelo sistema estiver desabilitada para o observador.
    • A mesma identidade atribuída pelo 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 pelo sistema de vários observadores, o acesso pode ser concedido a uma única identidade atribuída pelo usuário.
    • Para dar suporte à separação de funções, o gerenciamento de identidades pode ser separado do gerenciamento do observador. Uma identidade atribuída pelo usuário pode ser criada e obter concessão de acesso por um usuário diferente, antes ou depois da criação do observador.
    • Por outro lado, quando um observador é excluído, a identidade atribuída pelo usuário e seu acesso permanecem inalterados. A mesma identidade pode ser usada para um novo observador.
    • Não há suporte para especificar mais de uma identidade atribuída pelo usuário para um observador.

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

  • Para usar uma identidade atribuída pelo sistema, habilite a alternância de Identidade atribuída pelo sistema.

  • Para usar uma identidade atribuída pelo usuário, desabilite a alternância de Identidade atribuída pelo sistema. Selecione o botão Adicionar para localizar e adicionar uma identidade atribuída pelo usuário existente.

    Para criar uma identidade gerenciada atribuída pelo usuário, confira Criar uma identidade gerenciada atribuída pelo usuário.

  • Para remover uma identidade atribuída pelo usuário de um observador, selecione-a na lista e selecione Remover. Depois de remover uma identidade atribuída pelo usuário, será necessário adicionar uma identidade atribuída pelo usuário diferente ou habilitar a identidade atribuída pelo sistema.

    A identidade atribuída pelo usuário removida não é excluída do locatário do Microsoft Entra ID.

Selecione o botão Salvar para salvar alterações de identidade. Você não poderá salvar alterações de identidade se o resultado disso for o observador não ter nenhuma identidade. Não há suporte para observadores sem uma identidade gerenciada válida.

Dica

É recomendável que o nome de exibição da identidade gerenciada do observador seja exclusivo no locatário do Microsoft Entra ID. Você pode escolher um nome exclusivo ao criar uma identidade atribuída pelo usuário para observadores.

O nome de exibição da identidade atribuída pelo sistema é o mesmo que o nome do observador. Se você usar a identidade atribuída pelo sistema, verifique se o nome do observador é exclusivo dentro do locatário do Microsoft Entra ID.

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

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

Excluir um observador

Se houver um bloqueio de exclusão ou somente leitura no observador ou no respectivo grupo de recursos ou assinatura, remova o bloqueio. Você poderá adicionar o bloqueio novamente depois que o inspetor for excluído com êxito.

Quando você exclui um observador que tem a identidade gerenciada atribuída pelo sistema habilitada, a identidade também é excluída. Isso remove o acesso concedido a esta identidade. Se mais tarde você recriar o observador, será necessário conceder acesso à identidade gerenciada atribuída pelo sistema do novo observador para autenticar em cada recurso. Isso inclui:

Você deve permitir acesso a um observador criado novamente, mesmo se usar o mesmo nome do observador.

Ao excluir 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 monitoramento do SQL coletados no armazenamento de dados e pode usar o mesmo banco de dados do Azure Data Explorer ou Análise em Tempo Real que o armazenamento de dados se criar um novo observador posteriormente.

Permitir acesso a destinos do SQL

Para permitir que um observador colete dados de monitoramento do SQL, é necessário executar um script T-SQL que conceda as permissões específicas e limitadas do SQL para o observador.

  • 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 os bancos de dados e os pools elásticos que deseja monitorar.

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

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

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

  1. Navegue até o observador no portal do Azure, selecione Destinos do SQL, escolha um dos links Permitir Acesso para abrir o script T-SQL e copie o script. Certifique-se de escolher o link mais adequado para o seu 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 é específico para um observador porque inclui o nome da identidade gerenciada do observador. Para obter uma versão genérica desse script que você pode personalizar para cada observador, confira Permitir acesso a destinos do SQL com scripts T-SQL.

  2. No SQL Server Management Studio, no Azure Data Studio ou em outras ferramenta de cliente do SQL, abra um novo período de consulta e faça conexão com o banco de dados master em um servidor lógico do SQL do Azure que contém o destino ou ao banco de dados master em um destino de instância gerenciada de SQL.

  3. Cole e execute o script T-SQL para permitir acesso ao observador. O script cria um logon que o observador usará para se realizar a conexão e a concessão de 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 observador usar a identidade gerenciada atribuída pelo sistema, o observador já deve ter sido criado quando você executar o script. Se o observador usar uma identidade gerenciada atribuída pelo usuário, será possível executar o script antes ou depois da criação do observador.

    Você deve estar conectado à 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 posteriormente, precisará permitir acesso a esses destinos de maneira semelhante, a menos que esses destinos estejam em um servidor lógico para o qual o acesso já tenha sido concedido.

Permitir acesso a destinos do SQL com scripts T-SQL

Existem diferentes scripts para a autenticação do Microsoft Entra e a autenticação do SQL, e para destinos de Banco de Dados SQL do Azure e de Instância Gerenciada de SQL do Azure.

Importante

Sempre use os scripts fornecidos para permitir acesso ao observador de banco de dados. A concessão de acesso de uma forma diferente pode bloquear a coleção de dados. Para obter mais informações, confira 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.

Permitir acesso a observadores com autenticação do Microsoft Entra

Este script cria um logon de autenticação do Microsoft Entra (anteriormente conhecido como Azure Active Directory) em um servidor lógico no Banco de Dados SQL do Azure. O logon é 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 observador usar a identidade gerenciada atribuída pelo sistema, será preciso usar o nome do observador como o nome de logon. Se o observador usar uma identidade gerenciada atribuída pelo usuário, você deverá usar o nome de exibição da identidade como o nome de logon.

O script deve ser executado no banco de dados master do 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];

Permitir acesso a observadores com autenticação do SQL

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

Este script cria um logon de autenticação do SQL em um servidor lógico no Banco de Dados SQL do Azure. Ele concede ao logon 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 do servidor lógico, usando um logon que seja de um administrador do 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 do SQL

Para armazenar credenciais de autenticação com segurança, o uso da autenticação do SQL no observador de banco de dados requer uma configuração adicional.

Dica

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

Para configurar o observador de banco de dados para realizar uma conexão com um destino ao usar a autenticação do SQL, siga estas etapas:

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

    Se desejar usar a conectividade privada com o cofre, crie um ponto de extremidade privado na página Pontos de Extremidade Privados e Gerenciados. Selecione Microsoft.KeyVault/vaults como o Tipo de Recurso e vault como Sub-recurso de Destino. Certifique-se de que o ponto de extremidade privado é aprovado antes de iniciar o observador.

    Se desejar usar a conectividade pública, o cofre deverá permitir o acesso público de todas as redes. Não há suporte para a restrição da conectividade do cofre público para redes específicas no observador de banco de dados.

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

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

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

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

  4. Adicione um destino do SQL para um observador. Ao adicionar o destino, marque a caixa Usar Autenticação do SQL e selecione o cofre em que o nome de logon e os segredos de senha estão armazenados. Insira os nomes dos segredos para nome de logon e senha nos campos correspondentes.

    Ao adicionar um destino do SQL, não insira o nome de logon e a senha reais. Ao usar o exemplo anterior, você inseriria os nomes de segredos 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 o acesso necessário aos segredos do cofre de chaves automaticamente se o usuário atual for um membro da função Proprietários ou da função Administrador de acesso do 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 Controle de Acesso (IAM) de cada segredo, adicione uma atribuição de função para a identidade gerenciada do observador na função RBAC Key Vault Secrets User. Para seguir o princípio do menor privilégio, adicione esta atribuição de função para cada segredo, em vez de para todo o cofre. A página Controle de acesso (IAM) só será exibida se o cofre estiver configurado para usar o modelo de permissão RBAC.

Se desejar usar credenciais de autenticação de SQL diferentes em destinos do SQL diferentes, você deverá criar vários pares de segredos. Use o mesmo cofre ou cofres diferentes para armazenar os segredos de cada destino SQL.

Observação

Se você atualizar o valor do segredo para um nome de logon ou uma 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 do SQL em 15 minutos. Se desejar começar a usar as novas credenciais imediatamente, pare o que está fazendo e reinicie o observador.

Permitir acesso ao armazenamento de dados

Para criar e gerenciar o esquema do banco de dados do armazenamento de dados e para ingerir dados de monitoramento, o observador de banco de dados requer subscrição à função RBAC Administradores no banco de dados do armazenamento de dados, em um cluster do Azure Data Explorer ou na Análise em Tempo Real. O observador de banco de dados não requer acesso em nível de cluster ao cluster do Azure Data Explorer ou 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 o armazenamento de dados, esse acesso será concedido automaticamente caso você seja membro da função RBAC Proprietário do cluster. Caso contrário, o acesso deverá ser concedido conforme descrito nesta seção.

Se você usar um banco de dados na Análise em tempo real ou em um cluster gratuito do Azure Data Explorer, será necessário conceder acesso usando KQL.

Permitir acesso a um banco de dados do Azure Data Explorer ao usar o portal do Azure

É possível usar o portal do Azure para permitir 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 e Sistema de Rede, selecione Permissões. Não use a página Permissões do cluster.
  2. Selecione Adicionar e escolha Administrador.
  3. Na página Novas entidades de segurança, selecione Aplicativos empresariais. Se o observador usar a identidade gerenciada atribuída pelo sistema, digite o nome do observador na caixa Pesquisar. Se o observador usar uma identidade gerenciada atribuída pelo usuário, digite o nome de exibição dessa identidade na caixa Pesquisar.
  4. Selecione o aplicativo empresarial para a identidade gerenciada do observador.

Permitir acesso a um banco de dados do Azure Data Explorer ao usar KQL

Em vez de usar o portal do Azure, você pode permitir acesso ao banco de dados ao usar um comando do KQL. Use este método para permitir acesso a um banco de dados na Análise em Tempo Real ou em um cluster do Azure Data Explorer gratuito.

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

  2. Na amostra de comando do KQL apresentada a seguir, substitua três espaços reservados como indicado na tabela:

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

    Essa parte do comando é necessária se você usar um banco de dados na Análise em tempo real 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) podem ser omitidos 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 do observador.

    Por exemplo:

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

Para obter mais informações, confira Kusto role-based access control.

Permitir acesso ao armazenamento de dados para usuários e grupos

É possível usar o portal do Azure ou um comando do KQL para realizar a concessão de acesso a um banco de dados para usuários e grupos em um cluster do Azure Data Explorerou na Análise em Tempo Real. Para conceder acesso, você deve ser membro da função RBAC Admin no banco de dados.

Use um comando do KQL para permitir acesso a um banco de dados no cluster do Azure Data Explorer gratuito ou na Análise em Tempo Real. Para seguir o princípio do menor privilégio, recomendamos que você não adicione usuários e grupos para uma função RBAC que não seja Espectador por padrão.

Importante

Considere com atenção os requisitos de privacidade e segurança de seus dados ao permitir acesso para a exibição de dados de monitoramento do SQL coletados pelo observador de banco de dados.

Mesmo que o observador de banco de dados não tenha a capacidade de coletar dados armazenados em tabelas de usuários nos bancos de dados SQL, determinados conjuntos de dados, como Sessões Ativas, Metadados de Índice, Índices Ausentes, Estatísticas de Runtime da Consulta, Estatísticas de Espera da Consulta, Estatísticas da Sessão e Metadados da Tabela, podem conter dados potencialmente confidenciais, como nomes de tabelas e índices, texto de consulta, valores de parâmetros de consulta, nomes de logon etc.

Ao realizar a concessão de acesso de exibição ao armazenamento de dados para um usuário que não tem acesso para visualizar esses dados em um banco de dados SQL, é possível habilitar que ele veja dados confidenciais que, de outra forma, não conseguiria ver.

Permitir acesso ao armazenamento de dados ao usar o portal do Azure

É possível usar o portal do Azure para permitir acesso a um banco de dados para usuários e grupos 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 e Sistema de Rede, selecione Permissões. Não use a página Permissões do cluster.
  2. Selecione Adicionar e escolha Espectadores.
  3. Na página Novas Entidades de Segurança, digite o nome do usuário ou grupo na caixa de Pesquisa.
  4. Selecione o usuário ou o grupo.

Permitir acesso ao armazenamento de dados ao usar KQL

Em vez de usar o portal do Azure, você pode permitir acesso ao banco de dados para usuários e grupos ao usar um comando do KQL. Os exemplos de comandos do KQL apresentados a seguir concedem acesso de leitura de dados ao usuário mary@contoso.com e ao grupo SQLMonitoringUsers@contoso.com em um locatário do Microsoft Entra ID com um valor de ID de locatário 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, confira Kusto role-based access control.

Para permitir acesso ao armazenamento de dados para usuários e grupos de outro locatário, é necessário habilitar a autenticação entre locatários no cluster do Azure Data Explorer. Para obter mais informações, confira Allow cross-tenant queries and commands.

Dica

Para permitir que você conceda acesso a usuários e grupos o 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 o armazenamento de dados

Esta seção descreve como você pode gerenciar o armazenamento de dados de monitoramento, incluindo a escalabilidade, a retenção de dados e outras configurações. As considerações de escalabilidade do cluster nesta seção são relevantes se você usar um banco de dados no cluster do Azure Data Explorer. Se você usar um banco de dados na Análise em Tempo Real no Fabric, a escalabilidade será gerenciada automaticamente.

Escalar o cluster do Azure Data Explorer

É possível escalar o cluster do Azure Data Explorer conforme necessário. Por exemplo, você pode reduzir verticalmente o cluster para o SKU Extra pequeno de desenvolvimento/teste 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 observador de banco de dados, o SKU padrão do cluster com duas instâncias que é extra pequeno e tem computação otimizada será suficiente indefinidamente. Em alguns casos, dependendo da configuração e das alterações na carga de trabalho ao longo do tempo, poderá ser necessário escalar o cluster para garantir o desempenho de consulta adequado e manter a baixa latência de ingestão de dados.

O Azure Data Explorer oferece suporte para escalar o cluster vertical e horizontalmente. Com a escala vertical, você realiza alterações no SKU do cluster, o que altera o número de vCPUs, memória e cache por instância (nó). Com a escala horizontal, o SKU permanece o mesmo, mas o número de instâncias no cluster aumenta ou diminui.

Você precisará escalar o cluster horizontal ou verticalmente se notar um ou mais dos seguintes indícios:

  • O desempenho do dashboard ou da consulta ad hoc se tornou muito lento.
  • Você executa diversas consultas simultâneas no cluster e recebe erros de limitação.
  • A latência de ingestão de dados torna-se consistentemente superior ao aceitável.

Em geral, não é necessário escalar o cluster, pois a quantidade de dados no armazenamento de dados aumenta com o tempo. Isso ocorre porque as consultas do dashboard e as consultas analíticas mais comuns usam somente os dados mais recentes, que são armazenados em cache no armazenamento SSD local nos nós de cluster.

No entanto, se você executar consultas analíticas que abrangem intervalos de tempo mais longos, elas poderão se tornar mais lentas com o tempo, à medida que a quantidade total de dados coletados aumentar e não caber mais no armazenamento SSD local. Neste caso, pode ser necessário escalar o cluster para manter o desempenho de consulta adequado.

  • Se for necessário escalar cluster, recomendamos escalá-lo horizontalmente primeiro para aumentar o número de instâncias. Isto mantém o cluster disponível para consultas e para a ingestão durante o processo de escalabilidade.

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

  • Você pode descobrir que, mesmo depois de escalar horizontalmente o cluster, algumas consultas ainda não funcionam conforme o esperado. Isto poderá acontecer se o desempenho da consulta estiver limitado pelos recursos disponíveis em uma instância (nó) do cluster. Nesse caso, escale verticalmente o cluster.

    • A escala vertical do cluster demora 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 observador após a conclusão da operação de escalabilidade.

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 de dados não compactados originais. Você não pode escalonar um cluster gratuito do Azure Data Explorer para aumentar sua capacidade de computação ou armazenamento. Quando o cluster estiver perto de atingir a capacidade de armazenamento ou a sua capacidade, uma mensagem de aviso será exibida na página do cluster gratuito.

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

Se você descobrir que as especificações do cluster gratuito são insuficientes para seus requisitos, você pode atualizar para um cluster completo do Azure Data Explorer e reter todos os dados coletados. Como pode haver um período de inatividade durante a atualização, pode ser necessário parar e reiniciar o observador para retomar a coleção de dados quando a atualização for concluída.

Para continuar usando o cluster gratuito do Azure Data Explorer, gerencie a retenção de dados para excluir os dados mais antigos automaticamente e libere espaço para dados novos. Quando o espaço de armazenamento estiver disponível, será necessário interromper e reiniciar o observador para retomar a coleta de dados.

Gerenciar a retenção de dados

Se não precisar de dados mais antigos, você poderá configurar políticas de retenção de dados para limpá-los automaticamente. Por padrão, a retenção de dados é estabelecida como 365 dias em um novo banco de dados em um cluster do Azure Data Explorer ou na Análise em Tempo Real.

  • É possível reduzir o período de retenção de dados no nível do banco de dados ou para tabelas individuais no banco de dados.
  • Além disso, é possível aumentar a retenção se você precisar armazenar dados de monitoramento por mais de um ano. Não existe um limite máximo para o período de retenção de dados.
  • Se você configurar períodos de retenção de dados diferentes para tabelas distintas, os dashboards poderão não funcionar conforme o esperado para os intervalos de tempo mais antigos. Isso pode acontecer se os dados ainda estiverem presentes em algumas tabelas, mas já tiverem sido limpos em outras tabelas para o mesmo intervalo de tempo.

A quantidade de dados de monitoramento do SQL que são ingeridos no armazenamento de dados depende das cargas de trabalho SQL e do tamanho da propriedade SQL do Azure. Você pode usar a consulta KQL a seguir 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 de acesso no armazenamento de dados do observador de banco de dados

Com o tempo, a Microsoft poderá introduzir novos conjuntos de dados para o observador de banco de dados ou expandir os conjuntos de dados existentes. Isso significa que novas tabelas no armazenamento de dados ou novas colunas em tabelas existentes poderão ser adicionadas automaticamente.

Para isso, a identidade gerenciada atual de um observador de banco de dados deve ser um membro da função RBAC Administradores no armazenamento de dados. Revogar esta subscrição de função ou substituí-la por uma subscrição em outra função RBAC pode impactar a coleção de dados do observador de banco de dados e o gerenciamento de esquema. Além disso, não há suporte para isso.

De forma semelhante, não há suporte para a criação de novos objetos, como tabelas, tabelas externas, exibições materializadas, funções e entre outros, no armazenamento de dados do observador de banco de dados. É possível usar consultas entre clusters e entre bancos de dados para consultar dados no armazenamento de dados de outros clusters do Azure Data Explorer ou de outros bancos de dados no mesmo cluster.

Importante

Se você alterar o acesso do observador de banco de dados ao armazenamento de dados ou fizer alterações no esquema de banco de dados ou na configuração que afetem a ingestão de dados, pode ser necessário alterar o armazenamento de dados desse observador para um novo banco de dados vazio e realizar a concessão de acesso a esse novo banco de dados para o observador com a finalidade de retomar a coleção de dados e reverter para uma configuração com suporte.

Cluster do Azure Data Explorer interrompido

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 consultas 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 inspetor, o comportamento de parada automática será desabilitado para permitir a coleção de dados ininterrupta.

Se o cluster for interrompido, a coleta de dados do observador 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 observador.

É possível desabilitar o comportamento de parada automática se desejar que o cluster permaneça disponível mesmo quando estiver inativo. Isso pode aumentar o custo do cluster.

Ingestão de streaming

O observador de banco de dados requer que o cluster do Azure Data Explorer que contém o banco de dados do armazenamento de dados tenha a ingestão de streaming habilitada. A ingestão de streaming é automaticamente habilitada para o novo cluster do Azure Data Explorer criado quando você cria um novo observador. Além disso, ela está habilitada na Análise em Tempo Real e no cluster do Azure Data Explorer gratuito.

Se desejar usar um cluster do Azure Data Explorer existente, certifique-se de primeiro habilitar a ingestão de streaming. Isso demora alguns minutos e reinicializa 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 ponto de extremidade privado para se conectar ao cluster do navegador e ver os dados de monitoramento do SQL em painéis ou consultar os dados diretamente. Esse ponto de extremidade privado é um acréscimo ao ponto de extremidade privado gerenciado criado para permitir que o observador ingira os dados de monitoramento em um banco de dados no cluster do Azure Data Explorer.

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

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

    1. Usar o Gateway de VPN Azure ou o Azure ExpressRoute para estabelecer uma conexão privada da sua rede local com a rede virtual Azure.
    2. Criar um ponto de extremidade privado para o cluster do Azure Data Explorer na rede virtual do Azure, na qual a conexão VPN ou ExpressRoute termina, ou em outra rede virtual do Azure atingível pelo tráfego da máquina local.
    3. Configurar o DNS para esse ponto de extremidade privado.

A conectividade privada não está disponível para clusters gratuitos do Azure Data Explorer ou para Análise em Tempo Real no Microsoft Fabric.

Monitorar grandes propriedades

Para monitorar uma grande propriedade do SQL do Azure, pode ser necessário criar vários observadores.

Cada observador requer um banco de dados em um cluster do Azure Data Explorer ou na Análise em Tempo Real como armazenamento de dados. Os observadores criados podem usar um banco de dados individual como um armazenamento de dados comum ou bancos de dados separados como armazenamentos de dados separados. As considerações apresentadas a seguir podem ajudar você a fazer a escolha ideal de design para seus cenários e requisitos de monitoramento.

Considerações para um armazenamento de dados comum:

  • Há uma exibição de painel de controle único para toda a propriedade do SQL do Azure.
  • Os painéis de qualquer observador mostram todos os dados no armazenamento de dados, mesmo que eles sejam coletados por outros observadores.
  • Os usuários com acesso ao armazenamento de dados têm acesso aos dados de monitoramento de todo o estado do SQL do Azure.

Considerações para armazenamentos de dados separados:

  • Os subconjuntos da propriedade do SQL do Azure são monitorados de forma independente. Os painéis do observador do banco de dados no portal do Azure sempre mostram os dados de um armazenamento de dados individual.
  • Os usuários com acesso a múltiplos armazenamentos de dados podem usar consultas do KQL entre clusters ou entre bancos de dados para acessar dados de monitoramento em diversos armazenamentos de dados usando uma única consulta.
  • Como o acesso aos dados no Azure Data Explorer e na Análise em Tempo Real é gerenciado por um banco de dados, é possível gerenciar o acesso aos dados de monitoramento para os subconjuntos da propriedade de uma forma granular.
  • É possível estabelecer múltiplos bancos de dados em um 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ê necessitar de uma separação completa de ambientes, incluindo o acesso de rede para clusters do Azure Data Explorer, é possível estabelecer bancos de dados diferentes em clusters distintos.

Conteúdo relacionado