Se os proxies são usados em produção — para scraping, automação de contas SMM ou multi-contas em grande escala — chega um momento em que "parece estar funcionando" não é mais uma resposta suficiente. Precisamos de números: quantas requisições falham com erro, quanto aumentou a latência após a troca do pool de IP, se o limite de tráfego do provedor foi atingido. Vamos analisar 7 métricas que devem ser coletadas no Prometheus e visualizadas no Grafana, para identificar problemas antes que os usuários ou contas bloqueadas os percebam.
Por que monitorar proxies em produção
Proxies não são uma infraestrutura estática como um servidor com IP fixo. É um pool de endereços em constante mudança, cujo comportamento depende do provedor, carga, região e até mesmo do horário do dia. Sem monitoramento, você só descobre um problema quando o parser do Wildberries ou Ozon para de retornar dados, o painel de anúncios do Facebook Ads bloqueia a conta, ou o script de automação do Instagram começa a ser inundado com CAPTCHAs.
A tarefa do monitoramento é transformar a percepção subjetiva de "algo não está certo" em números concretos: a proporção de erros aumentou de 2% para 15% na última hora, a latência média triplicou, o tráfego de um proxy ultrapassou o limite. Isso permite reagir antes que o problema se torne crítico — alternar automaticamente o pool, trocar de provedor ou reduzir a frequência das requisições.
Para coletar métricas, usamos a combinação Prometheus (armazenamento de séries temporais) + Grafana (visualização e alertas). Este é um stack padrão em DevOps, que se integra facilmente com qualquer linguagem — Python, Node.js, Go. Abaixo estão exemplos em Python com a biblioteca prometheus_client, mas o princípio é universal.
Métrica 1: Taxa de Sucesso — proporção de requisições bem-sucedidas
Esta é uma métrica básica que sinaliza problemas com o pool de proxies. É calculada como a proporção de requisições com código de resposta 200-299 em relação ao número total de requisições em um determinado período. Uma queda na taxa de sucesso abaixo de 90% geralmente significa que parte dos IPs no pool foi banida pelo site-alvo ou que o provedor está fornecendo endereços instáveis.
Exemplo de instrumentação em Python:
from prometheus_client import Counter, start_http_server
import requests
REQUESTS_TOTAL = Counter(
'proxy_requests_total', 'Total de requisições através do proxy',
['proxy_pool', 'status']
)
def fetch_with_proxy(url, proxy, pool_name="residential"):
try:
resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
status = "success" if resp.status_code < 300 else "failure"
except requests.exceptions.RequestException:
status = "failure"
REQUESTS_TOTAL.labels(proxy_pool=pool_name, status=status).inc()
start_http_server(9100) # endpoint para Prometheus scrape
Consulta PromQL para calcular a taxa de sucesso nos últimos 5 minutos:
sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100
Se você está trabalhando com vários tipos de proxies ao mesmo tempo — por exemplo, proxies residenciais para redes sociais e proxies de data center para scraping — faz sentido dividir a taxa de sucesso pelo rótulo proxy_pool, para ver qual pool específico está se degradando.
Métrica 2: Latência — tempo de resposta
A latência mostra quão rapidamente o proxy retorna uma resposta. Um aumento repentino na latência frequentemente precede uma queda na taxa de sucesso — o provedor está sobrecarregado, ou o IP já está próximo do bloqueio e o servidor-alvo começa a intencionalmente atrasar as respostas. Para a latência, é importante coletar não apenas a média, mas também os percentis — p50, p95, p99, pois a média oculta as latências extremas que realmente atrapalham o trabalho.
from prometheus_client import Histogram
import time
REQUEST_DURATION = Histogram(
'proxy_request_duration_seconds',
'Duração da requisição através do proxy',
['proxy_pool'],
buckets=[0.1, 0.25, 0.5, 1, 2, 5, 10]
)
def fetch_timed(url, proxy, pool_name="mobile"):
start = time.time()
try:
requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
finally:
REQUEST_DURATION.labels(proxy_pool=pool_name).observe(time.time() - start)
PromQL para p95 de latência:
histogram_quantile(0.95,
sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)
Para tarefas onde a velocidade é crítica — por exemplo, na automação de anúncios do TikTok, onde cada segundo de carregamento da página aumenta o risco de timeout em um navegador anti-detect — vale a pena configurar um alerta para p95 acima de 3-4 segundos.
Métrica 3: Taxa de Erro por tipos de erro
Apenas sucesso/falha não é suficiente para diagnóstico. É necessário separar os erros por tipos: 407 (Proxy Authentication Required) significa um problema de autenticação, 429 (Too Many Requests) — limite de requisições excedido, timeouts — problema de rede, 403 — bloqueio por proteção anti-bot do site-alvo. Cada tipo de erro requer uma reação diferente.
ERROR_BY_TYPE = Counter(
'proxy_errors_total', 'Erros de proxy por tipo',
['proxy_pool', 'error_type']
)
def classify_error(resp=None, exc=None):
if exc:
if isinstance(exc, requests.exceptions.Timeout):
return "timeout"
return "connection_error"
if resp.status_code == 407:
return "auth_error"
if resp.status_code == 429:
return "rate_limited"
if resp.status_code == 403:
return "blocked_by_target"
return "other"
Tabela de erros típicos e suas causas:
| Código/tipo | Provável causa | O que verificar |
|---|---|---|
| 407 | Credenciais incorretas ou sessão expirada | Login/senha do proxy, formato da string de conexão |
| 429 | Limite de requisições no IP excedido | Frequência de requisições, tamanho do pool |
| 403 | Proteção anti-bot do site-alvo | User-Agent, fingerprint, tipo de proxy |
| timeout | Sobrecarga do provedor ou da rede | Carga no pool, configurações de timeout do cliente |
Métrica 4: Taxa de rotação e longevidade do IP
Se você está usando proxies rotativos, é importante saber com que frequência o IP muda e quantas requisições conseguem passar antes que o endereço "queime" (seja banido pelo site-alvo). Esta métrica é especialmente crítica para multi-contas — por exemplo, ao farmar contas de anúncios do Facebook Ads através do Dolphin Anty ou AdsPower, onde uma troca prematura de IP pode interromper a sessão e acionar uma verificação de segurança.
from prometheus_client import Gauge
IP_LIFETIME = Gauge(
'proxy_ip_lifetime_seconds', 'Tempo de vida do IP até a rotação',
['proxy_pool']
)
IP_REQUESTS_BEFORE_BAN = Histogram(
'proxy_requests_before_ban',
'Quantas requisições passaram até o banimento do IP',
['proxy_pool'],
buckets=[10, 50, 100, 500, 1000, 5000]
)
Para proxies móveis, esta métrica se comporta de maneira diferente em comparação com os residenciais — a rotação através da troca da estação base do operador fornece IPs mais "limpos" com menor probabilidade de banimento. Se sua tarefa é realmente a automação SMM com alta sensibilidade a banimentos, vale a pena comparar os indicadores de longevidade do IP entre proxies móveis e residenciais com dados reais do seu dashboard, em vez de confiar em recomendações gerais.
Métrica 5: Largura de banda — consumo de tráfego
A maioria dos planos de proxies é cobrada com base no volume de tráfego, e não no número de requisições. Sem monitoramento, é fácil perder o momento em que o limite está quase esgotado — especialmente se a tarefa envolve o carregamento de imagens ou vídeos, como no scraping de cartões de produtos do Wildberries com muitas fotos.
BANDWIDTH_USED = Counter(
'proxy_bandwidth_bytes_total', 'Tráfego consumido através do proxy',
['proxy_pool', 'direction'] # direction: upload/download
)
def track_bandwidth(resp, pool_name):
size = len(resp.content)
BANDWIDTH_USED.labels(proxy_pool=pool_name, direction="download").inc(size)
No dashboard do Grafana, é útil construir não o valor absoluto do tráfego, mas a taxa de consumo (rate) — isso ajuda a prever quando o limite acabará e planejar a compra ou troca para outro pool com antecedência.
Métrica 6: Geo-distribuição e conformidade regional
Para os profissionais de marketing que testam anúncios de diferentes países e para os arbitradores que trabalham com geo-targeting no Google Ads ou TikTok Ads, é crítico que o IP realmente corresponda à região declarada. Um erro de geolocalização pode resultar na exibição de anúncios para o público errado ou no bloqueio da conta por não conformidade com as configurações geográficas.
GEO_MISMATCH = Counter(
'proxy_geo_mismatch_total',
'Casos de não correspondência entre geo declarado e real',
['expected_country', 'actual_country']
)
def verify_geo(proxy, expected_country):
resp = requests.get("https://ipapi.co/json/", proxies={"https": proxy}, timeout=5)
actual = resp.json().get("country_code")
if actual != expected_country:
GEO_MISMATCH.labels(expected_country=expected_country, actual_country=actual).inc()
É recomendável verificar a geolocalização não em cada requisição (isso é caro em termos de tráfego e tempo), mas periodicamente — uma vez por hora em uma amostra de IPs do pool, suficiente para garantir a confiança estatística.
Métrica 7: Conexões Concorrentes — sessões paralelas
O número de conexões simultâneas através do proxy mostra a carga real no pool. Se o número de sessões paralelas exceder o que os IPs no pool podem processar sem degradação, isso leva diretamente ao aumento da latência e da taxa de erro mencionadas anteriormente. Esta métrica é especialmente importante durante a escalabilidade — quando uma agência SMM aumenta o número de contas de clientes ativas de 10 para 50.
from prometheus_client import Gauge
ACTIVE_CONNECTIONS = Gauge(
'proxy_active_connections', 'Conexões ativas atuais através do proxy',
['proxy_pool']
)
def on_request_start(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).inc()
def on_request_end(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).dec()
Comparar esta métrica com a taxa de erro em um único gráfico no Grafana rapidamente mostrará a correlação: assim que o número de sessões paralelas ultrapassa um determinado limite, os erros começam a aumentar de forma não linear.
Configuração do dashboard no Grafana: passo a passo
Depois que as métricas estão instrumentadas e o Prometheus as coleta, é necessário visualizar os dados no Grafana. A ordem das ações é:
- Adicione o Prometheus como fonte de dados: Configuração → Fontes de Dados → Adicionar fonte de dados → Prometheus, insira a URL do seu servidor Prometheus (geralmente
http://localhost:9090). - Crie um novo dashboard: Criar → Dashboard → Adicionar novo painel.
- Para o painel Taxa de Sucesso, use a consulta PromQL da seção sobre a métrica 1, tipo de visualização — Gauge ou Séries temporais.
- Para Latência, crie um painel do tipo Heatmap, para ver a distribuição de p50/p95/p99 ao longo do tempo.
- Para Taxa de Erro, construa um Gráfico de Barras Empilhadas com divisão pelo rótulo
error_type— isso mostrará claramente qual tipo de erro predomina. - Adicione uma variável ao dashboard (Configurações do Dashboard → Variáveis) para
proxy_pool, para alternar entre pools sem criar dashboards separados. - Salve o dashboard e configure a atualização automática a cada 30 segundos para monitoramento quase em tempo real.
O JSON do dashboard pronto pode ser exportado através de Compartilhar → Exportar → Salvar em arquivo e reutilizado para diferentes pools de proxies — residenciais, móveis e de data center, mudando apenas o valor da variável.
Alertas: quando é hora de agir
O dashboard é inútil se ninguém o observa no momento do incidente. Portanto, é crítico configurar alertas no Grafana (Alertas → Regras de alerta) com os seguintes valores de limite, ajustados para a maioria dos cenários de produção:
| Métrica | Limite de alerta | Ação |
|---|---|---|
| Taxa de Sucesso | abaixo de 85% por 5 minutos | Verificar o pool, alternar para o reserva |
| p95 Latência | acima de 5 segundos | Reduzir paralelismo, verificar o provedor |
| Taxa 429 | acima de 10% das requisições | Reduzir a frequência de requisições, aumentar o pool de IPs |
| Taxa de Largura de Banda | previsão de esgotamento do limite em 24h | Comprar mais tráfego ou otimizar requisições |
É melhor direcionar alertas para o Telegram ou Slack através de webhook — isso garante uma reação imediata, em vez de verificar o dashboard uma vez por dia.
Conclusão
Sete métricas — taxa de sucesso, latência, taxa de erro por tipos, longevidade do IP, tráfego, conformidade geográfica e concorrência de conexões — fornecem uma visão completa da saúde da infraestrutura de proxy em produção. A combinação Prometheus + Grafana permite não apenas registrar um problema post-fato, mas ver tendências e reagir antes que a degradação do pool leve a banimentos de contas ou interrupções no scraping.
A escolha do tipo de proxy afeta diretamente quais métricas terão prioridade: para tarefas com alta sensibilidade a banimentos, como multi-contas no Instagram ou TikTok, é importante monitorar principalmente a longevidade do IP e a taxa de sucesso, utilizando proxies residenciais para máxima semelhança com o tráfego real dos usuários. Para tarefas onde a velocidade e o volume são importantes — scraping em massa do Ozon, Avito ou Yandex.Market — a latência e a largura de banda se tornam prioritárias, e aqui frequentemente os proxies de data center funcionam de maneira mais eficaz devido à maior capacidade de throughput.