Pergunte a uma equipe de scraping como andam as coisas e você normalmente vai receber um número: taxa de sucesso. É a métrica óbvia e é genuinamente útil, mas sozinha ela é quase inútil para gerenciar um pipeline, porque esconde as duas perguntas que um líder de equipe realmente precisa responder. Os dados que estamos coletando estão corretos, e o que estamos pagando para coletá-los é razoável?
Um pipeline pode reportar noventa e oito por cento de sucesso enquanto silenciosamente enche um data warehouse com páginas de desafio, e pode reportar o mesmo número neste mês que no anterior custando o dobro. Aqui está o conjunto de métricas que capta os dois problemas, organizado pelo propósito de cada uma.
Comece pela métrica que todo mundo erra
Taxa de sucesso validada. Não a proporção de requisições que retornaram 200, mas a proporção que retornou os dados que você queria.
Essa distinção é a mudança de maior valor que a maioria das equipes pode fazer no seu monitoramento. Uma página de desafio, um conjunto de resultados vazio, uma listagem truncada, um aviso de consentimento ou um redirecionamento regional genérico podem chegar todos com status 200. Um contador que confia em códigos de status vai reportar saúde enquanto seu conjunto de dados se degrada, e você vai descobrir isso quando um usuário de negócio perguntar por que um gráfico parece errado, e não pelo seu próprio painel. Defina uma verificação de validade por alvo, um elemento esperado, um tamanho de conteúdo plausível, um campo obrigatório no JSON, e conte apenas as respostas que passam nela, conforme descrito em detectando conteúdo bloqueado ou falso.
Acompanhe isso por alvo e por região, nunca como um número global único. Um 95% global pode significar que todo alvo está em 95%, ou que dezenove alvos estão em 100% e um está em zero, e esses cenários exigem respostas completamente diferentes.
Métricas de qualidade dos dados
Além da validade, três números indicam se o resultado é confiável.
Cobertura. Dos registros esperados em uma execução, quantos você realmente obteve? Um job que tem sucesso em cada requisição que faz, mas faz menos requisições do que ontem porque a paginação quebrou ou uma etapa de descoberta retornou menos, vai parecer perfeito na taxa de sucesso e estar materialmente incompleto. A cobertura capta isso.
Atualidade (freshness). Qual a idade dos dados mais recentes por fonte? Para trabalhos de ritmo acelerado, como preços ou disponibilidade, dados desatualizados são um defeito mesmo quando tudo tecnicamente teve sucesso, então acompanhe a idade da coleta bem-sucedida mais recente por alvo e alerte quando ela ultrapassar o que o caso de uso tolera.
Completude em nível de campo. Dos registros coletados, qual proporção tem todos os campos que você precisa? Uma mudança de layout que remove um atributo raramente falha uma requisição; ela apenas anula silenciosamente uma coluna, e só o rastreamento em nível de campo revela isso cedo.
Juntas, essas métricas respondem “os dados estão corretos”, o que a taxa de sucesso sozinha não consegue.
Métricas de eficiência e custo
Essas respondem “o que estamos pagando é razoável”, e são geralmente as menos instrumentadas.
Bytes por registro. A métrica de custo mais útil de todo o conjunto. Divida a largura de banda consumida pelos registros úteis extraídos, por alvo. Isso normaliza entre jobs de tamanhos diferentes, torna os alvos comparáveis, e um aumento repentino quase sempre significa que alguém está renderizando uma página inteira quando um endpoint de dados resolveria. Como os proxies residenciais cobram por dados transferidos, esse número é próximo do seu custo unitário, e as alavancas sobre ele estão em reduzindo custos de largura de banda de proxy e escolhendo quando um navegador headless é necessário.
Custo por mil registros. Bytes por registro multiplicado pela sua tarifa, expresso por alvo. Esse é o número a apresentar para quem perguntar se uma fonte de dados vale a pena coletar, porque converte infraestrutura na linguagem que o negócio já usa, e é o que torna concreta a previsão em estimando a largura de banda mensal.
Taxa de repetição (retry ratio). Repetições como proporção do total de requisições, por alvo. Esse é um indicador antecedente: ele sobe antes da taxa de sucesso cair, porque um pipeline que faz retry até chegar a um resultado de aparência normal está escondendo um problema em vez de resolvê-lo. Também é puro desperdício em um produto cobrado por largura de banda, então é simultaneamente um sinal de saúde e uma linha de custo, motivo pelo qual está no centro de retry e backoff.
Largura de banda por alvo. Para onde o dinheiro realmente vai. Equipes frequentemente se surpreendem ao descobrir que um único alvo consome a maior parte de um plano, e a correção costuma ser barata assim que fica visível.
Métricas de desempenho
Percentis de latência, não médias. Acompanhe p50, p95 e p99 por alvo. Conexões residenciais são naturalmente mais lentas do que as diretas, então o número absoluto importa menos do que a forma e a tendência. Uma média esconde completamente a cauda, e é a cauda que determina se um job com prazo definido termina a tempo.
Throughput em relação ao plano. Registros por hora, comparados com o que o cronograma exige. É assim que você sabe se precisa de mais concorrência, melhor ritmo, ou uma estratégia de coleta diferente, e é o insumo prático para a questão de distribuição em quantos IPs de proxy você realmente precisa.
Taxa de bloqueio e desafio. Distinta de requisições falhas: a proporção de respostas que foram especificamente um bloqueio, um captcha, ou um desafio. Uma taxa de desafio crescente com taxa de sucesso estável significa que você está trabalhando mais para o mesmo resultado, e é um alerta precoce de que as defesas de um alvo mudaram.
O que não rastrear
Duas coisas são medidas com frequência e merecem menos atenção do que recebem.
Tamanho do pool. É um número do fornecedor, não uma métrica de desempenho, e não prevê seus resultados. A densidade nos países de onde você realmente coleta prevê, e a única forma de saber isso é a sua própria taxa de sucesso por região.
Contagem bruta de requisições. Volume sem validade é atividade, não resultado. Um pipeline que dobra suas requisições enquanto coleta o mesmo número de registros utilizáveis piorou, e um contador de requisições vai chamar isso de crescimento.
Da mesma forma, tenha cuidado com como você usa um SLA de uptime. A disponibilidade do provedor é real e vale a pena acompanhar, mas é um eixo diferente de saber se seus alvos aceitam seu tráfego, e confundir os dois deixa você coberto contratualmente e cego operacionalmente, o que é a fronteira discutida em SLAs de proxy e garantias de uptime.
Transformando métricas em alertas
Um painel que ninguém olha é decoração. Um pequeno número de alertas, vinculados às métricas acima, é o que realmente protege um pipeline.
Alerte quando a taxa de sucesso validada cair abaixo de um limite por alvo, já que um único número não serve para todos os sites. Alerte quando a cobertura cair em relação à mesma execução da semana passada, o que capta encolhimento silencioso. Alerte quando a atualidade ultrapassar a tolerância do caso de uso. Alerte quando bytes por registro subir acentuadamente, o que é uma regressão de custo e geralmente uma mudança de código. E alerte quando a taxa de repetição subir, porque essa é a primeira a disparar.
Duas regras práticas tornam esses alertas administráveis. Compare com uma linha de base móvel em vez de um número fixo, porque cada alvo tem seu próprio ritmo e um limite estático ou dispara falsos alarmes ou nunca dispara. E exija um desvio sustentado em vez de um único intervalo ruim, já que uma janela ruim de cinco minutos é ruído. A instrumentação em si é abordada em monitorando um pipeline de web scraping.
Um conjunto mínimo para começar
Se você está instrumentando do zero, seis métricas por alvo já trazem a maior parte do valor: taxa de sucesso validada, cobertura em relação ao esperado, atualidade do registro mais recente, bytes por registro, taxa de repetição, e latência p95. Adicione a região como uma dimensão nas duas primeiras, já que a geografia é onde pipelines multimercado falham silenciosamente. Tudo o mais pode esperar até que uma dessas seis levante uma pergunta que você não consegue responder.
Conclusão
A taxa de sucesso responde se as requisições foram concluídas, que é a menos interessante das três perguntas que um líder de equipe tem. Valide o que voltou antes de contá-lo como sucesso, depois meça cobertura, atualidade e completude de campos para saber se os dados estão corretos, e bytes por registro, custo por mil registros e taxa de repetição para saber se o preço é razoável. Acompanhe tudo por alvo e por região em vez de globalmente, alerte sobre desvios sustentados de uma linha de base móvel, e resista a julgar a infraestrutura pelo tamanho do pool ou pelo volume bruto de requisições. As métricas que importam são as que mudam uma decisão, e são essas que fazem isso.
Medir contra a própria rede é um exercício separado, abordado em testando velocidade, taxa de sucesso e precisão de localização. Os proxies residenciais por trás disso são cobrados por GB, motivo exato pelo qual bytes por registro é a métrica de custo que vale a pena observar: é o número do qual sua fatura é feita.