Disponibilidad de API desde diferentes países: 5 métricas que solo ve una IP externa

Si su monitoreo de API se ejecuta en un servidor en un solo centro de datos, solo verá una parte del panorama. Un usuario en Brasil puede recibir un error 500, mientras que su tablero en Moscú muestra un estado verde de "todo funciona". Analizaremos qué 5 métricas de disponibilidad no se pueden medir sin una solicitud a través de una IP externa real de otro país, y cómo hacerlo sin una infraestructura complicada.

Por qué el monitoreo local engaña

La mayoría de los equipos configuran el monitoreo de API a través de UptimeRobot, Pingdom o un script cron propio que hace ping a un endpoint una vez por minuto. El problema es que estas solicitudes casi siempre provienen de una o dos regiones, generalmente de EE. UU. o Europa, donde se encuentran los servidores de los servicios de monitoreo. Si su audiencia está en India, Brasil o el Sudeste Asiático, los proveedores locales pueden estar limitando el tráfico, el nodo de CDN puede estar sobrecargado, y el DNS puede resolverse en una IP obsoleta.

Otro escenario común es el geo-bloqueo a nivel de CDN o WAF (Cloudflare, Akamai). Algunas reglas de seguridad bloquean rangos completos de IP de ciertos países, y su API es físicamente inaccesible para parte de los usuarios, aunque desde su IP de oficina todo funcione perfectamente. Estos problemas son imposibles de diagnosticar si se prueba solo desde un punto.

Un tercer escenario es la distribución de carga a través de Anycast o CDN regionales. Una solicitud desde Alemania puede llegar a un nodo, mientras que desde Singapur puede llegar a otro completamente diferente, con otra versión de caché o configuración. La diferencia en el comportamiento de la API entre regiones no es una teoría, sino algo con lo que los equipos que tienen usuarios distribuidos por el mundo se enfrentan regularmente.

5 métricas de disponibilidad, visibles solo a través de IP externa

A continuación, se presentan cinco métricas que muestran la verdadera imagen de la disponibilidad solo cuando la solicitud se realiza desde una dirección IP que se encuentra físicamente en el país objetivo o al menos se enruta a través de su red.

1. Tiempo de respuesta (Latencia / RTT)

El Round-Trip Time es el tiempo desde que se envía la solicitud hasta que se recibe el primer paquete de respuesta. Desde un servidor en Europa, la latencia hasta su API puede ser de 20 ms, mientras que un usuario del Sudeste Asiático esperará entre 400 y 600 ms debido a la distancia geográfica y la cantidad de nodos intermedios (hops). Si no se mide la latencia desde diferentes regiones, es fácil pasar por alto el momento en que el servicio se vuelve prácticamente inutilizable para parte de la audiencia, especialmente crítico para APIs vinculadas a operaciones en tiempo real: pujas en publicidad, chats, transacciones fintech.

2. TTFB (Tiempo hasta el primer byte)

TTFB muestra cuánto tiempo tarda el servidor en procesar la solicitud antes de comenzar a enviar la respuesta. Esta métrica depende no solo de la red, sino también de qué nodo de CDN o balanceador está sirviendo a una región específica. No es raro que un servidor edge en un país almacene en caché la respuesta y la entregue en 50 ms, mientras que en otro país la solicitud llega al servidor de origen cada vez y se procesa de nuevo, tomando 800 ms o más. La diferencia en TTFB entre regiones es un signo seguro de problemas con la configuración de la CDN o cobertura insuficiente de nodos edge.

3. Tiempo de resolución de DNS

La resolución de DNS es una fuente separada de retrasos y errores que depende completamente del resolvedor local del usuario. Si tiene configurado GeoDNS (diferentes registros A dependiendo de la región de la solicitud), un error en la configuración puede hacer que los usuarios de un país se resuelvan en un centro de datos en otro continente, con una gran latencia. Este problema solo se puede ver al solicitar la resolución de DNS desde una IP real del país objetivo; una prueba local siempre se resolverá "correctamente" en relación con su propia geolocalización.

4. Porcentaje de solicitudes exitosas (Uptime) por regiones

Un uptime del 99.9% en el tablero de monitoreo, que hace ping desde un solo punto, no garantiza un 99.9% para los usuarios en otro país. Los proveedores locales pueden tener problemas de peering específicamente con su proveedor de hosting, lo que resulta en que parte de las solicitudes desde el país X se caigan por tiempo de espera, mientras que el resto del mundo no nota el problema en absoluto. Para ver el uptime real, es necesario contar las solicitudes exitosas y no exitosas por separado para cada región, y no de manera agregada.

5. Diferencias en contenido y códigos de estado (geo-bloqueo y personalización)

La quinta métrica no trata sobre la velocidad, sino sobre el contenido mismo de la respuesta. La API puede devolver un 403 Forbidden para ciertos países debido a reglas de WAF, devolver un conjunto de datos reducido debido a restricciones de licencia, o mostrar una versión diferente del contenido debido a pruebas A/B vinculadas a la geolocalización. Si se prueba la API solo desde su IP, tales diferencias quedarán completamente sin ser notadas, y son precisamente estas las que más a menudo causan quejas de los usuarios de regiones específicas.

Cómo configurar el monitoreo desde diferentes países

La lógica de configuración es simple: envía la misma solicitud HTTP a tu API desde varios puntos al mismo tiempo, registra las cinco métricas y compara los resultados. Paso a paso, esto se ve así:

1. Elabore una lista de países prioritarios: generalmente son los 5 principales países por volumen de tráfico o ingresos.
2. Para cada país, prepare un punto de salida con una IP real de ese país (servidor proxy o servidor físico).
3. Configure un script o servicio que envíe una solicitud idéntica a través de cada punto con un intervalo establecido (por ejemplo, cada 5 minutos).
4. Registre las 5 métricas por separado para cada país en una base de datos o sistema de métricas (Grafana, Prometheus, ClickHouse).
5. Configure alertas para desviaciones de las métricas del nivel base: por ejemplo, si la latencia desde un país específico aumenta 3 veces en una hora.

El punto clave es el punto 2. Sin una salida real al país necesario, todos los demás pasos son inútiles, porque las métricas medirán no lo que ve el usuario, sino lo que ve su propio servidor de monitoreo.

Qué tipo de proxy elegir para el monitoreo

Para construir un monitoreo geográficamente distribuido, se utilizan con mayor frecuencia servidores proxy: es más barato y rápido que alquilar servidores físicos o VPS en cada país necesario. La elección del tipo de proxy depende de lo que realmente desea medir.

Tipo de proxy	Cuándo usar	Características
Proxies de centros de datos	Verificación básica de disponibilidad y latencia, cuando no se necesita simular un usuario real	Alta velocidad, bajo costo, pero la IP se identifica fácilmente como de centro de datos — no es adecuada para probar geo-bloqueo por proveedores
Proxies residenciales	Verificación de lo que ve un usuario real con un proveedor doméstico	La IP pertenece a proveedores reales en un país específico, refleja con mayor precisión la ruta y las reglas de WAF
Proxies móviles	Prueba de disponibilidad de API para aplicaciones móviles y tráfico móvil	IP de redes de operadores móviles, muestra latencias y bloqueos específicos para tráfico móvil

Si su API atiende principalmente tráfico web desde escritorios y servidores, para construir un monitoreo básico son suficientes los proxies de centros de datos: proporcionan velocidad estable y latencia predecible. Pero si necesita verificar exactamente lo que enfrenta un usuario real — incluyendo reglas de geo-bloqueo configuradas por ASN del proveedor — vale la pena utilizar proxies residenciales, ya que se enrutan a través de las redes de proveedores de internet comunes en el mismo país. Para aplicaciones móviles y SDK que hacen solicitudes a la API, es razonable agregar pruebas a través de proxies móviles, ya que los operadores móviles a menudo utilizan NAT y sus propias reglas de enrutamiento, diferentes de las de internet doméstico.

Script listo en Python para la recolección de métricas

A continuación, se presenta un ejemplo simplificado de un script que envía una solicitud a través de un proxy en el país especificado y recopila cuatro de las cinco métricas (las diferencias de contenido deben compararse por separado, correlacionando las respuestas). El script utiliza la biblioteca requests y el módulo socket para medir el tiempo de resolución de DNS.

import time
import socket
import requests

def measure_api(url, proxy, country_label):
    hostname = url.split("//")[1].split("/")[0]

    # 1. Tiempo de resolución de DNS
    dns_start = time.time()
    try:
        socket.gethostbyname(hostname)
    except socket.gaierror:
        pass
    dns_time = time.time() - dns_start

    proxies = {
        "http": proxy,
        "https": proxy,
    }

    try:
        start = time.time()
        response = requests.get(
            url,
            proxies=proxies,
            timeout=10,
            stream=True
        )
        ttfb = time.time() - start  # TTFB aproximado

        full_load_time = time.time() - start
        status_code = response.status_code
        success = status_code == 200

        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": round(ttfb * 1000, 2),
            "total_time_ms": round(full_load_time * 1000, 2),
            "status_code": status_code,
            "success": success,
        }
    except requests.exceptions.RequestException as e:
        result = {
            "country": country_label,
            "dns_time_ms": round(dns_time * 1000, 2),
            "ttfb_ms": None,
            "total_time_ms": None,
            "status_code": None,
            "success": False,
            "error": str(e),
        }

    return result


# Ejemplo de uso con proxies de diferentes países
endpoints = [
    {"label": "Alemania", "proxy": "http://user:[email protected]:port"},
    {"label": "Brasil", "proxy": "http://user:[email protected]:port"},
    {"label": "Singapur", "proxy": "http://user:[email protected]:port"},
]

API_URL = "https://api.yourservice.com/health"

for ep in endpoints:
    data = measure_api(API_URL, ep["proxy"], ep["label"])
    print(data)

Para la versión de producción de este script, vale la pena agregar el registro de resultados en una base de datos (por ejemplo, ClickHouse o InfluxDB), visualización a través de Grafana y alertas a través de un bot de Telegram o webhook de Slack cuando se superen los umbrales. Es mejor ejecutar el script a través de cron o un programador de tareas con un intervalo de 5-15 minutos para cada país.

Si necesita una verificación rápida sin escribir código, se puede realizar una solicitud similar a través de cURL midiendo el tiempo:

curl -x http://user:[email protected]:port \
  -o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
  https://api.yourservice.com/health

Cómo interpretar los resultados

Después de recopilar datos de todos los países durante al menos una semana, aparece un nivel base (baseline) para cada región. Luego, debe observar no los números absolutos, sino las desviaciones de este nivel base. Si la latencia desde Brasil se mantiene constantemente en 350 ms, eso es normal para la geografía, y se debe levantar la alarma si el valor de repente aumenta a 1500 ms. De manera similar con el uptime: un 99.5% para una región complicada con internet inestable puede ser una norma aceptable, mientras que una caída al 95% ya es una señal de problema del lado del proveedor o de la CDN.

Se debe prestar especial atención a los códigos de estado 403 y 451: casi siempre indican geo-bloqueo por parte del WAF o CDN, y no un problema con la API misma. Si tales códigos aparecen solo desde un país específico y solo al usar proxies de un tipo determinado (por ejemplo, de centros de datos), esto puede significar que el bloqueo está configurado en función de la característica "la IP parece un centro de datos", y no por geolocalización real; en este caso, una prueba con proxies residenciales dará una imagen más honesta.

Servicios listos vs solución hecha a medida

Si no desea mantener su propio script, hay servicios listos en el mercado de monitoreo sintético con puntos de presencia en diferentes países: Pingdom, Uptrends, Site24x7, Checkly. Ellos eliminan la necesidad de configurar infraestructura, pero generalmente están limitados a un conjunto fijo de ubicaciones y no ofrecen flexibilidad en la elección del tipo de IP (residencial, móvil, de centro de datos) para una prueba específica.

Una solución hecha a medida basada en proxies ofrece más control: puede probar exactamente los países que son importantes para su negocio, alternar entre tipos de IP para diagnosticar problemas específicos (por ejemplo, geo-bloqueo por ASN) e integrar métricas directamente en su sistema de monitoreo sin intermediarios innecesarios. La combinación de ambos enfoques es un equilibrio razonable: servicios listos para el monitoreo básico de SLA, script propio con proxies para el diagnóstico puntual de problemas en regiones específicas.

Conclusión

El monitoreo local desde un solo punto muestra solo una parte de la verdad sobre la disponibilidad de la API. Para ver la verdadera imagen, es necesario medir la latencia, TTFB, el tiempo de resolución de DNS, el uptime y las diferencias en el contenido por separado para cada país, y hacerlo a través de una IP que realmente se enruta a través de la red de la región objetivo. Sin esto, es fácil pasar por alto un problema que impide que parte de los usuarios utilicen el servicio, mientras que el tablero muestra "todo en verde".

Para construir tal monitoreo, los proxies residenciales son los más adecuados si es importante ver lo mismo que ve un usuario real con internet doméstico en un país específico. Para una verificación básica más barata y rápida, los proxies de centros de datos son suficientes, y para diagnosticar problemas específicamente en la audiencia móvil, vale la pena agregar pruebas a través de proxies móviles. Este enfoque combinado proporciona una imagen completa de cómo se ve su API desde cualquier parte del mundo, y no solo desde el servidor donde está desplegada.