Compartilhar via

Criar e configurar um observador (versão prévia)

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

Este artigo contém etapas detalhadas para criar, configurar e iniciar um observador 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 exige que você implante e mantenha agentes de monitoramento ou outra infraestrutura de monitoramento. Você pode 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 criar e configurar um observador, consulte Início Rápido: Criar um observador para monitorar o SQL do Azure.

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

Para definir inspetores usando a infraestrutura como código (Bicep, modelos do ARM, AzAPI do Terraform), veja a documentação de referência de recursos do Azure.

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

Depois de criar e configurar um observador seguindo as etapas neste artigo, você pode usar alertas do Azure Monitor. Para obter mais informações, veja Alertas do inspetor de banco de dados.

Observação

Atualmente, o observador de banco de dados está em versão prévia.

Pré-requisitos

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

  • Você precisa 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 Proprietário da assinatura ou de um grupo de recursos para poder criar recursos.

  • Para configurar e iniciar um observador, você precisa de um destino 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 na sua assinatura do Azure.

    • Para usar a autenticação SQL para conexões com os recursos do SQL do Azure, o Microsoft.KeyVault provedor de recursos também deve ser registrado. Consulte Configuração adicional para usar a autenticação SQL.
    • Para criar regras de alerta, o provedor de recursos Microsoft.Insights também deve ser registrado.

    O registro do provedor de recursos será automático se você tiver a associação à função RBACProprietário ou Colaborador na assinatura. Caso contrário, um usuário em uma dessas funções deve registrar provedores de recursos antes que você possa criar e configurar um observador. Para saber mais, consulteRegistrar provedores de recursos.

  • O usuário que cria e configura o inspetor e os recursos de cluster do Azure Data Explorer precisam ser membros da função RBAC Proprietário ou Colaborador no grupo de recursos ou na assinatura em que esses recursos são criados.

    Além disso, se estiver usando a autenticação SQL, o usuário deverá ser membro da função Proprietário do grupo de recursos ou membro da função Proprietário ou Administrador de Acesso do Usuário para o cofre de chaves que armazena as credenciais de autenticação do SQL.

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

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

  • Para usar o Link Privado do Azure para obter conectividade privada com 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 RBAC necessárias. Para obter mais informações, veja RBAC de aprovação para o ponto de extremidade privado.

Criar um observador

  1. No portal do Azure, no menu de navegação, selecione Todos os Serviços. Selecione a categoria Monitor e, em Ferramentas de Monitoramento, selecione Observadores de banco de dados. Como alternativa, você pode digitar observador de banco de dados na caixa Pesquisar na parte superior da página do portal e selecionar Observadores de banco de dados.

    Depois que o modo de exibição Observadores de banco de dados for aberto, selecione Criar.

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

    Dica

    Durante a prévia, 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 saber mais, consulte Disponibilidade por região.

  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 dados de monitoramento coletados.

    • Por padrão, o novo cluster do Azure Data Explorer usa a SKU Extra Small, Compute Optimized. Esse é o SKU mais econômico que ainda fornece um Contrato de Nível de Serviço (SLA). Você pode dimensionar esse cluster mais tarde, conforme necessário.

    • Ou você pode usar um banco de dados em um cluster existente do Azure Data Explorer, em um cluster gratuito do Azure Data Explorer 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 existente do Azure Data Explorer, você deverá habilitar a ingestão de streaming.
      4. Criar um novo banco de dados ou use um existente.

      Observação

      Qualquer banco de dados existente que você selecionar deve estar vazio ou deve ser um banco de dados que você tenha usado anteriormente como um armazenamento de dados de monitoramento. Não há suporte para a seleção de um banco de dados que contenha objetos não criados pelo observador de banco de dados.

    • Ou você pode ignorar a adição de um armazenamento de dados no 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 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 destino antes de iniciar o inspetor.

  6. Na guia Revisar + criar, revise a configuração do inspetor e selecione Criar. Se você selecionar a opção padrão para criar um 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 na Análise em Tempo Real, a implantação normalmente leva até cinco minutos.

  7. Depois que a implantação for concluída, permita ao inspetor o acesso aos destinos SQL.

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

    • O acesso a um banco de dados em um cluster novo ou existente do Azure Data Explorer é 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ê deve permitir acesso ao armazenamento de dados usando um comando 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 inspetor

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

Para iniciar um inspetor, ele precisa 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 alguns minutos, novos dados de monitoramento são exibidos no armazenamento de dados e nos painéis. Se você não vir novos dados em cinco minutos, consulte Solução de Problemas.

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

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

Como 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 inspetor existente ou modificar a identidade gerenciada do inspetor.

Observação

A menos que indicado de forma diferente, as alterações feitas na configuração do observador se tornam efetivas depois que você para e reinicia o observador.

Como adicionar destinos SQL a um inspetor

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

  1. Para adicionar um destino, na página Destinos do SQL, selecione Adicionar.
  2. Localize o recurso SQL do Azure que você deseja monitorar. Selecione o tipo de recurso e a assinatura e selecione o destino SQL na lista de recursos. O destino do SQL pode estar em qualquer assinatura no mesmo locatário do Microsoft Entra ID que o inspetor.
  3. Para monitorar a réplica primária e uma réplica secundária de alta disponibilidade de um banco de dados, um pool elástico ou uma instância gerenciada do 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 SQL apenas 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, um observador usa a autenticação do Microsoft Entra ao se conectar aos destinos do SQL. Se você quiser que o observador use 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.

Como remover destinos SQL de um inspetor

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

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

Se você excluir um recurso do SQL do Azure monitorado por um observador, também deverá remover o destino SQL correspondente do observador. Como há um limite no número de destinos SQL que um observador pode ter, manter destinos obsoletos pode impedi-lo de adicionar novos destinos.

Criar um ponto de extremidade privado gerenciado

Você precisa criar pontos de extremidade privados gerenciados se quiser usar a conectividade privada para coleta de dados de destinos SQL, para ingestão no armazenamento de dados e para se conectar aos cofres de chaves. Se você não criar pontos de extremidade privados, um observador usará a conectividade pública.

Observação

Um observador requer que seus próprios pontos de extremidade privados gerenciados se conectem aos recursos do Azure. Um inspetor não pode usar nenhum ponto de extremidade privado que já possa existir para 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.

Para criar um ponto de extremidade privado gerenciado 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á criado um ponto de extremidade privado gerenciado, remova o bloqueio. Você pode adicionar o bloqueio novamente depois que o endpoint privado for criado com sucesso.

  2. Navegue até um observador no portal do Azure, abra a página Pontos de Extremidade Privados Gerenciados 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 do recurso para o qual você deseja criar um ponto de extremidade privado, selecione o Tipo de Recurso e o Sub-recurso de Destino da seguinte maneira:

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

  6. Selecione o recurso para o qual você 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 permite que um observador use conectividade privada para todos os destinos de banco de dados e pool elástico nesse servidor.

  7. Opcionalmente, insira a descrição do ponto de extremidade privado. Isso 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 endpoint privado é criado depois que seu estado de provisionamento é alterado de Aceito ou Em Execução para Concluído com sucesso. Atualize a exibição para ver o estado de provisionamento atual.

    Importante

    O ponto de extremidade privado é criado no estado Pendente. O proprietário do recurso deve aprovar o ponto de extremidade privado antes que um observador possa usá-lo para se conectar ao recurso.

    Para que os proprietários de recursos controlem a conectividade de rede, os endpoints privados gerenciados para um watcher não são aprovados automaticamente.

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

Se um inspetor já estiver em execução quando um ponto de extremidade privado for aprovado, ele precisará 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, consulte Conectividade privada com o armazenamento de dados.

Como excluir um ponto de extremidade privado gerenciado

  1. Se houver um bloqueio somente leitura no recurso, no grupo de recursos ou na 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 observador, abra a página Pontos de extremidade privados gerenciados.
  3. Selecione os pontos de extremidade privados que você deseja excluir.
  4. Selecione Excluir.

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

Alterar o armazenamento de dados para um inspetor

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 grade e selecione Excluir.

    • A remoção de um armazenamento de dados não exclui o banco de dados propriamente dito em um cluster do Azure Data Explorer ou na funcionalidade de Análise em Tempo Real do Microsoft Fabric.
    • Para interromper a coleta de dados em um armazenamento de dados removido, interrompa 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 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 repositório de dados de observador. Não há suporte para a seleção de um banco de dados que contenha objetos não criados pelo observador 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 Conceder acesso ao armazenamento de dados.
    • Depois que o observador é reiniciado, ele começa a usar o novo armazenamento de dados.

Dica

Se você alternar o armazenamento de dados de um cluster pago do Azure Data Explorer para um cluster gratuito do Azure Data Explorer, considere interromper ou excluir o cluster pago se você não precisar mais dele. Isso pode evitar custos desnecessários.

Como modificar a identidade do observador

Um inspetor precisa 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ída pelo sistema

    • Habilitado por padrão quando você cria um observador.
    • Sempre associado a um único observador.
    • Criado e excluído com o inspetor.
    • 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 inspetor cria uma identidade diferente com uma ID de objeto (entidade de segurança) diferente. Você precisa conceder acesso aos Destinos SQL, ao cofre de chaves e ao armazenamento de dados para essa nova identidade.

  • Atribuída 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 receber acesso de um usuário diferente, antes ou depois da criação do inspetor.
    • 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 opção 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 a um usuário de um observador, selecione-a na lista e depois clique em 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

Recomendamos que o nome de exibição da identidade gerenciada do inspetor 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 inspetor é 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 permitir ao inspetor o 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 inspetor se reconecta aos destinos SQL, aos cofres de chaves (se usados) e ao armazenamento de dados usando a respectiva identidade gerenciada atual.

Como excluir um observador

Se houver uma exclusão ou um bloqueio somente leitura no inspetor, no grupo de recursos ou na assinatura, remova o bloqueio. Da mesma forma, se houver um bloqueio no recurso, no grupo de recursos ou na assinatura do recurso para o qual você tenha 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 a identidade gerenciada atribuída pelo sistema habilitada, a identidade também é excluída. Isso remove qualquer acesso que você concedeu a essa identidade. Se mais tarde você recriar o inspetor, será necessário permitir acesso à identidade gerenciada atribuída pelo sistema do novo inspetor para autenticação em cada recurso. Isso inclui:

Você deve conceder acesso a um observador recriado, mesmo que use 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ê reterá os dados do SQL Monitoring coletados no armazenamento de dados e poderá usar o mesmo Azure Data Explorer ou banco de dados da Análise em Tempo Real que o armazenamento de dados se criar um inspetor mais tarde.

Como permitir acesso aos destinos SQL

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

  • Para executar o script no Banco de Dados SQL do Azure, você precisa do acesso do 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 existentes e novos e pools elásticos nesse servidor.

  • Para executar o script na Instância Gerenciada de SQL do Azure, você precisa ser membro da função de servidor sysadmin ou securityadmin ou ter a permissão CONTROL SERVER 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 inspetor no portal do Azure, selecione Destinos SQL, selecione um dos links de Permitir acesso para abrir o script T-SQL e copie o script. Escolha o link correto para o tipo de destino e o tipo de autenticação que você 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, consulte Conceder acesso a destinos SQL com scripts T-SQL.

  2. No SQL Server Management Studio ou em 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 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 conceder acesso ao observador. O script cria um logon que o observador usa 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 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 destinos a um observador mais tarde, precisará permitir acesso a esses destinos de maneira semelhante, a menos que eles estejam em um servidor lógico em que o acesso já tenha sido concedido.

Conceder acesso a destinos SQL com scripts T-SQL

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

Importante

Sempre use scripts fornecidos para conceder acesso a um observador. Conceder acesso de uma maneira diferente pode bloquear a coleta 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 com os valores reais.

Permitir acesso aos observadores autenticados do Microsoft Entra

Esse 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 no servidor lógico. Você deve estar conectado usando um logon de autenticação do Microsoft Entra que seja um administrador de 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 do 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 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 no servidor lógico, usando um logon 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 para um observador 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 um observador para se conectar a um destino SQL usando a autenticação SQL, siga estas etapas:

  1. Crie um cofre no Azure Key Vault ou identifique um cofre existente que você pode usar. O cofre precisa usar o modelo de permissão do RBAC. O modelo de permissão do 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 de política de acesso mais antigo.

    Se você quiser usar a conectividade privada com o cofre, crie um ponto de extremidade privado na página Pontos de extremidade privados gerenciados. Selecione Microsoft.KeyVault/vaults como Tipo de Recurso e vault como Sub-recurso de Destino. Verifique se o ponto de extremidade privado foi aprovado antes de iniciar o inspetor.

    Se você quiser usar a conectividade pública, o cofre deverá 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 do SQL do Azure ou em uma instância gerenciada que você deseja monitorar e conceda as permissões específicas e limitadas usando scripts de acesso fornecidos. No script, substitua o nome de login e os espaços reservados para senha pelos valores reais. Use uma senha forte.

  3. No cofre, crie dois segredos: um segredo para o nome de usuário e um segredo separado para a senha. Use os nomes válidos como o nome do segredo e insira o nome de logon e a senha que você usou no script T-SQL como o valor do segredo de 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 logon e uma senha forte.

    Para criar segredos, você precisa ser membro da função RBAC Responsável pelos segredos do cofre de chaves.

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

    Ao adicionar um destino SQL, não insira o nome de logon real e a senha. Usando o exemplo anterior, você inserirá os nomes e os nomes de segredo 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 inspetor na função RBAC Usuário de segredos do cofre de chaves. Para seguir o princípio de privilégio mínimo, adicione essa atribuição de função para cada segredo, em vez de para todo o cofre. A página Controle de acesso (IAM) será exibida somente se o cofre estiver configurado para usar o modelo de permissão do RBAC.

Se você quiser usar credenciais de autenticação SQL diferentes em diferentes destinos do SQL, 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 você atualizar o valor do segredo para um nome de logon ou uma senha no cofre de chaves enquanto um inspetor estiver em execução, o inspetor se reconectará aos destinos usando as novas credenciais de autenticação SQL em 15 minutos. Se você quiser começar a usar as novas credenciais imediatamente, pare e reinicie o observador.

Conceder acesso ao armazenamento de dados

Para criar e gerenciar o esquema de banco de dados no armazenamento de dados e ingerir dados de monitoramento, um observador requer associaçã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 não requer 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 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 permitir acesso usando KQL.

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

Você pode 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 + Rede, selecione Permissões. Não use a página Permissões do cluster.
  2. Selecione Adicionar e escolha Administrador.
  3. Na página Novos Principais, 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.

Conceder acesso a um banco de dados do Azure Data Explorer usando 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 na Análise em Tempo Real ou em um cluster gratuito do Azure Data Explorer.

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

  2. No seguinte comando KQL de exemplo, substitua os três espaços reservados, conforme 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 da entidade de segurança de uma identidade gerenciada (uma GUID), encontrado na página Identidade do inspetor. 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 inspetor. Você pode encontrá-lo na página Visão Geral do Microsoft Entra ID no portal do Azure. Em vez do domínio primário do locatário, o valor de GUID da ID do locatário também pode ser utilizado.

    Esta parte do comando será 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 (junto com o ponto e vírgula anterior) pode ser omitido em um banco de dados de um cluster do Azure Data Explorer porque o cluster sempre está no mesmo locatário do Microsoft Entra ID que a identidade gerenciada do 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 do Kusto.

Como permitir acesso ao armazenamento de dados a usuários e grupos

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 na Análise em Tempo Real. Para conceder acesso, você deve ser membro da função RBAC Administrador no banco de dados.

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

Importante

Considere cuidadosamente seus requisitos de privacidade e segurança de dados ao conceder acesso para exibir os dados de monitoramento do SQL coletados por um observador.

Embora um observador 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 sessões ativas, metadados de índice, índices ausentes, estatísticas de tempo de execução de consulta, estatísticas de espera de consulta, estatísticas de sessão e metadados de tabela, podem conter dados potencialmente confidenciais, como nomes de tabela e índice, texto da consulta, valores de parâmetros de consulta, nomes de logon 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 eles 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 Permissões do cluster.
  2. Selecione Adicionar e escolha Visualizadores.
  3. Na página Novos Principais, digite o nome do usuário ou grupo na caixa de pesquisa.
  4. Selecione o usuário ou grupo.

Conceder acesso ao armazenamento de dados usando 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 comandos KQL de exemplo 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, consulte Controle de acesso baseado em função do 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 na Análise em Tempo Real e em clusters gratuitos do Azure Data Explorer.

Como 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 na Análise em Tempo Real no Fabric, o dimensionamento será gerenciado automaticamente.

Como dimensionar um cluster do Azure Data Explorer

Você pode dimensionar o cluster do Azure Data Explorer conforme necessário. Por exemplo, você pode reduzir seu cluster para a SKU Extra pequena, Dev/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 inspetor de banco de dados, o SKU de cluster de duas instâncias otimizado para computação e extra pequeno será suficiente por tempo indefinido. Em alguns casos, dependendo das alterações de configuração e carga de trabalho ao longo do tempo, talvez seja necessário dimensionar o cluster para garantir o desempenho adequado da consulta e manter a baixa latência de ingestão de dados.

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

Você precisará expandir o cluster (horizontalmente) ou escalá-lo (verticalmente) se observar um ou mais dos seguintes sintomas:

  • O desempenho da consulta ad hoc ou painel fica muito lento.
  • Você executa muitas consultas simultâneas no cluster e observa erros de limitaçã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 ao longo do 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 que abrangem intervalos de tempo mais longos, elas poderão ficar mais lentas com o passar do tempo à medida que a quantidade total de dados coletados aumenta e não se encaixa mais no armazenamento SSD local. O dimensionamento do cluster pode ser necessário para manter o desempenho adequado da consulta nesse caso.

  • Se você precisar dimensionar o 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 reduzir ou aumentar automaticamente o número de instâncias em resposta a alterações na carga de trabalho ou às tendências sazonais.

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

    • O dimensionamento vertical do cluster leva vários minutos. Durante esse processo, há um período de tempo de inatividade, que pode interromper a coleta de dados pelo observador. Se isso acontecer, interrompa e reinicie o 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 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 não bastam 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 funcionando após a atualização, siga estas etapas:

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

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 você não precisar de dados mais antigos, poderá configurar políticas de retenção de dados para purgá-los automaticamente. Por padrão, a retenção de dados é definida como 365 dias em um novo banco de dados em um cluster do Azure Data Explorer ou na Análise em Tempo Real.

  • 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 há limite máximo no período de retenção de dados.
  • Se você configurar diferentes períodos de retenção de dados para tabelas diferentes, os painéis 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 excluídos em outras tabelas para o mesmo intervalo de tempo.

O volume de dados de SQL Monitoring que é ingerido no armazenamento de dados depende das cargas de trabalho SQL e do tamanho da infraestrutura do 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 acesso no repositório de dados do inspetor

Com o tempo, a Microsoft pode 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 podem ser adicionadas automaticamente.

Para fazer isso, a identidade gerenciada atual de um observador precisa ser membro da função RBAC Administradores no armazenamento de dados. Revogar essa associação de função ou substituí-la por associação em qualquer outra função RBAC pode afetar a coleta de dados e o gerenciamento de esquemas e não tem suporte.

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 repositório de dados do inspetor. Você pode usar Consultas entre clusters e entre bancos de dados para consultar dados em seu 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 de um observador ao armazenamento de dados ou fazer alterações de esquema ou configuração de banco de dados que impactem a ingestão de dados, talvez seja necessário alterar o armazenamento de dados desse observador 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 com suporte.

Clusters do Azure Data Explorer Parados

Um cluster do Azure Data Explorer pode ser interrompido, por exemplo, para reduzir 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 poderá acontecer se você parar o inspetor que ingerir dados no único banco de dados no cluster e não executar nenhuma consulta nesse banco de dados.

Se você usar a opção padrão para criar um 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 pelo observador também será interrompida. Para retomar a coleta de dados, você precisa iniciar o cluster. Depois que o cluster estiver em execução, reinicie o observador.

Você pode desabilitar o comportamento da interrupção automática se quiser que o cluster permaneça disponível mesmo quando ele estiver inativo. Isso pode aumentar o custo do cluster.

Ingestão de streaming

O observador de banco de dados requer que o cluster do Explorador de Dados do Azure que contém o banco de dados de armazenamento tenha a 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 está habilitado na Análise em Tempo Real e no cluster gratuito do Azure Data Explorer.

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

Conectividade privada para 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 nos painéis ou consultar os dados diretamente. Esse ponto de extremidade privado é uma adição ao ponto de extremidade privado gerenciado criado para permitir que o inspetor ingira os 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 de uma VM do Azure, crie um ponto de extremidade privado para o cluster do Azure Data Explorer na rede virtual do Azure em que sua VM do Azure está implantada.

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

    1. Use o Gateway de VPN do Azure ou o Azure ExpressRoute para estabelecer uma conexão privada da rede local com uma rede virtual do Azure.
    2. Crie um ponto de extremidade privado para o cluster do Azure Data Explorer na rede virtual do Azure em que a conexão VPN ou ExpressRoute termina ou em outra rede virtual do Azure acessível pelo tráfego do seu computador local.
    3. Configure DNS para esse endpoint 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 um grande ambiente do Azure SQL, talvez seja necessário criar vários monitores.

Cada inspetor exige um banco de dados em um cluster do Azure Data Explorer ou na Análise em Tempo Real como o 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 a seguir podem ajudá-lo a fazer uma opção de design ideal 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 de toda a sua infraestrutura do SQL do Azure.
  • Os painéis de todos os observadores mostram todos os dados no repositório de dados, mesmo que os dados sejam coletados por outros observadores.
  • Os usuários com acesso ao repositório de dados têm acesso aos dados de monitoramento de toda a propriedade SQL do Azure.

Considerações para armazenamentos de dados separados:

  • Os subconjuntos de sua propriedade SQL do Azure são monitorados independentemente. Os painéis do observador 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 entre 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 na Análise em Tempo Real é gerenciado por banco de dados, você pode gerenciar o acesso aos dados de monitoramento para os subconjuntos de sua propriedade 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 o acesso à rede aos clusters do Azure Data Explorer, poderá colocar bancos de dados diferentes em clusters diferentes.

Conteúdo relacionado