Pular para o conteúdo principal

Laboratório Hands-on Guiado: AZ-104 Microsoft Azure Administrator

Cenário​

A Nimbus Tecnologia é uma empresa de médio porte que opera uma plataforma SaaS de gestão financeira hospedada no Azure. O ambiente atual conta com máquinas virtuais que executam os serviços de backend, contas de armazenamento para dados de clientes e logs de auditoria, e redes virtuais que interconectam as camadas de aplicação, dados e gerenciamento. Recentemente, a equipe de operações identificou falhas intermitentes de conectividade entre as VMs de aplicação e o banco de dados, além de picos de consumo de CPU não investigados.

O objetivo deste laboratório é implementar uma estratégia completa de monitoramento com o Azure Monitor, cobrindo métricas, logs, alertas, insights de VMs, armazenamento e rede, além de diagnóstico avançado com o Network Watcher. Ao final, a equipe terá visibilidade operacional sobre todos os componentes críticos da infraestrutura da Nimbus Tecnologia.

Pré-requisitos​

Antes de iniciar a Fase 1, crie os recursos listados abaixo. Todos os recursos devem estar na mesma região para simplificar a configuração de monitoramento e evitar custos de transferência entre regiões.

  1. Crie o Resource Group rg-nimbus-lab na região East US.
  2. Crie uma Virtual Network vnet-nimbus com o espaço de endereços 10.0.0.0/16 e duas sub-redes:
    • snet-app com o intervalo 10.0.1.0/24
    • snet-data com o intervalo 10.0.2.0/24
  3. Crie uma VM Linux (Ubuntu 22.04) chamada vm-app-01 na sub-rede snet-app, tamanho Standard_B2s, com IP público habilitado e porta SSH (22) liberada no NSG.
  4. Crie uma VM Windows Server 2022 chamada vm-data-01 na sub-rede snet-data, tamanho Standard_B2s, com RDP (3389) liberado no NSG.
  5. Crie uma Storage Account chamada stnimbuslab (tipo StorageV2, redundância LRS), e dentro dela crie um Blob Container chamado logs-auditoria.
  6. Crie um Log Analytics Workspace chamado law-nimbus no mesmo resource group.
RecursoNome no labRegião
Resource Grouprg-nimbus-labEast US
Virtual Networkvnet-nimbusEast US
Sub-rede Aplicaçãosnet-appEast US
Sub-rede Dadossnet-dataEast US
VM Linuxvm-app-01East US
VM Windowsvm-data-01East US
NSG da VM Linuxvm-app-01-nsgEast US
NSG da VM Windowsvm-data-01-nsgEast US
Storage AccountstnimbuslabEast US
Blob Containerlogs-auditoriaEast US
Log Analytics Workspacelaw-nimbusEast US

Fases do Laboratório​

O laboratório está organizado em quatro fases progressivas. Cada fase expande o ambiente construído anteriormente, adicionando camadas de monitoramento até atingir a cobertura completa.

Fase 1 — Métricas e Logs no Azure Monitor​

Nesta fase, você configurará a coleta de métricas e logs para os recursos criados nos pré-requisitos. Ao final, o Log Analytics Workspace law-nimbus estará recebendo dados das VMs e da Storage Account, e você terá interpretado métricas de plataforma diretamente no Azure Monitor. Esta fase cobre os objetivos: Interpret metrics in Azure Monitor, Configure log settings in Azure Monitor e Query and analyze logs in Azure Monitor.

Tarefa 1.1 — Interpretar métricas de plataforma das VMs e da Storage Account​

O time de operações da Nimbus precisa entender o comportamento atual dos recursos antes de configurar qualquer regra de alerta. Nesta tarefa você acessará o Metrics Explorer, selecionará métricas relevantes e interpretará os gráficos resultantes.

Via Portal​

  1. Navegue até Monitor > Metrics.
  2. No campo Scope, selecione o recurso vm-app-01.
  3. No campo Metric Namespace, mantenha Virtual Machine Host.
  4. No campo Metric, selecione Percentage CPU.
  5. No campo Aggregation, selecione Avg.
  6. Ajuste o intervalo de tempo para Last 1 hour e a granularidade para 1 minute.
  7. Clique em Add metric para adicionar uma segunda métrica no mesmo gráfico.
  8. Repita os passos 2 a 5, mas agora selecione o recurso stnimbuslab, namespace Blob, métrica BlobCapacity e agregação Avg.
  9. Observe que métricas de recursos diferentes podem ser comparadas lado a lado no mesmo gráfico quando compartilham o mesmo eixo temporal.
  10. Clique em Pin to dashboard e selecione Create new > nomeie como Dashboard-Nimbus-Ops > Pin.
  11. Agora altere a agregação de Percentage CPU para Max e compare com o gráfico anterior. Observe como a agregação influencia a interpretação: Avg suaviza picos, enquanto Max revela os valores extremos.

Via CLI​

# Consultar a métrica Percentage CPU da VM nos últimos 30 minutos
az monitor metrics list \
  --resource $(az vm show -g rg-nimbus-lab -n vm-app-01 --query id -o tsv) \
  --metric "Percentage CPU" \
  --aggregation Average Maximum \
  --interval PT1M \
  --start-time $(date -u -d '-30 minutes' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --output table

# Consultar BlobCapacity da Storage Account
az monitor metrics list \
  --resource $(az storage account show -g rg-nimbus-lab -n stnimbuslab --query id -o tsv) \
  --metric "BlobCapacity" \
  --aggregation Average \
  --interval PT1H \
  --output table

Ao concluir, você terá observado que as métricas de plataforma são coletadas automaticamente, sem necessidade de agente, e que a escolha de agregação e granularidade altera significativamente a leitura dos dados. O dashboard fixado servirá como ponto de referência operacional nas próximas fases.

Tarefa 1.2 — Configurar Diagnostic Settings para enviar logs ao Log Analytics​

Sem configuração explícita de diagnóstico, os logs de atividade e de recurso não são enviados ao Log Analytics Workspace. Nesta tarefa, você habilitará Diagnostic Settings nas VMs e na Storage Account para direcionar logs e métricas ao workspace law-nimbus.

Via Portal​

  1. Navegue até a Storage Account stnimbuslab.
  2. No menu lateral, selecione Monitoring > Diagnostic settings.
  3. Selecione o sub-recurso blob.
  4. Clique em Add diagnostic setting.
  5. No campo Diagnostic setting name, preencha com diag-blob-nimbus.
  6. Na seção Logs, marque StorageRead, StorageWrite e StorageDelete.
  7. Na seção Metrics, marque Transaction.
  8. Na seção Destination details, marque Send to Log Analytics workspace e selecione law-nimbus.
  9. Clique em Save.
  10. Repita os passos 1 a 9 para o sub-recurso table da mesma Storage Account, nomeando como diag-table-nimbus.
  11. Navegue até Monitor > Activity log.
  12. Clique em Export Activity Logs.
  13. Clique em Add diagnostic setting, nomeie como diag-activity-nimbus.
  14. Marque todas as categorias de log: Administrative, Security, ServiceHealth, Alert, Recommendation, Policy, Autoscale e ResourceHealth.
  15. Marque Send to Log Analytics workspace e selecione law-nimbus.
  16. Clique em Save.

Via CLI​

# Obter o resource ID da storage account (sub-recurso blob)
STORAGE_ID=$(az storage account show -g rg-nimbus-lab -n stnimbuslab --query id -o tsv)

# Criar diagnostic setting para blob
az monitor diagnostic-settings create \
  --name diag-blob-nimbus \
  --resource "$STORAGE_ID/blobServices/default" \
  --workspace $(az monitor log-analytics workspace show -g rg-nimbus-lab -n law-nimbus --query id -o tsv) \
  --logs '[{"category":"StorageRead","enabled":true},{"category":"StorageWrite","enabled":true},{"category":"StorageDelete","enabled":true}]' \
  --metrics '[{"category":"Transaction","enabled":true}]'

# Criar diagnostic setting para Activity Log (nível de subscription)
az monitor diagnostic-settings subscription create \
  --name diag-activity-nimbus \
  --workspace $(az monitor log-analytics workspace show -g rg-nimbus-lab -n law-nimbus --query id -o tsv) \
  --logs '[{"category":"Administrative","enabled":true},{"category":"Security","enabled":true},{"category":"ServiceHealth","enabled":true},{"category":"Alert","enabled":true},{"category":"Recommendation","enabled":true},{"category":"Policy","enabled":true},{"category":"Autoscale","enabled":true},{"category":"ResourceHealth","enabled":true}]'

Agora os logs de operações no Blob Storage e os logs de atividade da subscription fluem para o workspace law-nimbus. Leva de 5 a 15 minutos para os primeiros registros aparecerem.

Tarefa 1.3 — Habilitar o Azure Monitor Agent e Data Collection Rules nas VMs​

Para coletar logs do sistema operacional (Syslog, Windows Events) e métricas de performance do guest OS, é necessário instalar o Azure Monitor Agent (AMA) e configurar uma Data Collection Rule (DCR). Sem essa configuração, o Azure Monitor só enxerga métricas do host.

Via Portal​

  1. Navegue até Monitor > Data Collection Rules.
  2. Clique em Create.
  3. No campo Rule Name, preencha dcr-nimbus-vms.
  4. Em Platform Type, selecione All.
  5. Em Region, selecione East US.
  6. Em Resource Group, selecione rg-nimbus-lab.
  7. Clique em Next: Resources.
  8. Clique em Add resources e selecione ambas as VMs: vm-app-01 e vm-data-01.
  9. Marque a opção Enable Data Collection Endpoints se disponível e selecione ou crie um endpoint na mesma região.
  10. Clique em Next: Collect and deliver.
  11. Clique em Add data source.
  12. Em Data source type, selecione Performance Counters. Mantenha as métricas padrão (CPU, Memory, Disk, Network) com intervalo de 60 segundos.
  13. Na aba Destination, selecione Azure Monitor Logs e aponte para law-nimbus.
  14. Clique em Add data source novamente.
  15. Selecione Linux Syslog. Marque as facilidades auth, authpriv, syslog, daemon com nível mínimo LOG_WARNING.
  16. Adicione o destino apontando para law-nimbus.
  17. Clique em Add data source novamente.
  18. Selecione Windows Event Logs. Marque System (Warning e acima) e Application (Error e acima).
  19. Adicione o destino apontando para law-nimbus.
  20. Clique em Review + create > Create.

Via CLI​

LAW_ID=$(az monitor log-analytics workspace show -g rg-nimbus-lab -n law-nimbus --query id -o tsv)

# Criar a Data Collection Rule via arquivo JSON
cat <<'EOF' > dcr-nimbus.json
{
  "location": "eastus",
  "properties": {
    "dataSources": {
      "performanceCounters": [{
        "name": "perfCounters",
        "streams": ["Microsoft-Perf"],
        "samplingFrequencyInSeconds": 60,
        "counterSpecifiers": [
          "\\Processor(_Total)\\% Processor Time",
          "\\Memory\\Available Bytes",
          "\\LogicalDisk(_Total)\\% Free Space"
        ]
      }],
      "syslog": [{
        "name": "syslogDataSource",
        "streams": ["Microsoft-Syslog"],
        "facilityNames": ["auth","authpriv","syslog","daemon"],
        "logLevels": ["Warning","Error","Critical","Alert","Emergency"]
      }],
      "windowsEventLogs": [{
        "name": "winEventLogs",
        "streams": ["Microsoft-Event"],
        "xPathQueries": [
          "System!*[System[(Level=1 or Level=2 or Level=3)]]",
          "Application!*[System[(Level=1 or Level=2)]]"
        ]
      }]
    },
    "destinations": {
      "logAnalytics": [{
        "workspaceResourceId": "LAW_ID_PLACEHOLDER",
        "name": "lawNimbus"
      }]
    },
    "dataFlows": [
      { "streams": ["Microsoft-Perf"], "destinations": ["lawNimbus"] },
      { "streams": ["Microsoft-Syslog"], "destinations": ["lawNimbus"] },
      { "streams": ["Microsoft-Event"], "destinations": ["lawNimbus"] }
    ]
  }
}
EOF

# Substituir o placeholder pelo ID real
sed -i "s|LAW_ID_PLACEHOLDER|$LAW_ID|" dcr-nimbus.json

az monitor data-collection rule create \
  --name dcr-nimbus-vms \
  --resource-group rg-nimbus-lab \
  --body @dcr-nimbus.json

# Associar a DCR às VMs (isso instala o AMA automaticamente)
DCR_ID=$(az monitor data-collection rule show -g rg-nimbus-lab -n dcr-nimbus-vms --query id -o tsv)

az monitor data-collection rule association create \
  --name assoc-vm-app-01 \
  --rule-id "$DCR_ID" \
  --resource $(az vm show -g rg-nimbus-lab -n vm-app-01 --query id -o tsv)

az monitor data-collection rule association create \
  --name assoc-vm-data-01 \
  --rule-id "$DCR_ID" \
  --resource $(az vm show -g rg-nimbus-lab -n vm-data-01 --query id -o tsv)

Ao concluir, o Azure Monitor Agent será instalado automaticamente em ambas as VMs por meio da associação com a DCR. Métricas de guest OS, Syslog e Windows Events começarão a fluir para law-nimbus em poucos minutos.

Tarefa 1.4 — Consultar e analisar logs com KQL no Log Analytics​

Agora que os logs estão fluindo para law-nimbus, a equipe de operações precisa extrair informações acionáveis. Nesta tarefa você executará consultas KQL progressivamente mais complexas e lidará com um cenário em que os dados ainda não apareceram (comportamento comum que gera confusão).

Via Portal​

  1. Navegue até Monitor > Logs.
  2. Confirme que o escopo está definido para o workspace law-nimbus.
  3. Execute a seguinte consulta para verificar se a tabela Heartbeat já está recebendo dados das VMs:
Heartbeat
| where TimeGenerated > ago(30m)
| summarize LastHeartbeat = max(TimeGenerated) by Computer
| order by LastHeartbeat desc
  1. Se a consulta retornar resultados vazios, aguarde mais 10 minutos e execute novamente. Esse atraso é esperado quando o agente foi recém-instalado. Confirme que a DCR está associada verificando em Monitor > Data Collection Rules > dcr-nimbus-vms > Resources.
  2. Execute uma consulta para identificar picos de CPU coletados pelo AMA:
Perf
| where ObjectName == "Processor" and CounterName == "% Processor Time"
| where InstanceName == "_Total"
| where TimeGenerated > ago(1h)
| summarize AvgCPU = avg(CounterValue), MaxCPU = max(CounterValue) by bin(TimeGenerated, 5m), Computer
| order by TimeGenerated desc
| render timechart
  1. Execute uma consulta para analisar operações no Blob Storage:
StorageBlobLogs
| where TimeGenerated > ago(1h)
| summarize Count = count() by OperationName, StatusCode = tostring(StatusCode)
| order by Count desc

  1. Se a tabela StorageBlobLogs estiver vazia, gere tráfego: no portal, navegue até stnimbuslab > Containers > logs-auditoria e faça upload de um arquivo de texto qualquer. Aguarde 5 minutos e execute a consulta novamente.

  2. Execute uma consulta de correlação entre Activity Log e operações de storage:

AzureActivity
| where TimeGenerated > ago(24h)
| where ResourceGroup == "RG-NIMBUS-LAB"
| project TimeGenerated, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated desc
| take 20

Via CLI​

# Executar consulta KQL via CLI
az monitor log-analytics query \
  --workspace $(az monitor log-analytics workspace show -g rg-nimbus-lab -n law-nimbus --query customerId -o tsv) \
  --analytics-query "Heartbeat | where TimeGenerated > ago(30m) | summarize LastHeartbeat = max(TimeGenerated) by Computer" \
  --output table

# Consulta de picos de CPU
az monitor log-analytics query \
  --workspace $(az monitor log-analytics workspace show -g rg-nimbus-lab -n law-nimbus --query customerId -o tsv) \
  --analytics-query "Perf | where ObjectName == 'Processor' and CounterName == '% Processor Time' | where TimeGenerated > ago(1h) | summarize AvgCPU=avg(CounterValue) by bin(TimeGenerated,5m), Computer" \
  --output table

Ao concluir, você terá praticado consultas KQL que cobrem agregação temporal, renderização de gráficos, filtragem por tipo de operação e correlação entre tabelas diferentes. O cenário de dados ainda não disponíveis é uma situação adversa real que o administrador deve saber diagnosticar.

Fase 2 — Alertas, Action Groups e Alert Processing Rules​

Nesta fase, você criará regras de alerta para detectar condições anômalas nos recursos monitorados na Fase 1, configurará action groups para notificação e aplicará alert processing rules para controlar o comportamento dos alertas. Os recursos law-nimbus, vm-app-01, vm-data-01 e stnimbuslab criados anteriormente serão utilizados. Esta fase cobre o objetivo: Set up alert rules, action groups, and alert processing rules in Azure Monitor.

Tarefa 2.1 — Criar Action Groups para notificação​

Antes de criar qualquer regra de alerta, a equipe precisa definir os canais de notificação. Você criará dois action groups: um para a equipe de operações (e-mail) e outro para incidentes críticos (e-mail + webhook simulado).

Via Portal​

  1. Navegue até Monitor > Alerts > Action groups.
  2. Clique em Create.
  3. Em Resource group, selecione rg-nimbus-lab.
  4. Em Action group name, preencha ag-ops-nimbus.
  5. Em Display name, preencha OpsNimbus.
  6. Clique em Next: Notifications.
  7. Em Notification type, selecione Email/SMS message/Push/Voice.
  8. Em Name, preencha email-ops.
  9. No painel que se abre, preencha o campo Email com um endereço de e-mail válido que você tenha acesso (para confirmar o recebimento na validação).
  10. Clique em OK > Review + create > Create.
  11. Repita os passos 2 a 10 para criar um segundo action group:
    • Nome: ag-critical-nimbus, Display name: CritNimbus
    • Notificação por e-mail (mesmo endereço ou diferente): nome email-critical
    • Na aba Actions, adicione um tipo Webhook com nome webhook-incident e URL https://example.com/webhook (URL simulada para fins de laboratório)

Via CLI​

# Criar action group de operações
az monitor action-group create \
  --resource-group rg-nimbus-lab \
  --name ag-ops-nimbus \
  --short-name OpsNimbus \
  --action email email-ops seu-email@exemplo.com

# Criar action group crítico com e-mail e webhook
az monitor action-group create \
  --resource-group rg-nimbus-lab \
  --name ag-critical-nimbus \
  --short-name CritNimbus \
  --action email email-critical seu-email@exemplo.com \
  --action webhook webhook-incident https://example.com/webhook

Os action groups estão prontos para serem referenciados pelas regras de alerta. O webhook simulado permite observar a tentativa de entrega na Fase de Validação Final.

Tarefa 2.2 — Criar regras de alerta de métrica e de log​

Agora você criará duas regras de alerta: uma baseada em métrica (CPU da VM) e outra baseada em consulta de log (erros no Syslog).

Via Portal​

Alerta de métrica (CPU):

  1. Navegue até Monitor > Alerts > Alert rules.
  2. Clique em Create.
  3. Em Scope, clique em Select scope e selecione o recurso vm-app-01.
  4. Clique em Next: Condition.
  5. Em Signal name, selecione Percentage CPU.
  6. Em Threshold, selecione Static.
  7. Em Operator, selecione Greater than.
  8. Em Threshold value, preencha 80.
  9. Em Aggregation granularity (Period), selecione 5 minutes.
  10. Em Frequency of evaluation, selecione 1 minute.
  11. Clique em Next: Actions.
  12. Clique em Select action groups e selecione ag-ops-nimbus.
  13. Clique em Next: Details.
  14. Em Alert rule name, preencha alert-cpu-vm-app-01.
  15. Em Severity, selecione Sev2 - Warning.
  16. Marque Enable upon creation.
  17. Clique em Review + create > Create.

Alerta de log (erros Syslog):

  1. Navegue até Monitor > Alerts > Alert rules > Create.
  2. Em Scope, selecione o workspace law-nimbus.
  3. Em Condition, selecione o signal Custom log search.
  4. No campo Search query, insira:
Syslog
| where SeverityLevel in ("err", "crit", "alert", "emerg")
| where TimeGenerated > ago(15m)
| summarize ErrorCount = count() by Computer
| where ErrorCount > 5
  1. Em Measurement: Measure = Table rows, Aggregation type = Count, Aggregation granularity = 15 minutes.
  2. Em Alert logic: Operator = Greater than, Threshold value = 0, Frequency of evaluation = 5 minutes.
  3. Clique em Next: Actions e selecione ag-critical-nimbus.
  4. Em Details, nomeie como alert-syslog-errors.
  5. Severity = Sev1 - Error.
  6. Clique em Review + create > Create.

Via CLI​

VM_ID=$(az vm show -g rg-nimbus-lab -n vm-app-01 --query id -o tsv)
AG_OPS_ID=$(az monitor action-group show -g rg-nimbus-lab -n ag-ops-nimbus --query id -o tsv)
AG_CRIT_ID=$(az monitor action-group show -g rg-nimbus-lab -n ag-critical-nimbus --query id -o tsv)

# Alerta de métrica para CPU
az monitor metrics alert create \
  --name alert-cpu-vm-app-01 \
  --resource-group rg-nimbus-lab \
  --scopes "$VM_ID" \
  --condition "avg Percentage CPU > 80" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --severity 2 \
  --action "$AG_OPS_ID" \
  --description "CPU acima de 80% na vm-app-01"

# Alerta de log para erros no Syslog
LAW_ID=$(az monitor log-analytics workspace show -g rg-nimbus-lab -n law-nimbus --query id -o tsv)

az monitor scheduled-query create \
  --name alert-syslog-errors \
  --resource-group rg-nimbus-lab \
  --scopes "$LAW_ID" \
  --condition "count 'Syslog | where SeverityLevel in (\"err\",\"crit\",\"alert\",\"emerg\") | where TimeGenerated > ago(15m) | summarize ErrorCount=count() by Computer | where ErrorCount > 5' > 0" \
  --condition-query "Syslog | where SeverityLevel in ('err','crit','alert','emerg') | where TimeGenerated > ago(15m) | summarize ErrorCount=count() by Computer | where ErrorCount > 5" \
  --window-size 15m \
  --evaluation-frequency 5m \
  --severity 1 \
  --action "$AG_CRIT_ID"

Agora a infraestrutura da Nimbus possui alertas ativos que detectam tanto anomalias de infraestrutura (CPU) quanto problemas no nível de aplicação/SO (Syslog). O alerta de CPU usa avaliação de métrica de plataforma (sem dependência de agente), enquanto o alerta de log depende dos dados coletados via AMA na Fase 1.

Tarefa 2.3 — Configurar Alert Processing Rules para supressão em janela de manutenção​

A Nimbus realiza manutenção programada toda sexta-feira das 22:00 às 02:00 (UTC). Durante esse período, os alertas de métrica não devem gerar notificações para evitar fadiga de alerta. Você criará uma alert processing rule que suprime notificações durante essa janela, e depois verificará que a regra está configurada corretamente antes de confiar nela.

Via Portal​

  1. Navegue até Monitor > Alerts > Alert processing rules.
  2. Clique em Create.
  3. Em Scope, selecione o resource group rg-nimbus-lab.
  4. Clique em Next: Rule settings.
  5. Selecione Suppress notifications.
  6. Clique em Next: Scheduling.
  7. Selecione At a specific time.
  8. Defina a recorrência como Weekly, marcando apenas Friday.
  9. Em Start time, preencha 22:00.
  10. Em End time, preencha 02:00.
  11. Em Time zone, selecione (UTC) Coordinated Universal Time.
  12. Clique em Next: Details.
  13. Em Rule name, preencha apr-manutencao-sexta.
  14. Em Resource group, selecione rg-nimbus-lab.
  15. Marque Enable upon creation.
  16. Clique em Review + create > Create.

Verificação do estado da regra:

  1. Após a criação, volte a Monitor > Alerts > Alert processing rules.
  2. Confirme que apr-manutencao-sexta aparece com o status Enabled.
  3. Clique na regra e verifique se o escopo, a agenda e o tipo (Suppress notifications) estão corretos.
  4. Para testar o cenário adverso, edite temporariamente a regra: altere o dia para o dia atual da semana e o horário para incluir o momento presente. Dispare um teste do action group ag-ops-nimbus (em Action groups > selecione > Test). Confirme que a notificação não é entregue enquanto a regra de supressão está ativa.
  5. Após validar, edite a regra de volta para a configuração original (sexta-feira, 22:00 a 02:00).

Via CLI​

# Criar a alert processing rule de supressão
az monitor alert-processing-rule create \
  --name apr-manutencao-sexta \
  --resource-group rg-nimbus-lab \
  --scopes "/subscriptions/$(az account show --query id -o tsv)/resourceGroups/rg-nimbus-lab" \
  --rule-type RemoveAllActionGroups \
  --schedule-recurrence-type Weekly \
  --schedule-recurrence Friday \
  --schedule-start-datetime "2025-01-03 22:00:00" \
  --schedule-end-datetime "2025-01-04 02:00:00" \
  --schedule-time-zone "UTC" \
  --enabled true

# Verificar a regra criada
az monitor alert-processing-rule show \
  --name apr-manutencao-sexta \
  --resource-group rg-nimbus-lab \
  --output table

A alert processing rule intercepta os alertas no nível do resource group inteiro, suprimindo notificações sem desativar as regras de alerta. Isso significa que os alertas continuam sendo gerados e registrados, mas as ações dos action groups não são executadas durante a janela de manutenção.

Fase 3 — Monitoramento com Azure Monitor Insights​

Nesta fase, você habilitará e interpretará os insights especializados do Azure Monitor para VMs, Storage Account e rede. Todos os recursos configurados nas Fases 1 e 2 serão utilizados, incluindo o workspace law-nimbus e as DCRs já associadas. Esta fase cobre o objetivo: Configure and interpret monitoring of virtual machines, storage accounts, and networks by using Azure Monitor Insights.

Tarefa 3.1 — Habilitar e interpretar VM Insights​

O VM Insights fornece uma visão consolidada de performance, dependências e saúde das VMs. Você habilitará o recurso e interpretará os mapas de dependência e gráficos de performance.

Via Portal​

  1. Navegue até Monitor > Virtual Machines (na seção Insights).
  2. Na aba Not Monitored, localize vm-app-01 e vm-data-01.
  3. Se as VMs aparecerem como Not Monitored, clique em Enable para cada uma.
  4. Selecione o workspace law-nimbus como destino.
  5. Confirme a habilitação. Isso instalará o Dependency Agent além do AMA (se ainda não instalado).
  6. Aguarde de 5 a 10 minutos para a coleta inicial de dados.
  7. Clique na aba Performance. Observe os gráficos de CPU, memória, disco e rede para ambas as VMs.
  8. Alterne para a aba Map. Este mapa mostra as conexões de rede ativas da VM, incluindo processos internos, portas e servidores remotos.
  9. No mapa de vm-app-01, identifique se há conexões ativas para o IP da vm-data-01 (10.0.2.x). Se houver, isso confirma comunicação entre as camadas de aplicação e dados.
  10. Se o mapa estiver vazio, gere tráfego: conecte-se via SSH à vm-app-01 e execute curl http://10.0.2.4 ou ping 10.0.2.4 para gerar conexões visíveis.

Via CLI​

# Verificar se o Dependency Agent está instalado na VM Linux
az vm extension list \
  --vm-name vm-app-01 \
  --resource-group rg-nimbus-lab \
  --query "[?contains(name,'DependencyAgent')]" \
  --output table

# Se não estiver instalado, habilitar manualmente
az vm extension set \
  --publisher Microsoft.Azure.Monitoring.DependencyAgent \
  --name DependencyAgentLinux \
  --vm-name vm-app-01 \
  --resource-group rg-nimbus-lab

# Para a VM Windows
az vm extension set \
  --publisher Microsoft.Azure.Monitoring.DependencyAgent \
  --name DependencyAgentWindows \
  --vm-name vm-data-01 \
  --resource-group rg-nimbus-lab

O VM Insights combina os dados de métricas do AMA com informações de dependência para fornecer uma visão operacional que vai além de gráficos individuais. O mapa de dependência é particularmente útil para identificar comunicações inesperadas ou ausentes entre VMs.

Tarefa 3.2 — Interpretar Storage Insights e identificar anomalias​

O Storage Insights oferece uma visão agregada de performance e disponibilidade de todas as storage accounts. Nesta tarefa, você acessará os insights, gerará tráfego anômalo e verificará como isso se reflete nos dados.

Via Portal​

  1. Navegue até Monitor > Storage accounts (na seção Insights).
  2. Localize stnimbuslab na lista.
  3. Observe as métricas agregadas: Availability, E2E Latency, Server Latency, Transactions e Capacity.
  4. Clique em stnimbuslab para ver os detalhes.
  5. Na aba Failures, observe se há transações com falha. Em um ambiente recém-criado, isso pode estar vazio.
  6. Para gerar um cenário adverso (erro 404), execute o seguinte procedimento: tente acessar um blob inexistente.

Gerando erro observável:

  1. Abra o Cloud Shell (Bash) no portal.
  2. Execute:
# Tentar baixar um blob que não existe (gerará erro 404)
az storage blob download \
  --account-name stnimbuslab \
  --container-name logs-auditoria \
  --name arquivo-inexistente.txt \
  --file /tmp/teste.txt \
  --auth-mode login 2>&1 || true

# Repetir 5 vezes para gerar volume
for i in {1..5}; do
  az storage blob download \
    --account-name stnimbuslab \
    --container-name logs-auditoria \
    --name "arquivo-fake-$i.txt" \
    --file /tmp/teste.txt \
    --auth-mode login 2>&1 || true
done
  1. Aguarde 10 minutos e retorne ao Storage Insights.
  2. Na aba Failures, verifique se as transações com código 404 (BlobNotFound) aparecem.
  3. Confirme no Log Analytics executando:
StorageBlobLogs
| where StatusCode == 404
| where TimeGenerated > ago(30m)
| project TimeGenerated, OperationName, Uri, StatusCode, StatusText

Via CLI​

A consulta KQL acima pode ser executada via CLI conforme demonstrado na Tarefa 1.4.

Ao concluir, você terá observado como erros operacionais na storage account se propagam para o Storage Insights e podem ser correlacionados via consultas KQL. Esse tipo de análise é essencial para distinguir falhas legítimas de tentativas de acesso indevidas.

Tarefa 3.3 — Configurar e interpretar Network Insights​

O Network Insights centraliza a visibilidade de todos os recursos de rede em um único painel. Nesta tarefa, você acessará a visão geral da rede da Nimbus e interpretará as métricas de conectividade.

Via Portal​

  1. Navegue até Monitor > Networks (na seção Insights).
  2. Na aba Network health, observe o inventário de recursos de rede: vnet-nimbus, os NSGs vm-app-01-nsg e vm-data-01-nsg, e os IPs públicos.
  3. Filtre por Resource Group = rg-nimbus-lab.
  4. Clique em vnet-nimbus. Observe a topologia mostrando as sub-redes snet-app e snet-data e os recursos conectados.
  5. Na aba Connectivity, observe se há testes de conectividade configurados. Neste ponto, não haverá nenhum (isso será configurado na Fase 4).
  6. Na aba Traffic, verifique se os NSG Flow Logs estão habilitados. Se não estiverem, faça uma anotação pois isso será configurado na próxima fase.

O Network Insights funciona como um hub de observabilidade de rede que consolida dados de múltiplas fontes (NSG, VNet, IP, Connection Monitor). A interpretação correta exige que os componentes de diagnóstico (flow logs, connection monitor) estejam habilitados, o que será feito a seguir.

Fase 4 — Network Watcher e Connection Monitor​

Nesta fase final, você utilizará o Azure Network Watcher para diagnosticar conectividade e configurará o Connection Monitor para monitoramento contínuo entre as VMs. Os recursos de rede vnet-nimbus, as VMs e os NSGs das fases anteriores serão utilizados. Esta fase cobre o objetivo: Use Azure Network Watcher and Connection monitor.

Tarefa 4.1 — Verificar o Network Watcher e executar diagnósticos de conectividade​

O Network Watcher é provisionado automaticamente por região, mas é fundamental confirmar que está ativo antes de utilizá-lo. Você executará diagnósticos para verificar a comunicação entre vm-app-01 e vm-data-01.

Via Portal​

  1. Navegue até Network Watcher.

  2. Na aba Overview, confirme que a região East US aparece com status Enabled. Se não estiver, clique em Enable.

  3. No menu lateral, selecione IP flow verify.

  4. Preencha os campos:

    • Virtual machine: vm-app-01
    • Network interface: selecione a NIC da VM
    • Protocol: TCP
    • Direction: Outbound
    • Local IP address: (preenchido automaticamente)
    • Local port: 50000
    • Remote IP address: insira o IP privado de vm-data-01 (10.0.2.4 ou o IP real atribuído)
    • Remote port: 3389

  5. Clique em Check. O resultado deve ser Access Allowed ou Access Denied dependendo das regras de NSG.

  6. Se o resultado for Access Denied, anote qual NSG e regra estão bloqueando o tráfego.

  7. Agora teste uma porta que certamente estará bloqueada: altere Remote port para 445 (SMB) e clique em Check novamente.

  8. Compare os resultados: identifique qual regra de NSG permite ou nega cada fluxo.

  9. No menu lateral, selecione NSG diagnostic.

  10. Selecione vm-app-01, protocolo TCP, direção Outbound, IP de destino = IP de vm-data-01, porta de destino 3389.

  11. Execute o diagnóstico. Observe a lista de regras avaliadas e qual regra determinou o resultado final (allow ou deny).

Via CLI​

# Verificar se o Network Watcher está habilitado
az network watcher show -l eastus --query provisioningState -o tsv

# IP Flow Verify: testar TCP de vm-app-01 para vm-data-01 na porta 3389
VM_APP_NIC=$(az vm show -g rg-nimbus-lab -n vm-app-01 --query 'networkProfile.networkInterfaces[0].id' -o tsv)
VM_DATA_IP=$(az vm show -g rg-nimbus-lab -n vm-data-01 -d --query privateIps -o tsv)

az network watcher test-ip-flow \
  --direction Outbound \
  --nic "$VM_APP_NIC" \
  --protocol TCP \
  --local '10.0.1.4:50000' \
  --remote "$VM_DATA_IP:3389" \
  --output table

# Testar porta bloqueada (445)
az network watcher test-ip-flow \
  --direction Outbound \
  --nic "$VM_APP_NIC" \
  --protocol TCP \
  --local '10.0.1.4:50000' \
  --remote "$VM_DATA_IP:445" \
  --output table

O IP Flow Verify é a ferramenta de primeiro nível para diagnosticar problemas de conectividade entre VMs. Ele testa contra as regras efetivas dos NSGs sem a necessidade de gerar tráfego real. O NSG Diagnostic complementa mostrando a cadeia completa de regras avaliadas.

Tarefa 4.2 — Habilitar NSG Flow Logs​

Para ter visibilidade contínua do tráfego de rede, é necessário habilitar os NSG Flow Logs. Esses logs registram cada fluxo permitido ou negado pelo NSG e são armazenados na storage account.

Via Portal​

  1. Navegue até Network Watcher > NSG flow logs.
  2. Clique em Create.
  3. Selecione o NSG vm-app-01-nsg.
  4. Em Storage account, selecione stnimbuslab.
  5. Em Retention (days), defina 7.
  6. Em Flow Logs version, selecione Version 2 (inclui informações de throughput).
  7. Habilite Traffic Analytics com intervalo de processamento de 10 minutos.
  8. Selecione o workspace law-nimbus para Traffic Analytics.
  9. Clique em Review + create > Create.
  10. Repita os passos 2 a 9 para o NSG vm-data-01-nsg.

Via CLI​

STORAGE_ID=$(az storage account show -g rg-nimbus-lab -n stnimbuslab --query id -o tsv)
LAW_ID=$(az monitor log-analytics workspace show -g rg-nimbus-lab -n law-nimbus --query id -o tsv)

# Habilitar NSG Flow Logs para vm-app-01-nsg
az network watcher flow-log create \
  --name flowlog-app-nsg \
  --nsg vm-app-01-nsg \
  --resource-group rg-nimbus-lab \
  --storage-account "$STORAGE_ID" \
  --retention 7 \
  --format JSON \
  --log-version 2 \
  --traffic-analytics true \
  --interval 10 \
  --workspace "$LAW_ID" \
  --location eastus

# Habilitar para vm-data-01-nsg
az network watcher flow-log create \
  --name flowlog-data-nsg \
  --nsg vm-data-01-nsg \
  --resource-group rg-nimbus-lab \
  --storage-account "$STORAGE_ID" \
  --retention 7 \
  --format JSON \
  --log-version 2 \
  --traffic-analytics true \
  --interval 10 \
  --workspace "$LAW_ID" \
  --location eastus

Os NSG Flow Logs v2 capturam dados de throughput (bytes e pacotes) além da decisão allow/deny. O Traffic Analytics processa esses dados e os envia para o Log Analytics, onde podem ser consultados com KQL e visualizados no Network Insights (Fase 3).

Tarefa 4.3 — Configurar Connection Monitor e validar conectividade contínua​

O Connection Monitor permite monitorar a conectividade entre endpoints de forma contínua. Você criará um monitor que verifica a comunicação entre vm-app-01 e vm-data-01, e depois simulará uma falha para observar a detecção.

Via Portal​

  1. Navegue até Network Watcher > Connection monitor.
  2. Clique em Create.
  3. Em Connection monitor name, preencha cm-app-to-data.
  4. Em Region, selecione East US.
  5. Em Workspace configuration, selecione law-nimbus.
  6. Clique em Next: Test groups.
  7. Em Test group name, preencha tg-app-data.
  8. Em Sources, clique em Add sources e selecione vm-app-01.
  9. Em Destinations, clique em Add destinations e selecione vm-data-01.
  10. Em Test configurations, clique em Add test configuration.
  11. Em Test configuration name, preencha tcp-rdp-test.
  12. Em Protocol, selecione TCP.
  13. Em Destination port, preencha 3389.
  14. Em Test frequency, selecione Every 30 seconds.
  15. Marque os thresholds: Checks failed (%) = 50, Round-trip time (ms) = 100.
  16. Clique em Add Test Configuration.
  17. Adicione uma segunda configuração de teste:
    • Nome: icmp-test
    • Protocolo: ICMP
    • Frequência: Every 1 minute
  18. Clique em Next: Alerts (a criação automática de alerta é opcional; pule por ora).
  19. Clique em Review + create > Create.

Simular falha de conectividade:

  1. Navegue até o NSG vm-data-01-nsg > Inbound security rules.
  2. Clique em Add.
  3. Crie uma regra com:
    • Source: Any
    • Source port ranges: *
    • Destination: Any
    • Destination port ranges: 3389
    • Protocol: TCP
    • Action: Deny
    • Priority: 100
    • Name: DenyRDP-Test
  4. Clique em Add.
  5. Aguarde de 1 a 2 minutos e retorne ao Connection Monitor cm-app-to-data.
  6. Observe que o teste tcp-rdp-test agora mostra falhas de conectividade (checks failed aumentando).
  7. Importante: Remova a regra DenyRDP-Test do NSG após a verificação. Navegue até vm-data-01-nsg > Inbound security rules > selecione DenyRDP-Test > Delete > confirme.
  8. Aguarde 1 a 2 minutos e confirme que o Connection Monitor volta a reportar sucesso.

Via CLI​

# Criar o Connection Monitor
az network watcher connection-monitor create \
  --name cm-app-to-data \
  --location eastus \
  --test-group-name tg-app-data \
  --endpoint-source-name vm-app-01 \
  --endpoint-source-resource-id $(az vm show -g rg-nimbus-lab -n vm-app-01 --query id -o tsv) \
  --endpoint-dest-name vm-data-01 \
  --endpoint-dest-resource-id $(az vm show -g rg-nimbus-lab -n vm-data-01 --query id -o tsv) \
  --test-config-name tcp-rdp-test \
  --protocol Tcp \
  --tcp-port 3389 \
  --frequency 30

# Simular falha: adicionar regra de deny no NSG
az network nsg rule create \
  --resource-group rg-nimbus-lab \
  --nsg-name vm-data-01-nsg \
  --name DenyRDP-Test \
  --priority 100 \
  --direction Inbound \
  --access Deny \
  --protocol Tcp \
  --destination-port-ranges 3389

# Aguardar e verificar o status do Connection Monitor
sleep 120
az network watcher connection-monitor show \
  --name cm-app-to-data \
  --location eastus \
  --query testGroups[0].testConfigurations \
  --output table

# Remover a regra de deny após validação
az network nsg rule delete \
  --resource-group rg-nimbus-lab \
  --nsg-name vm-data-01-nsg \
  --name DenyRDP-Test

Ao concluir, você terá implementado monitoramento contínuo de conectividade que detecta automaticamente interrupções. A simulação de falha com regra de NSG comprovou que o Connection Monitor detecta a mudança em tempo real e reporta a degradação. Esse ciclo de bloqueio, detecção e restauração valida todo o pipeline de monitoramento de rede.

Validação Final​

Verifique os seguintes critérios para confirmar que o laboratório foi executado com sucesso:

Critério 1 — Dados de métricas de guest OS no Log Analytics Navegue até Monitor > Logs, selecione o workspace law-nimbus e execute: Perf | where TimeGenerated > ago(1h) | summarize count() by Computer. Ambas as VMs (vm-app-01 e vm-data-01) devem aparecer com contagem maior que zero. Isso confirma que o AMA e a DCR da Fase 1 estão funcionando.

Critério 2 — Alerta de CPU disparado ou em estado ativo Gere carga na vm-app-01 via SSH com o comando stress --cpu 2 --timeout 300 (instale com sudo apt install stress se necessário). Aguarde 5 a 7 minutos e navegue até Monitor > Alerts. O alerta alert-cpu-vm-app-01 deve aparecer com status Fired. Verifique também o e-mail cadastrado no action group ag-ops-nimbus para confirmar o recebimento da notificação. Esse é o critério comportamental: a ação de estressar a CPU gera um alerta mensurável e uma notificação real.

Critério 3 — VM Insights mostrando mapa de dependência Navegue até Monitor > Virtual Machines > selecione vm-app-01 > aba Map. O mapa deve exibir pelo menos a VM com seus processos e conexões de rede. Se você executou comandos de rede entre as VMs, a conexão para vm-data-01 deve ser visível.

Critério 4 — Connection Monitor reportando status Navegue até Network Watcher > Connection monitor > cm-app-to-data. O teste tcp-rdp-test deve mostrar o status Pass (se a regra de deny foi removida). A porcentagem de checks failed deve estar abaixo do threshold de 50%.

Critério 5 — NSG Flow Logs registrando tráfego Execute no Log Analytics:

AzureNetworkAnalytics_CL
| where TimeGenerated > ago(1h)
| where SubType_s == "FlowLog"
| summarize count() by NSGRule_s, FlowDirection_s
| order by count_ desc

Deve haver registros de fluxos permitidos e/ou negados para os NSGs do lab. Se a tabela estiver vazia, aguarde até 30 minutos (o Traffic Analytics tem intervalo de processamento configurado em 10 minutos).

Cleanup do Ambiente​

Remova todos os recursos na ordem inversa para evitar cobranças. A forma mais eficiente é excluir o resource group, que remove todos os recursos filhos automaticamente.

Via Portal​

  1. Navegue até Network Watcher > Connection monitor.
  2. Selecione cm-app-to-data > Delete > confirme.
  3. Navegue até Network Watcher > NSG flow logs.
  4. Selecione os flow logs de ambos os NSGs e clique em Delete.
  5. Navegue até Monitor > Alerts > Alert rules.
  6. Selecione alert-cpu-vm-app-01 e alert-syslog-errors > Delete.
  7. Navegue até Monitor > Alerts > Alert processing rules.
  8. Selecione apr-manutencao-sexta > Delete.
  9. Navegue até Monitor > Alerts > Action groups.
  10. Selecione ag-ops-nimbus e ag-critical-nimbus > Delete.
  11. Navegue até Monitor > Data Collection Rules.
  12. Selecione dcr-nimbus-vms > Delete.
  13. Navegue até Resource groups > selecione rg-nimbus-lab.
  14. Clique em Delete resource group.
  15. Digite rg-nimbus-lab para confirmar > clique em Delete.
  16. Aguarde a conclusão. Navegue até Resource groups e confirme que rg-nimbus-lab não aparece mais na lista.

Via CLI​

# Remover Connection Monitor
az network watcher connection-monitor delete \
  --name cm-app-to-data \
  --location eastus

# Remover NSG Flow Logs
az network watcher flow-log delete \
  --name flowlog-app-nsg \
  --location eastus
az network watcher flow-log delete \
  --name flowlog-data-nsg \
  --location eastus

# Remover alert rules (scheduled query e metric alert)
az monitor scheduled-query delete \
  --name alert-syslog-errors \
  --resource-group rg-nimbus-lab --yes
az monitor metrics alert delete \
  --name alert-cpu-vm-app-01 \
  --resource-group rg-nimbus-lab

# Remover alert processing rule
az monitor alert-processing-rule delete \
  --name apr-manutencao-sexta \
  --resource-group rg-nimbus-lab --yes

# Remover action groups
az monitor action-group delete \
  --name ag-ops-nimbus \
  --resource-group rg-nimbus-lab
az monitor action-group delete \
  --name ag-critical-nimbus \
  --resource-group rg-nimbus-lab

# Remover Data Collection Rule
az monitor data-collection rule delete \
  --name dcr-nimbus-vms \
  --resource-group rg-nimbus-lab --yes

# Remover o Resource Group (exclui todos os recursos filhos)
az group delete --name rg-nimbus-lab --yes --no-wait

# Verificar a exclusão (pode levar alguns minutos)
az group show --name rg-nimbus-lab 2>&1 || echo "Resource Group excluído com sucesso."

Após a exclusão do resource group, todos os recursos filhos (VMs, VNet, Storage Account, Log Analytics Workspace, NSGs, IPs públicos e discos) serão removidos automaticamente. O processo pode levar de 5 a 15 minutos. Confirme a exclusão verificando que o grupo não aparece mais na listagem de resource groups.