A pequena tarefa de scraping ou funciona ou não funciona, e você descobre isso rapidamente. Uma grande nunca está em nenhum dos dois estados. A qualquer momento, uma fração do seu tráfego está falhando, e a pergunta operacionalmente útil não é “o proxy está funcionando” mas “qual parcela disso degradou, e é culpa nossa, do provedor ou do alvo”.
Obter uma resposta útil significa instrumentar ao longo das dimensões que podem falhar de forma independente, o que não é o mesmo que adicionar mais métricas. Aqui está o que medir, como fazer probes sem desperdiçar banda, e como distinguir as três fontes de falha.
A saúde é por rota, não por proxy
A primeira correção: em um gateway com pool, você não tem proxies para monitorar. Você nunca escolheu os endereços de saída, não os mantém, e um endereço que falhou uma vez não é uma entidade que você pode rastrear ao longo do tempo. O que você pode rastrear é uma rota, ou seja, uma combinação das coisas que você controla: alvo, país e, quando relevante, cidade ou ASN.
Portanto, a unidade de saúde é a rota. amazon-de, serp-us-chicago, marketplace-jp. Cada uma tem sua própria taxa de sucesso, perfil de latência e mix de falhas, e cada uma pode degradar enquanto as outras permanecem perfeitas. Um único número global de “saúde do proxy” faz uma média que elimina exatamente o sinal de que você precisa: noventa e cinco por cento no geral pode ser vinte rotas em noventa e nove por cento e uma rota em zero, e apenas a segunda leitura diz a você para fazer algo.
Adicione a saúde da sessão como uma segunda unidade, de vida mais curta. Uma sessão sticky que começa a atrair challenges deve ser aposentada e substituída em vez de reutilizada, e essa decisão pertence ao mesmo componente que distribui as sessões, conforme descrito em construindo um gerenciador de proxy.
Passivo primeiro: cada requisição real é uma verificação de saúde
O monitoramento mais barato é o tráfego que você já está enviando. Cada requisição de produção produz um resultado, e se você o registrar em relação à sua rota, obtém dados contínuos de saúde sem custo adicional de banda.
O detalhe crítico é o que conta como sucesso. Não um 200. Uma página de challenge, um resultado genérico ou vazio, uma listagem truncada ou um redirecionamento para uma landing page retornam todos 200 e todos significam que sua coleta falhou, então um monitor que conta códigos de status vai reportar saúde enquanto o dataset degrada. Valide o corpo em relação a uma expectativa específica por alvo antes de registrar o resultado, que é a disciplina em detectando conteúdo bloqueado ou falso. Essa única mudança é o que separa um dashboard de saúde que detecta problemas de um que apenas confirma seu viés.
Registre, no mínimo, por requisição: rota, resultado validado, latência, bytes e uma classe de falha caso tenha falhado. Isso é suficiente para calcular tudo abaixo.
Classifique as falhas, porque a classe é o diagnóstico
Contar falhas diz a você que algo está errado. Classificá-las diz o quê. Cinco classes cobrem quase tudo, e cada uma aponta para um lugar diferente.
Falhas de autenticação significam credenciais ou uma flag de segmentação malformada, o que é um problema de configuração do seu lado e não se resolve com uma nova tentativa, conforme corrigindo erros 407 e de credenciais. Falhas de no-match, quando o gateway não tem nenhum endereço que se encaixe no seu filtro naquele momento, significam que sua segmentação está estreita demais, e não que algo esteja quebrado; amplie de cidade para país e o problema desaparece. Sinais de rate, ou seja, 429 e afins, significam que seu ritmo está agressivo demais para aquele alvo, o que é um problema de throttling. Sinais de bloqueio, ou seja, challenges e 403s persistentes, significam que o alvo rejeitou a identidade, então aposente a sessão e considere se seus headers ou fingerprint são a causa real. Falhas de transporte, ou seja, timeouts e resets de conexão, são a classe ambígua e merecem sua própria investigação, já que as razões pelas quais requisições dão timeout incluem lentidão do alvo, uma rota não saudável e sua própria concorrência estar alta demais.
O mix importa mais do que o total. Uma rota com oitenta por cento de sucesso composta por sinais de rate precisa de um ritmo mais lento; a mesma rota com oitenta por cento composta por sinais de bloqueio precisa de uma estratégia de identidade diferente; composta por erros de no-match precisa de segmentação mais ampla. Mesmo número, três correções diferentes.
Probes ativos, usados com moderação
O monitoramento passivo tem um ponto cego: ele só cobre rotas que você está usando no momento, então uma rota programada para rodar às 03:00 não dá nenhum aviso às 22:00 de que quebrou. Um pequeno conjunto de probes ativos preenche essa lacuna, mas eles custam banda, então mantenha-os baratos e com propósito.
Vale a pena rodar dois tipos. Um probe de conectividade e geo por país, atingindo um pequeno endpoint que ecoa o endereço e sua localização, confirma que o gateway está acessível e que o país solicitado é o país obtido. Mantenha-o leve, já que este é o probe que você roda com mais frequência. Um canary de alvo por alvo importante, buscando uma página conhecida como estável e validando-a, diz se aquele alvo específico está respondendo normalmente, que é a verificação que distingue um problema do alvo de um problema do proxy.
import requests
def geo_probe(country):
proxy = f"http://customer-USERNAME-country-{country}:PASSWORD@p.shifter.io:443"
try:
r = requests.get("https://ipinfo.io/json",
proxies={"http": proxy, "https": proxy}, timeout=15)
d = r.json()
return {"ok": d.get("country","").lower() == country,
"got": d.get("country"), "org": d.get("org")}
except Exception as e:
return {"ok": False, "error": type(e).__name__}Rode probes de geo em uma cadência lenta em todos os países que você realmente usa, e canaries em uma cadência compatível com o quanto uma falha silenciosa custaria a você. Alerte quando um probe falhar repetidamente, não apenas uma vez, já que uma única falha em um pool rotativo é ruído normal.
Distinguindo as três fontes de falha
Essa é a pergunta que realmente é feita durante um incidente, e a resposta vem da comparação de sinais, não de nenhuma métrica isolada.
O seu lado aparece como falhas em muitos alvos não relacionados ao mesmo tempo, geralmente começando exatamente quando algo foi implantado. Falhas de autenticação em todo lugar, um pico de erros de transporte vindo de um pool de workers, ou um aumento em erros de no-match depois que alguém apertou um filtro, tudo isso aponta para dentro. O indício é a amplitude: seus próprios bugs raramente respeitam limites de alvo.
O provedor aparece como falhas em muitos alvos, mas confinadas à camada de rede: probes de conectividade falhando, probes de geo retornando o país errado, erros de transporte subindo enquanto canaries de alvo que conseguem passar ainda retornam páginas válidas. É aqui também que uma página de status pública ganha seu lugar, já que correlacionar sua própria queda com o histórico de incidentes do provedor responde à pergunta imediatamente, e o escalonamento que rege o que lhe é devido está em SLAs e garantias de uptime de proxy.
O alvo aparece como falhas confinadas a um único alvo enquanto todas as outras rotas permanecem saudáveis, e o canary daquele alvo falha enquanto seus probes de geo passam. Se ele falha em todas as regiões simultaneamente, o site provavelmente está tendo seus próprios problemas; se falha em apenas uma região, você está diante de um bloqueio específico de geo ou um problema regional de edge.
Instrumente de forma que essas comparações sejam uma única consulta, não uma tarde inteira: as mesmas classes de falha e resultados, marcados com rota, região e worker, já são suficientes.
No que alertar
Dashboards servem para investigar, alertas servem para acordar alguém. Mantenha o conjunto de alertas pequeno e faça com que cada um seja acionável.
Alerte quando a taxa de sucesso validada de uma rota cair abaixo de sua própria baseline móvel, não de um limiar global, porque uma rota que normalmente roda a setenta por cento contra um alvo hostil está saudável a setenta por cento e quebrada a quarenta. Alerte sobre uma mudança no mix de falhas, já que uma rota que mantém sua taxa de sucesso enquanto sinais de bloqueio substituem sinais de rate mudou de caráter de um jeito que prediz problemas. Alerte sobre a subida da proporção de retries, que sobe antes de a taxa de sucesso cair e é, portanto, o aviso mais precoce que você tem. Alerte sobre cobertura, ou seja, uma rota programada produzindo materialmente menos registros do que seu próprio histórico recente, o que captura encolhimento silencioso que a taxa de sucesso não consegue ver. E alerte quando um probe falhar repetidamente para uma região da qual você depende.
Exija desvio sustentado em vez de um único intervalo, e compare contra uma baseline móvel. As definições de métricas por trás disso estão em KPIs de proxy, e a instrumentação em nível de pipeline está em monitorando um pipeline de web scraping.
Faça o sistema agir sobre isso
Monitoramento que só produz gráficos mantém um humano no loop para problemas que uma máquina deveria resolver. Os mesmos sinais devem orientar um comportamento automático: aposentar uma sessão que acumula sinais de bloqueio, abrir um circuit breaker em uma rota cuja taxa de sucesso desaba para parar de alimentar um alvo que não está respondendo, transferir trabalho para outra região quando uma degrada, conforme failover em pipelines multi-região, e recuar automaticamente quando sinais de rate aparecem. Humanos devem ser alertados para coisas que exigem julgamento, não para coisas que exigem uma regra.
Resumo
Em escala, saúde não é uma propriedade do proxy, é uma propriedade de cada rota que você roda, então instrumente por alvo e região e deixe a saúde da sessão ser seu próprio sinal de vida curta. Julgue cada resultado com base em um corpo validado, não em um código de status, porque essa é a diferença entre monitoramento e autoengano. Classifique as falhas, já que o mix diz se você deve desacelerar, mudar de identidade, ampliar a segmentação ou corrigir sua própria configuração. Adicione uma camada fina de probes de geo e canaries de alvo para cobrir rotas que não estão rodando no momento e para separar problemas do provedor de problemas do alvo. Depois alerte sobre desvio sustentado em relação à própria baseline de cada rota, sobre mudanças no mix de falhas e sobre a proporção de retries, e conecte os mesmos sinais a aposentadoria automática, backoff e failover para que o sistema corrija o que puder antes que alguém precise ser acordado.
A camada subjacente são os proxies residenciais, onde a segmentação por país e cidade e o controle de sessão são expressos por requisição, o que faz da saúde no nível de rota uma questão de marcar suas próprias requisições, em vez de um projeto de integração, com preços por GB para que uma estratégia enxuta de probes custe quase nada perto da própria coleta.