Contenido del artículo

Imagina una mañana típica de un ingeniero de guardia. En el chat aparece un mensaje: "Todo nos está yendo lento". ¿Qué exactamente va lento? ¿Todo el pool o un segmento específico? ¿Los proxies de un país concreto o los de un operador específico? ¿Responde lento el sitio objetivo o crece la cola de reintentos? Sin números, esto no es un incidente, es adivinar el futuro en una bola de cristal. Y mientras el equipo adivina, el tiempo pasa y el dinero se escapa.

Este artículo trata sobre cómo convertir la vaga sensación de "va lento" en un diagnóstico preciso en un minuto. Vamos a desglosar qué métricas recolectar alrededor del pool de proxies, qué escribir en los logs por cada solicitud y qué no escribir bajo ninguna circunstancia, por qué los percentiles son más importantes que el promedio, cómo etiquetar los datos por dimensiones y cómo configurar alertas que no te despierten por falsos positivos. Al final encontrarás una tabla de respuesta rápida y un FAQ práctico.

Una aclaración importante sobre los límites del tema. Aquí hablamos únicamente de medición y notificación. La selección de una IP específica para una solicitud, el health-check de los nodos y la lógica de cuarentena dentro del pool son un tema aparte y extenso, al que dedicamos un material separado. Aquí nuestra tarea es más concreta: ver la degradación, localizarla y levantar la alarma a tiempo. En los ejemplos se usa la infraestructura de Proxeon, pero los principios son universales.

Fundamentos: qué es la observabilidad y por qué los proxies la exigen con especial urgencia

Empecemos por lo básico. La observabilidad es la propiedad de un sistema que permite, a partir de sus datos de salida externos, entender su estado interno sin necesidad de meterse dentro con un depurador. La tríada clásica de la observabilidad: métricas, logs y trazas. Las métricas responden a la pregunta "qué está pasando" en agregado, los logs a la pregunta "qué le pasó exactamente a una solicitud concreta", las trazas a la pregunta "cómo recorrió la solicitud toda la cadena".

¿En qué se diferencian los proxies de un servicio web normal? En que tienes un tercero al que no controlas por completo: el propio nodo proxy, el canal hacia él y el recurso objetivo detrás. Una aplicación normal se puede perfilar hasta la última función. Pero el proxy añade una capa de incertidumbre de red, donde la degradación puede venir de cualquier lado: del operador de telecomunicaciones, del enrutamiento, de la sobrecarga de un nodo específico, del comportamiento cambiado del sitio objetivo.

Por eso la observabilidad alrededor del pool de proxies no es un lujo, es higiene. Sin ella trabajas a ciegas. Con ella ves la estructura del problema: no "todo está mal", sino "se degradó el segmento de proxies móviles de un operador en una región, el resto está en orden". Esa es la diferencia entre el pánico y la precisión quirúrgica.

Tres niveles donde viven los problemas

Es útil tener en mente desde el principio tres niveles donde nace la degradación:

  • Nivel de transporte: canal hacia el proxy, pérdida de paquetes, tiempo de establecimiento de conexión. Aquí viven los timeouts y el TTFB lento.
  • Nivel de nodo proxy: sobrecarga de una IP concreta, agotamiento de límites, problemas del operador. Aquí vive el aumento de la tasa de errores en un segmento específico.
  • Nivel de recurso objetivo: el sitio empezó a responder más lento, devolvió códigos no estándar, cambió los límites. Aquí es importante no confundir un problema del sitio con un problema del pool.

Un buen sistema de observabilidad permite entender de un vistazo en cuál de los tres niveles está el problema. Esa es precisamente la "medida justa hasta el diagnóstico" por la que hacemos todo esto.

Cuatro señales para proxies: por qué precisamente estas

Existe la tentación de recolectar todo lo que se pueda. Cientos de métricas, decenas de dashboards, kilómetros de gráficos. Es una trampa. Muchas métricas significan ruido, y el ruido significa que en el momento del incidente no vas a encontrar lo necesario. La práctica ingenieril experimentada dice lo contrario: empieza con un conjunto mínimo de señales que cubra la mayoría de los problemas. Para un pool de proxies, esas señales son cuatro.

Primera señal: tasa de solicitudes exitosas

La tasa de solicitudes exitosas (success rate) es el porcentaje de solicitudes que terminaron como se esperaba, del total. Es el principal indicador de salud. Si el success rate cae, algo se rompió justo ahora y justo en el usuario.

La pregunta clave: ¿qué se considera éxito? La respuesta ingenua "código 200" es incorrecta. Lo más adecuado es definir el éxito a través del contrato de tu uso. A menudo se considera éxito todos los códigos 2xx y 3xx, así como los 4xx significativos, que son una respuesta válida del recurso objetivo y no un problema del proxy. Pero los timeouts, las caídas de conexión, los errores a nivel de proxy y los 5xx masivos son un fracaso.

Formalmente, el success rate pertenece a la familia de métricas de "disponibilidad" en el modelo SLI (Service Level Indicator). Es precisamente el indicador sobre el que después se construyen los SLO (objetivos de nivel de servicio) y el presupuesto de errores.

Segunda señal: latencia por percentiles

La latencia es el tiempo desde el envío de la solicitud hasta la recepción de la respuesta. Pero un solo número de latencia no tiene sentido. Se necesitan percentiles: p50, p95, p99. Por qué precisamente percentiles y no el promedio lo veremos en detalle en una sección aparte, porque es uno de los temas más subestimados de todo el monitoreo.

Para proxies es especialmente valioso el TTFB (Time To First Byte, tiempo hasta el primer byte). Separa la latencia de red y el tiempo de reacción del servidor del tiempo de transferencia del cuerpo de la respuesta. Si crece el TTFB, es un problema de red o del nodo. Si crece el tiempo total pero el TTFB se mantiene estable, posiblemente simplemente crecieron las respuestas o cayó el ancho de banda del canal.

Tercera señal: tasa de reintentos

La tasa de reintentos (retry rate) es el porcentaje de solicitudes que requirieron un intento adicional. Es un precursor temprano del desastre. A menudo el success rate todavía está bien, porque los reintentos sostienen la situación, pero la tasa de reintentos ya empezó a subir. Es como una temperatura de 37.2: formalmente todavía trabajas, pero el organismo ya está luchando.

Los reintentos enmascaran la degradación para el usuario final, pero devoran recursos: tiempo, tráfico, capacidad del pool. Ignorar esta señal es peligroso por partida doble, porque el crecimiento de reintentos puede derrumbar el sistema en avalancha, cuando las solicitudes repetidas añadan carga a los nodos ya sobrecargados.

Cuarta señal: consumo de tráfico

El consumo de tráfico (bandwidth) es el volumen de datos transferidos. ¿Por qué está entre las cuatro principales? Primero, es dinero directo, porque el tráfico se factura. Segundo, un consumo anómalo es una señal: un crecimiento repentino puede significar que alguien está tirando de algo de más, que las respuestas se inflaron o que los reintentos dan vueltas a los mismos datos. Una caída repentina a cero en un segmento donde normalmente hay actividad significa que el segmento simplemente dejó de funcionar.

Estas cuatro señales no son casuales. Se relacionan con la metodología de los "signals dorados" de la observabilidad, popularizada por ingenieros de confiabilidad: latencia, tráfico, errores, saturación. La adaptamos a las particularidades de los proxies, donde los reintentos merecen un lugar aparte como precursor único de esta área.

Inmersión profunda: qué escribir en el log por cada solicitud

Las métricas muestran tendencias. Pero cuando hay que entender qué le pasó a una solicitud concreta, los logs salvan la situación. Un log de solicitud bien diseñado es tu caja negra a la que recurres al analizar un incidente. Desglosemos qué escribir obligatoriamente y qué no se puede escribir nunca.

Qué escribir obligatoriamente

  • Identificador del proxy: no la IP en claro, sino un identificador estable del nodo o del pool. Esto permite vincular la solicitud con un recurso concreto y ver qué nodos están dando problemas.
  • Código de respuesta: el estado HTTP o el código de error de transporte (timeout, rechazo de conexión, caída). Es la base para calcular el success rate.
  • Tiempo hasta el primer byte (TTFB): en milisegundos. Uno de los indicadores más informativos para localizar problemas de red.
  • Tiempo total de la solicitud: desde el inicio hasta la finalización, también en milisegundos.
  • Tamaño de la respuesta: en bytes. Alimenta la métrica de tráfico y ayuda a notar respuestas anormalmente grandes o vacías.
  • Número de intento: si es el primero o ya un reintento, y cuál en la cuenta. Sin este campo es imposible calcular la tasa de reintentos.
  • Dimensiones para el etiquetado: país, operador, tipo de proxy. Sobre ellas hay una sección aparte, pero en el log deben estar.
  • Marca temporal e identificador de traza: para vincular los registros entre sí y con sistemas externos.

Así puede verse una entrada de log estructurada en formato JSON. Fíjate: es legible por máquina, lo cual es crítico para el análisis 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"}

Qué NO se puede escribir NUNCA

Esto no es menos importante que lo que sí hay que escribir. Los logs tienen la propiedad de filtrarse, copiarse a sistemas analíticos, caer en copias de respaldo. Todo lo que pongas ahí vive mucho tiempo y en lugares inesperados.

  • Credenciales (creds): logins, contraseñas, tokens de autorización al proxy, claves API. Nunca. Ni parcialmente. Ni "temporalmente para depurar".
  • El cuerpo de la respuesta completo: primero, es un volumen gigantesco; segundo, ahí puede haber datos personales y sensibles. Escribe solo el tamaño y, si es necesario, un hash o una firma corta.
  • Cabeceras con secretos: Authorization, Cookie, Set-Cookie y similares. Hay que limpiarlas antes de escribir.
  • URLs completas con parámetros sensibles: si en el query-string hay tokens o identificadores personales, hay que enmascararlos.
  • Datos personales de usuarios: todo lo que entre en el ámbito de la legislación sobre datos personales debe o no llegar al log, o anonimizarse.

Una técnica práctica de enmascaramiento en la etapa de formación del 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

Regla de oro: el log debe permitir diagnosticar el problema, pero no debe convertirse en una base de secretos filtrados. Si dudas si escribir un campo, no lo escribas. El valor diagnóstico casi siempre se puede obtener a través de sustitutos seguros: hashes, tamaños, banderas, categorías.

Percentiles en lugar del promedio: por qué el promedio oculta el problema

Esta es una sección que vale la pena releer dos veces. Porque aquí se esconde el error más común y más traicionero del monitoreo de rendimiento.

Por qué el promedio miente

Imagina: tienes cien solicitudes. Noventa y nueve de ellas se completaron en 100 milisegundos, y una en 10 segundos. El tiempo promedio será de unos 199 milisegundos. Se ve excelente, casi nada cambió. Mientras tanto, uno de tus usuarios esperó diez segundos y, muy probablemente, ya se fue, maldiciendo.

El promedio es un aparato que diluye los valores atípicos a lo largo de toda la muestra. Es sensible a los extremos, pero insensible a la estructura de la distribución. Y el rendimiento de los sistemas de red casi siempre tiene una distribución de cola larga: la mayoría de las solicitudes son rápidas, pero hay una minoría muy lenta. Y es precisamente esa cola la que determina la experiencia real del usuario y la presencia de problemas.

Qué son los percentiles y cómo leerlos

Un percentil es el valor por debajo del cual queda un porcentaje dado de observaciones. Veamos los tres principales:

  • p50 (mediana): la mitad de las solicitudes son más rápidas que este valor, la mitad más lentas. Es la experiencia "típica".
  • p95: el 95 por ciento de las solicitudes caben en este tiempo. Es la experiencia "casi del peor caso", que afecta a una parte notable de los usuarios.
  • p99: el 99 por ciento de las solicitudes son más rápidas. Es esa cola larga donde viven los timeouts, los reintentos y los usuarios furiosos.

En nuestro ejemplo con cien solicitudes, p50 y p95 se quedarán en unos 100 milisegundos, pero p99 saltará a 10 segundos. El percentil mostró honestamente el problema que el promedio escondió. Por eso los ingenieros experimentados miran primero p95 y p99, y casi no usan el promedio para evaluar la latencia.

Cómo calcular percentiles correctamente

El método ingenuo: recolectar todos los valores, ordenarlos y tomar la posición necesaria. Es exacto, pero no escala: con millones de solicitudes, almacenar todo el arreglo es imposible. En la práctica se usan estructuras de cálculo aproximado: histogramas con intervalos fijos o algoritmos especiales como t-digest y histogramas HDR.

La idea del histograma es simple: defines de antemano los rangos (buckets) de tiempo y simplemente cuentas cuántas solicitudes cayeron en cada uno. A partir de los contadores acumulados es fácil reconstruir cualquier percentil con precisión aceptable, y la memoria se gasta de forma fija.

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]

Una advertencia importante sobre la agregación. Los percentiles no se pueden promediar. Si tienes p95 en diez nodos, no puedes tomar el promedio de esos p95 y llamar al resultado p95 general. Eso es matemáticamente incorrecto. Para una agregación correcta hay que sumar los histogramas y ya a partir del histograma total calcular el percentil. Por eso los sistemas de monitoreo modernos almacenan histogramas, y no percentiles ya listos.

Etiquetado por dimensiones: ver el segmento, no el pool completo

Aquí es donde la observabilidad se convierte de un gráfico en una herramienta de diagnóstico. Una sola cifra de success rate de todo el pool te dice poco. Puede ser del 97 por ciento y verse normal, ocultando que un segmento cayó al 40 por ciento mientras los demás sostienen el promedio.

Tres dimensiones clave para proxies

  • País (country): la geografía del proxy. La degradación a menudo está localizada geográficamente: un problema de enrutamiento en una región, cambios del lado del recurso objetivo para ciertos países.
  • Operador (carrier): para los proxies móviles de Proxeon, esta es una dimensión críticamente importante. Un problema en un operador de telecomunicaciones específico se manifestará precisamente aquí, y entenderás de inmediato su magnitud.
  • Tipo de proxy (proxy_type): móviles, de servidor, residenciales. Distintos tipos se comportan de forma diferente, y la degradación de un tipo no debe perderse en la masa general.

Cardinalidad: dónde detenerse

Existe la tentación de etiquetar los datos por todo: por cada IP, por cada dominio objetivo, por cada usuario. Esto lleva a una explosión de cardinalidad: la cantidad de combinaciones únicas de etiquetas. La alta cardinalidad mata a los sistemas de monitoreo: crece el volumen de almacenamiento, se ralentizan las consultas, se encarece la infraestructura.

Regla práctica: etiqueta por dimensiones con un conjunto de valores limitado y estable. Los países son decenas, los operadores unidades o decenas, los tipos de proxy unidades. Eso es seguro. Pero una IP individual o una URL completa como etiqueta en métricas no se pueden usar: son únicos en cantidades enormes. Esos detalles son lugar para los logs, donde se almacenan línea por línea, y no en las métricas, donde multiplican las series de datos.

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)

Con ese etiquetado puedes construir en segundos una consulta: muestra el success rate por operadores de la última hora. Y ver de inmediato que no se degradó todo el pool, sino un segmento. Esa es la localización. La belleza de este enfoque está en que convierte el pánico "todo se rompió" en un tranquilo "el segmento X del operador Y requiere atención".

Alertas que no hacen ruido

La causa más frecuente por la que los equipos dejan de confiar en el monitoreo son las alertas ruidosas. Cuando el sistema te despierta cinco veces por noche por falsos positivos, muy pronto empezarás a ignorarlo. Y luego te perderás un incidente real. Esto se llama fatiga de alertas, y mata la observabilidad más eficazmente que la ausencia total de monitoreo.

Tres principios de las alertas silenciosas

Primer principio: umbrales sobre síntomas, no sobre causas. Hay que alertar sobre lo que siente el usuario: caída del success rate, crecimiento del p99 de latencia. No sobre fluctuaciones técnicas intermedias que por sí solas no significan un problema.

Segundo principio: ventanas de observación. No reacciones a un pico aislado. Una solicitud lenta es ruido. Una desviación sostenida a lo largo de una ventana de tiempo es una señal. Configura la alerta para que se dispare cuando la condición se mantiene, por ejemplo, cinco minutos seguidos, y no en un solo instante.

Tercer principio: histéresis. Este es un término prestado de la ingeniería que significa umbrales distintos para disparar y para desactivar. La alerta se enciende cuando el success rate cae por debajo del 90 por ciento, pero se apaga solo cuando sube por encima del 95. El intervalo entre los umbrales evita el "castañeteo", cuando la métrica oscila alrededor de un valor y la alerta parpadea encendiéndose y apagándose.

Ejemplo de configuración de alerta

Aquí tienes un ejemplo de regla en un estilo comprensible para la mayoría de los sistemas de monitoreo. Se dispara si la tasa de solicitudes exitosas en cualquier segmento de operador se mantiene por debajo del umbral durante la ventana de observación.

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"

Niveles de gravedad y enrutamiento

No todas las alertas son iguales. Divídelas por gravedad:

  • Warning: algo se desvió, vale la pena mirar en horario laboral. No te despierta por la noche.
  • Critical: los usuarios están sufriendo ahora mismo, se necesita reacción inmediata. Despierta al de guardia.

Un conjunto razonable para empezar incluye literalmente unas pocas alertas: caída crítica del success rate general, degradación del success rate por segmento, crecimiento brusco del p99 de latencia, salto anómalo de la tasa de reintentos. No más. Cada nueva alerta es una promesa de que alguien va a responder a ella. No hagas promesas que no puedas cumplir.

El presupuesto de errores como marco

Una técnica avanzada, en lugar de umbrales rígidos sobre valores instantáneos, es usar el presupuesto de errores. Si tu objetivo es el 99 por ciento de solicitudes exitosas al mes, el presupuesto de errores es ese mismo uno por ciento que puedes "gastar". La alerta sobre la velocidad de gasto del presupuesto (burn rate) reacciona no al hecho de un fallo aislado, sino a que estás gastando el límite admisible de errores demasiado rápido. Esas alertas son mucho más tranquilas y reflejan con más precisión la amenaza real para el SLO.

Diagnóstico rápido por el dashboard: tres imágenes típicas

Ahora lo más interesante. ¿Cómo entender en un minuto dónde está la degradación? La respuesta está en entrenar el ojo para varios patrones típicos. Un buen dashboard no es un vertedero de gráficos, sino una herramienta de reconocimiento de imágenes. Veamos tres imágenes clásicas.

Primera imagen: cayó un segmento, el resto está en orden

Miras el success rate desglosado por operadores. El indicador general bajó un poco, pero al mirar el desglose se ve: un operador se derrumbó al 50 por ciento, los demás mantienen el 98. La latencia en el segmento problemático creció, en los demás está estable.

Qué significa: problema localizado a nivel de nodo u operador. La causa no está en tu sistema ni en el recurso objetivo en general, sino en un segmento concreto del pool. Problema de transporte o del propio nodo.

Primera acción: sacar el segmento problemático de la rotación activa (esto ya es el área de cuarentena, tema aparte) y seguir observando. Verificar si la degradación está relacionada con una región concreta dentro del operador.

Segunda imagen: creció la latencia en todas partes, pero no hay errores

El success rate está estable, cerca del cien por ciento. Pero p95 y p99 de latencia crecieron en todos los segmentos simultáneamente y de forma uniforme. La tasa de reintentos subió de forma insignificante.

Qué significa: cuando todo se degrada a la vez y de forma uniforme, busca el factor común. Lo más frecuente es que sea tu propia infraestructura (sobrecarga, falta de recursos, cuello de botella en tu código), o que el recurso objetivo empezó a responder más lento para todos. Los nodos proxy no tienen nada que ver aquí, de lo contrario la degradación sería desigual.

Primera acción: mirar el TTFB por separado. Si creció el TTFB, es red o servidor. Si el TTFB está estable y el tiempo total crece, el problema está en la transferencia o el procesamiento del cuerpo. Verificar la carga de tu lado y las métricas del recurso objetivo.

Tercera imagen: crece la tasa de reintentos con success rate estable

El success rate se ve bien, alrededor del 97 por ciento. Pero la tasa de reintentos empezó a subir: era del 3 por ciento, ahora es del 15. La latencia también subió, porque los reintentos añaden tiempo.

Qué significa: este es el patrón más traicionero, porque el resultado final todavía está en orden. Pero el sistema trabaja al límite: gasta cada vez más intentos repetidos para sostener el success rate. Es un precursor de un derrumbe. Si la tendencia continúa, los reintentos dejarán de salvar la situación y el success rate se derrumbará.

Primera acción: no esperar a que el success rate se derrumbe. Encontrar en qué segmento crecen los reintentos (de nuevo el desglose por dimensiones) y entender la causa raíz antes de que sea tarde. Verificar si los propios reintentos están creando carga adicional que desenrolla la espiral.

Composición del dashboard para el diagnóstico en un minuto

Para que estos patrones se lean en un minuto, coloca en la pantalla principal solo cuatro paneles, correspondientes a las cuatro señales, y cada uno con opción de desglose rápido por dimensiones:

  1. Success rate: general y desglosado por operadores y países.
  2. Latencia: p50, p95, p99 en un mismo gráfico, para ver la diferencia de la cola.
  3. Tasa de reintentos: tendencia de las últimas horas.
  4. Consumo de tráfico: por segmentos, para detectar anomalías.

Todo lo demás es secundario y vive en pantallas aparte. La pantalla principal debe responder a una sola pregunta: ¿todo está en orden?, y si no, ¿dónde exactamente? Nada de más.

Tabla de respuesta rápida: métrica, su crecimiento y primera acción

Vale la pena imprimir esta tabla y colgarla junto al puesto de trabajo del de guardia. Convierte la observación en acción sin cavilaciones innecesarias.

Métrica: caída de la tasa de solicitudes exitosas (en todo el pool)

Qué significa: fallo masivo que afecta a la mayoría de las solicitudes. Problema de nivel sistémico.
Primera acción: verificar tu propia infraestructura y el recurso objetivo, ya que una caída uniforme rara vez viene de nodos individuales.

Métrica: caída de la tasa de solicitudes exitosas (en un segmento)

Qué significa: degradación localizada de un operador, país o tipo de proxy.
Primera acción: localizar el segmento por el desglose y sacarlo de la rotación, observando la dinámica.

Métrica: crecimiento del p99 de latencia con p50 estable

Qué significa: se alargó la cola, parte de las solicitudes se volvió muy lenta, mientras que la solicitud típica está en orden.
Primera acción: encontrar el segmento con la cola creciente, verificar los timeouts y los nodos que dan picos.

Métrica: crecimiento de p50 y p95 simultáneo y uniforme

Qué significa: degradación general del rendimiento, probablemente infraestructura o recurso objetivo.
Primera acción: separar el TTFB y el tiempo de transferencia del cuerpo, verificar la carga de tu lado.

Métrica: crecimiento de la tasa de reintentos con success rate estable

Qué significa: el sistema enmascara la degradación con repeticiones, precursor de un derrumbe.
Primera acción: encontrar el segmento con crecimiento de reintentos y eliminar la causa raíz antes del derrumbe del success rate.

Métrica: crecimiento anómalo del consumo de tráfico

Qué significa: respuestas infladas, repeticiones de más o actividad no planificada.
Primera acción: relacionar el crecimiento de tráfico con el número de solicitudes y el tamaño de las respuestas, encontrar la fuente.

Métrica: caída del consumo de tráfico a cero en un segmento activo

Qué significa: el segmento dejó de atender solicitudes por completo.
Primera acción: verificar la disponibilidad de los nodos del segmento y la conectividad, escalar si se confirma.

Errores típicos de la observabilidad de proxies

La experiencia de analizar decenas de incidentes permite armar una colección de rastrillos en los que se pisa con más frecuencia. Conocer estos errores ahorra meses de dolor.

Error 1: mirar el promedio en lugar de los percentiles

Ya lo analizamos, pero lo repetimos, porque el error es tan común. El tiempo de respuesta promedio no muestra los problemas de la cola larga. El equipo ve un promedio estable y está seguro de que todo va bien, hasta que los usuarios se quejan de cuelgues. Siempre p95 y p99.

Error 2: loguear secretos "temporalmente para depurar"

Lo temporal tiene la propiedad de volverse permanente. Un token, logueado "cinco minutos para verificar", se asienta en el sistema de almacenamiento de logs durante meses y cae en los backups. El enmascaramiento de secretos debe ser una regla rígida a nivel de la biblioteca de logging, y no la decisión de cada desarrollador en el momento.

Error 3: explosión de cardinalidad de etiquetas

Etiquetar las métricas por cada IP o URL parece conveniente, hasta que el sistema de monitoreo empieza a ahogarse y a exigir cada vez más recursos. Etiquetas solo para dimensiones con un conjunto de valores limitado. Los detalles en los logs.

Error 4: demasiadas alertas

El equipo, orgulloso de su monitoreo, configura cuarenta alertas. Al mes, la mitad de ellas hace ruido, los de guardia las apagan en las notificaciones, y un día se pierden un incidente real, porque se perdió en el flujo. Menos alertas, pero más precisas.

Error 5: alertas sin ventana ni histéresis

La alerta se dispara con el valor instantáneo y se apaga enseguida, luego se dispara de nuevo. El castañeteo de notificaciones irrita y devalúa el sistema. Las ventanas de observación y la histéresis son obligatorias.

Error 6: considerar éxito solo el código 200

Así o subestimas el success rate, considerando un fracaso respuestas válidas, o, al contrario, dejas pasar problemas. Define el éxito a través del contrato de uso de forma sensata, y no mecánicamente por un solo código.

Error 7: falta de desglose por dimensiones

Un solo gráfico general de success rate esconde problemas locales. Sin desglose ves que "en general está bien" y te pierdes un segmento caído. El etiquetado no es una opción, es una necesidad.

Error 8: ignorar los reintentos

Muchos ni siquiera cuentan la tasa de reintentos, confiando solo en el success rate final. Y pierden el precursor más temprano. Para cuando el success rate cae, los reintentos ya llevaban mucho tiempo gritando sobre el problema.

Error 9: almacenar percentiles en lugar de histogramas

Si guardas p95 ya listos por segmentos, no podrás calcular correctamente el p95 general, porque los percentiles no se suman. Guarda histogramas, calcula percentiles al consultar.

Error 10: el dashboard como vertedero

Cincuenta paneles en una pantalla no es observabilidad, es ruido informativo. En el momento del incidente, el ojo se pierde. La pantalla principal es minimalista, los detalles por clic.

Herramientas y recursos

La buena noticia: para una observabilidad de calidad alrededor del pool de proxies no se necesita un stack caro y complejo. Veamos el conjunto mínimamente suficiente y la lógica de elección.

Recolección y almacenamiento de métricas

Para las métricas son excelentes los sistemas basados en el modelo de series temporales con soporte de etiquetas e histogramas. El requisito clave es el soporte de histogramas para el cálculo correcto de percentiles y el etiquetado por dimensiones sin explosión de cardinalidad. Esos sistemas permiten hacer consultas del tipo "success rate por operadores en la última hora" al vuelo.

Visualización

Para los dashboards se necesita una herramienta capaz de construir gráficos de series temporales, superponer varios percentiles en un mismo gráfico y cambiar rápidamente el desglose por dimensiones. Es importante la posibilidad de hacer filtros variables: elegiste un operador y todos los paneles se reconstruyeron bajo él. Eso acelera el diagnóstico varias veces.

Recolección y almacenamiento de logs

Los logs de solicitudes deben ser estructurados (JSON) y llegar a un sistema que permita filtrar por campos: por identificador de proxy, por código de respuesta, por segmento. Requisito obligatorio: una política de almacenamiento con eliminación automática al vencer el plazo, para que los datos sensibles no se acumulen eternamente.

Alerting

El sistema de alertas debe soportar ventanas de observación (la condición se mantiene N minutos), niveles de gravedad y enrutamiento por canales. Aparte, es valioso el soporte de alertas sobre la velocidad de gasto del presupuesto de errores para disparos tranquilos pero precisos.

Bibliotecas para instrumentar el código

En el código del cliente proxy usa bibliotecas de métricas que soporten contadores e histogramas con etiquetas. Envuelve cada solicitud en una medición: fija el tiempo de inicio, al finalizar registra el resultado, la latencia y el tráfico. La instrumentación debe ser centralizada, en un solo lugar, para que un nuevo desarrollador no pueda pasarla por alto accidentalmente.

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

Tendencias de 2026

La industria de la observabilidad en 2026 avanza hacia varias direcciones notables. Primero, la estandarización de la telemetría basada en protocolos abiertos, que simplifica la integración de métricas, logs y trazas en una imagen única. Segundo, el creciente interés por los histogramas exponenciales, que dan percentiles precisos con un gasto mínimo de memoria. Tercero, la aplicación de la detección automática de anomalías basada en modelos estadísticos, que complementa las alertas por umbral, notando patrones inusuales para los que no se puede fijar un umbral de antemano. Y cuarto, el desplazamiento del foco de la cantidad de datos recolectados a su sentido: menos métricas, pero correctas. Esto es exactamente lo que decimos en este artículo.

Casos y resultados

Para que los principios cobren carne, veamos varios escenarios generalizados, construidos sobre la práctica típica de explotación de pools de proxies. Las cifras son ilustrativas, pero los patrones son reales.

Caso 1: degradación invisible de un operador

El equipo trabajaba con un pool de proxies móviles de Proxeon y se apoyaba en el success rate general. El indicador se mantenía cerca del 96 por ciento, no había alarma. Mientras tanto, los usuarios de una de las direcciones se quejaban de fallos. Tras implementar el desglose por operadores, el panorama se aclaró al instante: un operador daba un success rate del 62 por ciento, los demás cerca del 99. La cifra general enmascaraba el derrumbe de todo un segmento.

Resultado: tras añadir el etiquetado por operadores y una alerta sobre la degradación por segmento, el tiempo de detección de problemas similares se redujo de varias horas (por quejas) a varios minutos (por alerta). El segmento problemático empezó a sacarse de la rotación a tiempo, y el success rate general de la dirección subió al 98 por ciento.

Caso 2: la cola larga escondida tras el promedio

Otro equipo monitoreaba la latencia promedio, que se mantenía en unos cómodos 240 milisegundos. Las quejas periódicas por "cuelgues" se achacaban a caprichos. El paso a los percentiles abrió los ojos: p50 efectivamente estaba en unos 190 milisegundos, pero p99 alcanzaba los 8 segundos. Cada centésima solicitud era terriblemente lenta.

Resultado: tras empezar a vigilar el p99 y configurar una alerta sobre su crecimiento, descubrieron que la cola la generaban solicitudes a un grupo concreto de nodos en horas de carga pico. El problema se localizó por el desglose. El p99 se logró reducir a 1.2 segundos, y el número de quejas por cuelgues cayó prácticamente a cero.

Caso 3: la espiral de reintentos

El tercer escenario es demostrativo por su peligro. Un sistema con una política agresiva de repeticiones sostenía el success rate cerca del 97 por ciento, y todo parecía estable. Pero nadie vigilaba la tasa de reintentos. Un día, con un pequeño pico de carga, la tasa de reintentos en media hora creció del 5 al 40 por ciento. Las solicitudes repetidas añadieron carga, los nodos se sobrecargaron más, los reintentos aumentaron aún más: la clásica espiral. Al cabo de una hora, el success rate se derrumbó al 60 por ciento.

Resultado: el análisis del incidente llevó a la implementación de una métrica aparte de la tasa de reintentos y de una alerta temprana sobre su crecimiento. Ahora, al alcanzar el umbral de reintentos, el equipo recibe una advertencia mucho antes del derrumbe del success rate. Situaciones similares empezaron a detectarse en la etapa de precursor, sin llegar a la avería. Es una ilustración vívida de por qué los reintentos merecen un lugar entre las cuatro señales principales.

Conclusión general de los casos

Tres historias, tres problemas distintos, pero una misma regularidad. En todos los casos los datos para la detección existían físicamente en el sistema, pero no estaban presentados de modo que el problema se hiciera visible. El desglose por dimensiones, los percentiles en lugar del promedio y la atención a los reintentos no son recomendaciones abstractas. Son lentes concretas, cada una de las cuales hace visible su propia clase de problemas.

FAQ: preguntas frecuentes sobre la observabilidad de proxies

¿Por dónde empezar si ahora no hay absolutamente nada?

Empieza por loguear cada solicitud de forma estructurada con campos obligatorios: identificador del proxy, código de respuesta, TTFB, tamaño, número de intento, dimensiones. Incluso sin métricas ni dashboards, esto ya te dará la posibilidad de analizar incidentes. El siguiente paso es añadir cuatro métricas y una o dos alertas críticas. No intentes construirlo todo de golpe: un conjunto mínimo funcional vale más que uno ideal a medio terminar.

¿Con qué frecuencia tomar las métricas?