Fundamentação Teórica: Configure and interpret monitoring of virtual machines, storage accounts, and networks by using Azure Monitor Insights

1. Intuição Inicial

Imagine que você é responsável por um data center físico. Você tem painéis com luzes indicando o estado de cada servidor, alertas sonoros quando um disco está cheio, e relatórios diários de consumo de rede. Sem isso, você só descobriria problemas quando uma aplicação caísse.

No Azure, o equivalente a esse painel de controle é o Azure Monitor. Ele coleta dados de desempenho, disponibilidade e comportamento de todos os seus recursos, e o Azure Monitor Insights é a camada especializada que transforma esses dados brutos em visualizações e análises prontas para uso, específicas por tipo de recurso.

A diferença entre Azure Monitor genérico e Azure Monitor Insights é essa: o Monitor é o motor de coleta e análise; o Insights é o painel de instrumentos já configurado e otimizado para cada tipo de recurso (VMs, Storage, Redes).

2. Contexto

O Azure Monitor existe porque recursos em nuvem são dinâmicos, distribuídos e efêmeros. Uma VM pode estar consumindo 100% de CPU sem que ninguém perceba. Um storage account pode estar gerando latência anormal. Uma VNet pode ter tráfego bloqueado silenciosamente por um NSG.

Sem observabilidade, você opera no escuro.

O Azure Monitor se posiciona como a plataforma central de observabilidade do Azure, coletando três tipos de dados:

Métricas: valores numéricos coletados em intervalos regulares (ex: CPU %, bytes de rede).
Logs: registros estruturados de eventos e operações (ex: login na VM, operação em blob).
Traces: rastros de execução distribuída em aplicações (mais relevante para Application Insights).

O Azure Monitor Insights consome esses dados e os apresenta em experiências visuais pré-construídas, sem que você precise criar dashboards do zero.

100%

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

3. Construção dos Conceitos

3.1 A Base: Métricas vs Logs

Antes de entrar nos Insights específicos, é essencial distinguir esses dois pilares:

Característica	Métricas	Logs
Tipo de dado	Numérico, séries temporais	Texto estruturado, registros
Retenção padrão	93 dias	Configurável (30 a 730 dias)
Latência	Segundos	1 a 2 minutos
Custo	Incluído (básico)	Baseado em volume ingerido
Consulta	Métricas Explorer	Log Analytics (KQL)
Exemplos	CPU %, Disk IOPS, Bytes/s	Login de usuário, erro de aplicação, criação de recurso

Métricas são ideais para alertas em tempo real e visualizações de tendência. Logs são ideais para diagnóstico profundo, correlação de eventos e auditoria.

3.2 Log Analytics Workspace

O Log Analytics Workspace é o repositório central onde os logs do Azure Monitor são armazenados e consultados. Ele é um recurso do Azure que você cria em uma região e subscription.

Características importantes:

Múltiplos recursos podem enviar dados para o mesmo workspace.
As consultas são feitas em KQL (Kusto Query Language).
O workspace define a política de retenção de dados.
Insights de VMs e Redes dependem de um workspace configurado.

3.3 Diagnostic Settings

Para que logs e algumas métricas detalhadas cheguem ao Log Analytics Workspace, você precisa configurar Diagnostic Settings em cada recurso.

Cada Diagnostic Setting define:

O que coletar: categorias de logs e métricas.
Para onde enviar: Log Analytics Workspace, Storage Account, Event Hub, ou Partner Solutions.

Ponto não óbvio: métricas de plataforma (Platform Metrics) são coletadas automaticamente pelo Azure sem configuração. Mas logs de recursos (Resource Logs) e métricas detalhadas exigem Diagnostic Settings explícitos.

4. VM Insights

4.1 O que é

VM Insights é a experiência de monitoramento especializada para máquinas virtuais e Virtual Machine Scale Sets. Ele fornece visualizações prontas de desempenho e mapas de dependência entre processos e conexões de rede.

4.2 Pré-requisito: Azure Monitor Agent

Para que VM Insights funcione, cada VM precisa ter o Azure Monitor Agent (AMA) instalado. O AMA substitui os agentes legados (MMA e Dependency Agent standalone) e é a abordagem recomendada atualmente.

O AMA coleta:

Métricas de desempenho do sistema operacional (CPU, memória, disco, rede).
Logs de eventos do Windows e Syslog do Linux.
Dados de processos e conexões de rede (para o Map feature).

A instalação do AMA pode ser feita via:

Extensão de VM no portal.
Azure Policy (para implantação em escala).
Bicep/ARM/Terraform.

4.3 Data Collection Rules (DCR)

O AMA não coleta dados de forma autônoma. Ele precisa de uma Data Collection Rule (DCR) que define o que coletar, como transformar, e para onde enviar.

100%

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

4.4 O que o VM Insights mostra

VM Insights apresenta três abas principais:

Aba Performance: Exibe gráficos de desempenho prontos para cada VM ou grupo de VMs:

CPU Utilization %
Available Memory (MB)
Bytes Sent/Received per second
Disk I/O (reads e writes)
Logical Disk Space Used %

Esses dados vêm das métricas coletadas pelo AMA e podem ser filtrados por intervalo de tempo, assinatura, grupo de recursos ou VM individual.

Aba Map: Exibe um mapa visual de dependências: quais processos estão rodando na VM e quais conexões de rede TCP estão ativas, incluindo origem, destino e porta. Isso é valioso para:

Descobrir comunicações não documentadas entre serviços.
Mapear dependências antes de uma migração.
Diagnosticar falhas de conectividade entre aplicações.

Aba Overview (Get Started): Mostra o status de habilitação do VM Insights por VM, indicando quais têm o agente instalado e configurado.

4.5 Tabelas KQL relevantes para VMs

Quando você consulta dados de VMs no Log Analytics, as principais tabelas são:

Tabela	Conteúdo
`Perf`	Métricas de desempenho coletadas pelo agente (CPU, memória, disco)
`Event`	Eventos do Windows Event Log
`Syslog`	Logs do sistema Linux
`VMConnection`	Conexões TCP de e para a VM (requer Map feature)
`VMProcess`	Processos em execução na VM
`Heartbeat`	Sinal de vida do agente a cada minuto

Exemplo de consulta KQL para verificar VMs sem heartbeat nos últimos 5 minutos:

Heartbeat
| where TimeGenerated > ago(5m)
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| where LastHeartbeat < ago(5m)

5. Storage Insights

5.1 O que é

Storage Insights (parte do Azure Monitor for Storage) fornece uma visão unificada do desempenho, capacidade e disponibilidade de Storage Accounts. Ele funciona tanto para Blob, File, Queue e Table storage.

5.2 O que monitora

Storage Insights coleta dados de dois tipos:

Métricas de transação (coletadas automaticamente, sem Diagnostic Settings):

Disponibilidade (Availability %)
Total de transações
Latência média e de ponta a ponta (E2E Latency)
Taxa de erros (ServerErrors, ClientErrors)

Métricas de capacidade (coletadas automaticamente):

Used Capacity
Blob Count
Container Count

Logs de recursos (exigem Diagnostic Settings habilitados):

StorageRead, StorageWrite, StorageDelete: operações detalhadas por blob, arquivo ou fila.
Inclui: IP de origem, operação, status, tempo de resposta, tamanho de objeto.

5.3 Visão Estrutural do Storage Insights

100%

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

5.4 Tabelas KQL relevantes para Storage

Tabela	Conteúdo
`StorageBlobLogs`	Operações em blobs (read, write, delete)
`StorageFileLogs`	Operações em Azure Files
`StorageQueueLogs`	Operações em filas
`StorageTableLogs`	Operações em tabelas

Exemplo de consulta KQL para identificar os 10 IPs com mais operações de leitura em blobs:

StorageBlobLogs
| where OperationName == "GetBlob"
| summarize Count = count() by CallerIpAddress
| top 10 by Count desc

5.5 Comportamento não óbvio do Storage Insights

O Storage Insights agrega dados de múltiplos storage accounts em uma única view, permitindo comparar performance entre contas. Isso é valioso em ambientes com dezenas de storage accounts.

Outro ponto importante: a granularidade das métricas de transação é de 1 minuto. Para análises de latência em operações críticas, isso pode ser suficiente para identificar picos, mas não para correlação exata com eventos específicos de log.

6. Network Insights

6.1 O que é

Network Insights (Azure Monitor for Networks) oferece uma visão topológica e de saúde de todos os recursos de rede do Azure em uma subscription ou escopo definido. Ele é a experiência centralizada para monitorar VNets, NSGs, Load Balancers, Application Gateways, VPN Gateways, ExpressRoute, Private Endpoints e muito mais.

6.2 Visão Geral do Network Insights

O Network Insights está organizado em abas:

Overview: Apresenta um resumo de saúde de todos os recursos de rede agrupados por tipo: quantos estão saudáveis, em alerta ou em estado crítico.

Connectivity: Permite testar e visualizar conectividade entre recursos usando Connection Monitor. Mostra latência, perda de pacote e status de reachability entre origem e destino.

Traffic: Integra dados do NSG Flow Logs e do Traffic Analytics para visualizar padrões de tráfego. Mostra os pares de IP mais ativos, protocolos usados e fluxos bloqueados vs permitidos.

Diagnostic Toolkit: Agrupa ferramentas de diagnóstico como IP Flow Verify, Next Hop, Effective Routes, Security Group View e Packet Capture, todas fornecidas pelo Network Watcher.

Topology: Exibe um diagrama visual interativo da topologia de rede: VNets, subnets, VMs, Load Balancers, Gateways e suas conexões.

6.3 NSG Flow Logs e Traffic Analytics

NSG Flow Logs é um recurso do Network Watcher que registra informações sobre tráfego IP que passa por um NSG. Cada registro inclui:

IP de origem e destino
Porta de origem e destino
Protocolo
Decisão do NSG (allow/deny)
Direção (inbound/outbound)
Volume de bytes e pacotes (versão 2)

Os Flow Logs são enviados para um Storage Account. Para análise interativa, você habilita o Traffic Analytics, que processa os flow logs e os envia ao Log Analytics Workspace.

100%

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

Tabela KQL do Traffic Analytics:

Tabela	Conteúdo
`AzureNetworkAnalytics_CL`	Fluxos processados pelo Traffic Analytics

Exemplo de consulta para encontrar tráfego bloqueado por NSGs:

AzureNetworkAnalytics_CL
| where FlowStatus_s == "D"
| summarize BlockedFlows = count() by NSGName_s, DestPort_d
| sort by BlockedFlows desc

6.4 Connection Monitor

O Connection Monitor é um recurso do Network Watcher que realiza testes de conectividade contínuos entre origens e destinos. Ele substitui os recursos legados Connection Monitor (classic) e Network Performance Monitor.

Componentes:

Test Group: conjunto de origens e destinos com critérios de sucesso.
Test Configuration: protocolo (TCP, HTTP, ICMP), porta, frequência de teste.
Sources: VMs com Azure Monitor Agent, Arc-enabled servers.
Destinations: endereço IP, FQDN, URL, ou recurso Azure.

O Connection Monitor produz métricas de:

Checks Failed %: percentual de testes que falharam.
Round Trip Time (ms): latência medida.

Esses dados aparecem na aba Connectivity do Network Insights.

6.5 Network Watcher: Ferramentas de Diagnóstico

O Network Watcher é o serviço subjacente que fornece as ferramentas de diagnóstico de rede no Azure. Ele é habilitado automaticamente por região quando você cria o primeiro recurso de rede.

Ferramenta	O que faz	Quando usar
IP Flow Verify	Testa se tráfego seria permitido ou bloqueado por NSG	VM não consegue conectar em uma porta
Next Hop	Mostra o próximo salto de roteamento para um destino	Diagnosticar roteamento incorreto
Effective Routes	Lista todas as rotas efetivas de uma NIC	Entender roteamento real da VM
Security Group View	Lista todas as regras NSG efetivas para uma NIC	Auditoria de segurança
Packet Capture	Captura pacotes de rede de uma VM	Diagnóstico profundo de protocolo
Connection Troubleshoot	Testa conectividade pontual entre origem e destino	Verificação rápida de conectividade

7. Alertas no Azure Monitor

Alertas são a camada de resposta automatizada do Azure Monitor. Eles monitoram condições e disparam ações quando essas condições são atendidas.

7.1 Componentes de um Alerta

100%

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

7.2 Tipos de Alerta

Tipo	Base de dados	Latência	Uso típico
Metric Alert	Platform Metrics	Segundos	CPU alta, disco cheio, latência de storage
Log Alert	Log Analytics (KQL)	1 a 5 minutos	Eventos de erro, ausência de heartbeat
Activity Log Alert	Activity Log	Minutos	Exclusão de recurso, mudança de configuração
Smart Detection Alert	Application Insights	Automático	Anomalias em aplicações

7.3 Action Groups

Um Action Group define as ações que serão executadas quando um alerta é disparado. Um mesmo Action Group pode ser reutilizado em múltiplas Alert Rules.

Tipos de ação:

Notificação: Email, SMS, Push para Azure app, Voice call.
Ação automatizada: Azure Function, Logic App, Webhook, Automation Runbook, ITSM.

Boas práticas de Action Groups:

Crie Action Groups por equipe ou severidade, não por recurso.
Um Action Group "Crítico" pode notificar múltiplos canais ao mesmo tempo.
Action Groups suportam Rate Limiting para evitar flood de notificações.

8. Workbooks

Workbooks são relatórios interativos e parametrizáveis dentro do Azure Monitor. VM Insights, Storage Insights e Network Insights usam Workbooks internamente para exibir suas visualizações.

Você pode:

Usar Workbooks prontos (templates) fornecidos pelo Azure.
Personalizar Workbooks existentes.
Criar Workbooks do zero combinando métricas, logs KQL, texto e parâmetros.

Workbooks suportam:

Gráficos de série temporal.
Tabelas de resultados KQL.
Mapas geográficos.
Tiles de KPI.
Parâmetros de filtro interativos (subscription, resource group, intervalo de tempo).

9. Formas de Implementação

9.1 Portal do Azure

Quando usar: configuração inicial, exploração de dashboards, análise ad-hoc, Workbooks interativos.

Caminho para VM Insights: Azure Monitor > Insights > Virtual Machines

Caminho para Storage Insights: Azure Monitor > Insights > Storage Accounts

Caminho para Network Insights: Azure Monitor > Insights > Networks

Limitações: configuração manual para cada recurso, sem repetibilidade.

9.2 Azure CLI

Habilitar Diagnostic Settings via CLI:

az monitor diagnostic-settings create \
  --name "MyDiagSettings" \
  --resource "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vmName}" \
  --workspace "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}" \
  --logs '[{"category": "Administrative", "enabled": true}]' \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

Criar uma Alert Rule via CLI:

az monitor metrics alert create \
  --name "HighCPUAlert" \
  --resource-group MyRG \
  --scopes "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vmName}" \
  --condition "avg Percentage CPU > 90" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Insights/actionGroups/{agName}"

9.3 Azure Policy para habilitação em escala

Para garantir que todas as VMs de uma subscription ou management group tenham o AMA instalado e VM Insights habilitado, use Azure Policy com efeito DeployIfNotExists.

Políticas relevantes disponíveis na biblioteca:

Configure Windows virtual machines to run Azure Monitor Agent
Configure Linux virtual machines to run Azure Monitor Agent
Configure VM Insights data collection rule association

Isso cria uma remediation task que aplica automaticamente o agente e a DCR em VMs existentes e novas.

9.4 Bicep / ARM para Diagnostic Settings

resource diagnosticSetting 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  name: 'MyDiagSettings'
  scope: storageAccount
  properties: {
    workspaceId: logAnalyticsWorkspace.id
    logs: [
      {
        category: 'StorageRead'
        enabled: true
      }
      {
        category: 'StorageWrite'
        enabled: true
      }
      {
        category: 'StorageDelete'
        enabled: true
      }
    ]
    metrics: [
      {
        category: 'Transaction'
        enabled: true
      }
    ]
  }
}

10. Controle e Segurança

Acesso ao Log Analytics Workspace:

O workspace tem RBAC independente dos recursos que enviam dados.
A role Log Analytics Reader permite consultar dados mas não modificar configurações.
A role Log Analytics Contributor permite gerenciar o workspace completo.
Você pode configurar table-level RBAC para restringir acesso a tabelas específicas dentro do workspace.

Dados sensíveis em logs:

Logs de storage podem conter IPs de clientes, nomes de blobs e padrões de acesso.
NSG Flow Logs contêm informações de tráfego de rede, incluindo IPs internos e externos.
Defina políticas de retenção apropriadas (mínimo necessário) para dados sensíveis.

Diagnóstico de acesso ao workspace:

Use Azure Monitor Private Link Scope (AMPLS) para garantir que dados de recursos sejam enviados ao workspace via rede privada, sem tráfego pela internet pública.

11. Tomada de Decisão

Quando habilitar cada tipo de coleta

Situação	O que habilitar	Motivo
Alertar quando CPU da VM ultrapassa 90%	Platform Metrics + Metric Alert	Métricas têm latência de segundos, ideal para alertas reativos
Diagnosticar por que uma VM ficou offline	VM Insights + Heartbeat table	Heartbeat registra disponibilidade do agente minuto a minuto
Auditar quem deletou um blob no Storage	Diagnostic Settings com StorageDelete logs	Logs de recurso registram operações com identidade e timestamp
Identificar quais IPs estão sendo bloqueados pelo NSG	NSG Flow Logs + Traffic Analytics	Flow Logs registram cada decisão do NSG
Monitorar latência entre dois serviços	Connection Monitor	Testes contínuos com histórico de latência e perda
Entender dependências de uma VM antes de migrar	VM Insights Map feature	Exibe conexões TCP e processos ativos em tempo real
Monitorar disponibilidade de múltiplos storage accounts	Storage Insights	Visão agregada sem precisar criar dashboards individuais

Quando usar métricas vs logs para alertas

Critério	Métricas	Logs (KQL)
Latência necessária	Segundos	Minutos
Tipo de condição	Threshold numérico	Condição complexa, correlação
Exemplo	CPU > 90% por 5 min	Mais de 10 falhas de login em 1 hora
Custo de avaliação	Incluído	Baseado em volume de dados analisado

12. Boas Práticas

Log Analytics Workspace:

Use um workspace centralizado por ambiente (prod, dev) em vez de um por recurso. Facilita correlação de eventos e reduz custo de gestão.
Configure retenção de dados de acordo com requisitos de compliance. O padrão é 30 dias; muitas regulamentações exigem 90 ou 365 dias.
Monitore o custo de ingestão de dados. Use Log Analytics Workspace Insights (sim, existe um Insights para o próprio workspace) para identificar tabelas que geram mais volume.

VM Insights:

Implante o AMA via Azure Policy para garantir cobertura automática de novas VMs.
Use DCRs centralizadas e reutilizáveis, não uma por VM.
Monitore a tabela Heartbeat para detectar VMs com agente parado ou VM offline.

Storage Insights:

Habilite logs de recurso apenas para storage accounts com dados sensíveis ou requisito de auditoria. Logs de armazenamento têm custo por volume.
Para storage accounts de uso geral, métricas de transação automáticas já cobrem a maioria dos casos de monitoramento de disponibilidade e latência.

Network Insights:

Habilite NSG Flow Logs versão 2 (não versão 1). A versão 2 inclui dados de bytes e pacotes, essenciais para Traffic Analytics.
Configure Traffic Analytics com intervalo de processamento de 10 minutos para visualizações mais atualizadas.
Use Connection Monitor para monitorar caminhos críticos de conectividade (VM para banco de dados, VM para endpoint externo).

Alertas:

Evite criar alertas diretamente em recursos individuais. Prefira alertas em grupos de recursos ou subscriptions quando possível.
Configure supressão de alertas (alert suppression / action rule) para janelas de manutenção planejada.
Use severidades de alerta consistentes (Sev 0 = crítico, Sev 4 = informativo) e mapeie para Action Groups diferentes.

13. Erros Comuns

Não configurar Diagnostic Settings e achar que os logs chegam automaticamente: Platform Metrics chegam sem configuração, mas Resource Logs não. Muita gente habilita VM Insights e não consegue ver dados de log porque esqueceu os Diagnostic Settings.

Confundir Log Analytics Workspace com Storage Account como destino de logs: Você pode enviar logs para Storage Account (para arquivamento barato) ou para Log Analytics (para análise interativa). Logs no Storage não aparecem no Network Insights ou VM Insights. Logs precisam ir para o Log Analytics Workspace para serem consultáveis via KQL e exibidos nos Insights.

Instalar o agente legado (MMA) em vez do AMA: O Microsoft Monitoring Agent (MMA) está em processo de depreciação. Para novos deployments, sempre use o Azure Monitor Agent (AMA) com DCRs.

Esquecer de vincular o Connection Monitor a um Log Analytics Workspace: Sem esse vínculo, os dados de teste do Connection Monitor não são armazenados e não aparecem no Network Insights.

NSG Flow Logs habilitados mas Traffic Analytics não configurado: Os Flow Logs ficam no Storage Account como arquivos JSON, mas não aparecem na aba Traffic do Network Insights. Traffic Analytics precisa ser habilitado separadamente e apontado para um Log Analytics Workspace.

Criar um Alert Rule sem Action Group: O alerta dispara, fica visível no portal, mas ninguém é notificado. Action Group é obrigatório para notificações ou ações automatizadas.

Interpretar "Available Memory" incorretamente: No VM Insights, "Available Memory" é a memória disponível para novas alocações. Em Linux, valores baixos nem sempre indicam problema, pois o kernel usa memória livre como cache de disco (buffer/cache). A métrica relevante no Linux é MemAvailable, não MemFree.

14. Operação e Manutenção

Verificar cobertura de monitoramento:

No VM Insights (Get Started tab), verifique quais VMs têm o agente instalado e configurado.
Use a consulta Heartbeat | summarize LastHeartbeat = max(TimeGenerated) by Computer para identificar VMs sem heartbeat recente.

Verificar ingestão de dados:

Usage
| where TimeGenerated > ago(24h)
| summarize TotalGB = sum(Quantity) / 1000 by DataType
| sort by TotalGB desc

Limites importantes:

Recurso	Limite
Retenção máxima no Log Analytics	730 dias (com Archive até 12 anos)
Alertas de métrica por subscription	5.000
Action Groups por subscription	2.000
NSG Flow Logs retidos no Storage	Definido por você (custo de storage)
Frequência mínima de avaliação de alertas de métrica	1 minuto
Frequência mínima de avaliação de alertas de log	1 minuto

15. Integração e Automação

Azure Monitor + Azure Automation:

Alertas podem disparar Runbooks do Azure Automation para ações de remediação automática.
Exemplo: CPU persistentemente alta dispara um Runbook que aumenta o SKU da VM automaticamente.

Azure Monitor + Logic Apps:

Action Groups podem chamar Logic Apps para fluxos de ITSM, abertura de tickets, notificações em Teams ou Slack.

Azure Monitor + Grafana:

O Azure Managed Grafana integra nativamente com Azure Monitor como data source.
Permite criar dashboards Grafana usando métricas e logs do Azure Monitor sem exportar dados.

Azure Monitor + Microsoft Sentinel:

O Sentinel (SIEM/SOAR) consome dados do Log Analytics Workspace.
NSG Flow Logs, Activity Logs e Resource Logs de storage podem alimentar o Sentinel para detecção de ameaças.

Exportação contínua de dados:

Use Data Export Rules no Log Analytics para exportar tabelas específicas continuamente para um Storage Account ou Event Hub.
Isso permite integração com pipelines de dados externos (Azure Data Explorer, SIEM terceiros, etc.).

16. Resumo Final

Pontos essenciais:

O Azure Monitor é a plataforma central de observabilidade, coletando métricas, logs e traces.
Azure Monitor Insights são experiências pré-construídas para VMs, Storage e Redes, consumindo dados do Azure Monitor.
Métricas têm latência de segundos e retenção de 93 dias. Logs têm latência de minutos e retenção configurável.
VM Insights requer o Azure Monitor Agent (AMA) e uma Data Collection Rule (DCR) em cada VM.
Storage Insights usa métricas automáticas para transação e capacidade; logs detalhados exigem Diagnostic Settings.
Network Insights integra NSG Flow Logs, Traffic Analytics, Connection Monitor e Network Watcher.
NSG Flow Logs registram decisões de allow/deny por fluxo IP. Traffic Analytics processa esses logs para visualização no Log Analytics.
Alertas são compostos por Alert Rule (condição) e Action Group (ação). Um Action Group pode ser reutilizado em múltiplas regras.
Workbooks são a tecnologia de relatório interativo usada internamente por todos os Insights.

Diferenças críticas:

Platform Metrics chegam automaticamente; Resource Logs precisam de Diagnostic Settings.
AMA substitui MMA; novos deployments devem sempre usar AMA com DCR.
NSG Flow Logs no Storage não aparecem no Network Insights; Traffic Analytics é necessário para isso.
Log Analytics é para análise interativa; Storage Account é para arquivamento barato.
Metric Alert tem latência de segundos; Log Alert tem latência de minutos.

O que precisa ser lembrado para o AZ-104:

VM Insights exige AMA instalado e DCR associada.
Diagnostic Settings devem ser configurados explicitamente para logs de recurso.
Traffic Analytics precisa de NSG Flow Logs habilitados E um Log Analytics Workspace configurado.
Connection Monitor usa o Network Watcher e precisa do AMA nas VMs de origem.
Alertas sem Action Group disparam mas não notificam ninguém.
Storage Insights mostra dados de múltiplos storage accounts em uma visão unificada.
A tabela Heartbeat é a forma principal de verificar disponibilidade do agente nas VMs.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 A Base: Métricas vs Logs​

3.2 Log Analytics Workspace​

3.3 Diagnostic Settings​

4. VM Insights​

4.1 O que é​

4.2 Pré-requisito: Azure Monitor Agent​

4.3 Data Collection Rules (DCR)​

4.4 O que o VM Insights mostra​

4.5 Tabelas KQL relevantes para VMs​

5. Storage Insights​

5.1 O que é​

5.2 O que monitora​

5.3 Visão Estrutural do Storage Insights​

5.4 Tabelas KQL relevantes para Storage​

5.5 Comportamento não óbvio do Storage Insights​

6. Network Insights​

6.1 O que é​

6.2 Visão Geral do Network Insights​

6.3 NSG Flow Logs e Traffic Analytics​

6.4 Connection Monitor​

6.5 Network Watcher: Ferramentas de Diagnóstico​

7. Alertas no Azure Monitor​

7.1 Componentes de um Alerta​

7.2 Tipos de Alerta​

7.3 Action Groups​

8. Workbooks​

9. Formas de Implementação​

9.1 Portal do Azure​

9.2 Azure CLI​

9.3 Azure Policy para habilitação em escala​

9.4 Bicep / ARM para Diagnostic Settings​

10. Controle e Segurança​

11. Tomada de Decisão​

Quando habilitar cada tipo de coleta​

Quando usar métricas vs logs para alertas​

12. Boas Práticas​

13. Erros Comuns​

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

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

16. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 A Base: Métricas vs Logs

3.2 Log Analytics Workspace

3.3 Diagnostic Settings

4. VM Insights

4.1 O que é

4.2 Pré-requisito: Azure Monitor Agent

4.3 Data Collection Rules (DCR)

4.4 O que o VM Insights mostra

4.5 Tabelas KQL relevantes para VMs

5. Storage Insights

5.1 O que é

5.2 O que monitora

5.3 Visão Estrutural do Storage Insights

5.4 Tabelas KQL relevantes para Storage

5.5 Comportamento não óbvio do Storage Insights

6. Network Insights

6.1 O que é

6.2 Visão Geral do Network Insights

6.3 NSG Flow Logs e Traffic Analytics

6.4 Connection Monitor

6.5 Network Watcher: Ferramentas de Diagnóstico

7. Alertas no Azure Monitor

7.1 Componentes de um Alerta

7.2 Tipos de Alerta

7.3 Action Groups

8. Workbooks

9. Formas de Implementação

9.1 Portal do Azure

9.2 Azure CLI

9.3 Azure Policy para habilitação em escala

9.4 Bicep / ARM para Diagnostic Settings

10. Controle e Segurança

11. Tomada de Decisão

Quando habilitar cada tipo de coleta

Quando usar métricas vs logs para alertas

12. Boas Práticas

13. Erros Comuns

14. Operação e Manutenção

15. Integração e Automação

16. Resumo Final