Criar configurações de diagnóstico para enviar métricas de plataforma e logs do Azure Monitor para destinos diferentes

Este artigo fornece detalhes de como criar e definir configurações de diagnóstico para enviar métricas de plataforma e logs de plataforma para diferentes destinos.

As métricas de plataforma são enviadas automaticamente e sem configuração para métricas do Azure Monitor.

Os logs de plataforma, incluindo logs de recursos e log de atividades do Azure, apresentam informações detalhadas de diagnóstico e auditoria para recursos do Azure e para a plataforma do Azure da qual eles dependem. O Log de Atividades existe por conta própria, mas pode ser roteado para outros locais. Os logs de recursos não são coletados até que sejam roteados para um destino.

Cada recurso do Azure requer sua própria configuração de diagnóstico, o que define os seguintes critérios:

  • Fontes – o tipo de dados de log e métrica a ser enviado aos destinos definidos na configuração. Os tipos disponíveis variam de acordo com o tipo de recurso.
  • Destinos - um ou mais destinos para envio.

Uma única configuração de diagnóstico pode definir apenas um de cada um dos destinos. Se você quiser enviar dados para mais de um tipo de destino específico (por exemplo, dois workspaces do Log Analytics diferentes), crie várias configurações. Cada recurso pode ter até cinco configurações de diagnóstico.

O vídeo a seguir orienta você a como fazer o roteamento de logs da plataforma com configurações de diagnóstico.

Origens

Aqui estão as opções de fontes.

Métricas

A configuração AllMetrics encaminha as métricas de plataforma de um recurso para destinos adicionais. Essa opção pode não estar presente para todos os provedores de recursos.

Logs

Com os logs, você pode selecionar as categorias de log que deseja rotear individualmente ou escolher um grupo de categorias.

Observação

Os grupos de categorias não se aplicam às métricas. Nem todos os recursos têm grupos de categorias disponíveis.

Os grupos de categorias permitem coletar dinamicamente logs de recursos com base em grupos predefinidos em vez de selecionar categorias de log individuais. A Microsoft define os grupos para ajudar a monitorar casos de uso específicos em todos os serviços do Azure. Ao longo do tempo, as categorias no grupo podem ser atualizadas conforme novos logs são lançados ou conforme as avaliações mudam. Quando categorias de logs são adicionadas ou removidas de um grupo de categorias, sua coleção de logs é modificada automaticamente sem a necessidade de atualizar as configurações de diagnóstico.

Ao usar grupos de categorias, você:

  • Não pode mais selecionar individualmente logs de recursos com base em tipos de categoria individuais
  • Não pode mais aplicar configurações de retenção aos logs enviados ao Armazenamento do Microsoft Azure

Atualmente, há dois grupos de categorias:

  • Todos – cada log de recursos oferecido pelo recurso.
  • Auditoria – todos os logs de recursos que registram interações do cliente com os dados ou as configurações do serviço.

Destinos

Os logs e as métricas da plataforma podem ser enviados para os destinos da tabela a seguir.

Destino Descrição
Espaço de Trabalho do Log Analytics As métricas são convertidas no formulário de log. Essa opção pode não estar disponível para todos os tipos de recurso. Ao enviá-las para o repositório de Logs do Azure Monitor (que é pesquisável via Log Analytics) ajuda a integrá-las em consultas, alertas e visualizações com dados de log existentes.
Conta de Armazenamento do Azure O arquivamento de logs e métricas para uma conta de armazenamento do Azure é útil para auditoria, análise estática ou backup. Em comparação aos logs do Azure Monitor e um workspace do Log Analytics, o armazenamento do Azure é menos dispendioso e os logs podem ser mantidos indefinidamente.
Hubs de Evento O envio de logs e métricas para o Hubs de Eventos permite transmitir dados para sistemas externos, como SIEMs de terceiros e outras soluções do Log Analytics.
Integrações de parceiros do Azure Monitor Integrações especializadas entre o Azure Monitor e outras plataformas de monitoramento que não sejam da Microsoft. Útil quando você já está usando um dos parceiros.

Requisitos e limitações

Métricas como fonte

Há determinadas limitações na exportação de métricas.

  • No momento, não há suporte para o envio de métricas multidimensionais por meio de configurações de diagnóstico – as métricas com dimensões são exportadas como métricas unidimensionais niveladas, agregadas entre valores de dimensão. Por exemplo: a métrica “IOReadBytes” em um Blockchain pode ser explorada e plotada em um nível por nó. No entanto, quando exportada por meio de configurações de diagnóstico, a métrica é representada como todos os bytes de leitura de todos os nós.
  • Nem todas as métricas são exportáveis com configurações de diagnóstico – devido a limitações internas, nem todas as métricas são exportáveis para os Logs do Azure Monitor/Log Analytics. Para obter mais informações, consulte a coluna exportável na lista de métricas com suporte

Para contornar essas limitações para métricas específicas, sugerimos extraí-las manualmente usando a API REST de métricas e importá-las em Logs do Azure Monitor usando a API do coletor de dados do Azure Monitor.

Log de atividades como uma fonte

Importante

Antes de criar uma configuração de diagnóstico para o log de atividades, você deve desabilitar qualquer configuração herdada. Confira Métodos de coleção herdados para obter detalhes.

Limitações de destino

Todos os destinos para a configuração de diagnósticos devem ser criados antes da criação das configurações de diagnóstico. O destino não precisa estar na mesma assinatura que o recurso que envie os logs, contanto que o usuário que define a configuração tenha acesso RBAC do Azure apropriado a ambas as assinaturas. Com o Azure Lighthouse, também é possível enviar configurações de diagnóstico para um workspace em outro locatário do Azure Active Directory. A tabela a seguir fornece requisitos exclusivos para cada destino, incluindo quaisquer restrições regionais.

Destino Requisitos
Espaço de trabalho do Log Analytics O workspace não precisa estar na mesma região que o recurso sendo monitorado.
Conta de Armazenamento do Azure Não use uma conta de armazenamento existente que tenha outros dados armazenados sem monitoramento, assim você pode controlar melhor o acesso aos dados. Porém, caso esteja arquivando o Log de atividades e os logs de recursos juntos, você poderá optar por usar a mesma conta de armazenamento para manter todos os dados de monitoramento em um local central.

Para enviar os dados para o armazenamento imutável, defina a política imutável para a conta de armazenamento, conforme descrito em Definir e gerenciar políticas de imutabilidade para o armazenamento de blobs. Você deve seguir todas as etapas deste artigo, incluindo a habilitação de gravações de blobs de acréscimo protegidos.

A conta de armazenamento precisa estar na mesma região que o recurso sendo monitorado se o recurso for regional.
Hubs de Eventos A política de acesso compartilhado do namespace define as permissões que o mecanismo de streaming tem. O streaming para Hubs de Eventos exige as permissões Gerenciar, Enviar e Escutar. Para atualizar a configuração de diagnóstico para incluir o streaming, você deve ter a permissão ListKey nessa regra de autorização de Hubs de Eventos.

O namespace do hub de eventos precisa estar na mesma região que o recurso sendo monitorado se o recurso for regional.

As configurações de diagnóstico não pode acessar recursos do Hubs de Eventos quando as redes virtuais estão habilitadas. Você precisa habilitar a opção Permitir serviços confiáveis da Microsoft para ignorar essa configuração de firewall no Hub de Eventos para que o serviço do Azure Monitor (Configurações de Diagnóstico) obtenha acesso aos seus recursos do Hubs de Eventos.
Integrações de parceiro Varia de acordo com o parceiro. Confira a documentação de integração de parceiros do Azure Monitor para obter detalhes.

Azure Data Lake Storage Gen2 como um destino

Observação

Atualmente, contas de Azure Data Lake Storage Gen2 não são compatíveis como destino para configurações de diagnóstico, embora elas possam estar listadas como uma opção válida na portal do Azure.

Criar no portal do Azure

Você pode definir as configurações de diagnóstico no portal do Azure no menu do Azure Monitor ou no menu do recurso.

  1. O ponto no qual você define as configurações de diagnóstico no portal do Azure depende do recurso.

    • Para um único recurso, clique em Configurações de diagnóstico em Monitor no menu do recurso.

      Captura de tela da seção Monitoramento de um menu de recursos no portal do Azure com as Configurações de diagnóstico realçadas.

    • Para um ou mais recursos, clique em Configurações de diagnóstico em Configurações no menu Azure Monitor e clique no recurso.

      Captura de tela da seção Configurações no menu Azure Monitor com Configurações de diagnóstico realçadas.

    • Para o Log de atividades, clique no Log de atividades no menu Azure Monitor e, depois, em Configurações de diagnóstico. Desabilite qualquer configuração herdada para o Log de atividades. Confira Desabilitar configurações existentes para obter detalhes.

      Captura de tela do menu do Azure Monitor com o Log de atividades selecionado e as Configurações de diagnóstico realçadas na barra de menus do Log de atividades do monitor.

  2. Se nenhuma configuração existir no recurso que você selecionou, será solicitada a criação de uma configuração. Clique em Adicionar configuração de diagnóstico.

    Adicionar configuração de diagnóstico - nenhuma configuração existente

    Caso haja configurações existentes no recurso, você verá uma lista de configurações já definidas nesse recurso. Clique em Adicionar configuração de diagnóstico para adicionar uma nova configuração ou Editar configuração para editar uma existente. Cada configuração não pode ter mais de um de cada um dos tipos de destino.

    Adicionar configuração de diagnóstico - configurações existentes

  3. Dê um nome à sua configuração se ela ainda não tiver uma.

    Adicionar uma nova configuração de diagnóstico

  4. Logs e métricas a rotear – para logs, escolha um grupo de categorias ou marque as caixas individuais para cada categoria de dados que você deseja enviar para os destinos especificados posteriormente. A lista de categorias varia para cada serviço do Azure. Escolha allMetrics se quiser armazenar métricas nos Logs do Azure Monitor também.

  5. Detalhes de destino – marque a caixa para cada destino. Ao marcar cada caixa, as opções aparecem para permitir que você adicione outras informações.

    Enviar para o Log Analytics ou para os Hubs de Eventos

    1. Log Analytics – insira a assinatura e o workspace. Caso você não tenha um workspace, precisará criar um antes de prosseguir.

    2. Hubs de Eventos – especifique os seguintes critérios:

      • A assinatura da qual o hub de eventos faz parte
      • O namespace do Hub de Eventos – caso você ainda não tenha um, precisará criá-lo
      • Um nome de Hub de Eventos (opcional) para o qual enviar todos os dados. Se você não especificar um nome, um hub de eventos será criado para cada categoria de log. Se você estiver enviando várias categorias, talvez seja interessante especificar um nome para limitar o número de hubs de eventos criados. Confira Limites e cotas dos Hubs de Eventos do Azure para obter detalhes.
      • Uma política de Hub de Eventos (opcional) – uma política define as permissões do mecanismo de streaming. Para obter mais informações, confira Recursos dos Hubs de Eventos.
    3. Armazenamento – escolha a assinatura, a conta de armazenamento e a política de retenção.

      Enviar para o armazenamento

      Dica

      Considere definir a política de retenção como 0 e use a política de ciclo de vida de Armazenamento do Azure ou exclua seus dados do armazenamento usando um trabalho agendado. Essas estratégias provavelmente fornecerão um comportamento mais consistente.

      Em primeiro lugar, se você estiver usando o armazenamento para arquivamento, geralmente é porque você quer ter seus dados por mais de 365 dias. Em segundo lugar, se você escolher uma política de retenção maior que 0, a data de validade será anexada aos logs no momento do armazenamento. Não é possível alterar a data desses logs depois de armazenados. Por exemplo, se você definir a política de retenção de WorkflowRuntime como 180 dias e, 24 horas depois, defini-la como 365 dias, os logs armazenados durante essas primeiras 24 horas serão excluídos automaticamente após 180 dias, enquanto todos os logs subsequentes do tipo serão excluídos automaticamente após 365 dias. A alteração posterior da política de retenção não faz com que os logs das primeiras 24 horas sejam mantidos por 365 dias.

    4. Integração de parceiros - você deve primeiro instalar uma integração de parceiro em sua assinatura. As opções de configuração variam de acordo com o parceiro. Para saber mais, consulte Integrações de Parceiros do Azure Monitor.

  6. Clique em Salvar.

Após alguns instantes, a nova configuração aparece na lista de configurações desse recurso, e os logs de diagnóstico serão enviados para os destinos especificados assim que os novos dados de evento forem gerados. Podem se passar até 15 minutos entre o momento em que um evento é emitido e o momento em que ele aparece no workspace do Log Analytics.

Criar usando o PowerShell

Use o cmdlet Set-AzDiagnosticSetting para criar uma configuração de diagnóstico com o Azure PowerShell. Confira a documentação deste cmdlet para obter descrições de seus parâmetros.

Importante

Você não pode usar esse método para o Log de atividades do Azure. Em vez disso, use Criar uma configuração de diagnóstico no Azure Monitor usando um modelo do Resource Manager para criar um modelo do Resource Manager e implantá-lo com o PowerShell.

A seguir, há um exemplo de cmdlet do PowerShell para criar uma configuração de diagnóstico usando todos os três destinos.

Set-AzDiagnosticSetting -Name KeyVault-Diagnostics -ResourceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.KeyVault/vaults/mykeyvault -Category AuditEvent -MetricCategory AllMetrics -Enabled $true -StorageAccountId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount -WorkspaceId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/oi-default-east-us/providers/microsoft.operationalinsights/workspaces/myworkspace  -EventHubAuthorizationRuleId /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.EventHub/namespaces/myeventhub/authorizationrules/RootManageSharedAccessKey

Criar usando a CLI do Azure

Use o comando az monitor diagnostic-settings create para criar uma configuração do diagnóstico com a CLI do Azure. Confira a documentação desse comando para obter descrições de seus parâmetros.

Importante

Você não pode usar esse método para o Log de atividades do Azure. Em vez disso, use Criar uma configuração de diagnóstico no Azure Monitor usando um modelo do Resource Manager para criar um modelo do Resource Manager e implantá-lo com a CLI.

A seguir, há um exemplo de comando da CLI para criar uma configuração de diagnóstico usando todos os três destinos. A sintaxe fica ligeiramente diferente conforme o cliente.

az monitor diagnostic-settings create  ^
--name KeyVault-Diagnostics ^
--resource /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.KeyVault/vaults/mykeyvault ^
--logs    "[{""category"": ""AuditEvent"",""enabled"": true}]" ^
--metrics "[{""category"": ""AllMetrics"",""enabled"": true}]" ^
--storage-account /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount ^
--workspace /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myresourcegroup/providers/microsoft.operationalinsights/workspaces/myworkspace ^
--event-hub-rule /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/myresourcegroup/providers/Microsoft.EventHub/namespaces/myeventhub/authorizationrules/RootManageSharedAccessKey

Criar usando o modelo do Resource Manager

Confira Exemplos de modelo do Resource Manager para configurações de diagnóstico no Azure Monitor para criar ou atualizar configurações de diagnóstico com um modelo do Resource Manager.

Criar usando a API REST

Confira Configurações de diagnóstico para criar ou atualizar as configurações de diagnóstico usando a API REST do Azure Monitor.

Criar em escala usando o Azure Policy

Como uma configuração de diagnóstico precisa ser criada para cada recurso do Azure, o Azure Policy pode ser usado para criar automaticamente uma configuração de diagnóstico à medida que cada recurso é criado. Cada tipo de recurso do Azure tem um conjunto exclusivo de categorias que precisam ser listadas na configuração de diagnóstico. Por isso, cada tipo de recurso requer uma definição de política separada. Alguns tipos de recursos têm definições de política integrada que podem ser atribuídas sem modificação. Para outros tipos de recursos, é preciso criar uma definição personalizada.

Com a adição de grupos de categorias de log de recursos, agora você pode escolher opções que são atualizadas dinamicamente conforme as categorias de log mudam. Para obter mais informações, consulte as fontes de configurações de diagnóstico listadas anteriormente neste artigo.

Definições de política internas para o Azure Monitor

Há duas definições de política integrada para cada tipo de recurso: uma para o envio a um espaço de trabalho do Log Analytics e outra para o envio a um hub de eventos. Se você precisar de apenas um local, atribua essa política para o tipo de recurso. Se você precisar de ambos, atribua as duas definições de política para o recurso.

Por exemplo, a imagem a seguir mostra as definições de política de configuração de diagnóstico integradas para o Azure Data Lake Analytics.

Captura de tela parcial da página de definições do Azure Policy mostrando duas definições de política de configuração de diagnóstico integradas para o Data Lake Analytics.

Definições de políticas personalizadas

Para tipos de recursos que não têm uma política integrada, crie uma definição de política personalizada. Faça isso manualmente no portal do Azure, copiando uma política integrada existente e modificando-a para o seu tipo de recurso. No entanto, é mais eficiente, criar a política programaticamente usando um script na Galeria do PowerShell.

O script Create-AzDiagPolicy cria arquivos de política para um tipo de recurso específico que pode ser instalado usando o PowerShell ou a CLI do Azure. Use o procedimento a seguir para criar uma definição de política personalizada para configurações de diagnóstico:

  1. Verifique se o Azure PowerShell está instalado.

  2. Instale o script usando o comando a seguir:

    Install-Script -Name Create-AzDiagPolicy
    
  3. Execute o script usando os parâmetros para especificar para onde enviar os logs. Será necessário especificar uma assinatura e um tipo de recurso.

    Por exemplo, para criar uma definição de política que envia logs para um espaço de trabalho do Log Analytics e um hub de eventos, use o comando a seguir:

    Create-AzDiagPolicy.ps1 -ExportLA -ExportEH -ExportDir ".\PolicyFiles"  
    

    Como alternativa, especifique uma assinatura e um tipo de recurso no comando. Por exemplo, para criar uma definição de política que envia logs para um espaço de trabalho do Log Analytics e um hub de eventos para bancos de dados SQL Server, use o comando a seguir:

    Create-AzDiagPolicy.ps1 -SubscriptionID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -ResourceType Microsoft.Sql/servers/databases  -ExportLA -ExportEH -ExportDir ".\PolicyFiles"  
    
  4. O script cria pastas separadas para cada definição de política. Cada pasta contém três arquivos denominados azurepolicy.json, azurepolicy.rules.json e a azurepolicy.parameters.json. Para criar a política manualmente no portal do Azure, copie e cole o conteúdo de azurepolicy.json, porque ele inclui toda a definição de política. Use os outros dois arquivos com o PowerShell ou a CLI do Azure para criar a definição de política em uma linha de comando.

    Os exemplos a seguir mostram como instalar a definição de política pelo PowerShell e pela CLI do Azure. Cada exemplo inclui metadados para especificar uma categoria de Monitoramento para agrupar a nova definição de política com as definições de política integradas.

    New-AzPolicyDefinition -name "Deploy Diagnostic Settings for SQL Server database to Log Analytics workspace" -policy .\Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.rules.json -parameter .\Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.parameters.json -mode All -Metadata '{"category":"Monitoring"}'
    
    az policy definition create --name 'deploy-diag-setting-sql-database--workspace' --display-name 'Deploy Diagnostic Settings for SQL Server database to Log Analytics workspace'  --rules 'Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.rules.json' --params 'Apply-Diag-Settings-LA-Microsoft.Sql-servers-databases\azurepolicy.parameters.json' --subscription 'AzureMonitor_Docs' --mode All
    

Iniciativa

Em vez de criar uma atribuição para cada definição de política, uma estratégia comum é criar uma iniciativa que inclua as definições de política a fim de gerar configurações de diagnóstico para cada serviço do Azure. Crie uma atribuição entre a iniciativa e um grupo de gerenciamento, uma assinatura ou um grupo de recursos, dependendo de como seu ambiente é gerenciado. Essa estratégia oferece os seguintes benefícios:

  • Crie uma única atribuição para a iniciativa em vez de diversas atribuições para cada tipo de recurso. Use a mesma iniciativa para diversos grupos de monitoramento, assinaturas ou grupos de recursos.
  • Modifique a iniciativa quando precisar incluir um novo tipo de recurso ou destino. Por exemplo, os requisitos iniciais podem consistir no envio de dados somente para um espaço de trabalho do Log Analytics. No entanto, é possível que você queira incluir o hub de eventos posteriormente. Modifique a iniciativa em vez de criar novas atribuições.

Para obter detalhes sobre como criar uma iniciativa, consulte Criar e atribuir uma definição de iniciativa. Considere as seguintes recomendações:

  • Defina Categoria como Monitoramento para agrupá-la com as definições de política personalizadas e integradas relacionadas.
  • Em vez de especificar os detalhes para o espaço de trabalho do Log Analytics e o hub de eventos com relação às definições de política incluídas na iniciativa, use um parâmetro de iniciativa comum. Isso parâmetro permite especificar facilmente um valor comum para todas as definições de política e alterar esse valor, se necessário.

Captura de tela que mostra as configurações da definição de iniciativa.

Atribuição

Atribua a iniciativa a um grupo de gerenciamento, uma assinatura ou um grupo de recursos do Azure, dependendo do escopo dos recursos que serão monitorados. Um grupo de gerenciamento é útil para a política de escopo, especialmente quando sua organização tem várias assinaturas.

Captura de tela das configurações da guia Básico na seção Atribuir iniciativa das Configurações de diagnóstico para o espaço de trabalho do Log Analytics no portal do Azure.

Usando os parâmetros de iniciativa, especifique o espaço de trabalho ou qualquer outro detalhe uma vez para todas as definições de política na iniciativa.

Captura de tela que mostra os parâmetros da iniciativa na guia parâmetros.

Remediação

A iniciativa será aplicada a cada criação de máquina virtual. Uma tarefa de correção implanta as definições de política na iniciativa para os recursos existentes, para que você possa criar configurações de diagnóstico para quaisquer recursos que já foram criados.

Ao criar a atribuição usando o portal do Azure, você tem a opção de criar uma tarefa de correção ao mesmo tempo. Consulte Correção de recursos fora de conformidade com o Azure Policy para obter detalhes sobre a correção.

Captura de tela que mostra a correção da iniciativa para um espaço de trabalho Log Analytics.

Solução de problemas

Categoria de métrica não suportada

Ao implantar uma configuração de diagnóstico, você recebe uma mensagem de erro, semelhante à categoria de métrica ' xxxx ' não tem suporte. Você pode receber esse erro mesmo que uma implantação anterior tenha sido bem-sucedida.

O problema ocorre ao usar um modelo do Resource Manager, a API REST de configurações de diagnóstico, a CLI do Azure ou o Azure PowerShell. As configurações de diagnóstico criadas por meio do portal do Azure não são afetadas, pois apenas os nomes de categoria suportados são apresentados.

Esse problema é causado por uma alteração recente na API subjacente. Não há e nunca houve suporte para categorias de métrica diferentes de 'AllMetrics', exceto para alguns serviços do Azure muito específicos. No passado, outros nomes de categoria foram ignorados ao se implantar uma configuração de diagnóstico. O back-end do Azure Monitor redirecionava essas categorias para 'AllMetrics'. A partir de fevereiro de 2021, o back-end foi atualizado para confirmar especificamente que a categoria de métrica fornecida é precisa. Essa alteração causou a falha de algumas implantações.

Caso receba esse erro, atualize suas implantações para substituir quaisquer nomes de categoria de métricas por 'AllMetrics' para corrigir o problema. Se a implantação tiver sido adicionada anteriormente a várias categorias, apenas uma com a referência 'AllMetrics' deverá ser mantida. Caso continue tendo esse problema, entre em contato com o Suporte do Azure pelo portal do Azure.

A configuração desapareceu devido a caracteres não ASCII no resourceID

As configurações de diagnóstico não suportam resourceIDs com caracteres não ASCII (por exemplo, Preproducción). Como você não pode renomear recursos no Azure, sua única opção é criar um novo recurso sem os caracteres não ASCII. Se os caracteres estão em um grupo de recursos, você pode mover esses recursos para um novo. Caso contrário, você precisará recriar o recurso.

Próximas etapas