Fundamentação Teórica: Configure Log Settings in Azure Monitor

1. Intuição Inicial

Imagine que você administra uma grande empresa com centenas de departamentos, servidores, câmeras de segurança e sistemas. Cada um desses sistemas gera registros de atividade: quem acessou o quê, quando, com qual resultado. Sem uma estratégia de coleta centralizada, esses registros ficam espalhados em arquivos locais, impossíveis de correlacionar.

Configurar logs no Azure Monitor é definir o sistema de coleta centralizada dessa empresa: você especifica quais fontes devem enviar seus registros, para qual destino central (o "arquivo central" da empresa) e por quanto tempo esses registros devem ser mantidos.

A diferença fundamental em relação a simplesmente "habilitar logs" é que você está configurando uma pipeline de dados: a origem, o canal de transmissão, o destino de armazenamento e as políticas de retenção. Cada uma dessas decisões tem impacto direto em custo, segurança e capacidade de responder a incidentes.

2. Contexto

2.1 O ecossistema de logs no Azure Monitor

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

2.2 Os três tipos principais de logs

Antes de configurar, é essencial entender o que cada tipo de log contém:

Activity Log (Log de Atividade): Registra operações de plano de controle: quem criou, modificou ou deletou recursos Azure. É automático, sem configuração necessária para existir. Cobre toda a assinatura. Exemplo: "usuário X deletou a VM Y às 14:32".

Resource Logs (antigos Diagnostic Logs): Registram operações de plano de dados: o que aconteceu dentro do recurso. Exemplo para Storage Account: quais blobs foram lidos, escritos, quais erros ocorreram. Não são coletados automaticamente; requerem Diagnostic Settings configurados.

Azure Active Directory Logs: Incluem Sign-in logs (tentativas de autenticação) e Audit logs (mudanças no diretório). Requerem licença Azure AD P1/P2 para retenção além de 7 dias.

3. Construção dos Conceitos

3.1 Log Analytics Workspace: o destino central

O Log Analytics Workspace (LAW) é o repositório central de logs no Azure Monitor. É onde logs de múltiplos recursos convertem-se em dados consultáveis via KQL (Kusto Query Language).

Um LAW tem:

Retenção interativa: 30 dias (padrão, configurável de 4 a 730 dias)
Retenção de arquivo: 7 anos (dados em retenção reduzida, consultáveis mas mais lentos)
Tabelas: Cada tipo de log fica em uma tabela diferente (ex: AzureActivity, StorageBlobLogs, SigninLogs)
Região: O LAW tem uma região e os dados ficam nessa região

3.2 Diagnostic Settings: o mecanismo de roteamento

Diagnostic Settings (Configurações de Diagnóstico) são a configuração que define, para cada recurso, quais categorias de log enviar e para quais destinos.

Cada recurso pode ter até 5 Diagnostic Settings simultâneos, permitindo enviar logs para múltiplos destinos ao mesmo tempo (ex: Log Analytics para consulta e Storage Account para arquivo).

Uma Diagnostic Setting define:

Categorias de log: Quais tipos de evento capturar (ex: StorageRead, StorageWrite, StorageDelete)
Métricas: Opcionalmente exportar métricas junto com logs
Destinos: Log Analytics Workspace, Storage Account, Event Hub, e/ou parceiro (ex: Datadog)

3.3 Tabelas do Log Analytics e planos de retenção

Com a introdução do Basic Logs e Analytic Logs, o Log Analytics tem dois planos de tabela com custos e capacidades diferentes:

Plano	Custo de ingestão	Custo de consulta	Retenção interativa	Uso recomendado
Analytics	Alto	Gratuito	Até 730 dias	Logs críticos consultados frequentemente
Basic	Baixo (80% mais barato)	Por GB consultado	8 dias fixos	Logs de alto volume, raramente consultados
Auxiliary	Muito baixo	Por GB consultado	Sem retenção interativa	Logs para compliance apenas

Estratégia de custo: Logs de auditoria críticos (Activity Log, Sign-in logs) devem ficar em plano Analytics. Logs de diagnóstico de alto volume como NSG Flow Logs ou Storage verbose logs podem ir para Basic se forem raramente consultados.

3.4 Activity Log: configuração e retenção

O Activity Log existe automaticamente por 90 dias sem qualquer configuração. Para retenção além de 90 dias, você precisa criar um Diagnostic Setting no nível da assinatura que encaminha para Log Analytics, Storage Account ou Event Hub.

A tabela no Log Analytics é AzureActivity. Contém campos como:

OperationName: O que foi feito (ex: Microsoft.Compute/virtualMachines/delete)
Caller: Quem fez (email do usuário ou Service Principal)
Level: Informational, Warning, Error, Critical
ActivityStatus: Succeeded, Failed, Started
ResourceId: Qual recurso foi afetado

3.5 Data Collection Rules (DCRs): a nova arquitetura

Para VMs especificamente, a forma moderna de coletar logs é via Data Collection Rules (DCRs), que trabalham em conjunto com o Azure Monitor Agent (AMA):

DCR define: quais logs coletar (ex: eventos do Windows Event Log, syslog do Linux), filtros e transformações
AMA é o agente instalado na VM que executa as instruções da DCR
Os dados coletados vão para o destino configurado na DCR (geralmente Log Analytics)

DCRs substituem o Legacy Log Analytics Agent (MMA/OMS) e oferecem:

Filtragem de dados na fonte (envia apenas o necessário, reduzindo custo)
Transformações de dados antes da ingestão
Múltiplos destinos por DCR

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

5.1 Categorias de log por recurso

Cada tipo de recurso tem seu conjunto de categorias de log. Exemplos:

Storage Account:

Categoria	O que registra
StorageBlobLogs	Operações na API de Blob (read, write, delete)
StorageFileLogs	Operações na API de Files
StorageQueueLogs	Operações na API de Queue
StorageTableLogs	Operações na API de Table

Azure SQL Database:

Categoria	O que registra
SQLInsights	Dados de diagnóstico do Query Store
AutomaticTuning	Recomendações automáticas de ajuste
QueryStoreRuntimeStatistics	Estatísticas de runtime de queries
Errors	Erros do banco de dados
DatabaseWaitStatistics	Estatísticas de espera
Blocks	Eventos de bloqueio entre transações
Deadlocks	Deadlocks detectados

Key Vault:

Categoria	O que registra
AuditEvent	Toda operação de acesso a secrets, keys e certificates

5.2 Latência de ingestão de logs

Um comportamento importante: logs não chegam ao Log Analytics instantaneamente. A latência típica é:

Activity Log: 2 a 15 minutos após o evento
Resource Diagnostic Logs: 2 a 5 minutos
Guest OS logs via AMA: 1 a 5 minutos
Application Insights: Quase em tempo real

Ao investigar um incidente recente, aguarde alguns minutos antes de concluir que não há logs.

5.3 Configurando retenção e arquivo no Log Analytics

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

6. Formas de Implementação

6.1 Portal Azure

Quando usar: Configuração inicial, visualização de todas as categorias disponíveis, ajustes pontuais.

Criando Diagnostic Setting para um recurso:

Recurso > Monitoring > Diagnostic settings > + Add diagnostic setting

O portal lista automaticamente todas as categorias disponíveis para aquele tipo de recurso, permitindo marcar cada uma individualmente ou "allLogs" para capturar tudo.

Activity Log no nível da assinatura:

Azure Monitor > Activity Log > Export Activity Logs

6.2 Azure CLI

Criando Diagnostic Setting para Storage Account:

# Capturar todos os logs de Blob e enviar para Log Analytics
az monitor diagnostic-settings create \
  --name "storage-diagnostics" \
  --resource <storage-account-resource-id> \
  --logs '[
    {"category": "StorageBlobLogs", "enabled": true, "retentionPolicy": {"days": 0, "enabled": false}},
    {"category": "StorageFileLogs", "enabled": true, "retentionPolicy": {"days": 0, "enabled": false}}
  ]' \
  --metrics '[
    {"category": "Transaction", "enabled": true}
  ]' \
  --workspace <log-analytics-workspace-id>

Criando Diagnostic Setting com múltiplos destinos:

az monitor diagnostic-settings create \
  --name "multi-destination" \
  --resource <resource-id> \
  --logs '[{"category": "allLogs", "enabled": true}]' \
  --workspace <law-id> \
  --storage-account <storage-account-id>

Configurando Activity Log da assinatura:

az monitor diagnostic-settings subscription create \
  --name "activity-log-to-law" \
  --location eastus \
  --logs '[{"category": "Administrative", "enabled": true}, {"category": "Security", "enabled": true}, {"category": "ServiceHealth", "enabled": true}, {"category": "Alert", "enabled": true}, {"category": "Policy", "enabled": true}]' \
  --workspace <log-analytics-workspace-id>

Listando categorias disponíveis para um recurso:

az monitor diagnostic-settings categories list \
  --resource <resource-id> \
  --output table

Verificando Diagnostic Settings ativos:

az monitor diagnostic-settings list \
  --resource <resource-id> \
  --output table

6.3 Configurando Data Collection Rules para VMs

# Criar DCR para coletar eventos Windows
az monitor data-collection rule create \
  --resource-group myRG \
  --location eastus \
  --name dcr-windows-events \
  --data-flows '[
    {
      "streams": ["Microsoft-Event"],
      "destinations": ["myLAW"]
    }
  ]' \
  --data-sources '{
    "windowsEventLogs": [
      {
        "name": "eventLogsDataSource",
        "streams": ["Microsoft-Event"],
        "xPathQueries": [
          "Application!*[System[(Level=1 or Level=2 or Level=3)]]",
          "Security!*[System[(band(Keywords,13510798882111488))]]",
          "System!*[System[(Level=1 or Level=2 or Level=3)]]"
        ]
      }
    ]
  }' \
  --destinations '{
    "logAnalytics": [
      {
        "name": "myLAW",
        "workspaceResourceId": "<law-resource-id>"
      }
    ]
  }'

# Associar DCR a uma VM
az monitor data-collection rule association create \
  --resource-group myRG \
  --resource <vm-resource-id> \
  --rule-id <dcr-resource-id> \
  --name dcra-vm01

6.4 Bicep: Diagnostic Settings como código

// Diagnostic Settings para Storage Account
resource diagnosticSettings 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: 'storage-diagnostics'
  scope: storageAccount
  properties: {
    workspaceId: logAnalyticsWorkspace.id
    storageAccountId: archiveStorage.id
    logs: [
      {
        category: 'StorageBlobLogs'
        enabled: true
        retentionPolicy: {
          days: 0
          enabled: false
        }
      }
      {
        category: 'StorageFileLogs'
        enabled: true
        retentionPolicy: {
          days: 0
          enabled: false
        }
      }
    ]
    metrics: [
      {
        category: 'Transaction'
        enabled: true
        retentionPolicy: {
          days: 0
          enabled: false
        }
      }
    ]
  }
}

6.5 Configurando retenção do Log Analytics Workspace

# Configurar retenção interativa para 90 dias
az monitor log-analytics workspace update \
  --resource-group myRG \
  --workspace-name myLAW \
  --retention-time 90

# Configurar retenção de arquivo total para 2 anos (730 dias interativo + resto em arquivo)
az monitor log-analytics workspace update \
  --resource-group myRG \
  --workspace-name myLAW \
  --retention-time 90 \
  --data-retention 730

7. Controle e Segurança

7.1 Permissões para configurar logs

Operação	Role mínima
Criar/editar Diagnostic Settings em um recurso	Monitoring Contributor no recurso
Criar Activity Log Diagnostic Setting	Monitoring Contributor na assinatura
Criar/editar DCRs	Monitoring Contributor
Consultar logs no Log Analytics	Log Analytics Reader
Configurar retenção do LAW	Log Analytics Contributor

7.2 Segurança dos dados de log

Isolamento de workspace: Dados no Log Analytics são isolados por workspace. Usuários com acesso ao workspace podem consultar todos os dados nele. Para dados sensíveis de múltiplos times, considere workspaces separados ou use Table-level RBAC para restringir acesso por tabela.

Table-level RBAC:

# Restringir acesso à tabela SecurityEvent para apenas o time de segurança
az monitor log-analytics workspace table update \
  --resource-group myRG \
  --workspace-name myLAW \
  --name SecurityEvent \
  --retention-time 90

Dados em trânsito: Logs são transmitidos com HTTPS/TLS. Não há opção de desabilitar.

Imutabilidade de logs: Logs enviados ao Log Analytics não podem ser modificados. Para compliance que exige imutabilidade demonstrável, envie também para Storage Account com Immutability Policy configurada.

7.3 Custo: o principal risco de configuração incorreta

O principal risco ao configurar logs é custo inesperadamente alto. Log Analytics cobra por GB ingerido. Categorias de alto volume sem necessidade real podem gerar custos significativos.

Estratégias de controle de custo:

Habilite apenas categorias necessárias. Não use allLogs indiscriminadamente em produção de alto volume.
Use Basic Logs para categorias de alto volume raramente consultadas.
Configure transformações em DCRs para filtrar campos desnecessários antes da ingestão.
Monitore o próprio custo de ingestão via Usage table no LAW:

Usage
| where TimeGenerated > ago(30d)
| summarize TotalGB = sum(Quantity) / 1000 by DataType
| order by TotalGB desc

8. Tomada de Decisão

8.1 Qual destino usar para os logs

Necessidade	Destino	Motivo
Investigação e troubleshooting	Log Analytics Workspace	Consulta KQL flexível e rápida
Conformidade e retenção longa (> 2 anos)	Storage Account	Custo mais baixo para arquivamento
Integração com SIEM externo (Splunk, QRadar)	Event Hub	Streaming em tempo real
Visualização em Grafana ou Datadog	Event Hub ou Parceiro direto	Integração nativa
Alertas baseados em padrões de log	Log Analytics Workspace	Alert rules usam KQL
Auditoria de compliance com evidência imutável	Storage Account + Immutability	Dados não alteráveis

8.2 Retenção: interativa vs arquivo

Situação	Configuração recomendada	Motivo
Logs operacionais consultados diariamente	30-90 dias interativo	Custo equilibrado com necessidade
Logs de segurança auditados mensalmente	90-180 dias interativo	Janela de investigação razoável
Compliance que exige 1 ano de retenção	90 dias interativo + arquivo até 1 ano	Custo otimizado
Compliance que exige 7 anos	30 dias interativo + arquivo até 7 anos	Menor custo possível

8.3 Activity Log: categorias mais importantes

Categoria	O que inclui	Por que habilitar
Administrative	CRUD de recursos	Auditoria de mudanças de infraestrutura
Security	Alertas de Microsoft Defender	Detecção de ameaças
ServiceHealth	Incidentes e manutenção Azure	Contexto para problemas
Alert	Disparos de alertas	Histórico de alertas
Policy	Avaliações de Azure Policy	Compliance
Autoscale	Eventos de escala	Troubleshooting de capacidade

9. Boas Práticas

Nunca dependa apenas dos 90 dias padrão do Activity Log. Configure Diagnostic Setting da assinatura para enviar Activity Log para Log Analytics desde o início.
Crie Diagnostic Settings como código (Bicep/Terraform) para garantir que novos recursos os herdem automaticamente via Azure Policy.
Use Azure Policy com efeito DeployIfNotExists para aplicar automaticamente Diagnostic Settings em novos recursos.
Separe workspaces por propósito em ambientes grandes: um para segurança (Security Events, Sign-in logs), um para operações (diagnóstico de recursos), um para desenvolvimento. Isso reduz custo e melhora controle de acesso.
Configure a tabela SecurityEvent com retenção longa (90-180 dias) independentemente do padrão do workspace.
Monitore o custo de ingestão mensalmente com query na tabela Usage. Um pico de ingestão pode indicar misconfiguration ou atividade maliciosa gerando muitos logs.
Use DCRs com filtros XPath para coletar apenas eventos relevantes do Windows Event Log (ex: evitar coletar eventos de nível Verbose ou Debug em produção).
Configure workspace com múltiplos destinos para logs críticos: Log Analytics para consulta e Storage Account para arquivo imutável.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Activity Log perdido após 90 dias	Não havia Diagnostic Setting exportando para LAW	Configurar exportação no dia 1
Custo de Log Analytics inesperadamente alto	allLogs habilitado em recursos de alto volume	Selecionar apenas categorias necessárias
Logs de VM sem dados de memória	Apenas Agent de plataforma instalado, sem AMA	Instalar Azure Monitor Agent e configurar DCR
Logs chegam com atraso durante incidente	Latência de ingestão ignorada	Aguardar 5-10 min; verificar se o recurso está enviando via portal de diagnóstico
Consulta sem resultados para evento recente	Logs ainda em trânsito (latência)	Aguardar 2-5 minutos e repetir a consulta
Diagnostic Settings perdidos após recriar recurso	Não estava no IaC, foi criado manualmente	Incluir Diagnostic Settings no template Bicep/ARM
Retenção de arquivo não ativada mas cobrada	Configuração incorreta da política	Verificar via `az monitor log-analytics workspace show`
Dados em tabela Basic não consultáveis no alerta	Alert rules requerem tabela Analytics	Mover tabelas de alerta para plano Analytics

11. Operação e Manutenção

11.1 Verificando configurações de diagnóstico existentes

# Listar todas as Diagnostic Settings de um recurso
az monitor diagnostic-settings list \
  --resource <resource-id>

# Ver configuração detalhada de uma setting específica
az monitor diagnostic-settings show \
  --name "storage-diagnostics" \
  --resource <resource-id>

# Listar DCRs existentes
az monitor data-collection rule list \
  --resource-group myRG \
  --output table

11.2 Auditando cobertura de logs na assinatura

Query KQL para identificar recursos sem Diagnostic Settings:

// Recursos que NÃO enviaram nenhum log nas últimas 24 horas
Resources
| where type in~ (
    "microsoft.storage/storageaccounts",
    "microsoft.keyvault/vaults",
    "microsoft.sql/servers/databases"
)
| join kind=leftouter (
    AzureDiagnostics
    | where TimeGenerated > ago(24h)
    | summarize LastLog = max(TimeGenerated) by ResourceId
    | extend ResourceId = tolower(ResourceId)
) on $left.id == $right.ResourceId
| where isempty(LastLog)
| project name, type, resourceGroup

11.3 Monitorando a saúde da ingestão de logs

// Latência média de ingestão nas últimas 6 horas
Heartbeat
| where TimeGenerated > ago(6h)
| summarize AvgLatency = avg(TimeGenerated - RawTime) by Computer
| order by AvgLatency desc

// Volume de ingestão por tabela nas últimas 24 horas (em GB)
Usage
| where TimeGenerated > ago(1d)
| summarize TotalGB = round(sum(Quantity) / 1024, 2) by DataType
| order by TotalGB desc
| take 20

11.4 Limites importantes

Aspecto	Limite
Diagnostic Settings por recurso	5
Activity Log: retenção padrão	90 dias
Log Analytics retenção interativa máxima	730 dias
Log Analytics retenção de arquivo máxima	7 anos (2.557 dias)
Latência de ingestão típica	2 a 5 minutos
Throughput máximo de ingestão por LAW	Sem limite documentado (scale automático)
Workspaces por assinatura	Sem limite prático
DCR associations por VM	10

12. Integração e Automação

12.1 Azure Policy para aplicar Diagnostic Settings automaticamente

# Policy built-in: habilitar Diagnostic Setting em Storage Accounts
az policy assignment create \
  --name "storage-diagnostic-settings" \
  --policy "59760408-1f12-4b5a-89a5-ce2d23f97e46" \
  --scope "/subscriptions/<sub-id>" \
  --params '{"logAnalytics": {"value": "<law-resource-id>"}}'

Políticas com efeito DeployIfNotExists garantem que qualquer novo recurso na assinatura tenha Diagnostic Settings criados automaticamente, mesmo sem intervenção manual.

12.2 Exportando para Event Hub e integrando com Splunk

# Criar Event Hub namespace e hub para logs
az eventhubs namespace create \
  --resource-group myRG \
  --name myLogStreamNamespace \
  --location eastus

az eventhubs eventhub create \
  --resource-group myRG \
  --namespace-name myLogStreamNamespace \
  --name azure-logs

# Criar Diagnostic Setting enviando para Event Hub
az monitor diagnostic-settings create \
  --name "stream-to-eventhub" \
  --resource <resource-id> \
  --logs '[{"category": "allLogs", "enabled": true}]' \
  --event-hub-name azure-logs \
  --event-hub-rule <eventhub-auth-rule-id>

12.3 Microsoft Sentinel: SIEM nativo do Azure

O Microsoft Sentinel usa o Log Analytics Workspace como base e adiciona capacidades de SIEM (Security Information and Event Management). A integração é direta:

# Habilitar Sentinel no LAW
az sentinel onboarding-state create \
  --resource-group myRG \
  --workspace-name myLAW

Após habilitado, o Sentinel usa as tabelas existentes (AzureActivity, SigninLogs, SecurityEvent, etc.) para detecção de ameaças e investigação.

13. Resumo Final

Conceitos essenciais:

Activity Log existe automaticamente por 90 dias e registra operações de plano de controle (CRUD de recursos). Para retenção longa, configure Diagnostic Setting na assinatura.
Resource Logs registram operações de plano de dados (o que acontece dentro do recurso). Requerem Diagnostic Settings configurados explicitamente para cada recurso.
Log Analytics Workspace é o destino central para consulta KQL. Tem retenção interativa (até 730 dias) e retenção de arquivo (até 7 anos).
Data Collection Rules (DCRs) com Azure Monitor Agent são a forma moderna de coletar logs de VMs, substituindo o Legacy Agent.

Diferenças críticas:

Activity Log vs Resource Logs: Activity = plano de controle (quem mudou o recurso). Resource = plano de dados (o que aconteceu dentro do recurso).
Log Analytics (Analytics) vs Basic Logs: Analytics = consulta gratuita, ingestão cara, ideal para logs consultados frequentemente. Basic = ingestão barata, consulta paga por GB, ideal para logs de alto volume raramente consultados.
Retenção interativa vs Arquivo: Interativa = consulta KQL normal (custo maior). Arquivo = dados acessíveis via Restore temporário (custo menor).
Diagnostic Setting vs DCR: Diagnostic Setting roteia logs de recursos PaaS. DCR coleta logs do SO interno de VMs via Azure Monitor Agent.

O que precisa ser lembrado:

Logs têm latência de 2 a 5 minutos após o evento. Consultas imediatas podem não encontrar eventos recentes.
allLogs em recursos de alto volume pode gerar custos significativos. Selecione apenas categorias necessárias.
Diagnostic Settings são destruídos com o recurso. Sem IaC, precisam ser recriados manualmente.
Activity Log padrão fica disponível por apenas 90 dias. Para auditoria de longo prazo, configure exportação imediatamente.
Até 5 Diagnostic Settings por recurso, permitindo múltiplos destinos simultâneos.
Use Azure Policy com DeployIfNotExists para garantir cobertura de logs em toda a assinatura automaticamente.

1. Intuição Inicial​

2. Contexto​

2.1 O ecossistema de logs no Azure Monitor​

2.2 Os três tipos principais de logs​

3. Construção dos Conceitos​

3.1 Log Analytics Workspace: o destino central​

3.2 Diagnostic Settings: o mecanismo de roteamento​

3.3 Tabelas do Log Analytics e planos de retenção​

3.4 Activity Log: configuração e retenção​

3.5 Data Collection Rules (DCRs): a nova arquitetura​

4. Visão Estrutural​

5. Funcionamento na Prática​

5.1 Categorias de log por recurso​

5.2 Latência de ingestão de logs​

5.3 Configurando retenção e arquivo no Log Analytics​

6. Formas de Implementação​

6.1 Portal Azure​

6.2 Azure CLI​

6.3 Configurando Data Collection Rules para VMs​

6.4 Bicep: Diagnostic Settings como código​

6.5 Configurando retenção do Log Analytics Workspace​

7. Controle e Segurança​

7.1 Permissões para configurar logs​

7.2 Segurança dos dados de log​

7.3 Custo: o principal risco de configuração incorreta​

8. Tomada de Decisão​

8.1 Qual destino usar para os logs​

8.2 Retenção: interativa vs arquivo​

8.3 Activity Log: categorias mais importantes​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

11.1 Verificando configurações de diagnóstico existentes​

11.2 Auditando cobertura de logs na assinatura​

11.3 Monitorando a saúde da ingestão de logs​

11.4 Limites importantes​

12. Integração e Automação​

12.1 Azure Policy para aplicar Diagnostic Settings automaticamente​

12.2 Exportando para Event Hub e integrando com Splunk​

12.3 Microsoft Sentinel: SIEM nativo do Azure​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

2.1 O ecossistema de logs no Azure Monitor

2.2 Os três tipos principais de logs

3. Construção dos Conceitos

3.1 Log Analytics Workspace: o destino central

3.2 Diagnostic Settings: o mecanismo de roteamento

3.3 Tabelas do Log Analytics e planos de retenção

3.4 Activity Log: configuração e retenção

3.5 Data Collection Rules (DCRs): a nova arquitetura

4. Visão Estrutural

5. Funcionamento na Prática

5.1 Categorias de log por recurso

5.2 Latência de ingestão de logs

5.3 Configurando retenção e arquivo no Log Analytics

6. Formas de Implementação

6.1 Portal Azure

6.2 Azure CLI

6.3 Configurando Data Collection Rules para VMs

6.4 Bicep: Diagnostic Settings como código

6.5 Configurando retenção do Log Analytics Workspace

7. Controle e Segurança

7.1 Permissões para configurar logs

7.2 Segurança dos dados de log

7.3 Custo: o principal risco de configuração incorreta

8. Tomada de Decisão

8.1 Qual destino usar para os logs

8.2 Retenção: interativa vs arquivo

8.3 Activity Log: categorias mais importantes

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

11.1 Verificando configurações de diagnóstico existentes

11.2 Auditando cobertura de logs na assinatura

11.3 Monitorando a saúde da ingestão de logs

11.4 Limites importantes

12. Integração e Automação

12.1 Azure Policy para aplicar Diagnostic Settings automaticamente

12.2 Exportando para Event Hub e integrando com Splunk

12.3 Microsoft Sentinel: SIEM nativo do Azure

13. Resumo Final