El cliente llama: el checkout no cobra, o la home tarda, o «ayer funcionaba». Abres el servidor y no hay más rastro que un access.log de Apache y un «500» en el navegador. El siguiente incidente se diagnostica a ciegas. Eso no es mala suerte. Es una web a medida sin observabilidad.
Observabilidad no es un dashboard bonito ni «tener Analytics». Es poder responder, con datos de producción, qué ha fallado, a quién le ha afectado y desde cuándo. Si no hay logs útiles, métricas ni trazas, estás opinando. Y la opinión no restaura un pico de tráfico.
Este artículo es qué montamos en Truman desde el día uno en un proyecto de desarrollo web a medida. Sin teatro de APM. Con el suelo que evita que el incidente se convierta en una noche de SSH.
Qué es observabilidad web a medida (y qué no)
Observabilidad web a medida es la capacidad de explicar el comportamiento del sistema en producción a partir de lo que emite: logs, métricas y trazas. No es lo mismo que monitorización clásica (un ping, un disco, un 200 en la home). Monitorizar te dice que algo va mal. Observar te deja preguntar por qué sin haber previsto la pregunta el día del deploy.
En una plantilla compartida, a menudo «basta» un uptime externo. En una web a medida —CMS propio, integraciones, colas, un checkout, un panel— el fallo es específico. Un endpoint de pago, una query, un job que no corre, un cache que sirve HTML viejo. Si no instrumentas eso, el hosting puede estar sano y el producto, no.
El suelo de infra —máquina, cache, HTTPS— está en hosting y rendimiento para webs a medida. Este artículo es la capa de encima: cómo te enteras de lo que pasa cuando esa infra está viva. Sin observabilidad, el hosting bueno solo te da un sitio más cómodo para no saber.
Logs, métricas, trazas: los tres que importan
Logs: hechos con contexto. No Error a secas. Un request id, el usuario o sesión si aplica, el endpoint, el código de error de la pasarela, el tiempo. Estructura (JSON) para poder filtrar. Niveles de verdad: info no es debug, y error no es «algo raro». Si todo es error, no hay error.
Métricas: números que se pueden alertar. Las cuatro señales clásicas de SRE siguen siendo el mapa: latencia, tráfico, errores, saturación. En una web a medida se traducen a cosas de negocio: tiempo del checkout, tasa de 5xx en /api/pay, longitud de cola, saturación de PHP-FPM o de workers. CPU genérica no te dice si se venden entradas.
Trazas: el viaje de una petición a través de app, base de datos y terceros. Cuando el usuario dice «he pulsado y no ha pasado nada», la traza te dice si se quedó en el DNS, en tu controlador o en el timeout de la API de pago. Sin traza, culpas al azar. Con traza, dejas de discutir.
| Señal | Día uno | Si falta |
|---|---|---|
| Logs estructurados + request id | Obligatorio | El incidente no se puede reconstruir |
| Métricas de 5xx, latencia, cola | Obligatorio | Te enteras por el cliente |
| Uptime de la home | Necesario, no suficiente | La home 200 y el pago muerto |
| Trazas en rutas críticas | En checkout e integraciones | Discusión eterna con el proveedor |
| Dashboard de negocio en Grafana | Después, no en vez de | Bonito; no despierta a nadie |
| Logs de debug en producción | No | Ruido, coste y a veces datos personales |
Qué montar el día uno (sin un departamento de SRE)
No hace falta un stack de FAANG. Hace falta un mínimo que un equipo pequeño pueda operar. En Truman, el día del primer deploy a producción suele incluir esto, no «ya lo pondremos cuando haya tráfico».
El proveedor da igual más de lo que parece: Grafana Cloud, Datadog, Sentry + un Prometheus pequeño, el APM del host. Lo que no da igual es que los logs se queden en el disco del VPS y que la alerta sea un mail a un buzón que nadie lee. Observabilidad es operación, no un logo en el README.
Tip técnico: el request id es el hilo, no el dashboard
Genera un id por petición en el edge (nginx, load balancer o el primer middleware). Ponlo en la respuesta (X-Request-Id), en cada línea de log y en el error que ves en Sentry. Cuando el cliente manda un pantallazo, pides ese id. Sin él, cruzar front, back y el log del proveedor de pago es arqueología. Con él, es una búsqueda.
Alertas que sirven y deuda que las apaga
Una alerta sin runbook es un ruido. Una alerta que salta por un 404 de un bot es un insulto. El criterio es: ¿alguien tiene que hacer algo ahora? Si no, es una métrica, no una alerta. El 5xx de un asset cacheado no es el 5xx del pago. Agrupa. Pon umbral. Revisa cada trimestre qué se silenció «porque molestaba».
La observabilidad también se pudre. Dejar de emitir una métrica, llenar de debug, no versionar dashboards: es deuda técnica con otro nombre. Cuesta lo mismo que un índice sin usar: no duele hasta el incidente. El Core Web Vital que se va —INP incluido, lo tratamos en Core Web Vitals e INP— es otra señal: si solo lo miras en PageSpeed el día del launch, no tienes observabilidad de front. Tienes una foto.
Si esta noche el pago se queda a 8 segundos, ¿os enteráis vosotros o el primero que no puede comprar?
Mallorca Live y Klapper: producción con cara
Mallorca Live Festival no es una corporativa que se visita entre semana. Es un sitio con picos, cartel, venta y una audiencia que no espera a que «reinicies PHP». Ahí la observabilidad no es un extra de arquitectura: es saber si la home, el idioma o una landing de lineup están vivos cuando el tráfico llega de verdad. Un uptime de la raíz no te salva si la ruta que importa es otra.
Klapper añade la capa de producto: inventario, cobro, QR en puerta. El incidente típico no es «la web no carga». Es «esta sesión no valida» o «el stock se ha quedado corto». Logs de operación, métricas de venta y de error de pasarela, trazas hacia el tercero. Sin eso, discutes con el proveedor de pago a ciegas. Con eso, enseñas el request id y se acaba el teatro.
Si en producción no puedes responder qué ha fallado y a quién, no tienes un sistema. Tienes esperanza y un SSH. La observabilidad se monta el día uno o se paga en el incidente.
En València esto aparece en proyectos «ya lanzados» que nos llegan a mantenimiento: código propio, cero instrumentación, el hosting «va bien». El primer trabajo no es una feature. Es poder ver. Hasta entonces, cada arreglo es una hipótesis.
Antes de dar por cerrada la producción, verifica esto
- ¿Los logs son estructurados, salen de la máquina y llevan request id?
- ¿Mides 5xx, latencia p95 y saturación de las rutas de negocio, no solo CPU?
- ¿Hay traza (o al menos correlación) en checkout e integraciones?
- ¿Los errores de front llegan a algún sitio y se pueden cruzar con el back?
- ¿Existen tres o cuatro alertas con dueño y se han probado de verdad?
- ¿Un uptime de la home no es tu única señal de «está vivo»?
- ¿Los logs no guardan secretos, tarjetas ni tokens en claro?
- ¿Habéis ensayado un fallo y medido cuánto tardáis en verlo?
Preguntas frecuentes sobre observabilidad en webs a medida
¿Qué es la observabilidad en una web a medida?
Es poder explicar, con logs, métricas y trazas, qué está pasando en producción. No es un ping a la home ni un informe de Analytics. Es instrumentar las rutas que importan (pago, login, jobs) para diagnosticar sin adivinar.
¿Hace falta Datadog o vale algo más simple?
Vale lo que el equipo sepa operar. Un Sentry bien puesto, logs fuera de la máquina y cuatro métricas alertadas superan a un APM de folleto que nadie abre. El logo no observa. La disciplina sí. Cambia de herramienta cuando el volumen o las integraciones lo pidan, no el día del kickoff por moda.
¿Cuándo hay que montarla: en el launch o «cuando haya tráfico»?
El día uno. El primer incidente no avisa. «Cuando haya tráfico» es la frase que deja el checkout a ciegas el sábado de campaña. El mínimo (logs, errores, dos alertas) cabe en el mismo sprint que el deploy a producción.
¿Observabilidad y Core Web Vitals son lo mismo?
No. Los Web Vitals (LCP, INP, CLS) son señales de experiencia en el cliente. La observabilidad cubre también servidor, colas e integraciones. Se complementan: un INP malo sin traza de front es un número; un 5xx sin métrica de negocio es un log. Quieres las dos.
