Fundamentação Teórica: Interpret Metrics in Azure Monitor
1. Intuição Inicial​
Imagine que você está dirigindo um carro. No painel, você tem velocÃmetro, tacômetro, indicador de combustÃvel e temperatura do motor. Cada um desses instrumentos coleta uma medição numérica especÃfica em tempo real e a exibe de forma que você possa tomar decisões enquanto dirige. Se a temperatura subir demais, você sabe que algo está errado e precisa agir.
Métricas no Azure Monitor são exatamente esses instrumentos para os seus recursos na nuvem. Cada recurso Azure (VMs, Storage Accounts, bancos de dados, redes) gera continuamente valores numéricos que descrevem seu estado e comportamento: percentual de CPU, bytes transferidos, número de requisições, latência de resposta, capacidade de armazenamento usada.
A diferença em relação ao painel do carro é que no Azure você pode consultar essas medições historicamente, combinar múltiplas métricas em um gráfico, calcular médias e percentis, e configurar alertas automáticos quando um valor cruza um limite definido.
2. Contexto​
2.1 Métricas dentro do Azure Monitor​
O Azure Monitor é a plataforma central de observabilidade do Azure. Ele coleta três tipos de dados:
Por que métricas existem separadas de logs? Métricas são otimizadas para consultas rápidas e alertas em tempo real. São armazenadas em formato de série temporal comprimido, adequado para renderizar gráficos e avaliar condições de alerta em segundos. Logs são texto semiestruturado, adequados para investigação profunda mas com latência maior de ingestão.
3. Construção dos Conceitos​
3.1 O que é uma métrica: estrutura fundamental​
Uma métrica é uma série temporal de valores numéricos associados a um recurso Azure. Cada ponto de dados tem:
- Timestamp: Quando foi coletado
- Value: O valor numérico (ex: 78.5)
- Metric Name: O que está sendo medido (ex: "Percentage CPU")
- Resource: O recurso Azure ao qual pertence
- Dimensions (opcional): Subdivisões da métrica por atributo
3.2 Dimensões: o conceito que multiplica o poder das métricas​
Uma dimensão é um atributo que permite filtrar ou segmentar uma métrica. É a diferença entre "quantas requisições totais chegaram" e "quantas requisições chegaram por código de resposta HTTP".
Exemplo concreto com Storage Account:
A métrica Transactions (número de operações) tem dimensões como:
ResponseType: Sucesso, ServerError, ClientErrorApiName: GetBlob, PutBlob, ListContainersAuthentication: SAS, AccountKey, AzureActiveDirectory
Sem dimensões, você vê apenas o total. Com dimensões, você consegue responder: "Quantas operações GetBlob falharam com erro do servidor nas últimas 4 horas?"
3.3 Tipos de agregação​
Métricas não são exibidas como pontos individuais para cada segundo. Elas são agregadas em intervalos de tempo. Entender qual agregação usar é fundamental para interpretar corretamente:
| Agregação | Descrição | Quando usar |
|---|---|---|
| Average | Média dos valores no intervalo | CPU%, latência média |
| Maximum | Valor mais alto no intervalo | Pico de CPU, máximo de conexões |
| Minimum | Valor mais baixo no intervalo | Memória disponÃvel mÃnima |
| Sum | Soma de todos os valores | Total de requisições, bytes transferidos |
| Count | Número de pontos de dados | Número de operações |
| Percentile (P50, P95, P99) | Percentil dos valores | Latência percentil (ex: "95% das requisições responderam em menos de X ms") |
Erro clássico: Usar Average para analisar latência de ponta. Uma média de 100ms pode esconder que 5% das requisições levam 2 segundos. Use P95 ou P99 para entender a experiência real dos usuários mais lentos.
3.4 Granularidade de tempo (Time Granularity)​
Ao consultar métricas, você define o intervalo de tempo (ex: últimas 24 horas) e a granularidade (ex: pontos de 5 em 5 minutos). A granularidade determina o tamanho da janela de agregação.
| PerÃodo consultado | Granularidade mÃnima disponÃvel |
|---|---|
| 1 hora | 1 minuto |
| 24 horas | 5 minutos |
| 7 dias | 1 hora |
| 30 dias | 1 dia |
| Mais de 30 dias | 1 dia |
Retenção: Métricas com granularidade de 1 minuto são retidas por 93 dias. Após esse perÃodo, são agregadas em granularidades maiores. Para retenção de longo prazo, exporte métricas para Log Analytics ou Storage Account.
3.5 Métricas de plataforma vs métricas customizadas vs métricas de convidado​
Métricas de plataforma (Platform Metrics): Coletadas automaticamente pelo Azure para cada recurso, sem configuração. Exemplos: CPU de VM, transações de Storage, DTU de SQL Database. DisponÃveis imediatamente após criar o recurso.
Métricas de convidado (Guest OS Metrics): Métricas do sistema operacional dentro da VM: uso de memória, disco, processos. Requerem instalação do Azure Monitor Agent na VM pois o Azure não tem visibilidade do SO por padrão.
Métricas customizadas (Custom Metrics): Criadas pela sua aplicação ou por scripts. Enviadas para o Azure Monitor via API, SDK do Application Insights, ou Azure Monitor Metrics REST API. Permitem medir qualquer coisa especÃfica da sua aplicação.
3.6 Multi-dimensional metrics: Splitting e Filtering​
Dois conceitos poderosos ao trabalhar com dimensões no Metrics Explorer:
Splitting: Divide uma métrica em séries separadas por valor de dimensão. Por exemplo: dividir Transactions da Storage Account por ResponseType mostra linhas separadas para Success, ServerError e ClientError no mesmo gráfico.
Filtering: Mostra apenas os dados onde a dimensão tem um valor especÃfico. Por exemplo: filtrar Transactions por ApiName = GetBlob mostra apenas operações de download de blob.
4. Visão Estrutural​
5. Funcionamento na Prática​
5.1 Navegando pelo Metrics Explorer​
O Metrics Explorer é a interface principal para visualizar métricas. Acesse por:
Azure Monitor > Metrics ou [Recurso] > Metrics
A interface tem quatro controles principais:
Scope (Escopo): O recurso (ou grupo de recursos ou assinatura) cujas métricas você quer ver.
Metric Namespace: Agrupa métricas relacionadas. Uma VM tem vários namespaces: Virtual Machine Host (métricas de plataforma), azure.vm.windows.guestmetrics (métricas de convidado Windows), etc.
Metric: A métrica especÃfica (ex: Percentage CPU, Available Memory Bytes).
Aggregation: Como os valores serão combinados no intervalo de tempo (Average, Max, Sum, etc.).
5.2 Exemplos práticos de interpretação​
Cenário 1: VM com CPU consistentemente alta
Métrica: Percentage CPU | Agregação: Average | PerÃodo: 24 horas | Granularidade: 5 min
Se o gráfico mostra média de 85-90% por várias horas, isso indica saturação de CPU. Compare com o pico (Maximum) para ver se chega a 100% e em que momentos.
Cenário 2: Storage Account com erros
Métrica: Transactions | Splitting por ResponseType
Se você vê linhas para ServerError ou ThrottlingError crescendo, isso indica que a Storage Account está sendo limitada (throttling) ou com problemas internos.
Cenário 3: Latência de banco de dados
Métrica: Connection Failed ou DTU Consumption Percent (Azure SQL) | Agregação: Maximum
Picos no Maximum com Average normal indicam problemas intermitentes que a média esconde.
5.3 Comparando perÃodos (Time Range Comparison)​
O Metrics Explorer permite adicionar uma linha de comparação com um perÃodo anterior. Exemplo: comparar CPU das últimas 24 horas com as 24 horas da semana passada no mesmo horário. Isso revela padrões de comportamento anômalo versus o comportamento normal esperado.
5.4 Métricas de múltiplos recursos simultaneamente​
Com Multi-resource metrics, você pode comparar a mesma métrica em várias VMs ao mesmo tempo. Por exemplo: ver Percentage CPU de todas as VMs de um Scale Set lado a lado para identificar se uma VM especÃfica está desbalanceada.
6. Formas de Implementação​
6.1 Portal Azure (Metrics Explorer)​
Quando usar: Investigação interativa, criação de dashboards ad-hoc, troubleshooting em tempo real.
Vantagens: Interface visual intuitiva, sem necessidade de conhecer nomes de métricas de antemão, fácil exploração de dimensões com splitting e filtering.
Limitação: Não é automatizável; cada consulta é manual.
Dica: Use o botão "Pin to dashboard" para salvar gráficos úteis num dashboard permanente.
6.2 Azure CLI​
# Listar todas as métricas disponÃveis para um recurso
az monitor metrics list-definitions \
--resource <resource-id> \
--output table
# Consultar métrica especÃfica
az monitor metrics list \
--resource <resource-id> \
--metric "Percentage CPU" \
--interval PT5M \
--start-time 2025-01-15T00:00:00Z \
--end-time 2025-01-15T23:59:59Z \
--aggregation Average Maximum \
--output table
# Consultar métrica com filtro de dimensão
az monitor metrics list \
--resource <storage-account-id> \
--metric "Transactions" \
--interval PT1H \
--aggregation Total \
--filter "ResponseType eq 'ServerError'" \
--output table
Quando usar: Scripts de automação, relatórios periódicos, quando precisa processar valores programaticamente.
6.3 Azure PowerShell​
# Consultar métricas
$result = Get-AzMetric `
-ResourceId <resource-id> `
-MetricName "Percentage CPU" `
-StartTime (Get-Date).AddHours(-24) `
-EndTime (Get-Date) `
-TimeGrainInMinutes 5 `
-AggregationType Average
# Processar resultado
$result.Data | Select-Object TimeStamp, Average | Format-Table
6.4 REST API do Azure Monitor​
Para integração com sistemas externos ou dashboards customizados:
# Consultar via REST API
curl -X GET \
"https://management.azure.com{resource-id}/providers/microsoft.insights/metrics?metricnames=Percentage%20CPU×pan=2025-01-15T00:00:00Z/2025-01-15T23:59:59Z&interval=PT5M&aggregation=average&api-version=2019-07-01" \
-H "Authorization: Bearer <token>"
A resposta retorna um JSON com timestamps e valores agregados.
6.5 Kusto (Log Analytics) para métricas arquivadas​
Quando você exporta métricas para Log Analytics, pode consultá-las com Kusto Query Language (KQL):
// CPU média de todas as VMs nas últimas 24 horas
AzureMetrics
| where TimeGenerated > ago(24h)
| where MetricName == "Percentage CPU"
| where ResourceType == "MICROSOFT.COMPUTE/VIRTUALMACHINES"
| summarize AvgCPU = avg(Average) by Resource, bin(TimeGenerated, 1h)
| order by TimeGenerated desc
Quando usar: Análise histórica além de 93 dias, correlação de métricas com logs, relatórios complexos.
7. Controle e Segurança​
7.1 Permissões para leitura de métricas​
| Role | Acesso a métricas |
|---|---|
| Monitoring Reader | Leitura de métricas e alertas (sem modificar) |
| Monitoring Contributor | Criar e modificar alertas, action groups |
| Reader | Visualizar métricas do recurso (herdado) |
| Owner / Contributor | Acesso completo |
Para equipes de operações que precisam apenas monitorar sem modificar recursos, Monitoring Reader é o papel ideal.
7.2 Diagnóstico: habilitando métricas de diagnóstico​
Alguns recursos requerem habilitação explÃcita de diagnósticos para exportar métricas e logs além do padrão:
az monitor diagnostic-settings create \
--name "vm-diagnostics" \
--resource <vm-resource-id> \
--metrics '[{"category":"AllMetrics","enabled":true,"retentionPolicy":{"days":30,"enabled":true}}]' \
--workspace <log-analytics-workspace-id>
Isso envia métricas para Log Analytics, permitindo análise histórica além dos 93 dias padrão.
7.3 Exportação contÃnua de métricas​
Para retenção de longo prazo ou integração com sistemas de terceiros (Grafana, Datadog, Splunk):
# Exportar métricas para Storage Account
az monitor diagnostic-settings create \
--name "metrics-export" \
--resource <resource-id> \
--metrics '[{"category":"AllMetrics","enabled":true}]' \
--storage-account <storage-account-id>
8. Tomada de Decisão​
8.1 Qual agregação usar para cada cenário​
| Métrica | Aggregação recomendada | Motivo |
|---|---|---|
| CPU Percentage | Average + Maximum | Average mostra tendência; Max mostra picos |
| Available Memory Bytes | Minimum | Você quer saber o pior caso |
| Network In/Out bytes | Sum | Total de dados transferidos no perÃodo |
| Request Count | Sum | Total de requisições |
| Response Latency | P95 ou P99 | Experiência do usuário mais lento |
| Error Count | Sum | Total de erros |
| Disk Queue Depth | Average | Pressão média de I/O |
| Connections Active | Maximum | Pico de conexões simultâneas |
8.2 Platform metrics vs Log Analytics para consultas​
| Situação | Melhor abordagem | Motivo |
|---|---|---|
| Alerta em tempo real (< 1 min) | Platform Metrics | Latência mÃnima |
| Análise histórica > 93 dias | Log Analytics | Métricas exportadas para retenção longa |
| Correlacionar métricas com eventos de log | Log Analytics | Dados unidos na mesma query KQL |
| Dashboard operacional ao vivo | Platform Metrics + Metrics Explorer | Atualização frequente |
| Relatório mensal de capacidade | Log Analytics + KQL | Análise de tendências longa |
| Autoscale de VM Scale Set | Platform Metrics | Autoscale só usa platform metrics |
8.3 Granularidade adequada por cenário​
| Cenário | Granularidade recomendada |
|---|---|
| Investigação de incidente recente | 1 minuto |
| Dashboard operacional do dia | 5 minutos |
| Tendência semanal de capacidade | 1 hora |
| Relatório mensal | 1 dia |
| Análise de sazonalidade | 1 dia ou 1 semana |
9. Boas Práticas​
- Combine Average com Maximum ao analisar CPU: Average mostra tendência geral; Maximum revela picos que a média esconde.
- Use P95 ou P99 para métricas de latência, nunca apenas Average. Médias de latência mascaram a experiência dos usuários mais lentos.
- Habilite splitting por dimensão ao investigar erros: dividir
TransactionsporResponseTypeimediatamente revela se os erros vêm do servidor ou do cliente. - Salve gráficos úteis em dashboards compartilhados para a equipe, evitando recriar as mesmas visualizações durante incidentes.
- Configure retenção estendida exportando métricas para Log Analytics se você precisar análise histórica além de 93 dias.
- Use comparação de perÃodo (perÃodo anterior) ao investigar anomalias: comparar com a mesma janela da semana anterior revela se o comportamento é novo ou padrão.
- Documente os limites normais para métricas crÃticas de cada recurso. Sem linha de base, qualquer valor parece suspeito ou normal.
- Combine métricas de plataforma com métricas de convidado para VMs: a plataforma mostra CPU e rede; as métricas de convidado mostram memória e I/O de disco interno.
10. Erros Comuns​
| Erro | Por que acontece | Como evitar |
|---|---|---|
| CPU parece baixa mas aplicação está lenta | Usando Average escondendo picos curtos | Adicionar Maximum e granularidade menor (1 min) |
| Latência parece boa mas usuários reclamam | Usando Average em vez de P95/P99 | Usar percentis para métricas de latência |
| Métrica de memória não aparece para VM | Métricas de convidado não configuradas | Instalar Azure Monitor Agent na VM |
| Não encontra métrica esperada | Namespace errado selecionado | Verificar todos os namespaces disponÃveis para o recurso |
| Gráfico mostra "No data" | Recurso sem dados no perÃodo | Aumentar intervalo de tempo ou verificar se recurso estava ativo |
| Throttling de Storage não detectado | Não aplicando splitting por ResponseType | Usar split por ResponseType para ver ThrottlingError separadamente |
| Alerta disparando desnecessariamente | Threshold muito sensÃvel para granularidade longa | Ajustar granularidade ou usar agregação mais adequada |
| Dados históricos indisponÃveis | PerÃodo além de 93 dias sem exportação configurada | Configurar exportação para Log Analytics antecipadamente |
11. Operação e Manutenção​
11.1 Métricas essenciais por tipo de recurso​
Virtual Machines:
| Métrica | Namespace | Agregação | Threshold de atenção |
|---|---|---|---|
| Percentage CPU | Virtual Machine Host | Average + Max | > 80% avg ou 100% max por > 5 min |
| Available Memory Bytes | Guest OS | Min | < 10% da memória total |
| OS Disk Queue Depth | Virtual Machine Host | Average | > 10 |
| Network In/Out | Virtual Machine Host | Sum | Pico anormal vs baseline |
Storage Accounts:
| Métrica | Agregação | Threshold de atenção |
|---|---|---|
| Transactions | Sum, split por ResponseType | Qualquer ThrottlingError |
| SuccessE2ELatency | Average + P95 | > 200ms média |
| Availability | Average | < 99.9% |
| UsedCapacity | Average | > 80% do limite |
Azure SQL Database:
| Métrica | Agregação | Threshold de atenção |
|---|---|---|
| DTU Consumption Percent | Maximum | > 80% |
| Connection Failed | Sum | Qualquer valor > 0 |
| Deadlocks | Sum | Qualquer valor > 0 |
| Sessions Percent | Maximum | > 80% |
11.2 Monitorando o próprio Azure Monitor​
Se as métricas param de aparecer, verifique:
# Verificar se o Azure Monitor Agent está ativo na VM
az vm extension list \
--resource-group myRG \
--vm-name myVM \
--query "[?name=='AzureMonitorLinuxAgent'].{Name:name, State:provisioningState}" \
--output table
11.3 Limites importantes​
| Aspecto | Limite |
|---|---|
| Retenção de métricas de plataforma | 93 dias |
| Granularidade mÃnima disponÃvel | 1 minuto |
| Custom metrics por recurso | 50 dimensões, 10 valores por dimensão |
| Latência de ingestão de métricas | 2 a 3 minutos (métricas de plataforma) |
| Latência de métricas de convidado | 5 a 10 minutos após configuração |
| Custo de platform metrics | Gratuito |
| Custo de custom metrics | Por ponto de dados enviado |
12. Integração e Automação​
12.1 Criando alertas baseados em métricas​
az monitor metrics alert create \
--name "High-CPU-Alert" \
--resource-group myRG \
--scopes <vm-resource-id> \
--condition "avg Percentage CPU > 85" \
--window-size 5m \
--evaluation-frequency 1m \
--severity 2 \
--action-group <action-group-id> \
--description "CPU acima de 85% por 5 minutos"
O campo --condition suporta operadores como avg, max, min, sum, count e comparações >, <, >=, <=, ==.
12.2 Integrando com Grafana​
O Azure Monitor tem um data source plugin nativo para Grafana. Configure o data source apontando para sua assinatura Azure e crie dashboards com métricas de qualquer recurso:
{
"type": "grafana-azure-monitor-datasource",
"name": "Azure Monitor",
"access": "proxy",
"jsonData": {
"subscriptionId": "<sub-id>",
"tenantId": "<tenant-id>"
}
}
12.3 Autoscale baseado em métricas​
O Azure Autoscale usa métricas de plataforma para escalar recursos automaticamente:
az monitor autoscale create \
--resource-group myRG \
--resource <vmss-resource-id> \
--resource-type Microsoft.Compute/virtualMachineScaleSets \
--name myAutoscaleSettings \
--min-count 2 \
--max-count 10 \
--count 2
# Adicionar regra de scale-out baseada em CPU
az monitor autoscale rule create \
--resource-group myRG \
--autoscale-name myAutoscaleSettings \
--condition "Percentage CPU > 75 avg 5m" \
--scale out 1
12.4 Exportando métricas via Diagnostic Settings para múltiplos destinos​
az monitor diagnostic-settings create \
--name "full-diagnostics" \
--resource <resource-id> \
--metrics '[{"category":"AllMetrics","enabled":true}]' \
--workspace <log-analytics-workspace-id> \
--storage-account <storage-account-id> \
--event-hub-name <event-hub-name> \
--event-hub-rule <event-hub-auth-rule-id>
Você pode enviar para Log Analytics (consulta KQL), Storage Account (arquivamento de longo prazo) e Event Hub (integração com Splunk, Datadog, etc.) simultaneamente.
13. Resumo Final​
Conceitos essenciais:
- Métricas são séries temporais de valores numéricos coletadas automaticamente de recursos Azure, armazenadas por 93 dias com granularidade de até 1 minuto.
- Cada métrica pode ter dimensões que permitem filtrar (ver apenas erros) ou dividir (separar por tipo de operação) os dados.
- O Metrics Explorer é a interface principal para visualização interativa com scope, namespace, metric e aggregation como controles principais.
Diferenças crÃticas:
- Platform Metrics vs Guest OS Metrics: Platform metrics são automáticas. Guest metrics requerem Azure Monitor Agent instalado na VM para coletar métricas do SO interno (memória, disco).
- Average vs Maximum vs Percentile: Average para tendências. Maximum para picos. P95/P99 para latência real da experiência do usuário.
- Splitting vs Filtering: Splitting cria linhas separadas no gráfico por valor de dimensão. Filtering mostra apenas os dados correspondentes a um valor especÃfico de dimensão.
- Platform Metrics vs Log Analytics: Métricas são otimizadas para alertas em tempo real e têm retenção de 93 dias. Log Analytics tem retenção configurável e permite correlação com logs.
O que precisa ser lembrado:
- Métricas de plataforma têm latência de 2 a 3 minutos após o evento. Não confunda ausência de dados com inexistência de atividade.
- Para análise além de 93 dias, configure exportação para Log Analytics ou Storage Account antes de precisar.
- Autoscale usa apenas métricas de plataforma, não métricas de convidado nem logs.
- Para VMs, métricas de memória não aparecem por padrão no namespace de plataforma; é necessário o Azure Monitor Agent para métricas de convidado.
- Use P95 ou P99 para métricas de latência em qualquer análise de experiência do usuário. Médias de latência são enganosas.
- A granularidade disponÃvel diminui com o tempo: dados de 1 minuto ficam disponÃveis por 93 dias, mas dados históricos mais antigos só existem em granularidades maiores.