Sumário do artigo

Imagine uma manhã típica do engenheiro de plantão. Chega uma mensagem no chat: "Está tudo lento aqui". Mas o que exatamente está lento? O pool inteiro ou só um recorte? O proxy de um país específico ou de uma operadora específica? O site de destino está respondendo devagar ou a fila de retentativas está crescendo? Sem números, isso não é um incidente, é adivinhação. E enquanto a equipe adivinha, o tempo passa e o dinheiro escorre.

Este artigo é sobre como transformar a sensação vaga de "está lento" em um diagnóstico preciso em um minuto. Vamos ver quais métricas coletar em torno do pool de proxies, o que registrar nos logs a cada requisição e o que nunca registrar de jeito nenhum, por que os percentis importam mais que a média, como rotular os dados por dimensões e como configurar alertas que não te acordam por falsos motivos. No final, você encontra uma tabela de resposta rápida e um FAQ prático.

Uma ressalva importante sobre os limites do tema. Aqui falamos apenas sobre medição e alerta. Escolher um IP específico para uma requisição, fazer health-check dos nós e a lógica de quarentena dentro do pool é um assunto à parte, grande, e tem material dedicado. Nossa tarefa aqui é mais restrita: enxergar a degradação, localizá-la e levantar o alerta a tempo. Os exemplos usam a infraestrutura da Proxeon, mas os princípios são universais.

Fundamentos: o que é observabilidade e por que proxies exigem isso com tanta urgência

Vamos começar pelo básico. Observabilidade (observability) é a propriedade de um sistema pela qual, a partir de suas saídas externas, é possível entender seu estado interno sem precisar entrar nele com um depurador. A tríade clássica da observabilidade: métricas, logs e traces. As métricas respondem à pergunta "o que está acontecendo" de forma agregada, os logs respondem "o que exatamente aconteceu com aquela requisição específica", e os traces respondem "como a requisição percorreu toda a cadeia".

O que diferencia os proxies de um serviço web comum? O fato de existir um terceiro que você não controla por completo: o próprio nó de proxy, o canal até ele e o recurso de destino atrás dele. Uma aplicação comum pode ser perfilada função por função. Já o proxy adiciona uma camada de incerteza de rede, na qual a degradação pode vir de qualquer lugar: da operadora de telecom, do roteamento, da sobrecarga de um nó específico, de uma mudança de comportamento do site de destino.

É por isso que a observabilidade em torno de um pool de proxies não é luxo, é higiene. Sem ela, você trabalha às cegas. Com ela, você enxerga a estrutura do problema: não "está tudo ruim", mas "degradou o recorte de proxies móveis de uma operadora em uma região, o resto está normal". Essa é a diferença entre pânico e precisão cirúrgica.

Três níveis onde os problemas vivem

Vale ter desde o início em mente três níveis onde nasce a degradação:

  • Nível de transporte: o canal até o proxy, perda de pacotes, tempo de estabelecimento de conexão. É onde vivem os timeouts e o TTFB lento.
  • Nível do nó de proxy: sobrecarga de um IP específico, esgotamento de limites, problemas na operadora. É onde vive o aumento da taxa de erros em um recorte específico.
  • Nível do recurso de destino: o site passou a responder mais devagar, devolveu códigos fora do padrão, mudou limites. Aqui é importante não confundir problema do site com problema do pool.

Um bom sistema de observabilidade permite entender de relance em qual dos três níveis está o problema. É exatamente esse o tal "um minuto até o diagnóstico" pelo qual estamos fazendo tudo isso.

Quatro sinais para proxies: por que justamente esses

Existe a tentação de coletar tudo. Centenas de métricas, dezenas de dashboards, quilômetros de gráficos. Isso é uma armadilha. Muita métrica significa ruído, e ruído significa que, no momento do incidente, você não vai achar o que precisa. A prática experiente de engenharia diz o contrário: comece com um conjunto mínimo de sinais que cobre a maioria dos problemas. Para um pool de proxies, são quatro sinais.

Sinal um: taxa de sucesso

A taxa de sucesso (success rate) é a porcentagem de requisições que terminaram como esperado, sobre o total. É o principal indicador de saúde. Se a taxa de sucesso cai, algo quebrou agora, bem na frente do usuário.

A pergunta chave: o que conta como sucesso? A resposta ingênua "código 200" está errada. O correto é definir sucesso pelo contrato do seu uso. Frequentemente se considera sucesso todos os códigos 2xx e 3xx, além de 4xx significativos que são resposta válida do recurso de destino, e não problema do proxy. Já timeouts, quedas de conexão, erros no nível do proxy e 5xx em massa são falha.

Formalmente, a taxa de sucesso pertence à família de métricas de "disponibilidade" no modelo SLI (Service Level Indicator). É aquele indicador em torno do qual depois se constroem SLOs (objetivos de nível de serviço) e o orçamento de erros.

Sinal dois: latência por percentis

A latência (latency) é o tempo entre enviar a requisição e receber a resposta. Mas um único número de latência é inútil. Você precisa de percentis: p50, p95, p99. Por que percentis e não a média, veremos em detalhe numa seção à parte, porque esse é um dos temas mais subestimados de todo o monitoramento.

Para proxies, o TTFB (Time To First Byte, tempo até o primeiro byte) é especialmente valioso. Ele separa a latência de rede e o tempo de resposta do servidor do tempo de transmissão do corpo da resposta. Se o TTFB sobe, é problema de rede ou do nó. Se o tempo total sobe, mas o TTFB fica estável, possivelmente as respostas simplesmente cresceram ou a largura de banda do canal caiu.

Sinal três: taxa de retentativas

A taxa de retentativas (retry rate) é a porcentagem de requisições que precisaram de uma nova tentativa. É um prenúncio precoce de problema. Muitas vezes a taxa de sucesso ainda está normal, porque as retentativas seguram a situação, mas a taxa de retentativas já começou a subir. É como temperatura de 37,2: formalmente você ainda trabalha, mas o corpo já está lutando.

As retentativas mascaram a degradação para o usuário final, mas devoram recursos: tempo, tráfego, capacidade do pool. Ignorar esse sinal é perigoso em dobro, porque o crescimento de retentativas pode derrubar o sistema em cascata, quando as requisições repetidas adicionam carga a nós já sobrecarregados.

Sinal quatro: consumo de tráfego

O consumo de tráfego (bandwidth) é o volume de dados transmitidos. Por que ele entra no quarteto principal? Primeiro, porque é dinheiro direto, já que o tráfego é tarifado. Segundo, porque consumo anômalo é um sinal: um aumento súbito pode significar que alguém está puxando coisa a mais, que as respostas incharam, ou que as retentativas ficam rodando os mesmos dados em círculo. Uma queda súbita a zero em um recorte que normalmente tem atividade significa que o recorte simplesmente parou de funcionar.

Esses quatro sinais não são por acaso. Eles dialogam com a metodologia dos "sinais de ouro" da observabilidade, popularizada pelos engenheiros de confiabilidade: latência, tráfego, erros, saturação. Adaptamos essa metodologia à especificidade dos proxies, onde as retentativas merecem lugar próprio por serem um prenúncio único dessa área.

Mergulho fundo: o que registrar no log a cada requisição

As métricas mostram tendências. Mas quando é preciso entender o que aconteceu com uma requisição específica, são os logs que salvam. Um log de requisição bem projetado é sua caixa-preta, à qual você recorre ao investigar um incidente. Vamos ver o que é obrigatório registrar e o que nunca se pode registrar.

O que registrar obrigatoriamente

  • Identificador do proxy: não o IP em si aberto, mas um identificador estável de nó ou pool. Isso permite associar a requisição a um recurso específico e ver quais nós dão problema.
  • Código de resposta: o status HTTP ou o código de erro de transporte (timeout, recusa de conexão, queda). Essa é a base para calcular a taxa de sucesso.
  • Tempo até o primeiro byte (TTFB): em milissegundos. Um dos indicadores mais informativos para localizar problemas de rede.
  • Tempo total da requisição: do início ao fim, também em milissegundos.
  • Tamanho da resposta: em bytes. Alimenta a métrica de tráfego e ajuda a notar respostas anormalmente grandes ou vazias.
  • Número da tentativa: se é a primeira tentativa ou já uma retentativa, e qual a contagem. Sem esse campo é impossível calcular a taxa de retentativas.
  • Dimensões para rotulagem: país, operadora, tipo de proxy. Falamos disso numa seção à parte, mas no log elas precisam estar.
  • Timestamp e identificador de trace: para correlacionar registros entre si e com sistemas externos.

Veja como pode ser um registro de log estruturado em formato JSON. Repare: é legível por máquina, o que é crítico para a análise posterior.

{"ts":"2026-02-14T08:12:33Z","trace_id":"a1b2c3","proxy_id":"pool7-node042","country":"RU","carrier":"op-a","proxy_type":"mobile","status":200,"ttfb_ms":187,"total_ms":342,"bytes":20481,"attempt":1,"outcome":"success"}

O que NUNCA se pode registrar

Isso é tão importante quanto o que se deve registrar. Logs têm o hábito de vazar, serem copiados para sistemas analíticos, pararem em backups. Tudo o que você coloca ali vive muito tempo e em lugares inesperados.

  • Credenciais: logins, senhas, tokens de autorização do proxy, chaves de API. Nunca. Nem parcialmente. Nem "temporariamente, para depurar".
  • Corpo da resposta inteiro: primeiro, é um volume gigantesco; segundo, pode conter dados pessoais e sensíveis. Registre apenas o tamanho e, se necessário, um hash ou uma assinatura curta.
  • Cabeçalhos com segredos: Authorization, Cookie, Set-Cookie e afins. Precisam ser limpos antes do registro.
  • URLs completas com parâmetros sensíveis: se a query string tem tokens ou identificadores pessoais, eles devem ser mascarados.
  • Dados pessoais de usuários: tudo o que cai sob as exigências da legislação de proteção de dados deve ou não entrar no log, ou ser anonimizado.

Uma técnica prática de mascaramento no momento da formação do log:

def sanitize(entry):  secret_keys = {"authorization", "cookie", "set-cookie", "proxy-authorization"}  headers = {k: ("***" if k.lower() in secret_keys else v) for k, v in entry.get("headers", {}).items()}  entry["headers"] = headers  entry.pop("body", None)  entry.pop("proxy_credentials", None)  return entry

Regra de ouro: o log precisa permitir diagnosticar o problema, mas não pode virar uma base de segredos vazados. Se estiver em dúvida sobre registrar um campo, não registre. O valor diagnóstico quase sempre pode ser obtido por substitutos seguros: hashes, tamanhos, flags, categorias.

Percentis em vez de média: por que a média esconde o problema

Esta é a seção que vale reler duas vezes. Porque aqui mora o erro mais comum e mais traiçoeiro do monitoramento de desempenho.

Por que a média mente

Imagine: você tem cem requisições. Noventa e nove delas foram executadas em 100 milissegundos, e uma em 10 segundos. A média dá cerca de 199 milissegundos. Parece ótimo, quase nada mudou. Enquanto isso, um dos seus usuários esperou dez segundos e, provavelmente, já foi embora resmungando.

A média é um instrumento que espalha os outliers por toda a amostra. Ela é sensível a extremos, mas insensível à estrutura da distribuição. E o desempenho de sistemas de rede quase sempre tem distribuição de cauda longa: a maioria das requisições é rápida, mas uma minoria é muito lenta. E é justamente essa cauda que define a experiência real do usuário e a presença de problemas.

O que são percentis e como lê-los

Um percentil é o valor abaixo do qual está uma porcentagem determinada de observações. Vejamos os três principais:

  • p50 (mediana): metade das requisições é mais rápida que esse valor, metade mais lenta. É a experiência "típica".
  • p95: 95 por cento das requisições caberam nesse tempo. É a experiência de "quase pior caso", que afeta uma parcela perceptível dos usuários.
  • p99: 99 por cento das requisições mais rápidas. É a tal cauda longa, onde vivem timeouts, retentativas e usuários furiosos.

No nosso exemplo com cem requisições, p50 e p95 continuam em torno de 100 milissegundos, mas o p99 dispara para 10 segundos. O percentil mostrou honestamente o problema que a média escondeu. É por isso que engenheiros experientes olham p95 e p99 em primeiro lugar, e quase não usam a média para avaliar latência.

Como calcular percentis corretamente

O jeito ingênuo é juntar todos os valores, ordenar e pegar a posição desejada. É exato, mas não escala: com milhões de requisições, armazenar o array inteiro é inviável. Na prática, usam-se estruturas de contagem aproximada: histogramas com buckets fixos ou algoritmos dedicados como t-digest e histogramas HDR.

A ideia do histograma é simples: você define previamente faixas (buckets) de tempo e apenas conta quantas requisições caíram em cada uma. Pelos contadores acumulados, é fácil reconstruir qualquer percentil com precisão aceitável, e a memória gasta é fixa.

import bisectclass PercentileTracker:  def __init__(self):    self.buckets = [10, 25, 50, 100, 200, 500, 1000, 2000, 5000]    self.counts = [0] * (len(self.buckets) + 1)  def add(self, ms):    i = bisect.bisect_left(self.buckets, ms)    self.counts[i] += 1  def percentile(self, p):    total = sum(self.counts)    if total == 0:      return None    target = total * p / 100    acc = 0    for i, c in enumerate(self.counts):      acc += c      if acc >= target:        return self.buckets[min(i, len(self.buckets) - 1)]    return self.buckets[-1]

Um aviso importante sobre agregação. Percentis não podem ser calculados por média. Se você tem o p95 em dez nós, não pode tirar a média desses p95 e chamar o resultado de p95 geral. Isso é matematicamente incorreto. Para agregar corretamente, é preciso somar os histogramas e, a partir do histograma somado, calcular o percentil. É por isso que os sistemas modernos de monitoramento armazenam histogramas, e não percentis prontos.

Rotulagem por dimensões: enxergar o recorte, não o pool inteiro

Aí está o momento em que a observabilidade deixa de ser gráfico e vira ferramenta de diagnóstico. Um número único de taxa de sucesso para o pool inteiro diz pouco. Pode estar em 97 por cento e parecer normal, escondendo que um recorte caiu para 40 por cento e os outros seguram a média.

Três dimensões essenciais para proxies

  • País (country): a geografia do proxy. A degradação costuma ser geograficamente localizada: problema de roteamento em uma região, mudanças do lado do recurso de destino para determinados países.
  • Operadora (carrier): para proxies móveis da Proxeon, essa é uma dimensão criticamente importante. O problema de uma operadora específica aparece exatamente aqui, e você entende de imediato a escala dele.
  • Tipo de proxy (proxy_type): móveis, de servidor, residenciais. Tipos diferentes se comportam de formas diferentes, e a degradação de um tipo não pode se perder na massa geral.

Cardinalidade: onde parar

Há a tentação de rotular tudo: cada IP, cada domínio de destino, cada usuário. Isso leva à explosão de cardinalidade, ou seja, da quantidade de combinações únicas de rótulos. Alta cardinalidade mata sistemas de monitoramento: cresce o volume de armazenamento, as consultas ficam mais lentas, a infraestrutura encarece.

Regra prática: rotule por dimensões com conjunto de valores limitado e estável. Países são dezenas, operadoras são unidades ou dezenas, tipos de proxy são unidades. Isso é seguro. Já um IP individual ou uma URL completa como rótulo em métricas não pode ser usado: são únicos em quantidades enormes. Esses detalhes pertencem aos logs, onde ficam linha a linha, e não às métricas, onde multiplicam séries de dados.

from prometheus_client import Counter, Histogramrequests_total = Counter(  "proxy_requests_total",  "Total proxy requests",  ["country", "carrier", "proxy_type", "outcome"])latency_ms = Histogram(  "proxy_latency_ms",  "Request latency",  ["country", "carrier", "proxy_type"],  buckets=[10, 25, 50, 100, 200, 500, 1000, 2000, 5000])def record(country, carrier, ptype, outcome, ms):  requests_total.labels(country, carrier, ptype, outcome).inc()  latency_ms.labels(country, carrier, ptype).observe(ms)

Com essa rotulagem, você consegue montar em segundos uma consulta do tipo: mostre a taxa de sucesso por operadora na última hora. E ver de imediato que não degradou o pool inteiro, mas um recorte. Isso é localização. A beleza dessa abordagem é que ela transforma o pânico de "quebrou tudo" na calma de "o recorte X da operadora Y precisa de atenção".

Alertas que não fazem barulho

A causa mais comum de equipes deixarem de confiar no monitoramento são alertas barulhentos. Quando o sistema te acorda cinco vezes numa noite por falsos motivos, você rapidinho começa a ignorá-lo. E depois perde um incidente de verdade. Isso se chama fadiga de alertas, e mata a observabilidade com mais eficiência do que a ausência total de monitoramento.

Três princípios de alertas silenciosos

Princípio um: limiares sobre sintomas, não sobre causas. O alerta deve disparar sobre o que o usuário sente: queda da taxa de sucesso, aumento do p99 de latência. Não sobre oscilações técnicas intermediárias que, por si sós, não significam problema.

Princípio dois: janelas de observação. Não reaja a um pico isolado. Uma requisição lenta é ruído. Desvio sustentado durante uma janela de tempo é sinal. Configure o alerta para disparar quando a condição se mantém, por exemplo, cinco minutos seguidos, e não num instante.

Princípio três: histerese. Termo emprestado da engenharia, significa limiares diferentes para disparar e para limpar. O alerta acende quando a taxa de sucesso cai abaixo de 90 por cento, mas só apaga quando sobe acima de 95. O intervalo entre os limiares evita o "tremelique", quando a métrica oscila em torno de um valor e o alerta pisca acendendo e apagando.

Exemplo de configuração de alerta

Veja um exemplo de regra no estilo entendido pela maioria dos sistemas de monitoramento. Ela dispara se a taxa de sucesso em qualquer recorte de operadora se mantém abaixo do limiar durante a janela de observação.

groups:- name: proxy-health  rules:  - alert: LowSuccessRateByCarrier    expr: |      sum by (carrier) (rate(proxy_requests_total{outcome="success"}[5m]))      /      sum by (carrier) (rate(proxy_requests_total[5m]))      < 0.90    for: 5m    labels:      severity: warning    annotations:      summary: "Success rate below 90 percent for carrier"

Níveis de severidade e roteamento

Nem todos os alertas são iguais. Separe-os por severidade:

  • Warning: algo desviou, vale olhar em horário comercial. Não acorda ninguém de madrugada.
  • Critical: usuários sofrendo agora, precisa de reação imediata. Acorda o plantonista.

Um conjunto razoável para começar inclui literalmente poucos alertas: queda crítica da taxa de sucesso geral, degradação da taxa de sucesso por recorte, aumento abrupto do p99 de latência, salto anômalo da taxa de retentativas. Nada mais. Cada novo alerta é uma promessa de que alguém vai reagir a ele. Não faça promessas que não conseguirá cumprir.

Orçamento de erros como moldura

Uma técnica avançada, em vez de limiares rígidos sobre valores instantâneos, é usar o orçamento de erros. Se sua meta é 99 por cento de requisições bem-sucedidas no mês, o orçamento de erros é aquele um por cento que você pode "gastar". O alerta sobre a velocidade de consumo do orçamento (burn rate) reage não ao fato de uma falha isolada, mas ao fato de você estar gastando o limite de erros permitido rápido demais. Esses alertas são bem mais tranquilos e refletem com mais precisão a ameaça real ao SLO.

Diagnóstico rápido pelo dashboard: três cenários típicos

Agora a parte mais interessante. Como entender em um minuto onde está a degradação? A resposta é treinar o olho em alguns padrões típicos. Um bom dashboard não é um amontoado de gráficos, é uma ferramenta de reconhecimento de padrões. Vejamos três cenários clássicos.

Cenário um: caiu um recorte, o resto está normal

Você olha a taxa de sucesso, dividida por operadora. O indicador geral caiu um pouco, mas ao olhar a quebra fica claro: uma operadora despencou para 50 por cento, as outras seguram 98. A latência no recorte problemático subiu, nas demais está estável.

O que isso significa: problema localizado no nível do nó ou da operadora. A causa não está no seu sistema nem no recurso de destino como um todo, mas num recorte específico do pool. Problema de transporte ou do próprio nó.

Primeira ação: tirar o recorte problemático da rotação ativa (isso já é área de quarentena, tema à parte) e seguir observando. Verificar se a degradação está ligada a uma região específica dentro da operadora.

Cenário dois: a latência subiu em todo lugar, mas não há erros

A taxa de sucesso está estável, perto de cem por cento. Mas o p95 e o p99 de latência subiram em todos os recortes ao mesmo tempo e de forma uniforme. A taxa de retentativas subiu de leve.

O que isso significa: quando degrada tudo de uma vez e de forma uniforme, procure um fator comum. Na maioria das vezes é a sua própria infraestrutura (sobrecarga, falta de recursos, gargalo no seu código) ou o recurso de destino passou a responder mais devagar para todos. Os nós de proxy não têm nada a ver com isso, senão a degradação seria desigual.

Primeira ação: olhar o TTFB separadamente. Se o TTFB subiu, é rede ou servidor. Se o TTFB está estável e o tempo total cresce, o problema está na transmissão ou no processamento do corpo. Verificar a carga do seu lado e as métricas do recurso de destino.

Cenário três: a taxa de retentativas cresce com a taxa de sucesso estável

A taxa de sucesso parece normal, perto de 97 por cento. Mas a taxa de retentativas subiu: era 3 por cento, virou 15. A latência também subiu, porque as retentativas adicionam tempo.

O que isso significa: esse é o padrão mais traiçoeiro, porque o resultado final ainda está na norma. Mas o sistema está trabalhando no limite: gasta cada vez mais tentativas repetidas para segurar a taxa de sucesso. É prenúncio de desabamento. Se a tendência continuar, as retentativas param de salvar e a taxa de sucesso despenca.

Primeira ação: não esperar a taxa de sucesso desabar. Descobrir em qual recorte as retentativas crescem (de novo, quebra por dimensões) e investigar a causa raiz antes que seja tarde. Verificar se as próprias retentativas não geram carga adicional que gira a espiral.

Montagem do dashboard para diagnóstico em um minuto

Para que esses padrões sejam lidos em um minuto, coloque na tela principal apenas quatro painéis, correspondentes aos quatro sinais, cada um com quebra rápida por dimensões:

  1. Taxa de sucesso: geral e com quebra por operadoras e países.
  2. Latência: p50, p95, p99 no mesmo gráfico, para ver a discrepância da cauda.
  3. Taxa de retentativas: tendência das últimas horas.
  4. Consumo de tráfego: por recortes, para pegar anomalias.

Todo o resto é secundário e vive em telas separadas. A tela principal precisa responder a uma pergunta: está tudo bem? Se não estiver, onde exatamente? Nada além disso.

Tabela de resposta rápida: métrica, seu aumento e primeira ação

Vale imprimir esta tabela e pendurar ao lado da estação de trabalho do plantonista. Ela transforma observação em ação sem rodeios.

Métrica: queda da taxa de sucesso (no pool inteiro)

O que significa: falha massiva, atingindo a maioria das requisições. Problema de nível sistêmico.
Primeira ação: verificar a sua própria infraestrutura e o recurso de destino, já que uma queda uniforme raramente vem de nós isolados.

Métrica: queda da taxa de sucesso (em um único recorte)

O que significa: degradação localizada de operadora, país ou tipo de proxy.
Primeira ação: localizar o recorte pela quebra e tirá-lo da rotação, observando a dinâmica.

Métrica: aumento do p99 de latência com p50 estável

O que significa: a cauda se alongou, parte das requisições ficou muito lenta, enquanto a requisição típica está na norma.
Primeira ação: achar o recorte com cauda crescente, verificar timeouts e nós que geram picos.

Métrica: aumento simultâneo e uniforme de p50 e p95

O que significa: degradação geral de desempenho, provavelmente infraestrutura ou recurso de destino.
Primeira ação: separar TTFB e tempo de transmissão do corpo, verificar a carga do seu lado.

Métrica: aumento da taxa de retentativas com taxa de sucesso estável

O que significa: o sistema mascara a degradação com repetições, prenúncio de desabamento.
Primeira ação: achar o recorte com aumento de retentativas e resolver a causa raiz antes do desabamento da taxa de sucesso.

Métrica: aumento anômalo do consumo de tráfego

O que significa: respostas inchadas, repetições a mais ou atividade não planejada.
Primeira ação: comparar o aumento de tráfego com o número de requisições e o tamanho das respostas, achar a origem.

Métrica: queda do consumo de tráfego a zero em um recorte ativo

O que significa: o recorte parou de atender requisições por completo.
Primeira ação: verificar a disponibilidade dos nós do recorte e a conectividade, escalar em caso de confirmação.

Erros típicos de observabilidade de proxies

A experiência de analisar dezenas de incidentes permite montar uma coleção de armadilhas em que se cai com mais frequência. Conhecer esses erros economiza meses de dor.

Erro 1: olhar a média em vez dos percentis

Já falamos disso, mas repetimos, porque o erro é difundidíssimo. O tempo médio de resposta não mostra o problema da cauda longa. A equipe vê a média estável e tem certeza de que está tudo bem, enquanto os usuários reclamam de travamentos. Sempre p95 e p99.

Erro 2: registrar segredos "temporariamente, para depurar"

O temporário tem o hábito de virar permanente. Um token registrado "por cinco minutos, para conferir" fica no sistema de armazenamento de logs por meses e entra nos backups. O mascaramento de segredos precisa ser regra rígida no nível da biblioteca de logging, e não decisão de cada desenvolvedor no momento.

Erro 3: explosão de cardinalidade dos rótulos

Rotular métricas por cada IP ou URL parece conveniente, até o sistema de monitoramento começar a engasgar e pedir cada vez mais recursos. Rótulos só para dimensões com conjunto limitado de valores. Detalhes vão para os logs.

Erro 4: alertas demais

A equipe, orgulhosa do seu monitoramento, configura quarenta alertas. Um mês depois, metade deles faz barulho, os plantonistas os silenciam nas notificações e, um dia, perdem um incidente de verdade, porque ele se perdeu no fluxo. Menos alertas, mas mais precisos.

Erro 5: alertas sem janela e sem histerese

O alerta dispara sobre um valor instantâneo e apaga na hora, depois dispara de novo. O tremelique das notificações irrita e desvaloriza o sistema. Janelas de observação e histerese são obrigatórias.

Erro 6: considerar sucesso apenas o código 200

Assim você ou subestima a taxa de sucesso, tratando respostas válidas como falha, ou, ao contrário, deixa passar problemas. Defina sucesso pelo contrato de uso, de forma criteriosa, e não mecanicamente por um único código.

Erro 7: ausência de quebra por dimensões

Um gráfico único de taxa de sucesso esconde problemas locais. Sem a quebra, você vê que "no geral está normal" e perde o recorte que caiu. A rotulagem não é opção, é necessidade.

Erro 8: ignorar as retentativas

Muitos nem contam a taxa de retentativas, confiando só na taxa de sucesso final. E perdem o prenúncio mais precoce. Na hora em que a taxa de sucesso cai, as retentativas já vinham gritando faz tempo.

Erro 9: armazenar percentis em vez de histogramas

Se você guarda p95 prontos por recorte, não consegue calcular corretamente o p95 geral, porque percentis não se somam. Guarde histogramas, calcule percentis na consulta.

Erro 10: dashboard como depósito

Cinquenta painéis na mesma tela não é observabilidade, é poluição visual. No momento do incidente, o olho se perde. A tela principal é minimalista, os detalhes ficam a um clique.

Ferramentas e recursos

A boa notícia: para uma observabilidade de qualidade em torno de um pool de proxies, não é preciso um stack caro e complexo. Vejamos o conjunto mínimo suficiente e a lógica de escolha.

Coleta e armazenamento de métricas

Para métricas, sistemas baseados em modelo de séries temporais com suporte a rótulos e histogramas funcionam muito bem. O requisito-chave é o suporte a histogramas para o cálculo correto de percentis e para rotulagem por dimensões sem explosão de cardinalidade. Esses sistemas permitem fazer consultas como "taxa de sucesso por operadora na última hora" na hora.

Visualização

Para dashboards, é preciso uma ferramenta que construa gráficos de séries temporais, sobreponha vários percentis no mesmo gráfico e troque rapidamente a quebra por dimensões. É importante ter filtros variáveis: escolheu uma operadora e todos os painéis se reconfiguram para ela. Isso acelera o diagnóstico em várias vezes.

Coleta e armazenamento de logs

Os logs de requisições precisam ser estruturados (JSON) e ir para um sistema que permita filtrar por campos: por identificador de proxy, por código de resposta, por recorte. Requisito obrigatório: política de retenção com exclusão automática após o prazo, para que dados sensíveis não se acumulem para sempre.

Alertas

O sistema de alertas precisa suportar janelas de observação (condição mantida por N minutos), níveis de severidade e roteamento por canais. Um ponto especialmente valioso é o suporte a alertas sobre a velocidade de consumo do orçamento de erros, para disparos tranquilos, mas precisos.

Bibliotecas para instrumentar o código

No código do cliente de proxy, use bibliotecas de métricas que suportem contadores e histogramas com rótulos. Envolva cada requisição em medição: registre o horário de início e, ao concluir, o resultado, a latência e o tráfego. A instrumentação precisa ser centralizada, num único lugar, para que um novo desenvolvedor não consiga deixá-la passar por acidente.

import timedef instrumented_request(client, url, meta):  start = time.monotonic()  attempt = meta["attempt"]  try:    resp = client.get(url)    elapsed = (time.monotonic() - start) * 1000    outcome = "success" if resp.status_code < 500 else "server_error"    record(meta["country"], meta["carrier"], meta["type"], outcome, elapsed)    log_request(meta, resp.status_code, elapsed, len(resp.content), attempt, outcome)    return resp  except TimeoutError:    elapsed = (time.monotonic() - start) * 1000    record(meta["country"], meta["carrier"], meta["type"], "timeout", elapsed)    log_request(meta, None, elapsed, 0, attempt, "timeout")    raise

Tendências de 2026

A indústria de observabilidade em 2026 caminha para algumas direções marcantes. Primeiro, a padronização da telemetria com base em protocolos abertos, o que simplifica a integração de métricas, logs e traces numa visão única. Segundo, o crescimento do interesse por histogramas exponenciais, que dão percentis precisos com gasto mínimo de memória. Terceiro, o uso de detecção automática de anomalias baseada em modelos estatísticos, complementando alertas por limiar, percebendo padrões incomuns para os quais não se define limiar de antemão. E quarto, o deslocamento do foco da quantidade de dados coletados para o sentido deles: menos métricas, mas as certas. É exatamente disso que falamos neste artigo.

Cases e resultados

Para dar corpo aos princípios, vejamos alguns cenários generalizados, construídos a partir da prática típica de operação de pools de proxies. Os números são ilustrativos, mas os padrões são reais.

Caso 1: degradação invisível de uma operadora

A equipe trabalhava com um pool de proxies móveis da Proxeon e se baseava na taxa de sucesso geral. O indicador se mantinha em torno de 96 por cento e não havia alarme. Ao mesmo tempo, usuários de uma das frentes reclamavam de falhas. Depois de implementar a quebra por operadora, o quadro ficou claro na hora: uma operadora dava taxa de sucesso de 62 por cento, as outras em torno de 99. O número geral mascarava o colapso de um recorte inteiro.

Resultado: depois de adicionar a rotulagem por operadora e um alerta de degradação por recorte, o tempo de detecção desses problemas caiu de várias horas (por reclamações) para poucos minutos (por alerta). O recorte problemático passou a ser retirado da rotação em tempo, e a taxa de sucesso geral da frente subiu para 98 por cento.

Caso 2: cauda longa escondida atrás da média

Outra equipe monitorava a latência média, que se mantinha em confortáveis 240 milissegundos. Reclamações periódicas de "travamentos" eram creditadas a caprichos. A migração para percentis abriu os olhos: o p50 realmente estava em torno de 190 milissegundos, mas o p99 chegava a 8 segundos. Cada centésima requisição era penosamente lenta.

Resultado: depois que a equipe passou a acompanhar o p99 e configurou um alerta para seu crescimento, descobriu que a cauda era gerada por requisições a um determinado grupo de nós em horários de pico. O problema foi localizado pela quebra. O p99 caiu para 1,2 segundo, e o número de reclamações de travamentos caiu praticamente a zero.

Caso 3: a espiral de retentativas

O terceiro cenário é exemplar pela sua periculosidade. O sistema, com política agressiva de repetições, mantinha a taxa de sucesso em torno de 97 por cento, e tudo parecia estável. Mas ninguém acompanhava a taxa de retentativas. Um dia, com um pequeno pico de carga, a taxa de retentativas subiu de 5 para 40 por cento em meia hora. As requisições repetidas adicionaram carga, os nós sobrecarregaram mais, as retentativas aumentaram ainda mais, a clássica espiral. Em uma hora, a taxa de sucesso desabou para 60 por cento.

Resultado: a análise do incidente levou à implementação de uma métrica separada de taxa de retentativas e de um alerta precoce para seu crescimento. Agora, ao atingir o limiar de retentativas, a equipe recebe o aviso bem antes do desabamento da taxa de sucesso. Situações semelhantes passaram a ser capturadas na fase de prenúncio, sem chegar à pane. É a ilustração clara de por que as retentativas merecem lugar entre os quatro sinais principais.

Conclusão geral dos cases

Três histórias, três problemas diferentes, mas uma só regularidade. Em todos os casos, os dados para a detecção existiam fisicamente no sistema, mas não estavam apresentados de forma que o problema ficasse visível. Quebra por dimensões, percentis em vez de média e atenção às retentativas não são recomendações abstratas. São lentes concretas, cada uma tornando visível uma classe de problema.

FAQ: perguntas frequentes sobre observabilidade de proxies

Por onde começar, se hoje não existe absolutamente nada?

Comece registrando cada requisição de forma estruturada, com campos obrigatórios: identificador do proxy, código de resposta, TTFB, tamanho, número da tentativa, dimensões. Mesmo sem métricas e dashboards, isso já dará a você a possibilidade de investigar incidentes. O passo seguinte é adicionar as quatro métricas e um ou dois alertas críticos. Não tente construir tudo de uma vez: um conjunto mínimo que funciona vale mais que um ideal inacabado.

Com que frequência coletar as métricas?