Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você 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 do 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 de 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 os quais enviar.
Uma única configuração de diagnóstico pode definir não mais do que um dos destinos. Se você quiser enviar dados para mais de um tipo de destino específico (por exemplo, dois workspaces diferentes do Log Analytics), crie várias configurações. Cada recurso pode ter até cinco configurações de diagnóstico.
Aviso
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 do recurso excluído poderão ser incluídas com o novo recurso, dependendo da configuração do recurso para cada recurso. Se as configurações de diagnóstico estiverem incluídas no novo recurso, isso retomará a coleção de logs de recursos conforme definido na configuração de diagnóstico e enviará a métrica aplicável e os dados de log para o destino configurado anteriormente.
Além disso, é uma boa prática excluir as configurações de diagnóstico de um recurso que você vai excluir e não planeja usar novamente para manter 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 em uma arquitetura de armazenamento e encaminhamento projetada para mover petabytes de dados por dia em escala. Essa funcionalidade 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 transitórios de log devem interromper o serviço upstream quando não for possível confirmar a entrega de logs. Sempre que a equipe do Azure Monitor pode confirmar uma fonte persistente de perda de dados, a equipe considera a resolução e a prevenção sua prioridade mais alta. No entanto, pequenas perdas de dados ainda podem ocorrer devido a problemas de serviço temporários e não repetidos distribuídos pelo Azure e nem todos podem ser capturados.
O vídeo a seguir orienta você a como fazer o roteamento de logs da plataforma de recursos com as configurações de diagnóstico. O vídeo foi feito há um tempo atrás. Não esqueça do seguinte:
- Agora há quatro destinos. Você pode enviar logs e métricas de plataforma para determinados Azure Monitor parceiros.
- Um novo recurso chamado grupos de categorias foi introduzido em novembro de 2021.
Informações sobre esses recursos mais novos estão incluídas neste artigo.
Origens
Há três fontes para informações de diagnóstico:
- As métricas de plataforma são enviadas automaticamente para as Métricas do Azure Monitor por padrão e sem configuração. Para obter mais informações sobre métricas com suporte, consulte métricas compatíveis com o Azure Monitor
- Os logs de plataforma fornecem informações detalhadas de diagnóstico e auditoria para os recursos do Azure e a plataforma do Azure da qual dependem.
- Os logs de recursos não são coletados até que sejam roteados 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 por conta própria, mas podem ser roteadas para outros locais.
Métricas
A configuração AllMetrics roteia as métricas de plataforma de um recurso para outros destinos. Essa opção pode não estar presente para todos os provedores de recursos.
Logs 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 de métrica. 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 de 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. 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 log 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:
- Tudo: todos os logs de recursos disponibilizados pelo recurso.
- Auditoria: todos os logs de recursos que registram interações do cliente com 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. Conforme mencionado acima, o que é coletado é dinâmico, e a Microsoft pode alterá-lo ao longo do tempo à medida que novas categorias de registro de recursos se tornam disponíveis.
O grupo de categorias "Auditoria" é um subconjunto do grupo de categorias "Todos", mas o portal do Azure e a API REST os consideram configurações separadas. A seleção do grupo de categorias "Todos" coleta todos os logs de auditoria mesmo que o grupo de categorias "Auditoria" também esteja 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 habilitar a auditoria de banco de dados, você precisa fazê-lo na folha de auditoria do Banco de Dados do Azure.
Log de atividades
Consulte a seção Configurações do log de atividades .
Destinos
Os logs e as 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 oferecer suporte ao TLS 1.2.
| Destino | Descrição |
|---|---|
| Workspace 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 em uma conta de armazenamento é útil para auditoria, análise estática ou backup. Em comparação ao uso de logs do Azure Monitor ou um workspace do Log Analytics, o armazenamento é menos dispendioso e os logs podem ser mantidos indefinidamente. |
| Hubs de Eventos do Azure | Ao enviar logs e métricas para o Hubs de Eventos, você pode transmitir dados para sistemas externos, como SIEMs de terceiros e outras soluções do Log Analytics. |
| Soluções de parceiro 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 uma interface do usuário própria, pois se aplica a toda a assinatura em vez de recursos individuais. As informações de destino listadas aqui ainda são aplicáveis. Para obter mais informações, consulte o log de atividades do Azure.
Requisitos e limitações
Esta seção discute requisitos e limitações.
Tempo antes da 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 workspace do Log Analytics, a tabela será criada automaticamente se ela 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 você estiver enfrentando um problema, tente desabilitar a configuração e reativá-la. Entre em contato com Suporte do Azure por meio do portal do Azure se você continuar tendo problemas.
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 dimensionais simples, agregadas nos valores da 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 podem ser exportadas para o Azure Monitor Logs ou 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, você pode extraí-las manualmente usando a API REST de Métricas. Em seguida, você pode importá-los para logs do Azure Monitor usando a API do Coletor de Dados do Azure Monitor.
Importante
As configurações de diagnóstico não dão suporte a códigos de recursos com caracteres não ASCII (por exemplo, Preproduccón). Para obter mais informações, consulte Solução de problemas.
Limitações de destino
Todos os destinos para a configuração de diagnósticos devem ser criados antes de criar as configurações de diagnóstico. O destino não precisa estar na mesma assinatura que o recurso que envie os logs se o usuário que define a configuração tiver controle de acesso baseado em função do Azure apropriado a ambas as assinaturas. Usando o Azure Lighthouse, também é possível enviar 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 | 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 | Não use uma conta de armazenamento existente que tenha outros dados não monitorados armazenados nela. Dividir os tipos de dados permite controlar melhor o acesso aos dados. Caso você esteja arquivando o log de atividades e os logs de recursos juntos, você pode 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 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 do Azure. 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. As configurações de diagnóstico não pode acessar as 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. Pontos de extremidade de zona DNS do Azure (versão prévia) e quaisquer contas de armazenamento Premium não têm suporte como destino de log ou métrica. Há suporte para todas as contas de armazenamento Standard . |
| 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ê 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. Verifique a documentação dos Serviços ISV Nativos do Azure para obter detalhes. |
Logs de diagnóstico do Application Insights
Se desejar armazenar logs de diagnóstico para o Application Insights em um workspace do Log Analytics, não envie os logs para o mesmo workspace no qual se baseia o recurso do Application Insights. 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 workspace diferente do Log Analytics.
Ao enviar logs do Application Insights para um workspace diferente, saiba que o Application Insights acessa a telemetria entre recursos do Application Insight, incluindo vários workspaces do Log Analytics. Restrinja o acesso do usuário do Application Insights apenas ao workspace do Log Analytics vinculado ao recurso do Application Insights. Defina o modo de controle de acesso como Requer permissões de workspace e gerencie permissões por meio do controle de acesso baseado em função do Azure para garantir que o Application Insights tenha acesso apenas ao workspace do Log Analytics no qual o recurso do Application Insights se baseia.
Controle dos custos
Há um custo para coletar dados em um workspace do Log Analytics; portanto, colete apenas as categorias necessárias para cada serviço. O volume de dados para logs de recurso varia significativamente entre os serviços.
Também pode não ser necessário coletar métricas de plataforma de recursos do Azure, pois esses dados já estão sendo coletados em Métricas. Configure seus dados de diagnóstico para coletar métricas somente se precisar de dados de métricas no workspace para análises mais complexas com consultas de log. As configurações de diagnóstico não permitem a filtragem granular de logs de recursos.
Dica
Para obter estratégias para reduzir os custos do Azure Monitor, consulte a otimização de custos e o Azure Monitor.
Resolução de problemas
Não há suporte para a categoria de métrica
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 sua implantação anterior tenha sido bem-sucedida.
O problema ocorre ao usar um modelo do Resource Manager, a API REST, 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 com suporte são apresentados.
Não há suporte para as categorias de métrica diferentes de AllMetrics, 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 de métrica fornecida passou a ser validada. Essa alteração causou a falha de algumas implantações.
Para corrigir esse problema, atualize suas implantações para remover nomes de categoria de métrica que não sejam AllMetrics. Se a implantação adicionar várias categorias, use apenas uma categoria AllMetrics. 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 dão suporte a códigos de recursos com caracteres não ASCII (por exemplo, Preproduccón). Como não é possível renomear os 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á mover os recursos para um novo grupo.
Possibilidade de dados duplicados ou removidos
Todos os esforços são feitos para garantir que todos os dados de log sejam enviados corretamente aos seus destinos, no entanto, não é possível garantir 100% de transferência de dados de logs entre pontos de extremidade. Novas tentativas e outros mecanismos estão em vigor para contornar esses problemas e tentar garantir que os dados de log cheguem ao ponto de extremidade.
Recursos inativos
Quando um recurso está inativo e exportando métricas de valor zero, o mecanismo de exportação das configurações de diagnóstico reduz gradualmente a frequência para evitar custos desnecessários de exportação e armazenamento de valores zero. A retração pode levar a um atraso na exportação do próximo valor não-zero.
Quando um recurso fica inativo por uma hora, o mecanismo de exportação recua para 15 minutos. Isso significa que há uma possível latência de até 15 minutos para que o próximo valor diferente de zero seja exportado. O tempo máximo de espera de duas horas é alcançado após sete dias de inatividade. Quando o recurso começa a exportar valores diferentes de zero, o mecanismo de exportação retorna à latência de exportação original de três minutos.
Esse comportamento se aplica apenas 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?
Quando você habilita as Configurações de Diagnóstico para exportar dados do Application Insights baseados em workspace para qualquer workspace do Log Analytics, incluindo o mesmo que já armazena dados do Application Insights, as consultas retornam resultados duplicados. Essa duplicação ocorre porque o pipeline padrão e as Configurações de Diagnóstico enviam os mesmos dados para o workspace.
Para evitar telemetria duplicada, não defina configurações de diagnóstico para enviar dados para o mesmo workspace. Se você precisar exportar dados para um workspace diferente, use uma DCR (Regra de Coleta de Dados) com uma transformação e uma tabela personalizada. Essa configuração filtra os dados antes da ingestão e impede registros duplicados em suas consultas.