¿Está caído, o eres solo tú?
Una comprobación desde varios puntos de vista ejecuta la misma prueba — un ping, una petición HTTP, una consulta DNS — desde sondas en redes de otras personas, en otros países, en el mismo momento en que la ejecutas desde la tuya. Ese único cambio convierte una pregunta sin respuesta («a mí me funciona — ¿alguien más lo está viendo?») en una comparación: si cada punto de vista falla, el objetivo está caído; si solo falla el tuyo, el problema vive en el camino entre tú y él. Esta guía explica qué prueba realmente un segundo punto de vista, la trampa del anycast en la que todo el mundo cae una vez, y cómo ejecutar la comprobación con el ping global de este sitio.
El problema del «a mí me funciona»
Todo canal de incidentes ha oído las dos frases en la misma hora: «el sitio está caído» y «a mí me funciona». Ambas pueden ser informes honestos. Una prueba ejecutada desde un solo punto de vista — tu portátil, tu oficina, una máquina de monitorización — mide exactamente una cosa: la experiencia de esa única red, en ese único camino, en ese único momento. No puede distinguir un servicio caído para todos de un camino roto solo para ti: un proveedor de tránsito enfermo, una regla de filtrado regional, un resolver DNS que devuelve respuestas envenenadas u obsoletas, una disputa de peering a tres redes de distancia de la que nunca has oído hablar. Desde dentro del único punto de vista, todo eso se ve idéntico: un fallo sin dirección de retorno.
Los tickets de soporte y las páginas de estado sufren la misma geometría. Una página de estado dice «operativo» porque las sondas del propio proveedor — sentadas en el propio barrio del proveedor — alcanzan el servicio sin problema, mientras toda una región no puede. Un usuario informa de «caído» porque su ISP está tragándose el tráfico en un agujero negro, mientras el servicio tararea. Ninguna de las dos partes miente; ambas generalizan desde una sola silla. La solución no es más precisión desde la misma silla. Son más sillas.
Qué prueba un segundo punto de vista
Añade sondas en otras redes — otros sistemas autónomos, otros países, otros tipos de conexión — y ejecuta la prueba idéntica desde todas a la vez. Ahora el patrón hace la argumentación. Si sondas en cinco redes de tres continentes fallan todas de la misma manera en el mismo momento, el factor común es el objetivo: el servicio, su host o su propia red están caídos, y ninguna cantidad de retoques locales cambiará eso. Si cuatro tienen éxito y solo falla la sonda más cercana a tu situación — o solo fallas tú — el factor común se invierte: el objetivo está en pie, y la rotura está en algún lugar del camino que los puntos de vista fallidos comparten. El acuerdo entre puntos de vista independientes es lo más parecido a una prueba que tiene la pregunta «¿está caído?».
Las sondas que usa este sitio pertenecen a la red Globalping, operada por jsDelivr: miles de pequeñas sondas de software alojadas por voluntarios en todo el mundo, en todo tipo de sitios, desde servidores en centros de datos hasta conexiones domésticas, que aceptan mediciones estandarizadas — ping, traceroute, MTR, DNS y HTTP — e informan de lo que vieron. El valor no es ninguna sonda individual; una máquina voluntaria en una ciudad es una anécdota. El valor es que las anécdotas son independientes: redes distintas, upstreams distintos, modos de fallo distintos, todas respondiendo a la misma pregunta en el mismo momento.
La advertencia del anycast y los CDN
Aquí está la trampa, y todo el mundo cae en ella una vez: respuestas distintas desde lugares distintos pueden ser todas correctas. Los servicios modernos no son una máquina en un lugar. Anycast anuncia la misma dirección desde muchas ubicaciones, de modo que una sonda en Fráncfort y una en São Paulo que envían paquetes a «la misma» IP están hablando con bordes físicos distintos, posiblemente en continentes de infraestructura distintos — uno sano, otro reiniciándose. Un CDN dirige a cada cliente a un borde cercano, y un borde puede estar caído en una región mientras el servicio es impecable en otra parte. La divergencia entre sondas no es automáticamente una contradicción; para un objetivo anycast, la divergencia es el diseño funcionando como se pretendía, y la pregunta pasa a ser «¿caído dónde?» en lugar de «¿caído?».
El DNS hace el mismo punto desde el otro lado. Los servidores autoritativos y los resolvers entregan respuestas distintas por diseño — GeoDNS devuelve la dirección del borde «más cercano», y EDNS Client Subnet permite a un resolver preguntar en nombre de tu barrio, así que el resolver de una sonda en Tokio y uno en Texas reciben legítimamente direcciones distintas para el mismo nombre (compáralas lado a lado con el comprobador de propagación DNS cuando la pregunta sea qué registros tiene el mundo). Direcciones distintas desde sondas distintas no son evidencia de inconsistencia. Son evidencia de que el nombre está haciendo localización — y te dicen con qué borde se encontrarán realmente los usuarios de cada región.
Elige la medición que responde a la pregunta
El ping global ofrece cinco tipos de medición, y elegir bien importa más que ejecutar muchas. Cada una responde a una pregunta distinta, y ejecutar la equivocada produce una respuesta segura a algo que no preguntaste. Empareja el tipo con el síntoma antes de mirar los resultados de nadie.
Ping responde a la pregunta más estrecha: ¿es el objetivo alcanzable desde aquí, y cuánto se pierde por el camino? Es la prueba correcta para «¿puede esta red ver esa máquina en absoluto?», y la prueba incorrecta para cualquier cosa sobre la aplicación — una máquina puede responder al ping mientras su servicio web está muerto. HTTP responde a la pregunta del usuario: ¿tiene éxito una petición real desde allí, con qué código de estado, y cuánto tardó todo? Cuando la discusión es «el sitio funciona / el sitio no funciona», HTTP desde varias sondas es la evidencia que ambas partes deberían aceptar. DNS responde a la pregunta del nombre: ¿qué direcciones recibe realmente cada región para este nombre? Es como separas «el servicio está caído» de «mi región está siendo enviada al borde muerto».
Traceroute responde a la pregunta del dónde: salto a salto, ¿dónde se detiene, se atasca o se desvía a un lugar inesperado el camino desde esta sonda hasta el objetivo? Ejecútalo desde el punto de vista que falla, no desde uno que funciona. MTR es traceroute a lo largo del tiempo — el mismo camino sondado repetidamente, de modo que la pérdida y el retraso se muestran por salto como tasas en lugar de como una única muestra congelada; es la herramienta para «se rompe intermitentemente», donde un solo traceroute pilla el camino en un día de buen comportamiento. La disciplina en las cinco: decide qué fallo estás probando, elige la única medición que puede verlo, y deja que las demás esperen.
Leer resultados sin engañarte
Empieza separando los dos números que la gente habitualmente mezcla. La pérdida — peticiones que nunca volvieron — es daño; la latencia — peticiones que volvieron despacio — es incomodidad, y ambas tienen causas y soluciones distintas. Una sonda que muestra un 100 % de pérdida ha encontrado un muro; una sonda que muestra cero pérdida y latencia alta ha encontrado un camino largo o congestionado, e informar de lo segundo como «caído» es como los servicios sanos reciben llamadas a las tres de la mañana. Después compara lo comparable: toma la sonda mediana como la historia, no la mejor ni la peor. Una sonda que devuelve un valor atípico salvaje — una latencia enorme, un tiempo de espera agotado que nadie más vio — es una afirmación sobre el momento de esa sonda, su host o su upstream. Solo se convierte en evidencia sobre el objetivo cuando sondas independientes están de acuerdo con ella.
Cuida también la contabilidad. Una sonda que informa del objetivo como «sin conexión» mientras sus vecinas tienen éxito lo más probable es que se haya informado a sí misma — una sonda caída, una conexión doméstica que se cortó, un filtro local — y las sondas voluntarias tienen todo eso; es el precio de una red que nadie opera centralmente. Anota las marcas de tiempo y trata los resultados obsoletos o cacheados como historia, no como noticia. Y cuando cada sonda coincide en que el objetivo está en pie pero tus usuarios siguen sin alcanzarlo, cree a ambas: has aprendido que el fallo es real y estrecho — vive en un camino que ninguna de tus sondas compartía por casualidad, lo cual es un hallazgo, no una contradicción.
Límites honestos
Las sondas son voluntarias, y la red se comporta como tal. Las sondas van y vienen — una ubicación disponible esta mañana puede estar sin conexión esta noche, la cobertura es densa en algunos países y escasa hasta inexistente en otros, y no puedes exigir una sonda dentro de un ISP concreto solo porque ahí están tus usuarios. Las sondas también se sientan en su mayoría en centros de datos y en conexiones de entusiastas, no en las redes residenciales y móviles desde las que navegan tus usuarios reales; una sonda de centro de datos prueba que el servicio es alcanzable desde lugares bien conectados, que es la mayor parte de la pregunta, pero no toda. Trata el mapa como una muestra de las redes del mundo, generosamente dibujada — no como el mundo.
El uso que este sitio hace de la red es deliberadamente modesto: funciona sobre el nivel gratuito anónimo y compartido de Globalping, así que las comprobaciones llevan límites por visitante y los resultados se cachean brevemente en lugar de martillear un recurso voluntario — si una comprobación te pide que esperes, eso es el nivel compartido siendo compartido. Dentro de esos límites, el patrón de trabajo es: ejecuta aquí la comprobación desde varios puntos de vista para zanjar «¿caído o solo yo?», y después profundiza en el ganador — la comprobación de salud del sitio web para todo lo que una mirada detallada única al sitio puede decirte, y una ronda nueva desde el ping global una vez que hayas cambiado algo. Caído-para-todos y caído-solo-para-ti necesitan tardes distintas; diez minutos de puntos de vista ajenos es como descubres qué tarde estás teniendo.
Preguntas frecuentes
¿Desde cuántas ubicaciones debería probar?
Esta herramienta ejecuta hasta cuatro ubicaciones por comprobación, y cuatro bien elegidas ganan a cuarenta elegidas al azar. Elige una distribución que encaje con la discusión: una sonda cerca de tus propios usuarios, una en otro continente, una cerca del alojamiento del objetivo, y una en cualquier lugar distante como control. Si las sondas cercanas y las lejanas están de acuerdo, tienes tu respuesta; si solo fallan las cercanas, también has localizado el problema. Más ubicaciones ayudan sobre todo cuando las cuatro primeras no están de acuerdo en un patrón que aún no sabes leer.
Una sonda dice sin conexión — ¿está caído el sitio?
No con esa evidencia sola. Una única sonda puede estar sin conexión ella misma — caída, desconectada o detrás de un filtro propio — y las sondas voluntarias no tienen ningún operador que las garantice. «Caído» es una conclusión que sacas del acuerdo: varias sondas independientes, en redes distintas, fallando de la misma manera en el mismo momento. Una sonda fallando mientras sus vecinas tienen éxito te habla del camino de esa sonda, y el informe honesto es «inalcanzable desde ese único punto de vista», no «caído».
¿Por qué el mismo dominio se resuelve a direcciones distintas desde sondas distintas?
Porque así es como se supone que debe funcionar. GeoDNS y EDNS Client Subnet hacen que las respuestas DNS dependan de dónde parece venir la consulta, así que a cada región se le entrega la dirección de su borde sano más cercano; anycast y los CDN se apoyan en el mismo truco en la capa de enrutamiento. Direcciones distintas desde sondas distintas son la localización haciendo su trabajo. Solo se convierte en un hallazgo cuando la dirección de una región está muerta mientras las demás funcionan — entonces el nombre está enviando fielmente a los usuarios de esa región a un borde roto.