Criar e gerenciar um cluster dedicado nos Logs do Azure Monitor

  • Artigo

A vinculação de um workspace do Log Analytics a um cluster dedicado no Azure Monitor fornece funcionalidades avançadas e maior utilização de consulta. Os clusters exigem um compromisso mínimo de ingestão de 100 GB por dia. Você pode vincular e desvincular workspaces de um cluster dedicado sem perda de dados ou interrupção do serviço.

Recursos avançados

Os recursos que exigem clusters dedicados são:

  • Chaves gerenciadas pelo cliente – Criptografe os dados de cluster usando chaves fornecidas e controladas por você.
  • Sistema de Proteção de Dados – Controle as solicitações de acesso dos engenheiros de suporte da Microsoft aos seus dados.
  • Criptografia dupla – Forneça proteção contra um cenário em que um dos algoritmos ou uma das chaves de criptografia pode ser comprometida. Nesse caso, a camada extra de criptografia continua protegendo seus dados.
  • Otimização entre consultas – as consultas entre workspaces são executadas mais rapidamente quando os workspaces estão no mesmo cluster.
  • Otimização de custos – Vincule seus workspaces na mesma região ao cluster para obter o desconto por nível de compromisso para todos os workspaces, mesmo para os que têm baixa ingestão que estão qualificados para o desconto por nível de compromisso.
  • Zonas de disponibilidade – Proteja seus dados contra falhas do datacenter, contando com datacenters em diferentes localizações físicas, equipadas com energia, resfriamento e rede independentes. Essa separação física em zonas e infraestrutura independente tornam um incidente muito menos provável, pois o workspace pode contar com os recursos de qualquer uma das zonas. As zonas de disponibilidade do Azure Monitor abrangem partes mais amplas do serviço e, quando disponíveis na sua região, estendem automaticamente a resiliência do Azure Monitor. O Azure Monitor cria clusters dedicados como habilitados para zonas de disponibilidade (isAvailabilityZonesEnabled: 'true') por padrão nas regiões com suporte. Atualmente, não há suporte para zonas de disponibilidade de clusters dedicados em todas as regiões.
  • Ingerir a partir de Hubs de Eventos do Azure: permite ingerir dados diretamente de um hub de eventos para um workspace do Log Analytics. O cluster dedicado permite que você use a funcionalidade quando a ingestão de todos os workspaces vinculados combinados atende ao nível de compromisso.

Modelo de preço do cluster

Os Clusters Dedicados do Log Analytics usam um modelo de preço de nível de compromisso de pelo menos 100 GB/dia. Qualquer uso acima do nível da camada gera custos com base na taxa por GB do respectivo nível de compromisso. Consulte os detalhes de preços dos Logs do Azure Monitor para obter detalhes de preços para clusters dedicados. As camadas de compromisso têm um período de compromisso de 31 dias a partir do momento em que uma camada de compromisso é selecionada.

Pré-requisitos

  • Os clusters dedicados exigem um compromisso mínimo de ingestão de 100 GB por dia.
  • Ao criar um cluster dedicado, não é possível nomeá-lo com o mesmo nome de um cluster que foi excluído nas últimas duas semanas.

Permissões necessárias

Para executar ações relacionadas ao cluster, você precisa ter estas permissões:

Ação Permissões ou função necessárias
Criar um cluster dedicado As permissões Microsoft.Resources/deployments/* e Microsoft.OperationalInsights/clusters/write, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Alterar propriedades do cluster As permissões Microsoft.OperationalInsights/clusters/write, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Vincular workspaces a um cluster As permissões Microsoft.OperationalInsights/clusters/write, Microsoft.OperationalInsights/workspaces/write e Microsoft.OperationalInsights/workspaces/linkedservices/write conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Verificar o status de vinculação do workspace As permissões Microsoft.OperationalInsights/workspaces/read para os workspaces, conforme fornecidas pela função integrada Leitor do Log Analytics, por exemplo
Obter clusters ou verificar o status de provisionamento de um cluster As permissões Microsoft.OperationalInsights/clusters/read, conforme fornecidas pela função interna do Leitor do Log Analytics, por exemplo
Atualizar a camada de compromisso ou billingType em um cluster As permissões Microsoft.OperationalInsights/clusters/write, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Conceder as permissões necessárias Função Proprietário ou Colaborador que tenha permissões */write ou uma função interna de Colaborador do Log Analytics que tenha permissões Microsoft.OperationalInsights/*
Desvincular um workspace do cluster As permissões Microsoft.OperationalInsights/workspaces/linkedServices/delete, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo
Excluir um cluster dedicado As permissões Microsoft.OperationalInsights/clusters/delete, conforme fornecidas pela função interna do Colaborador do Log Analytics, por exemplo

Para obter mais informações sobre as permissões do Log Analytics, confira Gerenciar o acesso a dados de log e workspaces no Azure Monitor.

Criar um cluster dedicado

Informe as seguintes propriedades ao criar um cluster dedicado:

  • ClusterName: deve ser exclusivo para o grupo de recursos.
  • ResourceGroupName: use um grupo de recursos de TI central, porque muitas equipes da organização costumam compartilhar clusters. Para ver mais considerações de design, examine Como criar uma configuração de workspace do Log Analytics.
  • Localidade
  • SkuCapacity: você pode definir o nível de compromisso para 100, 200, 300, 400, 500, 1.000, 2.000, 5.000, 10.000, 25.000, 50.000 GB por dia. O nível de compromisso mínimo com suporte na CLI atualmente é de 500. Use REST para configurar níveis de compromisso mais baixos com um mínimo de 100. Para obter mais informações sobre os custos do cluster, consulte Dedicar clusters.
  • Identidade gerenciada: os clusters dão suporte a dois tipos de identidade gerenciada:

    • Identidade gerenciada atribuída pelo sistema – Gerada automaticamente com a criação do cluster quando o type de identidade é definido como "SystemAssigned". Essa identidade pode ser usada posteriormente para conceder acesso de armazenamento à sua Key Vault para operações de encapsulamento e desencapsulamento.

      Identidade na chamada REST do cluster

      {
  "identity": {
    "type": "SystemAssigned"
    }
}

    • Identidade gerenciada atribuída pelo usuário – Permite configurar a chave gerenciada pelo cliente na criação do cluster, ao conceder a ela permissões no Key Vault antes da criação do cluster.

      Identidade na chamada REST do cluster

      {
"identity": {
  "type": "UserAssigned",
    "userAssignedIdentities": {
      "subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.ManagedIdentity/UserAssignedIdentities/<cluster-assigned-managed-identity>"
    }
  }  
}

Depois de criar o recurso de cluster, edite propriedades como sku, *keyVaultProperties ou billingType. Veja mais detalhes abaixo.

Os clusters excluídos levam duas semanas para serem completamente removidos. Você pode ter até sete clusters por assinatura e região, cinco ativos e dois excluídos nas últimas duas semanas.

Observação

A criação do cluster dispara a alocação de recursos e o provisionamento. Essa operação pode demorar algumas horas para ser concluída. O cluster dedicado é cobrado depois de provisionado, independentemente da ingestão de dados, e é recomendável preparar a implantação para agilizar o link de provisionamento e workspaces para o cluster. Verifique o seguinte:

  • Uma lista do workspace inicial a ser vinculado ao cluster é identificada
  • Você tem permissões para assinatura destinadas ao cluster e a qualquer workspace a ser vinculado

N/D

Verificar o status do provisionamento do cluster

O provisionamento do cluster do Log Analytics leva algum tempo para ser concluído. Use um dos seguintes métodos para verificar a propriedade ProvisioningState. O valor é ProvisioningAccount durante o provisionamento e Succeeded quando concluído.

N/D

Observação

  • A vinculação de um workspace só pode ser executada após a conclusão do provisionamento de cluster do Log Analytics.
  • Vincular um workspace a um cluster envolve a sincronização de vários componentes de back-end e hidratação de cache, o que pode levar até duas horas.
  • Ao vincular um workspace do Log Analytics, o plano de cobrança do workspace foi alterado para LACluster e você deve remover o SKU no modelo de workspace para evitar conflitos durante a implantação do workspace.
  • Além dos aspectos de cobrança regidos pelo plano de cluster, todas as configurações do workspace e os aspectos de consulta permanecem inalterados durante e após o link.

Você precisa ter permissões de 'gravação' no workspace e o recurso de cluster para a operação de vinculação do workspace:

  • No workspace: Microsoft.OperationalInsights/workspaces/write
  • No recurso de cluster: Microsoft.OperationalInsights/clusters/write

Quando um workspace do Log Analytics é vinculado a um cluster dedicado, novos dados enviados para o workspace são ingeridos para seu cluster dedicado, enquanto os dados ingeridos anteriormente permanecem no cluster do Log Analytics. A vinculação de um workspace não tem efeito sobre a operação do workspace, incluindo a ingestão e as experiências de consulta. O mecanismo de consulta do Log Analytics costura dados de clusters antigos e novos automaticamente, e os resultados das consultas são completos.

Quando o cluster dedicado é configurado com a chave gerenciada pelo cliente (CMK), novos dados ingeridos são criptografados com a sua chave, enquanto os dados mais antigos permanecem criptografados com a chave gerenciada pela Microsoft (MMK). A configuração de chave é abstraída pelo Log Analytics e a consulta entre criptografias de dados antigas e novas é executada perfeitamente.

Um cluster pode ser vinculado a até 1.000 workspaces localizados na mesma região com o cluster. Um workspace não pode ser vinculado a um cluster mais de duas vezes por mês, para evitar a fragmentação de dados.

O workspace e o cluster podem estar em assinaturas diferentes. É possível que o workspace e o cluster sejam em locatários diferentes quando o Azure Lighthouse é usado para mapear ambos para um só locatário.

Use as seguintes etapas para vincular um workspace a um cluster. Você pode usar automação para vincular vários workspaces:

N/D

Quando um cluster é configurado com chaves gerenciadas pelo cliente, os dados ingeridos nos workspaces após a conclusão da operação de vinculação são armazenados de maneira criptografada com sua chave gerenciada. A operação de link do workspace pode levar até 90 minutos para ser concluída e você pode verificar o estado enviando solicitação Get para o workspace e observar se a propriedade clusterResourceId está presente na resposta em recursos.

  1. Abra o menu Workspaces do Log Analytics e selecione seu workspace.
  2. Na página Visão geral, selecione Exibição JSON.

Alterar propriedades do cluster

Depois que você criar o recurso de cluster e ele estiver totalmente provisionado, edite as propriedades do cluster usando a CLI, o PowerShell ou a API REST. As propriedades que você poderá definir depois que o cluster for provisionado incluem:

  • keyVaultProperties – contém a chave no Azure Key Vault com os seguintes parâmetros: KeyVaultUri, KeyName, KeyVersion. Confira Atualizar cluster com detalhes do identificador de chave.
  • Identidade – a identidade usada para autenticar o Key Vault. Pode ser atribuída pelo sistema ou pelo usuário.
  • billingType – atribuição de cobrança para o recurso de cluster e seus dados. Inclui os seguintes valores:
    • Cluster (padrão): os custos do cluster são atribuídos ao recurso de cluster.
    • Workspaces: os custos do cluster são atribuídos proporcionalmente aos workspaces no cluster, com o recurso de cluster sendo cobrado por parte do uso se o total de dados ingeridos por dia está abaixo do nível de compromisso. Confira Clusters Dedicados do Log Analytics para saber mais sobre o modelo de preço do cluster.

Importante

A atualização do cluster não deve incluir os detalhes do identificador da chave e da identidade na mesma operação. Se você precisar atualizar ambos, a atualização deverá ocorrer em duas operações consecutivas.

Observação

Não há suporte para a propriedade billingType na CLI.

Obter todos os clusters no grupo de recursos

N/D

Obter todos os clusters na assinatura

N/D

Atualizar o nível de compromisso no cluster

Quando o volume de dados nos workspaces vinculados mudar ao longo do tempo, você pode atualizar o Nível de Compromisso adequadamente para otimizar o custo. O nível é especificado em unidades de Gigabytes (GB) e pode ter valores de 100, 200, 300, 400, 500, 1.000, 2.000, 5.000, 10.000, 25.000, 50.000 GB por dia. Você não precisa fornecer o corpo da solicitação REST completa, mas precisa incluir o SKU.

Durante o período de compromisso, você pode alterar para um nível de compromisso mais alta, que reinicia o período de compromisso de 31 dias. Você não pode voltar para o pagamento conforme o uso ou para um nível de compromisso inferior até terminar o período de compromisso.

N/D

Atualizar billingType no cluster

A propriedade billingType determina a atribuição de cobrança para o cluster e seus dados:

  • Cluster (padrão) – a cobrança é atribuída ao recurso de cluster
  • Workspaces – a cobrança é atribuída aos workspaces vinculados proporcionalmente. Quando o volume de dados de todos os workspaces vinculados está abaixo do Nível de Compromisso, a fatura do volume restante é atribuída ao cluster

N/D

Você pode desvincular um workspace de um cluster a qualquer momento. O tipo de preço do workspace é alterado para por GB, os dados são ingeridos no cluster antes que a operação de desvinculação permaneça no cluster e novos dados para o workspace são ingeridos no Log Analytics.

Aviso

Desvincular um workspace não move os dados do workspace para fora do cluster. Todos os dados coletados para o workspace enquanto estiverem vinculados ao cluster, permanecerão no cluster durante o período de retenção definido no workspace e poderão ser acessados desde que o cluster não seja excluído.

As consultas não são afetadas quando o workspace está desvinculado e o serviço executa consultas entre clusters perfeitamente. Se o cluster tiver sido configurado com a Chave gerenciada pelo cliente (CMK), os dados ingeridos no workspace enquanto vinculados continuam criptografados e acessíveis com sua chave, enquanto a chave e as permissões para o Key Vault permanecerem.

Observação

  • Há um limite de duas operações de vinculação para um workspace específico dentro de um mês para impedir a distribuição de dados entre clusters. Entre em contato com o suporte se você atingir o limite.
  • Workspaces desvinculados são movidos para o tipo de preço Pagamento Conforme o Uso.

Use os seguintes comandos para desvincular um workspace do cluster:

N/D

Excluir cluster

Você precisa ter permissões de gravação no recurso de cluster.

A operação de exclusão de cluster deve ser feita com cuidado, pois a operação não é recuperável. Todos os dados ingeridos no cluster por meio de workspaces vinculados são excluídos permanentemente.

A cobrança do cluster é interrompida quando excluída, independentemente do nível de compromisso de 31 dias definido no cluster.

Se você excluir um cluster que tenha workspaces vinculados, eles serão desvinculados automaticamente do cluster, os workspaces serão movidos para o tipo de preço pagamento conforme o uso e novos dados para workspaces serão ingeridos para clusters do Log Analytics. Você poderá consultar o workspace para o intervalo de tempo antes do link para o cluster e após a desvinculação, e o serviço executará consultas entre clusters perfeitamente.

Observação

  • Há um limite de sete clusters por assinatura e região, cinco ativos e dois excluídos nas últimas duas semanas.
  • O nome do cluster permanece reservado por duas semanas após a exclusão e não pode ser usado para criar um novo cluster.

Use os seguintes comandos para excluir um cluster:

N/D

Limites e restrições

  • É possível criar um máximo de cinco clusters ativos em cada região e assinatura.

  • No máximo, sete clusters são permitidos por assinatura e região, cinco ativos e dois excluídos nas duas últimas semanas.

  • No máximo 1.000 workspaces do Log Analytics podem ser vinculados a um cluster.

  • Um máximo de duas operações de vinculação de workspace em um workspace específico é permitido no período de 30 dias.

  • No momento, não há suporte para mover o cluster para outro grupo de recursos ou assinatura.

  • Não há suporte para a movimentação de um cluster para outra região.

  • A atualização do cluster não deve incluir os detalhes do identificador da chave e da identidade na mesma operação. Se você precisar atualizar ambos, a atualização deverá ocorrer em duas operações consecutivas.

  • No momento, o Sistema de Proteção de Dados não está disponível na China.

  • A criptografia dupla é configurada automaticamente para clusters criados a partir de outubro de 2020 em regiões com suporte. Para verificar se o cluster está configurado para criptografia dupla, envie uma solicitação GET ao cluster e observe se o valor isDoubleEncryptionEnabled é true para clusters com criptografia dupla habilitada.

    • Se você criar um cluster e receber um erro "Nome-da-região não dá suporte à criptografia dupla para clusters.", ainda poderá criar o cluster sem criptografia dupla adicionando "properties": {"isDoubleEncryptionEnabled": false} ao corpo da solicitação REST.
    • A configuração de criptografia dupla não pode ser alterada após a criação do cluster.

  • A exclusão de um workspace vinculado é permitida enquanto ele está vinculado ao cluster. Se você decidir recuperar o workspace durante o período de exclusão temporária, ele retornará ao estado anterior e permanecerá vinculado ao cluster.

  • Durante o período de compromisso, você pode alterar para um nível de compromisso mais alta, que reinicia o período de compromisso de 31 dias. Você não pode voltar para o pagamento conforme o uso ou para um nível de compromisso inferior até terminar o período de compromisso.

Solução de problemas

  • Se você receber um erro de conflito ao criar um cluster, ele pode ter sido excluído nas últimas duas semanas e ainda estar em processo de exclusão. O nome do cluster permanece reservado durante o período de exclusão e você não poderá criar outro cluster com esse nome.

  • Atualizações do cluster, enquanto ele estiver no estado de provisionamento ou de atualização, falharão.

  • Algumas operações são longas e podem demorar um pouco para serem concluídas. Elas incluem: criação de cluster, atualização de chave de cluster e exclusão de cluster. Você pode verificar o status da operação enviando solicitação GET ao cluster ou workspace e observar a resposta. Por exemplo, um workspace desvinculado não terá clusterResourceId em recursos.

  • Se você tentar vincular um workspace do Log Analytics que já esteja vinculado a outro cluster, ocorrerá uma falha na operação.

Mensagens de erro

Criação de Cluster

  • 400 – O nome do cluster não é válido. O nome do cluster pode conter caracteres de a-z, A-Z, 0-9 e ter comprimento de 3-63.
  • 400 – O corpo da solicitação é nulo ou está em formato inadequado.
  • 400 – O nome do SKU é inválido. Defina o nome do SKU como capacityReservation.
  • 400 – A capacidade foi fornecida, mas o SKU não é capacityReservation. Defina o nome do SKU como capacityReservation.
  • 400 – Capacidade ausente no SKU. Defina o valor da capacidade como 100, 200, 300, 400, 500, 1.000, 2.000, 5.000, 10.000, 25.000, 50.000 GB por dia.
  • 400 – A capacidade está bloqueada por 30 dias. A redução da capacidade é permitida 30 dias após a atualização.
  • 400 – Nenhum SKU definido. Defina o nome da SKU como capacityReservation e o valor da capacidade como 100, 200, 300, 400, 500, 1.000, 2.000, 5.000, 10.000, 25.000, 50.000 GB por dia.
  • 400 – Identidade nula ou vazia. Defina identidade com o tipo systemAssigned.
  • 400 – As KeyVaultProperties foram definidas na criação. Atualize KeyVaultProperties após a criação do cluster.
  • 400 – A operação não pode ser executada agora. A operação assíncrona está em um estado diferente de bem-sucedido. O cluster precisa concluir a operação antes que uma atualização seja executada.

Atualização do cluster

  • 400 – O cluster está em estado de exclusão. A operação assíncrona está em andamento. O cluster precisa concluir a operação antes que uma atualização seja executada.
  • 400 – KeyVaultProperties não está vazio, mas tem um formato inválido. Confira a atualização do identificador de chave.
  • 400 – Falha ao validar a chave no Key Vault. Pode ser que faltem permissões ou que a chave não exista. Verifique se você definiu a política de acesso e chave no Key Vault.
  • 400 – A chave não pode ser recuperada. Key Vault precisa ser definido como exclusão reversível e proteção de limpeza. Confira a documentação do Key Vault
  • 400 – A operação não pode ser executada agora. Espere pela conclusão da operação assíncrona e tente de novo.
  • 400 – O cluster está em estado de exclusão. Espere pela conclusão da operação assíncrona e tente de novo.

Obtenção de Cluster

  • 404 – Cluster não encontrado. Ele pode ter sido excluído. Se você tentar criar um cluster com esse nome e ocorrer um conflito, significa que o cluster está em processo de exclusão.

Exclusão de cluster

  • 409 – Não é possível excluir um cluster no estado de provisionamento. Espere pela conclusão da operação assíncrona e tente de novo.
  • 404 – Workspace não encontrado. O workspace especificado não existe ou foi excluído.
  • 409 – Operação de vinculação ou desvinculação do workspace em andamento.
  • 400 – Cluster não encontrado. O cluster especificado não existe ou foi excluído.
  • 404 – Workspace não encontrado. O workspace especificado não existe ou foi excluído.
  • 409 – Operação de vinculação ou desvinculação do workspace em andamento.

Próximas etapas