Definições de diagnóstico no Azure Monitor
Este artigo fornece detalhes sobre como criar e configurar definições de diagnóstico para enviar métricas e registos da plataforma do Azure para diferentes destinos.
As métricas da plataforma são enviadas automaticamente para as Métricas do Azure Monitor por predefinição e sem configuração.
Os registos da plataforma fornecem informações detalhadas de diagnóstico e auditoria para os recursos do Azure e a plataforma do Azure de que dependem:
- Os registos de recursos não são recolhidos até serem encaminhados para um destino.
- Os registos de atividades existem por conta própria, mas podem ser encaminhados para outras localizações.
Cada recurso do Azure requer a sua própria definição de diagnóstico, que define os seguintes critérios:
- Origens: o tipo de dados de métricas e de registo a enviar para os destinos definidos na definição. Os tipos disponíveis variam consoante o tipo de recurso.
- Destinos: um ou mais destinos para onde enviar.
Uma única definição de diagnóstico não pode definir mais do que um dos destinos. Se quiser enviar dados para mais do que um tipo de destino específico (por exemplo, duas áreas de trabalho diferentes do Log Analytics), crie várias definições. Cada recurso pode ter até cinco definições de diagnóstico.
Aviso
Se precisar de eliminar um recurso ou migrá-lo entre grupos de recursos ou subscrições, deve primeiro eliminar as definições de diagnóstico. Caso contrário, se recriar este recurso, as definições de diagnóstico do recurso eliminado poderão ser incluídas no novo recurso, consoante a configuração do recurso para cada recurso. Se as definições de diagnóstico estiverem incluídas no novo recurso, esta ação retoma a coleção de registos de recursos conforme definido na definição de diagnóstico e envia os dados de métrica e registo aplicáveis para o destino configurado anteriormente.
Além disso, é uma boa prática eliminar as definições de diagnóstico de um recurso que vai eliminar e não planear voltar a utilizar para manter o seu ambiente limpo.
O vídeo seguinte explica-lhe como encaminhar registos da plataforma de recursos com definições de diagnóstico. O vídeo foi feito numa altura anterior. Tenha em atenção as seguintes alterações:
- Existem agora quatro destinos. Pode enviar métricas e registos da plataforma a determinados parceiros do Azure Monitor.
- Uma nova funcionalidade denominada grupos de categorias foi introduzida em novembro de 2021.
As informações sobre estas funcionalidades mais recentes estão incluídas neste artigo.
Origens
Existem três origens para informações de diagnóstico:
- Métricas
- Registos de Recursos
- Registos de atividade
Métricas
A definição AllMetrics encaminha as métricas da plataforma de um recurso para outros destinos. Esta opção pode não estar presente para todos os fornecedores de recursos.
Registos do recurso
Com os registos, pode selecionar as categorias de registo que pretende encaminhar individualmente ou escolher um grupo de categorias.
Nota
Os grupos de categorias não se aplicam a todos os fornecedores de recursos de métricas. Se um fornecedor não os tiver disponíveis nas definições de diagnóstico no portal do Azure, também não estarão disponíveis através de modelos de Resource Manager do Azure.
Pode utilizar grupos de categorias para recolher dinamicamente registos de recursos com base em agrupamentos predefinidos em vez de selecionar categorias de registo individuais. A Microsoft define os agrupamentos para ajudar a monitorizar casos de utilização específicos em todos os serviços do Azure.
Ao longo do tempo, as categorias no grupo podem ser atualizadas à medida que os novos registos são lançados ou à medida que as avaliações mudam. Quando as categorias de registo são adicionadas ou removidas de um grupo de categorias, a coleção de registos é modificada automaticamente sem ter de atualizar as definições de diagnóstico.
Quando utiliza grupos de categorias, pode:
- Já não é possível selecionar individualmente os registos de recursos com base em tipos de categoria individuais.
- Já não pode aplicar definições de retenção a registos enviados para o Armazenamento do Azure.
Atualmente, existem dois grupos de categorias:
- Todos: todos os registos de recursos oferecidos pelo recurso.
- Auditoria: todos os registos de recursos que registam interações do cliente com dados ou as definições do serviço. Os registos de auditoria são uma tentativa de cada fornecedor de recursos fornecer os dados de auditoria mais relevantes, mas podem não ser considerados suficientes numa perspetiva de normas de auditoria.
A categoria "Auditoria" é um subconjunto de "Todos", mas a portal do Azure e a API REST consideram-nas definições separadas. Selecionar "Tudo" recolhe todos os registos de auditoria, independentemente de a categoria "Auditoria" também estar selecionada.
Nota: ativar a Auditoria para a Base de Dados SQL do Azure não ativa a auditoria da Base de Dados SQL do Azure. Para ativar a auditoria da base de dados, tem de a ativar a partir do painel de auditoria da Base de Dados do Azure.
Registo de atividades
Veja a secção Definições do registo de atividades .
Destinos
Os registos e as métricas da plataforma podem ser enviados para os destinos listados na tabela seguinte.
Para garantir a segurança dos dados em trânsito, todos os pontos finais de destino estão configurados para suportar o TLS 1.2.
| Destino | Description |
|---|---|
| Área de trabalho do Log Analytics | As métricas são convertidas em formulário de registo. Esta opção pode não estar disponível para todos os tipos de recursos. Enviá-los para o arquivo de Registos do Azure Monitor (que é pesquisável através do Log Analytics) ajuda-o a integrá-los em consultas, alertas e visualizações com dados de registo existentes. |
| Conta de armazenamento do Azure | Arquivar registos e métricas numa conta de Armazenamento é útil para auditoria, análise estática ou cópia de segurança. Em comparação com a utilização dos Registos do Azure Monitor ou de uma área de trabalho do Log Analytics, o Armazenamento é menos dispendioso e os registos podem ser mantidos lá indefinidamente. |
| Azure Event Hubs | Quando envia registos e métricas para os Hubs de Eventos, pode transmitir dados em fluxo para sistemas externos, como SIEMs de terceiros e outras soluções do Log Analytics. |
| Integrações de parceiros do Azure Monitor | Podem ser efetuadas integrações especializadas entre o Azure Monitor e outras plataformas de monitorização que não sejam da Microsoft. A integração é útil quando já está a utilizar um dos parceiros. |
Definições do registo de atividades
O registo de atividades utiliza uma definição de diagnóstico, mas tem a sua própria interface de utilizador porque se aplica a toda a subscrição em vez de recursos individuais. As informações de destino aqui listadas ainda se aplicam. Para obter mais informações, veja Registo de atividades do Azure.
Requisitos e limitações
Esta secção aborda os requisitos e as limitações.
Tempo antes da telemetria chegar ao destino
Depois de configurar uma definição de diagnóstico, os dados devem começar a fluir para os destinos selecionados no prazo de 90 minutos. Se não receber informações dentro de 24 horas, também
- não estão a ser gerados registos ou
- algo está errado no mecanismo de encaminhamento subjacente. Experimente desativar a configuração e, em seguida, reativar a configuração. Contacte suporte do Azure através do portal do Azure se continuar a ter problemas.
Métricas como origem
Existem determinadas limitações com a exportação de métricas:
- O envio de métricas multidimensionais através de definições de diagnóstico não é atualmente suportado: As métricas com dimensões são exportadas como métricas unidimensionais achatadas, agregadas entre valores de dimensão. Por exemplo, a métrica IOReadBytes num blockchain pode ser explorada e gráfico num nível por nó. No entanto, quando exportada através das definiçõ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 definições de diagnóstico: Devido a limitações internas, nem todas as métricas são exportáveis para Registos do Azure Monitor ou Log Analytics. Para obter mais informações, veja a coluna Exportável na lista de métricas suportadas.
Para contornar estas limitações para métricas específicas, pode extraí-las manualmente com a API REST de Métricas. Em seguida, pode importá-los para os Registos do Azure Monitor com a API do Recoletor de Dados do Azure Monitor.
Limitações de destino
Todos os destinos para a definição de diagnóstico têm de ser criados antes de criar as definições de diagnóstico. O destino não tem de estar na mesma subscrição que os registos de envio de recursos se o utilizador que configurar a definição tiver o acesso adequado ao controlo de acesso baseado em funções do Azure a ambas as subscrições. Ao utilizar o Azure Lighthouse, também é possível que as definições de diagnóstico sejam enviadas para uma área de trabalho, conta de armazenamento ou hub de eventos noutro inquilino do Azure Active Directory.
A tabela seguinte fornece requisitos exclusivos para cada destino, incluindo quaisquer restrições regionais.
| Destino | Requisitos |
|---|---|
| Área de trabalho do Log Analytics | A área de trabalho não precisa de estar na mesma região que o recurso que está a ser monitorizado. |
| Conta de armazenamento | Não utilize uma conta de armazenamento existente que tenha outros dados não monitorizados armazenados na mesma para que possa controlar melhor o acesso aos dados. Se estiver a arquivar o registo de atividades e os registos de recursos em conjunto, poderá optar por utilizar a mesma conta de armazenamento para manter todos os dados de monitorização numa localização central. Para enviar os dados para armazenamento imutável, defina a política imutável para a conta de armazenamento, conforme descrito em Definir e gerir políticas de imutabilidade para Armazenamento de Blobs do Azure. Tem de seguir todos os passos neste artigo ligado, incluindo ativar escritas de blobs de acréscimo protegidos. A conta de armazenamento tem de estar na mesma região que o recurso que está a ser monitorizado se o recurso for regional. As definições de diagnóstico não conseguem aceder às contas de armazenamento quando as redes virtuais estão ativadas. Tem de ativar a definição Permitir serviços Microsoft fidedignos para ignorar esta definição de firewall nas contas de armazenamento para que o serviço de definições de diagnóstico do Azure Monitor tenha acesso à sua conta de armazenamento. Os pontos finais da zona DNS do Azure (pré-visualização) e as contas de armazenamento do Azure Premium LRS (armazenamento localmente redundante) não são suportados como um destino de registo ou métrica. |
| Hubs de Eventos | A política de acesso partilhado para o espaço de nomes define as permissões que o mecanismo de transmissão em fluxo tem. A transmissão em fluxo para os Hubs de Eventos requer permissões de Gerir, Enviar e Escutar. Para atualizar a definição de diagnóstico para incluir a transmissão em fluxo, tem de ter a permissão ListKey nessa regra de autorização dos Hubs de Eventos. O espaço de nomes do hub de eventos tem de estar na mesma região que o recurso que está a ser monitorizado se o recurso for regional. As definições de diagnóstico não conseguem aceder aos recursos dos Hubs de Eventos quando as redes virtuais estão ativadas. Tem de ativar a definição Permitir serviços Microsoft fidedignos para ignorar esta definição de firewall nos Hubs de Eventos para que o serviço de definições de diagnóstico do Azure Monitor tenha acesso aos seus recursos dos Hubs de Eventos. |
| Integrações de parceiros | As soluções variam consoante o parceiro. Veja a documentação de integrações de parceiros do Azure Monitor para obter detalhes. |
Controlar os custos
Existe um custo para recolher dados numa área de trabalho do Log Analytics, pelo que só deve recolher as categorias necessárias para cada serviço. O volume de dados dos registos de recursos varia significativamente entre serviços,
Também poderá não querer recolher métricas de plataforma dos recursos do Azure porque estes dados já estão a ser recolhidos em Métricas. Configure apenas os dados de diagnóstico para recolher métricas se precisar de dados de métricas na área de trabalho para uma análise mais complexa com consultas de registo.
As definições de diagnóstico não permitem a filtragem granular dos registos de recursos. Pode exigir determinados registos numa categoria específica, mas não outros. Em alternativa, poderá querer remover colunas desnecessárias dos dados. Nestes casos, utilize transformações na área de trabalho para filtrar registos de que não precisa.
Também pode utilizar transformações para reduzir os requisitos de armazenamento dos registos que pretende ao remover colunas sem informações úteis. Por exemplo, pode ter eventos de erro num registo de recursos que pretende para alertas. Contudo, poderá não precisar de determinadas colunas nesses registos que contêm uma grande quantidade de dados. Pode criar uma transformação para a tabela que remove essas colunas.
Dica
Para obter estratégias para reduzir os custos do Azure Monitor, veja Otimização de custos e Azure Monitor.
Criar as definições de diagnóstico
Pode criar e editar definições de diagnóstico com vários métodos.
Pode configurar as definições de diagnóstico no portal do Azure no menu do Azure Monitor ou no menu do recurso.
O local onde configura as definições de diagnóstico no portal do Azure depende do recurso:
Para um único recurso, selecione Definições de diagnóstico em Monitorização no menu do recurso.
Para um ou mais recursos, selecione Definições de diagnóstico em Definições no menu do Azure Monitor e, em seguida, selecione o recurso.
Para o registo de atividades, selecione Registo de atividades no menu do Azure Monitor e, em seguida, selecione Definições de diagnóstico. Certifique-se de que desativa qualquer configuração legada para o registo de atividades. Para obter instruções, consulte Desativar definições existentes.
Se não existirem definições no recurso que selecionou, ser-lhe-á pedido para criar uma definição. Selecione Adicionar definição de diagnóstico.
Se existirem definições no recurso, verá uma lista de definições já configuradas. Selecione Adicionar definição de diagnóstico para adicionar uma nova definição. Em alternativa, selecione Editar definição para editar uma existente. Cada definição não pode ter mais do que um dos tipos de destino.
Atribua um nome à definição se ainda não tiver um.
Registos e métricas a encaminhar: para registos, selecione um grupo de categorias ou selecione as caixas de verificação individuais para cada categoria de dados que pretende enviar para os destinos especificados mais tarde. A lista de categorias varia para cada serviço do Azure. Selecione AllMetrics se também quiser armazenar métricas nos Registos do Azure Monitor.
Detalhes de destino: selecione a caixa de verificação para cada destino. São apresentadas opções para poder adicionar mais informações.
Log Analytics: introduza a subscrição e a área de trabalho. Se não tiver uma área de trabalho, tem de criar uma antes de continuar.
Hubs de Eventos: especifique os seguintes critérios:
- Subscrição: a subscrição da qual o hub de eventos faz parte.
- Espaço de nomes do hub de eventos: se não tiver um, tem de criar um.
- Nome do hub de eventos (opcional): o nome para o qual enviar todos os dados. Se não especificar um nome, é criado um hub de eventos para cada categoria de registo. Se estiver a enviar para várias categorias, poderá querer especificar um nome para limitar o número de hubs de eventos criados. Para obter mais informações, veja Hubs de Eventos do Azure quotas e limites.
- Nome da política do hub de eventos (também opcional): uma política define as permissões que o mecanismo de transmissão em fluxo tem. Para obter mais informações, veja Funcionalidades dos Hubs de Eventos.
Armazenamento: selecione a política Subscrição, Conta de armazenamento e Retenção .
Dica
Considere definir a política de retenção como 0 e utilizar a Política de Ciclo de Vida do Armazenamento do Azure ou eliminar os dados do armazenamento com uma tarefa agendada. É provável que estas estratégias forneçam um comportamento mais consistente.
Primeiro, se estiver a utilizar o armazenamento para arquivar, geralmente pretende que os seus dados sejam retidos durante mais de 365 dias.
Em segundo lugar, se escolher uma política de retenção superior a 0, a data de expiração é anexada aos registos no momento do armazenamento. Não pode alterar a data desses registos depois de serem armazenados.
Por exemplo, se definir a política de retenção de WorkflowRuntime para 180 dias e, 24 horas depois, defini-la como 365 dias, os registos armazenados durante essas primeiras 24 horas serão automaticamente eliminados após 180 dias. Todos os registos subsequentes desse tipo serão eliminados automaticamente após 365 dias. Alterar a política de retenção mais tarde não mantém as primeiras 24 horas de registos durante 365 dias.
Integração de parceiros: primeiro tem de instalar a integração de parceiros na sua subscrição. As opções de configuração variam consoante o parceiro. Para obter mais informações, veja Integrações de parceiros do Azure Monitor.
Selecione Guardar.
Após alguns momentos, a nova definição é apresentada na sua lista de definições para este recurso. Os registos são transmitidos para os destinos especificados à medida que são gerados novos dados de eventos. Pode demorar até 15 minutos entre quando um evento é emitido e quando aparece numa área de trabalho do Log Analytics.
Resolução de problemas
Seguem-se algumas sugestões de resolução de problemas.
A categoria de métricas não é suportada
Quando implementa uma definição de diagnóstico, recebe uma mensagem de erro semelhante a "A categoria de métricas 'xxxx' não é suportada". Poderá receber este erro mesmo que a implementação anterior tenha sido bem-sucedida.
O problema ocorre quando utiliza um modelo de Resource Manager, a API REST, a CLI ou Azure PowerShell. As definições de diagnóstico criadas através do portal do Azure não são afetadas porque são apresentados apenas os nomes de categoria suportados.
O problema é causado por uma alteração recente na API subjacente. As categorias de métricas que não o AllMetrics não são suportadas e nunca foram exceto alguns serviços específicos do Azure. No passado, outros nomes de categorias foram ignorados ao implementar uma definição de diagnóstico. O back-end do Azure Monitor redirecionou estas 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. Esta alteração causou a falha de algumas implementações.
Se receber este erro, atualize as implementações para substituir quaisquer nomes de categorias de métricas por AllMetrics para corrigir o problema. Se a implementação estava anteriormente a adicionar várias categorias, mantenha apenas uma com a referência AllMetrics . Se continuar a ter o problema, contacte suporte do Azure através do portal do Azure.
A definição desaparece devido a carateres não ASCII no resourceID
As definições de diagnóstico não suportam IDs de recursos com carateres não ASCII. Por exemplo, considere o termo Preproducción. Uma vez que não pode mudar o nome dos recursos no Azure, a única opção é criar um novo recurso sem os carateres não ASCII. Se os carateres estiverem num grupo de recursos, pode mover os recursos para um novo. Caso contrário, terá de recriar o recurso.
Possibilidade de dados duplicados ou removidos
Todos os esforços são feitos para garantir que todos os dados de registo são enviados corretamente para os seus destinos. No entanto, não é possível garantir a transferência de dados a 100% dos registos entre pontos finais. As repetições e outros mecanismos estão implementados para contornar estes problemas e tentar garantir que os dados de registo chegam ao ponto final.