Monitorización de uptime y latencia desde ciudades de centros de datos

¿Por qué monitorizar desde ciudades de centros de datos?

La monitorización desde ciudades de centros de datos muestra cómo se comporta tu servicio desde los nodos de red por los que pasa el tráfico de tus usuarios. Una comprobación desde tu oficina solo prueba una ruta. Una comprobación desde Fráncfort, Singapur o São Paulo prueba la ruta, la respuesta DNS y el edge del CDN que se sirve a esa región.

Preguntas típicas que responde:

• ¿Responde el sitio desde todos los mercados, o una región recibe errores?
• ¿El CDN envía a los visitantes de Tokio a un edge asiático, o hasta Virginia?
• ¿Llegó un cambio de DNS o de certificado a todas las regiones?
• ¿Una página lenta es un problema del servidor o de distancia?

Una IP de centro de datos mide la ruta del centro de datos, no la última milla de un usuario doméstico por Wi-Fi o móvil. Eso es una ventaja para comprobaciones repetibles, y un límite si necesitas tiempos de usuarios reales.

¿Cuál es la latencia mínima entre dos ciudades?

El tiempo mínimo de ida y vuelta en milisegundos es aproximadamente la distancia en kilómetros dividida por 100. La luz en fibra óptica viaja a unos 200 km por milisegundo, y una ida y vuelta recorre la distancia dos veces. Las rutas reales son más largas que una línea recta, por lo que los valores medidos son más altos.

Los pares más cercanos entre nuestras páginas de ciudades de centros de datos, según las distancias en esas páginas:

Si una comprobación desde Ámsterdam a un servidor en Londres tarda 40 ms, la distancia explica menos de 4 ms; fíjate en el enrutamiento, la configuración de TLS o el servidor. La tabla de datos de ciudades enumera cada ciudad con sus instalaciones y su vecino más cercano.

¿Cómo cambia un proxy lo que mido?

Un proxy añade un tramo a cada solicitud: tu comprobador habla con el proxy, y el proxy habla con tu servicio. El tiempo total es la suma de ambos tramos, así que un comprobador en París usando una IP de Tokio mide principalmente París a Tokio.

Dos formas limpias de leer los números:

1. Ejecuta el comprobador cerca del proxy. Un pequeño servidor en la misma región mantiene corto el primer tramo, para que el tiempo refleje la ciudad que elegiste.
2. Mide el primer tramo por separado. Cronometra una solicitud a un endpoint ligero a través del proxy y resta esa línea base del tiempo de tu servicio.

Solo para uptime, el tramo extra no importa: la pregunta es si tu servicio responde desde esa ciudad, y con qué código de estado y contenido.

# Documentation address; use an IP, port and credentials from your account
curl -x http://USERNAME:[email protected]:8000 \
  -o /dev/null -s \
  -w "status=%{http_code} connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" \
  https://example.com/health

¿Cómo construyo un monitor simple para varias ciudades?

Un monitor simple para varias ciudades necesita una IP por región, una URL de salud en tu lado y un programador de tareas.