Fundamentação Teórica: Troubleshoot load balancing

1. Intuição Inicial

Você configurou um Load Balancer, adicionou três VMs ao backend pool, criou a regra de balanceamento e o health probe. Tudo parece correto no portal. Mas quando você tenta acessar o IP público do Load Balancer, a conexão falha ou só funciona para algumas requisições.

O diagnóstico de Load Balancer é diferente do diagnóstico de conectividade de rede geral. Aqui, o problema pode estar em qualquer uma das cinco peças do LB (frontend, probe, backend pool, regra, NSG), e cada peça tem seu próprio comportamento e ponto de falha.

A analogia continua com o restaurante: o recepcionista (Load Balancer) pode estar funcionando, mas se as caixas (VMs) não respondem ao sinal do gerente (health probe), o recepcionista as considera fechadas e não direciona clientes. Ou as caixas estão abertas, mas um segurança na porta (NSG) está bloqueando os clientes de chegarem.

Diagnosticar Load Balancing é sistematicamente verificar cada componente dessa cadeia até encontrar onde a falha está.

2. Contexto

O diagnóstico de Load Balancer integra todos os conceitos dos módulos anteriores. Uma falha pode ter origem em múltiplas camadas:

100%

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

As ferramentas principais são as métricas do Load Balancer no Azure Monitor, o Network Watcher (estudado anteriormente) e os logs de diagnóstico do LB. Entender o que cada métrica indica é o núcleo deste módulo.

3. Construção dos Conceitos

3.1 As Métricas Fundamentais do Load Balancer Standard

O Azure Load Balancer Standard expõe métricas no Azure Monitor que são a primeira linha de diagnóstico:

Métrica	O que mede	Valor saudável	Sinal de problema
Data Path Availability	Disponibilidade do caminho de dados do LB para o backend	100%	< 100% indica VMs unhealthy
Health Probe Status	Percentual de VMs passando no health probe	100%	< 100% indica VMs com falha no probe
Byte Count	Bytes processados pelo LB (entrada + saída)	Positivo e constante	Zero = sem tráfego chegando
Packet Count	Pacotes processados	Proporcional ao tráfego	Queda abrupta = problema de conectividade
SYN Count	Pacotes SYN recebidos (novas conexões TCP)	Proporcional ao tráfego	Zero = tráfego não chega ao LB
SNAT Connection Count	Conexões SNAT ativas e falhas	Falhas = 0	Falhas > 0 = esgotamento de portas SNAT
Allocated SNAT Ports	Portas SNAT alocadas	Proporcional às VMs	Próximo ao máximo = risco de esgotamento
Used SNAT Ports	Portas SNAT em uso	Menor que alocadas	Igual ao máximo = esgotamento ativo

3.2 Data Path Availability vs. Health Probe Status

Estas duas métricas são complementares e devem ser analisadas juntas:

100%

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

O cenário C4 (probes passando mas sem tráfego) é o mais confuso: indica que as VMs estão saudáveis segundo o probe, mas o tráfego real não está chegando. Isso geralmente aponta para problema na regra de balanceamento, na configuração do frontend IP ou em um NSG que bloqueia o tráfego de negócio (mas não o probe, que usa AzureLoadBalancer como source).

3.3 Os Três Tipos de Falha e Seus Padrões

Tipo 1: Nenhum tráfego chega ao Load Balancer

Sintoma: SYN Count = 0, Byte Count = 0. O problema está antes do LB: DNS incorreto, IP público errado, NSG na subnet bloqueando tráfego de entrada antes de chegar ao LB (para LB Standard, o tráfego de entrada não é bloqueado por NSG na subnet do frontend, pois o LB é um serviço gerenciado, mas o NSG nas VMs pode bloquear). Ou para LB interno: o cliente não está na VNet correta ou não há rota para o IP do LB.

Tipo 2: Tráfego chega ao LB, mas VMs estão unhealthy

Sintoma: Health Probe Status < 100%, Data Path Availability < 100%. As VMs não respondem ao probe. Causas: aplicação parou, NSG bloqueia o probe, porta errada no probe, erro 500 retornado pela aplicação quando o probe espera 200.

Tipo 3: VMs saudáveis, mas conexões falham

Sintoma: Health Probe Status = 100%, Data Path Availability = 100%, mas o cliente recebe timeout ou erro. Causas: NSG bloqueia o tráfego de negócio (mas não o probe), aplicação falha apenas para tráfego real (probe em endpoint simplificado não detecta o problema), session persistence mal configurada, SNAT exhaustion para conexões de saída.

4. Visão Estrutural

O Fluxo de Diagnóstico Sistemático

100%

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

5. Funcionamento na Prática

Verificando Health Probe Status por VM Individual

Uma das funcionalidades mais úteis para diagnóstico é verificar qual VM específica está falhando no probe, não apenas a média geral. No Azure Monitor, filtre a métrica Health Probe Status por dimensão Backend IP Address:

# Verificar probe status por VM individual via CLI
az monitor metrics list \
  --resource /subscriptions/<sub-id>/resourceGroups/rg-networking/providers/Microsoft.Network/loadBalancers/lb-web-public \
  --metric "HealthProbeStatus" \
  --dimension "BackendIPAddress" \
  --aggregation Average \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
  --output table

Isso mostra, para cada VM, se o probe está passando ou falhando, permitindo identificar exatamente qual VM tem problema.

Testando o Health Probe Manualmente

Para verificar se um health probe HTTP/HTTPS funcionaria, execute o mesmo teste que o LB faz, a partir da perspectiva da VM ou de um cliente na mesma rede:

# Testar o endpoint de probe a partir de outra VM na mesma VNet
curl -v -k https://10.0.1.4:443/health

# Verificar se a porta TCP está aberta (para probe TCP)
Test-NetConnection -ComputerName 10.0.1.4 -Port 443

Se o endpoint retorna 200, o probe deveria estar passando. Se retorna outro código, o probe falha. Se a conexão é recusada, a aplicação não está escutando ou o firewall do SO está bloqueando.

Verificando NSG para Probes

O probe do Load Balancer origina de 168.63.129.16 com a tag de serviço AzureLoadBalancer. Para confirmar se o NSG está permitindo:

# Ver regras efetivas do NSG na NIC da VM
az network nic list-effective-nsg \
  --name nic-vm-web-01 \
  --resource-group rg-producao \
  --output json | grep -A 5 "AzureLoadBalancer"

Se AzureLoadBalancer não aparece nas regras de entrada como Allow, o probe está sendo bloqueado.

Diagnóstico de SNAT Exhaustion

O esgotamento de portas SNAT é silencioso: o health probe continua funcionando (probe é inbound, não usa SNAT), as VMs parecem saudáveis, mas conexões de saída para a internet falham ou têm timeout.

# Verificar métricas de SNAT
az monitor metrics list \
  --resource /subscriptions/<sub-id>/resourceGroups/rg-networking/providers/Microsoft.Network/loadBalancers/lb-web-public \
  --metric "SNATConnectionCount" \
  --filter "ConnectionState eq 'Failed'" \
  --aggregation Total \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

Se ConnectionState = Failed tem valores elevados, há esgotamento de SNAT. Dentro das VMs, o sintoma é conexões TCP de saída que ficam em CLOSE_WAIT ou TIME_WAIT excessivamente:

# Verificar conexões em TIME_WAIT na VM (Linux)
ss -s | grep TIME-WAIT

# Windows
netstat -n | findstr TIME_WAIT | measure -line

6. Formas de Implementação

6.1 Portal do Azure: Azure Monitor para Load Balancer

Quando usar: visualização de tendências, diagnóstico inicial com gráficos.

Caminho: Load Balancer > Monitoring > Metrics

O portal oferece gráficos de todas as métricas com filtros por dimensão (por VM, por porta, por frontend). A dimensão Backend IP Address é especialmente útil para identificar qual VM específica está com problema.

Configure alertas diretamente no portal para notificação proativa:

Caminho: Load Balancer > Monitoring > Alerts > New alert rule

Alertas recomendados:

Health Probe Status < 100% por mais de 5 minutos
Data Path Availability < 100%
SNAT Connection Count com ConnectionState = Failed > 0

6.2 Azure CLI

Verificar configuração completa do Load Balancer (componentes, regras, probes):

# Visão completa do Load Balancer
az network lb show \
  --name lb-web-public \
  --resource-group rg-networking \
  --output json

# Listar apenas os probes
az network lb probe list \
  --lb-name lb-web-public \
  --resource-group rg-networking \
  --output table

# Listar regras de balanceamento
az network lb rule list \
  --lb-name lb-web-public \
  --resource-group rg-networking \
  --output table

# Verificar VMs no backend pool
az network lb address-pool show \
  --lb-name lb-web-public \
  --name bp-vms-web \
  --resource-group rg-networking \
  --query "loadBalancerBackendAddresses[].{Nome:name, IP:networkInterfaceIPConfiguration.id}"

Verificar se uma VM está corretamente adicionada ao pool:

# Ver a qual backend pool uma NIC pertence
az network nic show \
  --name nic-vm-web-01 \
  --resource-group rg-producao \
  --query "ipConfigurations[0].loadBalancerBackendAddressPools[].id"

Se o resultado estiver vazio, a NIC não está no backend pool. Isso é um dos problemas mais comuns: o Load Balancer foi criado com pool, mas as VMs nunca foram adicionadas.

6.3 PowerShell

# Obter o LB e inspecionar todos os componentes
$lb = Get-AzLoadBalancer -Name "lb-web-public" -ResourceGroupName "rg-networking"

# Listar probes
$lb.Probes | Select-Object Name, Protocol, Port, RequestPath, IntervalInSeconds, NumberOfProbes

# Listar regras
$lb.LoadBalancingRules | Select-Object Name, Protocol, FrontendPort, BackendPort, LoadDistribution

# Verificar VMs no backend pool
$lb.BackendAddressPools[0].LoadBalancerBackendAddresses | Select-Object Name

# Verificar se VM está no pool pela NIC
$nic = Get-AzNetworkInterface -Name "nic-vm-web-01" -ResourceGroupName "rg-producao"
$nic.IpConfigurations[0].LoadBalancerBackendAddressPools

6.4 Network Watcher: Complement de Diagnóstico

O Network Watcher complementa o diagnóstico do Load Balancer:

# IP Flow Verify: verificar se NSG permite tráfego da internet para a VM
az network watcher test-ip-flow \
  --direction Inbound \
  --protocol TCP \
  --local 10.0.1.4:443 \
  --remote 203.0.113.1:54321 \
  --vm /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-web-01 \
  --resource-group NetworkWatcherRG \
  --watcher-resource-group NetworkWatcherRG

# Connection Troubleshoot: testar conectividade pelo caminho do LB
az network watcher test-connectivity \
  --source-resource /subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-cliente \
  --dest-address 40.68.100.50 \
  --dest-port 443 \
  --protocol Tcp \
  --resource-group NetworkWatcherRG \
  --watcher-resource-group NetworkWatcherRG

7. Controle e Segurança

Diagnóstico de Regras NSG Conflitantes

Um padrão muito comum de falha é ter dois NSGs: um que permite AzureLoadBalancer (para os probes) mas não o tráfego de negócio, ou um que permite o tráfego de negócio mas não o probe. Verificar ambos os NSGs (NIC e Subnet) é essencial:

# Verificar NSG da subnet
az network nsg rule list \
  --nsg-name nsg-subnet-web \
  --resource-group rg-networking \
  --output table

# Verificar NSG da NIC
az network nsg rule list \
  --nsg-name nsg-nic-vm-web-01 \
  --resource-group rg-networking \
  --output table

A análise deve verificar:

Há uma regra Allow para AzureLoadBalancer na porta do probe?
Há uma regra Allow para o tráfego de negócio (porta 80/443) de qualquer origem (ou da internet via Internet tag)?
Há alguma regra Deny de alta prioridade que pode estar sobrepondo as regras Allow?

Verificar Logs de Diagnóstico do Load Balancer

O Load Balancer Standard pode enviar logs para Log Analytics:

# Habilitar logs de diagnóstico
az monitor diagnostic-settings create \
  --name diag-lb-web \
  --resource /subscriptions/<sub-id>/resourceGroups/rg-networking/providers/Microsoft.Network/loadBalancers/lb-web-public \
  --workspace /subscriptions/<sub-id>/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-monitoring \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

Com logs no Log Analytics, queries KQL permitem análise histórica:

// Health probe failures nas últimas 24 horas por VM
AzureMetrics
| where TimeGenerated > ago(24h)
| where ResourceType == "LOADBALANCERS"
| where MetricName == "HealthProbeStatus"
| where Average < 100
| project TimeGenerated, ResourceId, Average, DimensionValue1
| sort by TimeGenerated desc

8. Tomada de Decisão

Qual métrica verificar primeiro conforme o sintoma?

Sintoma	Primeira métrica	O que procurar
Nenhum tráfego funciona	`SYN Count`	Zero = tráfego não chega ao LB
Algumas requisições funcionam, outras não	`Health Probe Status` por VM	VMs específicas com probe falhando
Lentidão / timeouts	`Data Path Availability` + `SNAT Connection Count`	Degradação gradual ou SNAT exhaustion
VM removida do pool inesperadamente	`Health Probe Status` por VM no período	Falhas intermitentes no probe
Conexões de saída das VMs falhando	`SNAT Connection Count` com Failed	Esgotamento de portas SNAT
Tráfego desigual entre VMs	Não há métrica direta	Verificar Session Persistence e distribuição pelo hash de 5 tuplas

Qual ferramenta de diagnóstico usar?

Situação	Ferramenta	Motivo
Verificar se NSG bloqueia probe	IP Flow Verify com source `AzureLoadBalancer`	Simula o pacote do probe
Verificar se NSG bloqueia tráfego de negócio	IP Flow Verify com IP de origem real	Simula o pacote do cliente
Testar se LB entrega tráfego para VM	Connection Troubleshoot do LB frontend para VM	Teste ponta a ponta
Ver exatamente quais pacotes chegam na VM	Packet Capture na NIC da VM	Análise raw de tráfego
Diagnóstico de VPN Gateway no caminho	VPN Troubleshoot	Específico para gateways
Histórico de falhas de probe	Azure Monitor Metrics histórico	Identificar padrão temporal

9. Boas Práticas

Configure alertas proativos antes de ter problemas: criar alertas para Health Probe Status < 100% e Data Path Availability < 100% garante notificação imediata quando uma VM é removida do pool, antes que o impacto seja reportado pelos usuários.

Use endpoints de probe dedicados com verificações profundas: um probe HTTP em /health que apenas retorna 200 imediatamente não detecta falhas reais da aplicação. Um endpoint /health que verifica conexão com banco de dados, filas e outros dependências remove VMs do pool quando há problemas funcionais, não apenas quando o servidor está offline.

Habilite diagnósticos do Load Balancer para Log Analytics desde a criação: as métricas históricas permitem análise retroativa quando um problema é reportado com atraso ("ontem à tarde o site estava lento"). Sem logs históricos, a janela de diagnóstico fica limitada ao que o Azure Monitor retém por padrão (93 dias para métricas).

Documente o design de NSG esperado para o LB: manter documentação de quais regras NSG são necessárias para o Load Balancer funcionar (AzureLoadBalancer para probe + fonte de internet para tráfego) facilita o diagnóstico quando alguém modifica as regras inadvertidamente.

10. Erros Comuns

Probe configurado na porta errada

O probe está configurado na porta 443, mas a aplicação escuta apenas na porta 8443 (ou vice-versa). O probe TCP verifica 443, não encontra nada escutando (connection refused), marca a VM como unhealthy. A VM está funcionando perfeitamente, mas o LB não envia tráfego para ela. Verificar a porta real da aplicação via netstat -an | grep LISTEN na VM e corrigir o probe resolve.

VM adicionada ao backend pool mas NIC desassociada

Uma VM foi excluída e recriada, mas a NIC antiga permanece associada ao backend pool. O pool mostra uma entrada mas sem NIC associada a uma VM ativa. O LB tenta enviar probes para um endereço IP que não existe mais. Verificar se cada entrada no backend pool corresponde a uma NIC e VM existentes.

Health probe bem-sucedido, mas aplicação falha para tráfego real

O probe é GET /health HTTP/1.1 e retorna 200 imediatamente sem fazer nada. Mas o tráfego real da aplicação (GET /api/data) falha porque a conexão com o banco de dados está quebrada. A VM continua no pool. O probe não detecta o problema real porque o endpoint /health não verifica os subsistemas críticos.

Session Persistence configurada incorretamente causando carga desigual

Com Client IP session persistence, clientes corporativos atrás de NAT (todos com o mesmo IP de saída) são sempre enviados para a mesma VM, sobrecarregando-a enquanto as outras ficam ociosas. O administrador aumenta as VMs no pool mas a distribuição não melhora. A solução é None (hash de 5 tuplas) para aplicações stateless, que distribui por client IP + porta de origem.

Ignorar dimensão BackendIPAddress nas métricas de probe

O administrador vê Health Probe Status = 80% (algum problema), mas não filtra por VM individual. Passa horas tentando diagnosticar "o LB" sem identificar que apenas uma das 5 VMs está com probe falhando. Sempre filtre por BackendIPAddress ao investigar probe failures.

11. Operação e Manutenção

Script de Diagnóstico Automatizado para Load Balancer

#!/bin/bash
LB_NAME="lb-web-public"
RG="rg-networking"
POOL_NAME="bp-vms-web"

echo "=== Configuração do Load Balancer ==="
az network lb show --name $LB_NAME --resource-group $RG \
  --query "{SKU:sku.name, FrontendIPs:frontendIPConfigurations[].name, ProbeCount:length(probes), RuleCount:length(loadBalancingRules)}" \
  --output table

echo ""
echo "=== Health Probes ==="
az network lb probe list --lb-name $LB_NAME --resource-group $RG \
  --query "[].{Nome:name, Protocolo:protocol, Porta:port, Path:requestPath, Intervalo:intervalInSeconds, Threshold:numberOfProbes}" \
  --output table

echo ""
echo "=== Load Balancing Rules ==="
az network lb rule list --lb-name $LB_NAME --resource-group $RG \
  --query "[].{Nome:name, Protocolo:protocol, PortaFront:frontendPort, PortaBack:backendPort, Distribuicao:loadDistribution}" \
  --output table

echo ""
echo "=== VMs no Backend Pool ==="
az network lb address-pool show \
  --lb-name $LB_NAME \
  --name $POOL_NAME \
  --resource-group $RG \
  --query "loadBalancerBackendAddresses[].{Nome:name, NIC:networkInterfaceIPConfiguration.id}" \
  --output table

echo ""
echo "=== Métricas recentes (últimos 30 min) ==="
START=$(date -u -d '30 minutes ago' +%Y-%m-%dT%H:%M:%SZ)
END=$(date -u +%Y-%m-%dT%H:%M:%SZ)

LB_ID=$(az network lb show --name $LB_NAME --resource-group $RG --query id -o tsv)

echo "Data Path Availability:"
az monitor metrics list --resource $LB_ID \
  --metric "VipAvailability" --aggregation Average \
  --start-time $START --end-time $END \
  --query "value[0].timeseries[0].data[-1].average" --output tsv

echo "Health Probe Status:"
az monitor metrics list --resource $LB_ID \
  --metric "DipAvailability" --aggregation Average \
  --start-time $START --end-time $END \
  --query "value[0].timeseries[0].data[-1].average" --output tsv

Queries KQL para Análise de Load Balancer

// Histórico de health probe por VM
AzureMetrics
| where ResourceType == "LOADBALANCERS"
| where MetricName == "DipAvailability"
| where TimeGenerated > ago(6h)
| summarize avg(Average) by bin(TimeGenerated, 5m), tostring(DimensionValue1)
| render timechart

// Detectar momentos de SNAT exhaustion
AzureMetrics
| where ResourceType == "LOADBALANCERS"
| where MetricName == "SnatConnectionCount"
| where TimeGenerated > ago(24h)
| where DimensionValue1 == "Failed"
| where Total > 0
| project TimeGenerated, Total
| sort by TimeGenerated desc

Limites Relevantes para Diagnóstico

Item	Limite	Impacto no diagnóstico
Retenção de métricas no Azure Monitor	93 dias	Histórico disponível para análise retroativa
Portas SNAT por VM (sem Outbound Rule)	1.024 (padrão Standard)	Pode esgotar em VMs com muitas conexões de saída
VMs por backend pool (Standard)	1.000	Limite raramente atingido, mas verificar em VMSS grandes
Probes por segundo por endpoint	~2 probes/seg (intervalo mínimo 5s)	Probe falha 2 vezes consecutivas antes de marcar unhealthy

12. Integração e Automação

Alertas Automatizados e Runbooks

Configure alertas que disparam runbooks automáticos para diagnóstico:

100%

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

Dashboard de Saúde do Load Balancer

Crie um Azure Dashboard centralizado com as métricas críticas do LB:

# Criar workbook no Azure Monitor para visualização consolidada
az monitor workbook create \
  --resource-group rg-monitoring \
  --name "lb-health-dashboard" \
  --display-name "Load Balancer Health Dashboard" \
  --kind shared \
  --source-id /subscriptions/<sub-id>/resourceGroups/rg-networking/providers/Microsoft.Network/loadBalancers/lb-web-public \
  --serialized-data @lb-workbook-template.json

13. Resumo Final

Pontos essenciais:

As duas métricas fundamentais são Data Path Availability (o LB consegue alcançar as VMs?) e Health Probe Status (as VMs respondem ao probe?). Analisá-las juntas revela o tipo de problema.
O probe do Load Balancer origina de 168.63.129.16 (tag AzureLoadBalancer). NSGs que bloqueiam esse IP causam VMs unhealthy mesmo com a aplicação funcionando.
SNAT Exhaustion é silencioso: probes passam, VMs parecem saudáveis, mas conexões de saída das VMs falham. A métrica SNAT Connection Count (Failed) revela o problema.
A dimensão BackendIPAddress nas métricas de probe permite identificar qual VM específica está com problema, não apenas a média geral.

Diferenças críticas:

Probe falhando vs. NSG bloqueando tráfego de negócio: o probe usa AzureLoadBalancer como source; o tráfego de negócio usa o IP do cliente ou da internet. Um NSG pode permitir um e bloquear o outro, resultando em VMs saudáveis (probe OK) mas sem tráfego real chegando.
Health Probe Status vs. Data Path Availability: Health Probe Status mede se o probe chega à VM; Data Path Availability mede se o tráfego real pode ser entregue. Podem ter valores diferentes.
SNAT Exhaustion vs. Probe failure: são completamente independentes. SNAT afeta conexões de saída das VMs. Probe afeta se as VMs ficam no pool para receber tráfego de entrada.

O que precisa ser lembrado:

Sempre verifique as métricas com dimensão BackendIPAddress para identificar qual VM tem problema.
Configure alertas proativos para Health Probe Status < 100% em ambiente de produção.
Se VMs estão no pool, probes passando, mas tráfego real falha: verifique o NSG para a porta de negócio (não apenas a porta do probe).
Use az network lb address-pool show para confirmar que as NICs das VMs estão corretamente associadas ao backend pool.
Para SNAT Exhaustion: configure Outbound Rules com alocação explícita de portas ou migre para NAT Gateway.
O comando mais rápido para diagnóstico inicial é verificar Health Probe Status e Data Path Availability no Azure Monitor para o LB afetado.

1. Intuição Inicial​

2. Contexto​

3. Construção dos Conceitos​

3.1 As Métricas Fundamentais do Load Balancer Standard​

3.2 Data Path Availability vs. Health Probe Status​

3.3 Os Três Tipos de Falha e Seus Padrões​

4. Visão Estrutural​

O Fluxo de Diagnóstico Sistemático​

5. Funcionamento na Prática​

Verificando Health Probe Status por VM Individual​

Testando o Health Probe Manualmente​

Verificando NSG para Probes​

Diagnóstico de SNAT Exhaustion​

6. Formas de Implementação​

6.1 Portal do Azure: Azure Monitor para Load Balancer​

6.2 Azure CLI​

6.3 PowerShell​

6.4 Network Watcher: Complement de Diagnóstico​

7. Controle e Segurança​

Diagnóstico de Regras NSG Conflitantes​

Verificar Logs de Diagnóstico do Load Balancer​

8. Tomada de Decisão​

Qual métrica verificar primeiro conforme o sintoma?​

Qual ferramenta de diagnóstico usar?​

9. Boas Práticas​

10. Erros Comuns​

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

Script de Diagnóstico Automatizado para Load Balancer​

Queries KQL para Análise de Load Balancer​

Limites Relevantes para Diagnóstico​

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

Alertas Automatizados e Runbooks​

Dashboard de Saúde do Load Balancer​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

3. Construção dos Conceitos

3.1 As Métricas Fundamentais do Load Balancer Standard

3.2 Data Path Availability vs. Health Probe Status

3.3 Os Três Tipos de Falha e Seus Padrões

4. Visão Estrutural

O Fluxo de Diagnóstico Sistemático

5. Funcionamento na Prática

Verificando Health Probe Status por VM Individual

Testando o Health Probe Manualmente

Verificando NSG para Probes

Diagnóstico de SNAT Exhaustion

6. Formas de Implementação

6.1 Portal do Azure: Azure Monitor para Load Balancer

6.2 Azure CLI

6.3 PowerShell

6.4 Network Watcher: Complement de Diagnóstico

7. Controle e Segurança

Diagnóstico de Regras NSG Conflitantes

Verificar Logs de Diagnóstico do Load Balancer

8. Tomada de Decisão

Qual métrica verificar primeiro conforme o sintoma?

Qual ferramenta de diagnóstico usar?

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Script de Diagnóstico Automatizado para Load Balancer

Queries KQL para Análise de Load Balancer

Limites Relevantes para Diagnóstico

12. Integração e Automação

Alertas Automatizados e Runbooks

Dashboard de Saúde do Load Balancer

13. Resumo Final