Azure Monitor: Monitorização Cloud para PMEs em 2026

Tags: Azure Monitor · Log Analytics · KQL · Alertas · Application Insights · Workbooks · Azure · Cloud

Por Duarte Spínola · 5 de Julho de 2026

Azure Monitor: Monitorização Cloud para PMEs em 2026

O Azure Monitor é a solução nativa de monitorização da Microsoft Azure, que reúne métricas, logs, traces e alertas numa plataforma unificada. Permite a uma PME observar a saúde de VMs, aplicações, bases de dados e serviços híbridos sem instalar ferramentas separadas. Este guia cobre arquitetura, Log Analytics Workspace, KQL, Data Collection Rules, alertas, Application Insights, Workbooks, VM Insights, Azure Arc, custos e comparação com Prometheus e Zabbix, com base na documentação oficial do Azure Monitor e no guia de data platform.

Para complementar, consulta os artigos sobre Azure IaaS: Optimizar Custos Cloud, Microsoft Sentinel: SIEM para PMEs, Azure Virtual Desktop para PMEs, Windows 365 Cloud PC e Grafana para PMEs com Prometheus.

Conteúdos

1. O Que é o Azure Monitor
2. Arquitetura do Azure Monitor (Metrics, Logs, Traces)
3. Log Analytics Workspace
4. KQL (Kusto Query Language) Básico
5. Data Collection Rules e Agents
6. Alertas: Regras de Alerta e Action Groups
7. Application Insights (APM)
8. Workbooks e Dashboards
9. Monitorizar VMs Azure (VM Insights)
10. Monitorizar Recursos On-Premises (Azure Arc)
11. Custos e Otimização do Azure Monitor
12. Azure Monitor vs Prometheus vs Zabbix
13. Cenário Prático PME (híbrido Azure + on-prem)
14. Checklist de Implementação

1. O Que é o Azure Monitor

O Azure Monitor é o serviço de observabilidade nativo da Microsoft Azure. Em vez de comprar e manter três ferramentas separadas — uma para métricas, outra para logs e outra para APM (Application Performance Monitoring) — uma PME pode usar uma única plataforma que cobre infraestrutura, aplicações e serviços cloud. A Microsoft descreve-o como uma “solução completa para recolha, análise e resposta a telemetria dos ambientes cloud e on-premises” (overview oficial).

Os componentes principais do Azure Monitor são:

Metrics — séries temporais numéricas (CPU, memória, pedidos/seg), armazenadas automaticamente para a maioria dos recursos Azure. Retenção por defeito de 93 dias.
Logs — dados semi-estruturados e não-estruturados (eventos, traces, heartbeats) armazenados num Log Analytics Workspace, consultados com KQL. Retenção configurável até 730 dias.
Alertas — regras que avaliam métricas ou logs e disparam notificações (email, SMS, webhook, Logic App) via Action Groups.
Dashboards e Workbooks — visualizações interativas construídas sobre queries KQL e métricas.
Application Insights — APM para aplicações web, APIs e serviços, com deteção automática de dependências.

ℹ️ Informação: Ao contrário do Prometheus (métricas pull) ou Zabbix (agent polling), o Azure Monitor usa ingestão push: os agentes enviam dados para o Log Analytics Workspace. Isto simplifica a configuração em ambientes híbridos sem expor endpoints HTTP.

Característica	Azure Monitor
Tipo	Observabilidade unificada cloud-native
Métricas	Azure Monitor Metrics (séries temporais)
Logs	Log Analytics Workspace (Kusto)
Linguagem	KQL (Kusto Query Language)
APM	Application Insights
Agent	Azure Monitor Agent (AMA)
Retenção métricas	93 dias (gratuito)
Retenção logs	31–730 dias (pay-per-GB)

2. Arquitetura do Azure Monitor (Metrics, Logs, Traces)

A arquitetura do Azure Monitor separa-se em dois pipelines distintos: Metrics (numéricos, baixa cardinalidade, baixa latência) e Logs (texto, alta cardinalidade, queries complexas). Sobre estes dois pipelines assenta o APM com traces distribuídos via Application Insights.

Os três pilares da observabilidade no Azure Monitor:

Pilar	Componente	Exemplos	Retenção
Metrics	Azure Monitor Metrics	CPU %, memória, IOPS, pedidos/seg	93 dias
Logs	Log Analytics Workspace	Eventos Windows, Syslog, heartbeat, custom logs	31–730 dias
Traces	Application Insights	Distributed tracing, exceptions, dependências	90 dias (pay-per-GB)

As fontes de telemetria são variadas e incluem:

Plataforma Azure — métricas de recursos (VM, App Service, SQL) recolhidas automaticamente, sem configuração.
Sistema operativo convidado — métricas e logs do SO dentro da VM, via Azure Monitor Agent (AMA).
Aplicações — telemetria de código via SDKs do Application Insights (telemetria automática em .NET, Java, Node.js, Python).
On-premises — servidores físicos ou VMs fora do Azure, via AMA ou Azure Arc.
Custom — logs e métricas enviados via API REST (Data Collection Endpoints).

💡 Dica: As métricas de plataforma são gratuitas e já estão disponíveis para qualquer recurso Azure. O custo do Azure Monitor vem essencialmente da ingestão de logs no Log Analytics Workspace. Monitorizar primeiro métricas e só depois ativar logs é uma forma eficaz de controlar despesa.

3. Log Analytics Workspace

O Log Analytics Workspace (LAW) é o contentor lógico onde os logs são armazenados, consultados e exportados. É um recurso Azure independente, com a sua própria retenção, pricing tier e controlo de acesso (RBAC). Vários recursos podem enviar logs para o mesmo workspace, permitindo consultas correlacionadas entre VMs, aplicações e serviços.

A criação de um workspace pode ser feita no portal, em Bicep/Terraform ou via Azure CLI:

az monitor log-analytics workspace create \
  --resource-group "rg-monitorizacao" \
  --workspace-name "law-pme-prod" \
  --location "westeurope" \
  --retention-time 90 \
  --sku PerGB2018

Os pricing tiers disponíveis em 2026 são:

Tier	Preço (West Europe)	Retenção	Uso
PerGB2018 (Pay-as-you-go)	~2,30 €/GB ingerido	31–730 dias	PMEs com volume variável
Capacity Reservation	100–5000 GB/dia, desconto ~25%	31–730 dias	Volume >100 GB/dia consistente
Commitment Tier	Níveis de 100/200/500 GB/dia	31–730 dias	Volume previsível alto

⚠️ Atenção: A retenção de logs para além de 31 dias tem custo adicional (~0,12 €/GB/mês). Para PMEs, 90 dias é um bom equilíbrio entre investigação de incidentes e custo. Para dados de auditoria, considere exportar para Storage Account (mais barato) em vez de manter no workspace.

Para listar workspaces existentes e verificar a configuração:

az monitor log-analytics workspace list \
  --resource-group "rg-monitorizacao" \
  --query "[].{name:name, retention:retentionInDays, sku:sku.name}" \
  -o table

4. KQL (Kusto Query Language) Básico

O KQL (Kusto Query Language) é a linguagem de consulta do Azure Monitor, do Log Analytics Workspace e do Microsoft Sentinel. É uma linguagem declarativa, pipeline-based, optimizada para grandes volumes de dados. Quem já usou LINQ, Splunk SPL ou SQL encontra KQL familiar — mas a sua sintaxe é própria e vale a pena aprender. A documentação de referência está em Kusto Query Language docs.

Estrutura básica de uma query KQL:

// Tabela | filtros | projecoes | agregacoes | ordenacao | limite
Perf
| where TimeGenerated > ago(1h)
| where CounterName == "% Processor Time"
| where Computer startswith "vm-prod-"
| summarize AvgCPU = avg(CounterValue) by Computer, bin(TimeGenerated, 5m)
| order by Computer, TimeGenerated desc
| take 50

Os operadores mais usados numa PME para diagnóstico diário:

where — filtra linhas (equivalente a WHERE em SQL).
project — selecciona colunas (SELECT em SQL).
extend — cria colunas calculadas.
summarize — agrega (GROUP BY + funções como avg, count, min, max, sum).
join — cruza duas tabelas (INNER/LEFT OUTER).
sort / order — ordena resultados.
take / limit — limita número de linhas.
bin() — arredonda timestamps para intervalos (5m, 1h, 1d).
ago() — referência temporal relativa (“há 1 hora”).

Exemplos práticos para monitorizar VMs:

// Top 10 VMs por CPU médio (últimas 24h)
Perf
| where TimeGenerated > ago(24h)
| where CounterName == "% Processor Time" and ObjectName == "Processor"
| summarize CPU_Medio = avg(CounterValue) by Computer
| top 10 by CPU_Medio desc
| render barchart

// Eventos de erro do Windows nas últimas 6 horas
Event
| where TimeGenerated > ago(6h)
| where EventLevelName == "Error"
| summarize Contagem = count() by Computer, Source
| order by Contagem desc
| take 20

// Heartbeat: VMs que não reportaram há mais de 30 minutos
Heartbeat
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| where LastHeartbeat < ago(30m)
| extend MinutosOffline = datetime_diff("minute", now(), LastHeartbeat)
| order by MinutosOffline desc

ℹ️ Informação: O operador render permite gerar gráficos (barchart, timechart, piechart) directamente na query. Ao guardar a query num Workbook, o gráfico fica disponível no dashboard sem ferramentas adicionais.

Para cruzar logs de VM com alertas gerados:

// Cruzar alerts com VMs com CPU elevado
Alert
| where TimeGenerated > ago(1d)
| where Severity == "Sev1" or Severity == "Sev2"
| join kind=inner (
    Perf
    | where TimeGenerated > ago(1d)
    | where CounterName == "% Processor Time"
    | summarize CPU = avg(CounterValue) by Computer
    | where CPU > 80
) on $left.ResourceId == $right.Computer
| project TimeGenerated, AlertName, Severity, Computer, CPU

5. Data Collection Rules e Agents

O Azure Monitor Agent (AMA) é o agente moderno que substitui o antigo Log Analytics Agent (MMA/OMS Agent), que foi descontinuado em Agosto de 2024. O AMA é mais leve, modular e seguro, usando Data Collection Rules (DCR) para definir o que recolher, para onde enviar e com que frequência. A documentação está em Azure Monitor Agent overview.

Vantagens do AMA sobre o MMA legacy:

Suporte para Windows e Linux num único agente
Configuração centralizada via DCR (não precisa de editar configs no servidor)
Menor consumo de CPU e memória (~20% mais leve)
Suporte para Managed Identity (sem chaves de workspace)
Filtragem de eventos antes do envio (reduz custo de ingestão)
Integração com Azure Policy para deploy automático

Instalação do AMA numa VM Linux via Azure CLI:

az vm extension set \
  --resource-group "rg-prod" \
  --vm-name "vm-prod-web-01" \
  --name "AzureMonitorLinuxAgent" \
  --publisher "Microsoft.Azure.Monitor" \
  --version 1.29 \
  --settings '{"authenticationMode":"msi"}'

Exemplo de Data Collection Rule (DCR) em JSON para recolher Syslog e métricas de Linux:

{
  "location": "westeurope",
  "properties": {
    "dataSources": [
      {
        "name": "syslogCollection",
        "kind": "Syslog",
        "streams": ["Microsoft-Syslog"],
        "properties": {
          "facilityNames": ["auth", "syslog", "daemon", "kern"],
          "severityLevels": ["Warning", "Error", "Critical"]
        }
      },
      {
        "name": "perfCounterCollection",
        "kind": "PerformanceCounters",
        "streams": ["Microsoft-Perf"],
        "properties": {
          "samplingFrequencyInSeconds": 60,
          "counterSpecifiers": [
            "\\Processor(_Total)\\% Processor Time",
            "\\Memory\\Available MBytes",
            "\\LogicalDisk(_Total)\\Disk Reads/sec"
          ]
        }
      }
    ],
    "destinations": {
      "logAnalytics": [
        {
          "workspaceResourceId": "/subscriptions/xxxx/resourceGroups/rg-monitorizacao/providers/Microsoft.OperationalInsights/workspaces/law-pme-prod"
        }
      ]
    }
  }
}

💡 Dica: Usar Azure Policy para associar automaticamente o AMA e uma DCR a todas as VMs novas garante que não existem "VMs órfãs" sem monitorização. A policy built-in "Configure Linux VMs to be associated with Azure Monitor Agent" está disponível em todas as subscrições.

Criar uma DCR via Azure CLI:

az monitor data-collection-rule create \
  --resource-group "rg-monitorizacao" \
  --name "dcr-linux-vms" \
  --location "westeurope" \
  --rule-file ./dcr-linux.json

Associar a DCR a uma VM:

az monitor data-collection-rule-association create \
  --resource "/subscriptions/xxxx/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm-prod-web-01" \
  --association-name "assoc-dcr-linux" \
  --rule-id "/subscriptions/xxxx/resourceGroups/rg-monitorizacao/providers/Microsoft.Insights/dataCollectionRules/dcr-linux-vms"

6. Alertas: Regras de Alerta e Action Groups

Os alertas no Azure Monitor são compostos por três elementos:

Regra de alerta (Alert Rule) — define o sinal a monitorizar (métrica ou log), a condição e o limiar.
Condition — quando o sinal cruza o limiar, o alerta dispara (fires).
Action Group — define o que fazer: email, SMS, push da app Azure, webhook, Logic App, ITSM ticket, função Azure.

Existem quatro tipos de regras de alerta:

Tipo	Sinal	Latência	Custo
Metric Alert	Métrica de plataforma	~1 min	Gratuito até 20 regras
Log Search Alert	Query KQL	5–15 min	~0,06 € por query executada
Activity Log Alert	Evento do Azure (criação, deleção)	~1 min	Gratuito
Smart Detection	ML (Application Insights)	Horas	Incluso no App Insights

Criar um Action Group via Azure CLI com email e SMS:

az monitor action-group create \
  --resource-group "rg-monitorizacao" \
  --name "ag-pme-noc" \
  --short-name "PME-NOC" \
  --action email admin "[email protected]" \
  --action sms suporte "+351912345678" "Serviços de TI"

Criar um alerta de métrica para CPU > 80% numa VM:

az monitor metrics alert create \
  --resource-group "rg-prod" \
  --name "alert-cpu-alto-vm-web-01" \
  --scopes "/subscriptions/xxxx/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm-prod-web-01" \
  --condition "avg Percentage CPU > 80" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --severity 2 \
  --action-groups "/subscriptions/xxxx/resourceGroups/rg-monitorizacao/providers/Microsoft.Insights/actionGroups/ag-pme-noc" \
  --description "CPU acima de 80% durante 5 minutos"

Para um log search alert baseado em KQL (eventos de erro crítico):

az monitor log-analytics alert create \
  --resource-group "rg-monitorizacao" \
  --name "alert-eventos-criticos" \
  --workspace-name "law-pme-prod" \
  --condition "Event | where EventLevelName == 'Critical' | summarize count() by Computer | where count_ > 5" \
  --frequency 10m \
  --time-window 30m \
  --severity 1 \
  --action-groups "/subscriptions/xxxx/resourceGroups/rg-monitorizacao/providers/Microsoft.Insights/actionGroups/ag-pme-noc"

🚨 Perigo: Não definir supressão de alertas (alert suppression) pode gerar dezenas de notificações por minuto durante um incidente. Use sempre a janela de supressão de pelo menos 30 minutos e agrupe alertas semelhantes por Computer e AlertRuleName.

7. Application Insights (APM)

O Application Insights é o módulo de APM (Application Performance Monitoring) do Azure Monitor. Fornece deteção automática de dependências, tracing distribuído, métricas de carga, tempos de resposta, rastreio de excepções e mapas de aplicação. Suporta .NET, .NET Core, Java, Node.js, Python e aplicações web em geral. Referência: Application Insights overview.

Para aplicações .NET, a instrumentação automática pode ser activada no Azure App Service sem alterar código:

az webapp config appsettings set \
  --resource-group "rg-prod" \
  --name "app-prod-api" \
  --settings \
    APPINSIGHTS_INSTRUMENTATIONKEY="" \
    APPINSIGHTS_PROFILERFEATURE_VERSION=1.0.0 \
    APPINSIGHTS_SNAPSHOTPUBLISHERFEATURE_VERSION=1.0.0 \
    APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=;IngestionEndpoint=https://westeurope-2.in.applicationinsights.azure.com/"

Para aplicações Node.js, instalar o SDK e configurar a connection string:

// app.js - Node.js
const appInsights = require("applicationinsights");
appInsights.setup("")
  .setAutoDependencyCorrelation(true)
  .setAutoCollectRequests(true)
  .setAutoCollectPerformance(true, true)
  .setAutoCollectExceptions(true)
  .setAutoCollectDependencies(true)
  .setAutoCollectConsole(true, true)
  .setUseDiskRetryCaching(true)
  .setSendLiveMetrics(true)
  .start();

As funcionalidades chave do Application Insights incluem:

Funcionalidade	Descrição
Live Metrics	Métricas em tempo real (1 seg de latência), sem custo extra
Application Map	Mapa visual de dependências (HTTP, SQL, Redis)
Transaction Search	Procurar pedidos individuais e ver traces correlacionados
Smart Detection	ML detecta anomalias (latência alta, falhas em massa)
Availability Tests	Ping multi-região para verificar uptime do endpoint
Snapshot Debugger	Captura snapshot de excepções .NET para debugging

Query KQL para top 5 endpoints mais lentos:

requests
| where timestamp > ago(1h)
| summarize AvgDuration = avg(duration), P95Duration = percentile(duration, 95), Requests = count()
  by name
| top 5 by P95Duration desc
| render barchart

💡 Dica: O Application Map é excelente para onboarding: abre-se e vê-se imediatamente a topologia de uma aplicação com 20 microserviços sem precisar de documentação. Para PMEs, é frequentemente a primeira vista unificada da sua arquitetura.

8. Workbooks e Dashboards

Os Workbooks são dashboards interativos do Azure Monitor construídos sobre queries KQL e métricas. Ao contrário dos Azure Dashboards tradicionais (que são tiles estáticos), os Workbooks suportam parâmetros (dropdowns, pickers de tempo, filtros), gráficos múltiplos, texto Markdown e lógica condicional. São ideais para operações NOC, relatórios de capacidade e painéis de gestão. Documentação: Azure Workbooks overview.

Um Workbook típico para NOC pode conter:

Parâmetro de subscrição (dropdown)
Parâmetro de intervalo temporal (last 24h, 7d, 30d)
Top 10 VMs por CPU (barchart)
Lista de alertas ativos (tabela)
Mapa de dependências das aplicações (Application Map)
Resumo de custos do workspace (tabela)
Logs de eventos críticos (tabela com drill-down)

Os Workbooks suportam templates da galeria, que incluem:

Performance & Availability
Virtual Machine insights
Container insights
Key Vault analytics
Network performance
Active Directory analytics
Audit reports

Para exportar um Workbook como ARM template para reutilização:

az resource show \
  --resource-group "rg-monitorizacao" \
  --name "wb-noc-pme" \
  --resource-type "Microsoft.Insights/workbooks" \
  --query properties.serializedData -o tsv > workbook-noc.json

ℹ️ Informação: Os Workbooks são gratuitos — só pagamos pelas queries KQL que executam por trás. Para reduzir custo, usar intervalo de refresh de 5 minutos em vez de 1 minuto em ambientes de produção reduz drasticamente o volume de queries.

9. Monitorizar VMs Azure (VM Insights)

O VM Insights é a solução pré-configurada de monitorização de VMs do Azure Monitor. Combina o Azure Monitor Agent com um conjunto de Workbooks e regras de detecção prontas para fornecer gráficos de performance, mapa de dependências e health state. Em vez de construir tudo do zero, a PME activa o VM Insights e obtém dashboards profissionais em minutos. Referência: VM Insights overview.

Funcionalidades do VM Insights:

Performance — CPU, memória, disco, rede, com comparação a baseline.
Map — mapa de dependências de processos (que processo liga a que porta/IP).
Health — estado de saúde (Healthy, Warning, Critical) baseado em regras.
Guest OS health — monitoriza serviços críticos do SO (Linux systemd, Windows services).
Trends — tendências de capacidade a 30/60/90 dias.

Ativar VM Insights numa VM via Azure CLI:

az vm extension set \
  --resource-group "rg-prod" \
  --vm-name "vm-prod-web-01" \
  --name "DependencyAgentLinux" \
  --publisher "Microsoft.Azure.Monitoring.DependencyAgent" \
  --version 9.10

# Associar a DCR do VM Insights
az monitor data-collection-rule-association create \
  --resource "/subscriptions/xxxx/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm-prod-web-01" \
  --association-name "assoc-vmi" \
  --rule-id "/subscriptions/xxxx/resourceGroups/rg-monitorizacao/providers/Microsoft.Insights/dataCollectionRules/ms-vmi-linux"

⚠️ Atenção: O Dependency Agent é necessário para o mapa de dependências mas adiciona ~5% de overhead de CPU em VMs pequenas (B-series). Para VMs de dev/test, considere desactivar o Dependency Agent e usar apenas o AMA para métricas.

10. Monitorizar Recursos On-Premises (Azure Arc)

O Azure Arc permite gerir recursos on-premises (servidores físicos, VMs VMware, VMs AWS, VMs GCP) como se fossem recursos nativos do Azure. Isto estende o Azure Monitor a servidores fora da cloud sem VPN Site-to-Site nem ExpressRoute — o servidor liga-se ao Azure por HTTPS e passa a ser tratado como uma VM Azure para efeitos de monitorização. Documentação: Azure Arc servers overview.

O fluxo de implementação é:

Instalar o agente Azure Arc no servidor on-prem (script gerado no portal).
O servidor aparece no Azure com recurso type "Microsoft.HybridCompute/machines".
Instalar a extensão do AMA no servidor Arc (igual a uma VM Azure).
Associar a DCR que define o que recolher.
Os logs aparecem no Log Analytics Workspace e podem ser consultados com KQL.

Instalação do agente Azure Arc em Linux (Ubuntu/Debian):

# Gerar script no portal: Azure Arc > Add > Servers > Generate script
# Executar no servidor on-prem
sudo bash install_arc_agent.sh \
  --subscription-id "xxxx-xxxx-xxxx" \
  --resource-group "rg-onprem" \
  --location "westeurope" \
  --tenant-id "yyyy-yyyy-yyyy" \
  --tags "env=prod,site=lisboa,role=db"

Instalar a extensão do AMA no servidor Arc:

az connectedmachine extension create \
  --resource-group "rg-onprem" \
  --machine-name "srv-prod-db-01" \
  --name "AzureMonitorLinuxAgent" \
  --publisher "Microsoft.Azure.Monitor" \
  --type "AzureMonitorLinuxAgent" \
  --type-handler-version 1.29 \
  --location "westeurope"

ℹ️ Informação: Um servidor on-prem monitorizado via Azure Arc aparece nas queries KQL exactamente como uma VM Azure: a tabela Heartbeat tem a coluna Computer preenchida e AzureResource indica se é Arc ou VM nativa. As queries não precisam de ser adaptadas.

11. Custos e Otimização do Azure Monitor

O custo do Azure Monitor depende quase exclusivamente do volume de logs ingeridos no Log Analytics Workspace. Métricas de plataforma, alertas básicos (até 20 regras) e Activity Log são gratuitos. A otimização de custos passa por reduzir a ingestão sem perder visibilidade. Para aprofundar custos, ver Azure Monitor cost management.

Componente	Modelo	Preço (West Europe, 2026)
Log ingestion (Pay-as-you-go)	Por GB ingerido	~2,30 €/GB
Log retention > 31 dias	Por GB/mês	~0,12 €/GB/mês
Log Search Alert	Por query executada	~0,06 €/execução
Application Insights	Por GB ingerido	~2,30 €/GB (primeiros 5 GB/mês grátis)
Data export (LAW → Storage/EventHub)	Por GB exportado	~0,05 €/GB
Métricas de plataforma	Gratuito	0 €
Metric Alerts (até 20)	Gratuito	0 €

Estratégias de otimização de custos para PMEs:

Usar sampling no Application Insights — para apps de alto tráfego, configurar sampling adaptativo a 5–10% reduz ingestão sem perder tendências.
Filtrar logs na DCR — não enviar Syslog de nível INFO, só Warning/Error/Critical.
Reduzir retenção — 90 dias em vez de 365 para dados operacionais; exportar para Storage Account para retenção longa.
Usar Capacity Reservation — se ingerir consistentemente >100 GB/dia, o desconto de ~25% compensa.
Eliminar VM Insights em dev/test — só activar em produção; em dev, o AMA básico chega.
Desactivar Dependency Agent em VMs pequenas onde o mapa de dependências não é essencial.
Exportar logs para Storage Account (Cool tier) — 0,01 €/GB/mês vs 0,12 €/GB/mês no workspace.
Ver Usage no portal — Azure Monitor > Usage & estimated costs mostra o top de tabelas que ingerem mais.

// Query para ver volume ingerido por tabela (últimas 24h)
Usage
| where TimeGenerated > ago(24h)
| summarize GB = sum(Quantity) / 1024 by DataType
| order by GB desc
| render barchart

💡 Dica: A tabela Usage é gerada automaticamente pelo Log Analytics Workspace e permite ver exatamente quanto está a ser ingerido por tipo de dados. Executar esta query semanalmente é a melhor forma de detectar picos anómalos de ingestão antes de receber a factura.

12. Azure Monitor vs Prometheus vs Zabbix

Para uma PME que já usa Grafana + Prometheus ou Zabbix, a comparação com Azure Monitor é inevitável. Nenhuma solução é universalmente "melhor" — a escolha depende de onde estão os recursos, que stack já existe e que competências a equipa tem. Para aprofundar o tema Grafana + Prometheus, ver o artigo Grafana para PMEs: Dashboards com Prometheus.

Critério	Azure Monitor	Prometheus	Zabbix
Modelo	SaaS managed	Self-hosted (pull)	Self-hosted (agent)
Linguagem	KQL	PromQL	Sem SQL (macros)
Logs	Sim (LAW)	Não (usar Loki)	Sim
APM	Sim (App Insights)	Não (usar Jaeger)	Limitado
Custo (100 VMs)	~150–400 €/mês	~50 €/mês (VM hosting)	~50 €/mês (VM hosting)
Manutenção	Zero (managed)	Média (operar Prometheus)	Média (operar Zabbix server)
Tempo para arranque	Minutos	Horas/dias	Horas/dias
Integração Azure	Nativa	Via exporter	Via scripts
Dashboards	Workbooks	Grafana	Grafana / built-in
Vendor lock-in	Alto	Baixo	Médio

ℹ️ Informação: Para PMEs cuja infraestrutura está maioritariamente no Azure, o Azure Monitor é quase sempre a escolha mais simples. Para PMEs com infraestrutura on-prem ou multi-cloud (AWS + Azure + on-prem), Prometheus + Grafana pode ser mais flexível. Zabbix é forte em ambientes tradicionais com muitos dispositivos de rede (switches, routers, PDUs).

13. Cenário Prático PME (híbrido Azure + on-prem)

Considere uma PME portuguesa fictícia, "TechLisboa Lda", com a seguinte infraestrutura:

3 VMs Azure em West Europe (web, app, db)
2 servidores on-prem (ficheiros + AD) monitorizados via Azure Arc
1 aplicação .NET 8 em App Service
1 Azure SQL Database
Equipa de TI: 2 pessoas (sem NOC 24/7)

Objectivo: monitorizar tudo com alertas para incidentes críticos, dashboards para gestão e custo controlado abaixo de 200 €/mês.

Passo 1 — Criar Log Analytics Workspace:

az group create --name "rg-monitorizacao" --location "westeurope"

az monitor log-analytics workspace create \
  --resource-group "rg-monitorizacao" \
  --workspace-name "law-techlisboa" \
  --location "westeurope" \
  --retention-time 90 \
  --sku PerGB2018

Passo 2 — Ativar AMA + VM Insights nas 3 VMs Azure:

for VM in vm-web-01 vm-app-01 vm-db-01; do
  az vm extension set \
    --resource-group "rg-prod" \
    --vm-name "$VM" \
    --name "AzureMonitorLinuxAgent" \
    --publisher "Microsoft.Azure.Monitor" \
    --version 1.29

  az vm extension set \
    --resource-group "rg-prod" \
    --vm-name "$VM" \
    --name "DependencyAgentLinux" \
    --publisher "Microsoft.Azure.Monitoring.DependencyAgent" \
    --version 9.10
done

Passo 3 — Instalar Azure Arc + AMA nos 2 servidores on-prem:

# No servidor on-prem (AD + ficheiros)
sudo bash install_arc_agent.sh \
  --subscription-id "xxxx" \
  --resource-group "rg-onprem" \
  --location "westeurope" \
  --tenant-id "yyyy" \
  --tags "env=prod,site=lisboa"

# Instalar AMA no servidor Arc
az connectedmachine extension create \
  --resource-group "rg-onprem" \
  --machine-name "srv-ad-01" \
  --name "AzureMonitorWindowsAgent" \
  --publisher "Microsoft.Azure.Monitor" \
  --type "AzureMonitorWindowsAgent" \
  --type-handler-version 1.29 \
  --location "westeurope"

Passo 4 — Activar Application Insights na aplicação .NET:

az monitor app-insights component create \
  --resource-group "rg-prod" \
  --app "appi-techlisboa-api" \
  --location "westeurope" \
  --kind web

az webapp config appsettings set \
  --resource-group "rg-prod" \
  --name "app-techlisboa-api" \
  --settings \
    APPLICATIONINSIGHTS_CONNECTION_STRING="InstrumentationKey=;IngestionEndpoint=https://westeurope-2.in.applicationinsights.azure.com/"

Passo 5 — Criar Action Group e 5 alertas essenciais:

az monitor action-group create \
  --resource-group "rg-monitorizacao" \
  --name "ag-techlisboa-ti" \
  --short-name "TI-TL" \
  --action email ti "[email protected]"

# Alerta 1: CPU > 90% durante 10 min (todas as VMs)
az monitor metrics alert create \
  --resource-group "rg-monitorizacao" \
  --name "alert-cpu-90" \
  --scopes "/subscriptions/xxxx/resourceGroups/rg-prod" \
  --condition "avg Percentage CPU > 90" \
  --window-size 10m \
  --severity 1 \
  --action-groups "/subscriptions/xxxx/resourceGroups/rg-monitorizacao/providers/Microsoft.Insights/actionGroups/ag-techlisboa-ti"

# Alerta 2: VM offline (sem heartbeat há 15 min)
az monitor log-analytics alert create \
  --resource-group "rg-monitorizacao" \
  --name "alert-vm-offline" \
  --workspace-name "law-techlisboa" \
  --condition "Heartbeat | summarize LastHeartbeat = max(TimeGenerated) by Computer | where LastHeartbeat < ago(15m)" \
  --frequency 5m \
  --time-window 15m \
  --severity 0 \
  --action-groups "/subscriptions/xxxx/resourceGroups/rg-monitorizacao/providers/Microsoft.Insights/actionGroups/ag-techlisboa-ti"

Passo 6 — Criar Workbook para a direcção:

No portal, ir a Azure Monitor > Workbooks > New. Criar um Workbook com:

Parâmetro de intervalo temporal (30 dias por defeito)
Secção "Saúde das VMs" — top 5 por CPU, top 5 por memória
Secção "Alertas activos" — tabela com últimas 24h
Secção "Aplicação" — top 5 endpoints por latência P95
Secção "Custos" — volume ingerido por dia (últimos 30 dias)

Resultado estimado:

Item	Volume	Custo/mês
Logs das 5 máquinas	~30 GB/mês	~69 €
Application Insights	~8 GB/mês (5 GB grátis)	~7 €
Retenção > 31 dias	~25 GB	~3 €
Log search alerts (5 regras)	~4320 execuções	~14 €
Métricas + Activity Log	—	0 €
Total estimado	—	~93 €/mês

💡 Dica: Com ~93 €/mês, a TechLisboa tem monitorização completa de 5 máquinas, 1 aplicação web, alertas 24/7 e dashboards para a direcção. O custo de uma ferramenta comercial equivalente (Datadog, New Relic) seria 4–8x superior para o mesmo número de hosts.

14. Checklist de Implementação

☐ Criar Log Analytics Workspace numa região próxima (West Europe para Portugal)
☐ Definir retenção adequada (90 dias para operacional; exportar para Storage para longo prazo)
☐ Escolher sku PerGB2018 (Pay-as-you-go) para começar; migrar para Capacity Reservation se >100 GB/dia
☐ Activar Azure Monitor Agent (AMA) em todas as VMs Azure
☐ Aplicar Azure Policy "Configure VMs to be associated with AMA" para deploy automático
☐ Criar Data Collection Rules para Windows e Linux
☐ Filtrar eventos na DCR (só Warning/Error/Critical) para reduzir ingestão
☐ Instalar Dependency Agent em VMs de produção (para mapa de dependências)
☐ Activar VM Insights em todas as VMs de produção
☐ Instalar Azure Arc + AMA em servidores on-prem
☐ Activar Application Insights na aplicação web (com sampling adaptativo)
☐ Configurar Availability Tests multi-região para endpoints críticos
☐ Criar Action Group com email + SMS para a equipa de TI
☐ Configurar pelo menos 5 alertas: CPU, memória, disco, VM offline, erros de aplicação
☐ Definir supressão de alertas (mínimo 30 min) para evitar ruído
☐ Criar Workbook para a direcção com parâmetros e gráficos
☐ Criar Workbook para NOC com alertas activos e troubleshooting
☐ Configurar exportação de logs para Storage Account (retenção longa >90 dias)
☐ Rever Usage semanalmente (top tabelas por volume ingerido)
☐ Aplicar tags (CostCenter, Environment, Owner) ao workspace e DCRs
☐ Configurar budget com alertas (50%, 90%, 100%) para o resource group de monitorização
☐ Documentar queries KQL úteis para a equipa (repositório interno)
☐ Rever trimestralmente: alertas que disparam demasiado, alertas que nunca disparam
☐ Considerar Microsoft Sentinel para SIEM (ver artigo sobre Sentinel para PMEs)
☐ Considerar optimização de custos Azure (ver Azure IaaS: Optimizar Custos)

Azure Monitor: Monitorização Cloud para PMEs em 2026

Pesquisa Online

Azure Monitor: Monitorização Cloud para PMEs em 2026

Conteúdos

1. O Que é o Azure Monitor

2. Arquitetura do Azure Monitor (Metrics, Logs, Traces)

3. Log Analytics Workspace

4. KQL (Kusto Query Language) Básico

5. Data Collection Rules e Agents

6. Alertas: Regras de Alerta e Action Groups

7. Application Insights (APM)

8. Workbooks e Dashboards

9. Monitorizar VMs Azure (VM Insights)

10. Monitorizar Recursos On-Premises (Azure Arc)

11. Custos e Otimização do Azure Monitor

12. Azure Monitor vs Prometheus vs Zabbix

13. Cenário Prático PME (híbrido Azure + on-prem)

14. Checklist de Implementação

Artigos Relacionados

Este artigo foi útil?

Duarte Spínola

Deixe um Comentário