Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo fornece detalhes sobre como criar e definir configurações de diagnóstico para enviar métricas da plataforma Azure, logs de recursos e o log de atividades para destinos diferentes.
Cada recurso do Azure requer sua própria configuração de diagnóstico, que define os seguintes critérios:
- Fontes: o tipo de dados de métrica e log a serem enviados para os destinos definidos na configuração. Os tipos disponíveis variam de acordo com o tipo de recurso.
- Destinos: Um ou mais destinos para enviar.
Uma única configuração de diagnóstico não pode definir mais do que um de cada um dos destinos. Se você quiser enviar dados para mais de um tipo de destino específico (por exemplo, dois espaços de trabalho diferentes do Log Analytics), crie várias configurações. Cada recurso pode ter até cinco configurações de diagnóstico.
Advertência
Se você precisar excluir um recurso, renomear ou mover um recurso, ou migrá-lo entre grupos de recursos ou assinaturas, primeiro exclua suas configurações de diagnóstico. Caso contrário, se você recriar esse recurso, as configurações de diagnóstico para o recurso excluído poderão ser incluídas com o novo recurso, dependendo da configuração do recurso para cada recurso. Se as definições de diagnóstico estiverem incluídas com o novo recurso, isto retoma a coleção de registos de recursos conforme definido na definição de diagnóstico e envia os dados de métricas e registos aplicáveis para o destino previamente configurado.
Além disso, é uma boa prática eliminar as definições de diagnóstico de um recurso que irá apagar e que não planeia usar novamente, para manter o seu ambiente limpo.
Observação
Os Logs de Recursos do Azure Monitor não são 100% sem perdas. Os Logs de Recursos são baseados numa arquitetura de armazenamento e encaminhamento projetada para mover petabytes de dados por dia em grande escala de maneira acessível. Esse recurso inclui redundância interna e novas tentativas em toda a plataforma, mas não fornece garantias transacionais. O monitoramento transacional pode reduzir a confiabilidade e o desempenho do serviço monitorado. Além disso, erros de log transitórios devem interromper o serviço upstream quando não for possível confirmar a entrega do log. Sempre que a equipe do Azure Monitor puder confirmar uma fonte persistente de perda de dados, a equipe considerará a resolução e a prevenção como sua prioridade mais alta. No entanto, pequenas perdas de dados ainda podem acontecer devido a problemas de serviço temporários e não repetitivos distribuídos pelo Azure, e nem todos podem ser detetados.
O vídeo a seguir orienta você pelos logs da plataforma de recursos de roteamento com configurações de diagnóstico. O vídeo foi feito em um momento anterior. Esteja atento às seguintes alterações:
- Existem agora quatro destinos. Você pode enviar métricas e logs da plataforma para determinados parceiros do Azure Monitor.
- Um novo recurso chamado grupos de categorias foi introduzido em novembro de 2021.
Informações sobre esses recursos mais recentes estão incluídas neste artigo.
Fontes
Existem três fontes de informação diagnóstica:
- As métricas da plataforma são enviadas automaticamente para o Azure Monitor Metrics por padrão e sem configuração. Para obter mais informações sobre métricas suportadas, consulte Métricas suportadas com o Azure Monitor
- Os logs da plataforma fornecem informações detalhadas de diagnóstico e auditoria para os recursos do Azure e a plataforma do Azure da qual eles dependem.
- Os logs de recursos não são recolhidos até que sejam encaminhados para um destino. Para obter mais informações sobre logs com suporte, consulte Categorias de log de recursos com suporte para o Azure Monitor
- O log de atividades fornece informações sobre recursos de fora do recurso, como quando o recurso foi criado ou excluído. As entradas existem independentemente, mas podem ser encaminhadas para outros locais.
Métricas
A configuração AllMetrics roteia as métricas da plataforma de um recurso para outros destinos. Essa opção pode não estar presente para todos os provedores de recursos.
Registos de recursos
Com os logs de recursos, você pode selecionar as categorias de log que deseja rotear individualmente ou escolher um grupo de categorias.
Grupos de categorias
Observação
Os grupos de categorias não se aplicam a todos os provedores de recursos métricos. Se um provedor não os tiver disponíveis nas configurações de diagnóstico no portal do Azure, eles também não estarão disponíveis por meio dos modelos do Azure Resource Manager.
Você pode usar grupos de categorias para coletar dinamicamente logs de recursos com base em agrupamentos predefinidos em vez de selecionar categorias de log individuais. A Microsoft define os agrupamentos para ajudar a monitorar casos de uso específicos em todos os serviços do Azure. Com o tempo, as categorias no grupo podem ser atualizadas conforme novos diários são implementados ou as avaliações mudam. Quando categorias de log são adicionadas ou removidas de um grupo de categorias, sua coleção de logs é modificada automaticamente sem que você precise atualizar suas configurações de diagnóstico.
Ao usar grupos de categorias, você:
- Não é mais possível selecionar individualmente logs de recursos com base em tipos de categoria individuais.
- Não é mais possível aplicar configurações de retenção aos logs enviados para o Armazenamento do Azure.
Atualmente, existem dois grupos de categorias:
- Todos: Todos os registos de recursos disponibilizados pela fonte.
- Auditoria: todos os logs de recursos que registram as interações do cliente com os dados ou as configurações do serviço. Os logs de auditoria são uma tentativa de cada provedor de recursos de fornecer os dados de auditoria mais relevantes, mas podem não ser considerados suficientes do ponto de vista dos padrões de auditoria, dependendo do seu caso de uso. Como mencionado acima, o que é coletado é dinâmico, e a Microsoft pode alterá-lo ao longo do tempo à medida que novas categorias de log de recursos ficam disponíveis.
O grupo de categorias "Auditoria" é um subconjunto do grupo de categorias "Todos", mas o portal do Azure e a API REST consideram-nos configurações separadas. A seleção do grupo de categorias "Todos" recolhe todos os registos de auditoria, mesmo quando o grupo de categorias "Auditoria" também está selecionado.
A imagem a seguir mostra os grupos de categorias de logs na página Adicionar configurações de diagnóstico.
Observação
Habilitar a categoria Auditoria nas configurações de diagnóstico do Banco de Dados SQL do Azure não ativa a auditoria para o banco de dados. Para ativar a auditoria da base de dados, tem de ativá-la no painel de auditoria da Base de Dados do Azure.
Registo de atividades
Consulte a seção Configurações do registro de atividades .
Destinos
Os logs e métricas da plataforma podem ser enviados para os destinos listados na tabela a seguir.
Para garantir a segurança dos dados em trânsito, todos os pontos de extremidade de destino são configurados para suportar TLS 1.2.
| Destino | Descrição |
|---|---|
| Área de trabalho do Log Analytics | As métricas são convertidas para forma logarítmica. Esta opção pode não estar disponível para todos os tipos de recursos. Enviá-los para o repositório de Logs do Azure Monitor (que pode ser pesquisado por meio do Log Analytics) ajuda você a integrá-los em consultas, alertas e visualizações com dados de log existentes. |
| Conta de armazenamento do Azure | O arquivamento de logs e métricas em uma conta de armazenamento é útil para auditoria, análise estática ou backup. Em comparação com o uso do Azure Monitor Logs ou um espaço de trabalho do Log Analytics, o armazenamento é mais barato e os logs podem ser mantidos lá indefinidamente. |
| Hubs de Eventos do Azure | Ao enviar logs e métricas para Hubs de Eventos, você pode transmitir dados para sistemas externos, como SIEMs de terceiros e outras soluções de Análise de Logs. |
| Soluções de parceiros do Azure Monitor | Integrações especializadas podem ser feitas entre o Azure Monitor e outras plataformas de monitoramento que não sejam da Microsoft. A integração é útil quando você já está usando um dos parceiros. |
Configurações do log de atividades
O log de atividades usa uma configuração de diagnóstico, mas tem sua própria interface de usuário porque se aplica a toda a assinatura em vez de recursos individuais. As informações de destino listadas aqui ainda se aplicam. Para obter mais informações, consulte Log de atividades do Azure.
Requisitos e limitações
Esta seção discute requisitos e limitações.
Tempo antes de a telemetria chegar ao destino
Depois de configurar uma configuração de diagnóstico, os dados devem começar a fluir para o(s) destino(s) selecionado(s) dentro de 90 minutos. Ao enviar logs para um espaço de trabalho do Log Analytics, a tabela é criada automaticamente se ainda não existir. A tabela só é criada quando os primeiros registros de log são recebidos. Se você não receber nenhuma informação dentro de 24 horas, então você pode estar enfrentando um dos seguintes problemas:
- Nenhum log está sendo gerado.
- Algo está errado no mecanismo de roteamento subjacente.
Se tiver um problema, pode tentar desativar a configuração e, em seguida, reativá-la. Contacte o suporte do Azure através do portal do Azure se continuar a ter problemas.
Métricas como fonte
Há certas limitações com as métricas de exportação:
- Atualmente, 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 simplificadas, agregadas em valores de dimensão. Por exemplo, a métrica IOReadBytes numa blockchain pode ser explorada e representada graficamente ao nível de cada nó. No entanto, quando exportada através de configurações de diagnóstico, a métrica exportada mostra todos os bytes de leitura para 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 o Azure Monitor Logs ou Log Analytics. Para obter mais informações, consulte a coluna Exportável na lista de métricas suportadas.
Para contornar essas limitações para métricas específicas, você pode extraí-las manualmente usando a API REST de métricas. Em seguida, você pode importá-los para os Logs do Azure Monitor usando a API do Coletor de Dados do Azure Monitor.
Importante
As configurações de diagnóstico não suportam resourceIDs com caracteres não-ASCII (por exemplo, Preproduccón). Para mais informações, consulte Resolução de Problemas.
Limitações de destino
Todos os destinos para a configuração de diagnóstico devem ser criados antes de criar as configurações de diagnóstico. O destino não precisa estar na mesma assinatura que a do recurso que envia logs, desde que o usuário que configura a definição tenha o acesso adequado de controle baseado em funções do Azure para ambas as assinaturas. Usando o Azure Lighthouse, também é possível enviar as configurações de diagnóstico para um espaço de trabalho, conta de armazenamento ou hub de eventos em outro locatário do Microsoft Entra.
A tabela a seguir fornece requisitos exclusivos para cada destino, incluindo quaisquer restrições regionais.
| Destino | Requerimentos |
|---|---|
| área de trabalho do Log Analytics | O espaço de trabalho não precisa estar na mesma região que o recurso que está sendo monitorado. |
| Conta de armazenamento | Não use uma conta de armazenamento existente que tenha outros dados não monitorantes armazenados nela. Dividir os tipos de dados permite controlar melhor o acesso aos dados. Se você estiver arquivando o log de atividades e os logs de recursos juntos, poderá optar por usar a mesma conta de armazenamento para manter todos os dados de monitoramento em um local central. Para evitar a modificação dos dados, envie-os para 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 do Azure. Você deve seguir todas as etapas neste artigo vinculado, 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 que está sendo monitorado se o recurso for regional. As configurações de diagnóstico não podem acessar contas de armazenamento quando as redes virtuais estão habilitadas. Você deve habilitar Permitir que serviços confiáveis da Microsoft ignorem essa configuração de firewall em contas de armazenamento para que o serviço de configurações de diagnóstico do Azure Monitor tenha acesso à sua conta de armazenamento. Os pontos de extremidade da zona DNS do Azure (visualização) e quaisquer contas de armazenamento Premium não são suportados como destinos de logs ou métricas. Todas as contas de armazenamento padrão são suportadas. |
| Hubs de Eventos | A política de acesso compartilhado para o namespace define as permissões que o mecanismo de streaming tem. O streaming para Hubs de Eventos requer as permissões Gerenciar, Enviar e Ouvir. Para atualizar a configuração de diagnóstico para incluir 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 que está sendo monitorado se o recurso for regional. As configurações de diagnóstico não podem acessar os recursos dos Hubs de Eventos quando as redes virtuais estão habilitadas. Você deve habilitar Permitir que serviços confiáveis da Microsoft ignorem essa configuração de firewall nos Hubs de Eventos para que o serviço de configurações de diagnóstico do Azure Monitor tenha acesso aos recursos dos Hubs de Eventos. |
| Soluções de parceiros | As soluções variam de acordo com o parceiro. Consulte a documentação dos Serviços ISV Nativos do Azure para obter detalhes. |
Logs de diagnóstico para o Application Insights
Se você quiser armazenar logs de diagnóstico do Application Insights em um espaço de trabalho do Log Analytics, não envie os logs para o mesmo espaço de trabalho no qual o recurso do Application Insights se baseia. Essa configuração pode fazer com que a telemetria duplicada seja exibida porque o Application Insights já está armazenando esses dados. Envie seus logs do Application Insights para um espaço de trabalho diferente do Log Analytics.
Ao enviar logs do Application Insights para um espaço de trabalho diferente, lembre-se de que o Application Insights acede à telemetria entre os recursos do Application Insights, incluindo vários espaços de trabalho do Log Analytics. Restrinja o acesso do usuário do Application Insights apenas ao espaço de trabalho do Log Analytics vinculado ao recurso do Application Insights. Defina o modo de controle de acesso como Requer permissões de espaço de trabalho e gerencie permissões por meio do controle de acesso baseado em função do Azure para garantir que o Application Insights só tenha acesso ao espaço de trabalho do Log Analytics no qual o recurso do Application Insights se baseia.
Controlo de custos
Há um custo para coletar dados em um espaço de trabalho do Log Analytics, portanto, colete apenas as categorias necessárias para cada serviço. O volume de dados para logs de recursos varia significativamente entre serviços.
Você também pode não querer coletar métricas da plataforma dos recursos do Azure porque esses dados já estão sendo coletados em Métricas. Configure seus dados de diagnóstico apenas para coletar métricas se precisar de dados métricos no espaço de trabalho para análises mais complexas com consultas de log. As configurações de diagnóstico não permitem filtragem granular de logs de recursos.
Sugestão
Para obter estratégias para reduzir os custos do Azure Monitor, consulte Otimização de custos e Azure Monitor.
Solução de problemas
A 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 é suportada. Você pode receber esse erro mesmo que sua implantação anterior tenha sido bem-sucedida.
O problema ocorre ao usar um modelo do Gerenciador de Recursos, API REST, CLI do Azure ou 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 com suporte são apresentados.
Categorias de métricas diferentes de AllMetrics não são suportadas, exceto por um número limitado de serviços do Azure. Anteriormente, outros nomes de categoria eram ignorados ao implantar uma configuração de diagnóstico, redirecionando-os para AllMetrics. A partir de fevereiro de 2021, a categoria métrica fornecida é validada. Essa alteração fez com que algumas implantações falhassem.
Para corrigir esse problema, atualize suas implantações para remover qualquer nome de categoria métrica diferente de AllMetrics. Se a implantação adicionar várias categorias, use apenas uma AllMetrics categoria. Se continuar a ter o problema, contacte o suporte do Azure através do portal do Azure.
A configuração desaparece 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, Preproduccón). Como não é possível renomear recursos no Azure, você deve criar um novo recurso sem os caracteres não-ASCII. Se os caracteres estiverem em um grupo de recursos, você poderá movê-los para um novo grupo.
Possibilidade de dados duplicados ou descartados
Todos os esforços são feitos para garantir que todos os dados de log sejam enviados corretamente para seus destinos, no entanto, não é possível garantir 100% de transferência de dados de logs entre endpoints. Novas tentativas e outros mecanismos estão implementados para contornar esses problemas e tentar garantir que os dados de log cheguem ao destino final.
Recursos inativos
Quando um recurso está inativo e exporta apenas métricas de valor zero, o mecanismo de exportação de configurações de diagnóstico reduz gradualmente a frequência de exportação para ajudar a evitar custos desnecessários. Essa redução pode atrasar a exportação da próxima métrica diferente de zero.
Quando um recurso fica inativo por uma hora, o mecanismo de exportação recua para 15 minutos. Isso significa que há uma latência potencial de até 15 minutos para que o próximo valor diferente de zero seja exportado. O tempo máximo de descanso de duas horas é atingido após sete dias de inatividade. Quando o recurso começa a exportar valores diferentes de zero, o mecanismo de exportação reverte para a latência de exportação original de três minutos.
Esse comportamento só se aplica a métricas exportadas e não afeta alertas baseados em métricas ou dimensionamento automático.
Por que vejo telemetria duplicada no Application Insights depois de habilitar as Configurações de diagnóstico?
As Configurações de Diagnóstico duplicam os dados do Application Insights. Se você precisar fazer backup ou encaminhar dados do Application Insights para outro espaço de trabalho, use uma Regra de Coleta de Dados com transformação. Essa abordagem filtra e encaminha os dados antes da ingestão, evita a duplicação e fornece mais controle sobre o que é armazenado.