Azure Monitor: o que é, componentes e como usar em 2026

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado mai/2019Atualizado set/2026

O Azure Monitor é a plataforma nativa de observabilidade da Microsoft Azure. Ele concentra métricas, logs, rastreamentos e eventos de recursos na nuvem, em ambientes híbridos e, via Azure Arc, em outras nuvens. Antes de desenhar a estratégia de operação, portanto, vale entender como a ferramenta coleta, armazena e analisa telemetria.

Este guia foi escrito para quem decide sobre observabilidade na Azure. Ele cobre a arquitetura, os componentes principais e a coleta na prática. Além disso, traz a tabela de preços de 2026 com a comparação entre Brazil South e East US. Em seguida, expõe as limitações da ferramenta nativa e o comparativo com Amazon CloudWatch e Google Cloud Operations.

As consultas KQL deste guia não são ilustrativas. Todas rodaram em 2 de setembro de 2026, no emulador Kusto (build 1.0.9740.38841), que executa o mesmo motor de consulta do Log Analytics. Os dados são sintéticos, no formato das tabelas reais. Ao final, você saberá quando o Azure Monitor basta sozinho e quando vale somar uma camada externa.

O que é o Azure Monitor

O Azure Monitor é o serviço de observabilidade unificada da Microsoft. Ele coleta, analisa e responde a telemetria de ambientes na nuvem, on-premises e multi-cloud. Métricas, logs, traces e eventos ficam na mesma plataforma de dados. A consulta sai em KQL, no caso dos logs, ou em PromQL, no caso das métricas.

Quando você cria uma assinatura Azure, a coleta já começa sozinha. Nesse momento, o log de atividades e as métricas de plataforma dos recursos provisionados entram sem configuração alguma. A partir daí, é possível estender a coleta com agentes, extensões, regras de coleta de dados e integrações nativas.

Vale destacar a integração com o ecossistema Microsoft, que é o principal valor da ferramenta. Sentinel, Defender for Cloud e o agente de observabilidade do Azure Copilot dividem a mesma plataforma de dados. Dessa forma, a correlação entre operação, segurança e custo acontece sem exportar nada. Nesse sentido, quem busca uma visão ampla de cloud computing corporativa costuma começar por aqui.

Como o Azure Monitor funciona: arquitetura e plataforma de dados

São três as camadas da arquitetura: fontes de dados, plataforma de dados centralizada e ferramentas de análise, visualização e resposta.

As fontes de dados incluem recursos Azure, como máquinas virtuais, App Services, bancos, AKS e Storage. Entram, inclusive, aplicações instrumentadas com OpenTelemetry ou com os SDKs do Application Insights. Por fim, chegam sistemas operacionais via agentes e recursos externos conectados por Azure Arc.

A plataforma de dados guarda telemetria em dois repositórios distintos. Workspaces do Log Analytics recebem logs e traces, consultados em KQL. Do mesmo modo, Azure Monitor Workspaces recebem métricas Prometheus e OpenTelemetry, consultadas em PromQL. Como resultado, logs e métricas escalam de maneira independente, com modelos de ingestão próprios.

Por cima, a camada de análise combina Metrics Explorer, Log Analytics, pastas de trabalho e painéis Grafana nativos. Ela traz ainda alertas com limites dinâmicos e o dimensionamento automático, que reage a sinais de carga. Adicionalmente, a documentação oficial da Microsoft detalha o fluxo entre as três camadas.

Principais componentes do Azure Monitor

Entender os componentes ajuda a evitar confusão entre serviços que dividem o mesmo guarda-chuva. Estes são os cinco que aparecem em qualquer projeto:

Metrics. Guarda séries temporais leves, com latência de segundos, para CPU, memória, requisições e latência de rede. Serve, principalmente, a painéis em tempo real, auto-scaling e alertas sensíveis a variação curta.

Logs (Log Analytics). Guarda eventos estruturados e semiestruturados de alta cardinalidade. Entram aqui auditoria, diagnóstico, traces e log de aplicação. A análise sai em KQL, que correlaciona tabelas e agrega em uma consulta só.

Alerts. Motor de alertas com regras estáticas, limites dinâmicos por aprendizado de máquina e grupos de ação. As ações cobrem, por exemplo, e-mail, SMS, webhook, ITSM, Logic Apps e Runbooks. Ele também correlaciona sinais, o que reduz fadiga de alerta.

Application Insights. Componente de APM nativo, construído sobre OpenTelemetry. Coleta traces distribuídos, dependências, exceções e métricas de performance de aplicações web, APIs e agentes de IA.

Insights especializados. Experiências prontas como VM Insights, Container Insights, Network Insights e Storage Insights. Elas combinam métricas, logs e visualização para um cenário específico. Dessa forma, o operador não precisa montar o painel do zero.

Como o Azure Monitor coleta dados: Azure Monitor Agent e Data Collection Rules

Na prática, duas peças controlam a coleta: o Azure Monitor Agent (AMA) e as Data Collection Rules (DCRs).

O Azure Monitor Agent é o agente unificado que substitui as gerações anteriores. Ele atende máquinas virtuais, servidores Arc-enabled e nodes de cluster. Roda em Windows e Linux, instala por extensão, template ARM, Bicep ou Terraform. Além disso, a coleta cobre eventos de sistema, syslog, contadores de performance e arquivos customizados.

As Data Collection Rules definem o que sai de cada máquina, com qual frequência e para qual destino. Em vez de configurar VM por VM, o operador cria uma DCR e a associa a um grupo de recursos. Assim, o erro manual cai e a governança fica centralizada.

Para monitoramento de Kubernetes em clusters AKS, o Container Insights usa configuração parecida, apoiada em OpenTelemetry e Prometheus. Ele coleta métricas de pods, nodes e controllers, bem como da aplicação, sem exigir agente adicional. Em ambientes maiores, o padrão aberto de instrumentação mantém a telemetria portável entre ferramentas.

Em quantos minutos declarar que a máquina parou de reportar

Cada instância do AMA envia uma batida de heartbeat por minuto. Logo, a pergunta operacional é direta: quantos minutos de silêncio viram alerta? A consulta abaixo lista o intervalo entre batidas de cada máquina, sobre 14 servidores em 24 horas.

// Intervalo entre batidas de heartbeat, por maquina.
// Em producao, troque a variavel agora por now().
let agora = datetime(2026-09-02T00:00:00Z);
let batidas = Heartbeat | project Computer, TimeGenerated
  | union (Heartbeat | summarize by Computer | extend TimeGenerated = agora);
batidas
| order by Computer asc, TimeGenerated asc
| extend Anterior = prev(TimeGenerated), CompAnterior = prev(Computer)
| where Computer == CompAnterior
| extend LacunaMin = datetime_diff('second', TimeGenerated, Anterior) / 60.0
| where LacunaMin > 1.5
| project Computer, ParouEm = Anterior, LacunaMin
| sort by LacunaMin desc

// saida medida: 12 lacunas em 14 maquinas, 24 horas
// Computer      ParouEm                LacunaMin
// vm-app-03     2026-09-01T14:11:00Z         589
// aks-node-02   2026-09-01T08:04:00Z          66
// vm-sql-02     2026-09-01T03:13:00Z          10
// vm-web-03     2026-09-01T21:39:00Z           9
// vm-app-01     2026-09-01T06:57:00Z           4
// ... mais 7 lacunas, todas de 3 a 4 minutos

Repare no union com o instante-âncora, que existe por um motivo prático. A máquina que nunca volta não tem batida seguinte, logo ela some de qualquer análise baseada em prev(). Sem esse ponto costurado no fim da janela, a queda de 589 minutos, justamente a única que importa, não aparece no relatório.

Doze interrupções conhecidas entraram no laboratório. São oito falhas de rede, de 3 a 4 minutos cada. Somado a isso, entraram duas reinicializações de manutenção, de 9 e 10 minutos, mais duas quedas reais, de 66 e 589 minutos. Em seguida, contei quantos alertas cada janela dispararia.

Essa leitura contraria o reflexo comum. Aumentar a janela até o ruído sumir custa 15 minutos de cegueira. Quem define esse preço é a reinicialização de manutenção de 10 minutos, ou seja, o único evento que sobrevive à janela de 10.

Por isso, a resposta melhor não é uma janela maior. Suprimir o alerta durante a janela de manutenção mata o mesmo ruído sem atrasar a detecção. Com a supressão configurada, 5 minutos volta a ser um limiar defensável. Além disso, a queda de 66 minutos passa a aparecer 10 minutos antes.

Casos de uso do Azure Monitor em ambientes corporativos

Alguns cenários mostram bem o valor prático da ferramenta e ajudam a desenhar a implantação.

Monitoramento de VMs e servidores híbridos. Com AMA e Azure Arc, a equipe padroniza a coleta de CPU, memória, disco, rede e log de sistema. Assim, as mesmas DCRs e os mesmos alertas valem para VMs Azure, servidores on-premises e VMs de outra nuvem.

Observabilidade de aplicações web e APIs. Instrumentando com o SDK do Application Insights ou com OpenTelemetry, o time recebe traces distribuídos, mapa de dependências e exceções. A correlação entre a requisição do frontend e a chamada ao banco vem pronta.

Monitoramento de clusters AKS. O Container Insights entrega métricas Prometheus, logs de container, eventos de orquestração e drilldown por pod, node ou namespace.

Segurança operacional integrada. Como Sentinel e Defender for Cloud dividem a plataforma de dados, o alerta de segurança se correlaciona com a métrica de performance. Assim, dá para detectar o ataque que muda o comportamento do workload antes do impacto no SLA.

Monitoramento de redes Azure. Network Watcher e Network Insights combinam métricas, logs e topologia. Logo, eles diagnosticam latência, perda de pacotes e problema de conectividade entre subnets, VNets e peering.

Planos e custos do Azure Monitor em 2026

Entre todas as decisões de adoção, a cobrança é a mais sensível. Ela segue três variáveis: o volume ingerido, o plano da tabela e a retenção.

Quanto custa cada plano de tabela em 2026

Cuidado com a página de preços da Microsoft: ela monta os valores por JavaScript, portanto uma leitura automatizada dela devolve célula vazia. Os números abaixo vieram da API pública de preços de varejo da Azure, consultada em 2 de setembro de 2026.

Compare as duas colunas de preço antes de qualquer outra coisa. Todo medidor de log em Brazil South custa exatamente o dobro do mesmo medidor em East US, sem uma exceção nos oito conferidos. Quem dimensiona a conta pela tabela americana, portanto, erra por 100%.

A consulta que mostra qual tabela está pagando a conta

Antes de discutir plano, convém saber para onde o dinheiro está indo. A tabela Usage responde isso em uma consulta só. Ademais, ela existe em todo workspace desde o primeiro dia.

// Quantity vem em MBytes. Na conta da Azure, 1 GB = 1000 MB.
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize GB = round(sum(Quantity) / 1000, 1) by DataType
| sort by GB desc

// saida medida em 02/09/2026, janela de 30 dias
// DataType             GB     Fatia
// ContainerLogV2    323,4     39,2%
// AzureDiagnostics  183,5     22,3%
// AppTraces         109,1     13,2%
// Syslog             67,0      8,1%
// Perf               52,0      6,3%
// SecurityEvent      38,8      4,7%
// W3CIISLog          26,3      3,2%
// AppRequests        16,3      2,0%
// AzureMetrics        7,9      1,0%
// total faturavel   824,3    100,0%

No laboratório entraram 824,3 GB faturáveis em 30 dias, ou 27,5 GB por dia. Duas tabelas concentram 61,5% do volume: ContainerLogV2 fica com 39,2% e AzureDiagnostics, com 22,3%. Note que Heartbeat e AzureActivity nem aparecem, porque a Azure não cobra por elas.

Rode essa consulta no seu workspace antes de negociar qualquer coisa. O desenho da sua fatura pode ser outro. Por conseguinte, a decisão de plano depende exatamente dessa distribuição.

Quanto cai a fatura ao trocar o plano da tabela

Com o volume medido e o preço de Brazil South, a conta mensal sai direto. Vale dizer que o cálculo abaixo já desconta os 5 GB gratuitos do plano Analytics.

O commitment tier não entra nessa conta. O tier de entrada pede 100 GB por dia e o laboratório consome 27,5 GB. Abaixo desse piso não existe desconto por volume, ou seja, o único caminho é o plano da tabela.

Acima do piso, o desconto cresce junto com o compromisso. Em Brazil South, ele sai de 14,8% no tier de 100 GB por dia e chega a 36% no de 50 TB por dia. A mesma disciplina de corte se aplica fora da Azure, inclusive. O raciocínio inteiro está no guia de custo de observabilidade.

A armadilha da consulta ampla em Basic e Auxiliary

Mover uma tabela para Basic ou Auxiliary muda quem paga a consulta. Nesses dois planos, a Azure cobra por GB varrido além do preço de ingestão. Por isso, a mesma pergunta pode custar valores diferentes conforme o jeito de escrever.

// Mesma pergunta: quantas linhas de log citam timeout?

// (1) caminho amplo
search "timeout"
| count

// (2) caminho escopado
ContainerLogV2
| where TimeGenerated > ago(2d)
| where LogLevel == "ERROR"
| where LogMessage has "timeout"
| count

// as duas devolveram as mesmas 1.574 linhas
//                linhas varridas   bytes lidos   tempo
// (1) amplo             185.929     2.057.021   23 ms
// (2) escopado          150.000       165.883    6 ms

Ambas devolveram as mesmas 1.574 linhas. Todavia, a diferença aparece no que o motor precisou ler: 2.057.021 bytes contra 165.883, um fator de 12,4.

Em número de linhas, no entanto, a diferença foi de apenas 1,2 vez. O motor do Log Analytics é colunar, logo o custo mora em colunas vezes linhas, não em linhas. A consulta ampla lê todas as colunas de todas as tabelas, inclusive a mensagem de log inteira.

Em resumo, a regra prática cabe em uma frase: escreva o nome da tabela antes do filtro. Em Analytics isso devolve tempo de quem investiga. Em Basic e Auxiliary, por sua vez, devolve dinheiro na razão direta dos bytes varridos.

Limitações do Azure Monitor e quando combinar com uma camada externa

O custo não é a única fronteira da ferramenta nativa. O Azure Monitor não resolve sozinho todas as necessidades de monitoramento corporativo. Cabe conhecer três limitações antes de assumir que ele será a única camada.

A primeira é o custo em escala. Muitos ambientes, alta cardinalidade e retenção longa produzem, como resultado, faturas difíceis de prever. A tabela acima mostra a ordem de grandeza: sem disciplina de DCR e de plano de tabela, a conta dobra ou triplica sem aviso.

A segunda é a cobertura fora do ecossistema Microsoft. Azure Arc amplia o alcance, porém a integração nativa acaba onde acaba a Microsoft. Dispositivo de rede legado, appliance proprietário, banco on-premises e workload SAP costumam exigir conector, script ou ferramenta complementar.

Por fim, pesa a curva de KQL e de governança. Quem nunca usou o ecossistema Azure leva tempo para dominar workspace, DCR, plano de tabela e particionamento. Enquanto isso, a configuração inicial gera custo que ninguém previu.

Nesses cenários, somar uma camada externa de observabilidade traz ganhos concretos. Ela entrega visão unificada multi-cloud, governança centralizada e alerta independente da própria nuvem, o que ajuda durante um incidente de plataforma. Ela também conecta a operação a processos de NOC, ITSM e SLA contratual, ou seja, ao que fica fora do escopo da Azure.

Azure Monitor vs. Amazon CloudWatch vs. Google Cloud Operations

Para quem opera multi-cloud, comparar as ferramentas nativas ajuda a decidir onde investir esforço de instrumentação.

Duas leituras completam a tabela. O Amazon CloudWatch tem o ecossistema mais maduro dentro da AWS, com curva curta para quem já opera lá. Já o Google Cloud Platform entrega a suíte Cloud Operations, forte em painel de SLO e em análise de log com BigQuery.

Em ambientes multi-cloud reais, nenhuma das três cobre sozinha todas as nuances de observabilidade corporativa. Por isso, o padrão mais adotado usa cada ferramenta dentro do seu provedor e agrega uma camada externa de visualização, alerta e correlação. Essa é a base da estratégia descrita no guia de monitoramento Azure da OpServices.

Conclusão

O Azure Monitor é uma plataforma madura e integrada ao ecossistema Microsoft. Seus componentes cobrem desde VM tradicional até cluster Kubernetes, bem como aplicação instrumentada com OpenTelemetry. A governança vem do Azure Monitor Agent e das Data Collection Rules, que centralizam o que cada máquina envia.

Ao mesmo tempo, o modelo de cobrança exige disciplina e a cobertura fora do mundo Microsoft tem limite prático. Os números deste guia mostram os dois pontos. Em Brazil South, cada medidor de log custa o dobro do mesmo medidor em East US. No laboratório, trocar o plano de duas tabelas derrubou a conta simulada em 53%. Nenhuma das duas decisões aparece sem medir antes.

Talvez a sua operação esteja avaliando observabilidade em Azure com governança, custo previsível e integração com NOC e ITSM. Nesse caso, converse com um especialista da OpServices para desenhar a estratégia sob medida.