Un cliente te escribe: su web está caída, devuelve un 502. Tú administras cuarenta servidores. Antes de poder arreglar nada, tienes que responder una pregunta más tonta: ¿en qué servidor está ese dominio?
Esa segunda pregunta es donde se van los minutos. No el arreglo: el triaje. Entrar por SSH al servidor equivocado, mirar los logs equivocados, recordar de qué cuenta era. En un solo servidor un 502 es cosa de cinco minutos; en una flota, los primeros cuatro se te van solo en encontrar al paciente.
Este artículo recorre una caída de principio a fin — un 502 real — y muestra cómo CentralHost colapsa ese triaje.
Paso 1: encuentra el servidor
No te pongas a buscar a mano. Escribe el dominio en el buscador de la flota.
Lo resuelve al instante contra todos los hosts gestionados: qué servidor sirve shop.example.com, qué cuenta de hosting es la dueña, qué panel, qué stack. Nada de “déjame mirar el cPanel de web-03, no, espera, era web-07”. Un servidor, una búsqueda, la respuesta.
Suena a poco. No lo es. La premisa entera de una herramienta fleet-first es que tu unidad de trabajo es la flota, no el servidor: nunca deberías tener que recordar dónde vive cada cosa. El buscador es la parte de CentralHost de la que la gente se enamora en silencio, justamente porque borra una pregunta que ya ni notaban que se hacían.
Así que: shop.example.com está en web-07, cuenta acmeshop, cPanel, PHP 8.2 con PHP-FPM detrás de nginx. Ya tenemos paciente.
Paso 2: describe el síntoma al AI Assistant
Abre el servidor, abre el AI Assistant y díselo como se lo dirías a un colega:
shop.example.comestá devolviendo 502 Bad Gateway. ¿Por qué?
Sin rutas de logs, sin nombres de servicios, sin adivinar qué subsistema mirar. Le das el síntoma; el trabajo de campo lo hace él.
Paso 3: míralo razonar, no adivinar
Un 502 tiene una docena de causas plausibles, y desde el navegador todas se ven igual. El Assistant no elige una y cruza los dedos: ejecuta el mismo loop que haría un buen operador, pero en paralelo y sin saltarse un paso:
- El servidor web primero. nginx está arriba y responde, así que el 502 sale de nginx, no en lugar de él: lo que falla es el upstream. Ese único dato descarta la mitad de los candidatos.
- Sigue el upstream. El pool de PHP-FPM de
acmeshopes ese upstream. Revisa el servicio: el master corre, pero el log del pool está lleno deserver reached pm.max_children setting, consider raising ity workers muriendo. - ¿Por qué mueren los workers? Saca la presión de recursos y encuentra la historia real en el ring buffer del kernel: el OOM killer disparó hace veinte minutos y se llevó por delante a los workers de PHP. El servidor se quedó sin memoria.
- ¿Qué cambió? Correlaciona la línea de tiempo: un job de backup y un pico de tráfico cayeron sobre un techo de memoria ya justo, en el mismo minuto en que empezaron los 502.
Todo eso te lo presenta como una cadena corta de evidencia, citando en cada paso la línea de log o la métrica que leyó — no un veredicto que tengas que creerte de palabra. Puedes ver por qué concluyó lo que concluyó, que es la diferencia entre una herramienta en la que confías a las 2 de la mañana y otra que acabas revisando a mano (y entonces, ¿para qué la tienes?).
La causa raíz no es “PHP-FPM está caído”. Es “el pool lo está matando el OOM killer bajo carga porque pm.max_children está dimensionado para una memoria que este servidor ya no tiene”. Dos capas más abajo del error que te enseñó el navegador.
Paso 4: arréglalo — con tu mano en el interruptor
El Assistant propone el arreglo: bajar pm.max_children a la memoria real, o pasar el pool a ondemand, y reiniciarlo. En CentralHost la IA puede aplicar cambios — editar el archivo, lanzar el reinicio — pero las acciones que mutan no son autónomas. Se detienen en un gate de aprobación: te muestra el diff exacto y el comando exacto, y nada toca el servidor hasta que pulsas aprobar. El diagnóstico de solo lectura fluye libre; cualquier cosa que cambie el estado espera a un humano.
Así que lees el diff de una línea, lo apruebas, ves volver el pool y el 502 se limpia. Tiempo total de “la web está caída” a “arreglado”: lo que dura una conversación — y la mayor parte fue el Assistant leyendo logs, no tú.
Lo importante no es el 502
Es que, en una flota, el conocimiento es barato y el triaje es caro. Tú ya sabías arreglar un pool de FPM que mata el OOM. Lo que te costaba era encontrar el servidor correcto y luego reconstruir la cadena: del error del navegador al upstream, a la memoria, al job que la desbordó — cinco herramientas de profundidad, con el “¿ya volvió?” del cliente encima.
CentralHost comprime los dos extremos: el buscador encuentra el host, y el AI Assistant recorre la evidencia para que llegues a la causa en vez de cazarla — con el arreglo a una aprobación de distancia, nunca a tus espaldas.
La próxima vez que un dominio devuelva un 5xx, el primer movimiento no es SSH. Es una caja de búsqueda y una pregunta en lenguaje normal.