Saltar al contenido
Paco Segovia
Reservar 20 min

Observabilidad

Si algo falla en esta web, me entero yo primero

Un formulario que deja de enviar no avisa a nadie: quien lo prueba se va. Por eso cada fallo de esta web llega a Sentry, y de ahí a un canal de Discord, con la versión que lo trajo y la línea que lo causó.

Ver también cómo se edita esta web y cómo trabajo con IA.

Qué es

Saber qué ha fallado sin tener que reproducirlo

Un sistema es observable cuando, al fallar, puedes saber desde fuera qué ha pasado, dónde y a quién ha afectado. Monitorizar es comprobar lo que ya sabes que puede fallar. Observar es poder contestar preguntas que no te habías hecho, como por qué un formulario se rechazó un martes a las once de la noche.

Errores
Con su pila, la versión desplegada y el contexto en el que pasaron. Es lo que recoge Sentry.
Registros
El diario del servidor: qué peticiones recibe y qué avisos da. Sirve para ver qué pasó justo antes de un error.
Trazas
Cuánto tarda cada paso de una petición: una consulta a la base de datos, una subida de imagen.
Disponibilidad
Una comprobación desde fuera, cada minuto, de que la web responde.

Lo delicado son las alertas. Cada una tiene que servir para hacer algo: si llegan avisos de cosas que no importan, acabas por no leerlos, y el día que llegue uno grave pasará igual de desapercibido. Un fallo puntual de un proveedor que el código ya gestionó queda registrado, pero no avisa. Y un aviso del navegador que no es un error se filtra.

Qué se observa

Lo que puede fallar y a quién afecta

  • Formulario de contacto

    Qué puede fallar
    El correo no sale, se rechaza el envío o PHP se cae
    A quién afecta
    A quien quiere encargarte algo
    Antes
    Nadie se enteraba
    Ahora
    Sentry y Discord

  • JavaScript de la web

    Qué puede fallar
    No llega la clave del formulario o falla un script
    A quién afecta
    Igual: sin clave, el envío se rechaza
    Antes
    Nadie se enteraba
    Ahora
    Sentry y Discord

  • Alojamiento

    Qué puede fallar
    Caída, certificado caducado, configuración rota
    A quién afecta
    A todo el que entra
    Antes
    Nadie se enteraba
    Ahora
    Monitor cada minuto

  • Despliegue

    Qué puede fallar
    Falla el build, la descarga del CMS o la subida
    A quién afecta
    La web se queda en la versión anterior
    Antes
    Aviso en Discord
    Ahora
    Igual

  • CMS

    Qué puede fallar
    Se cae la base de datos o el almacenamiento, falla la API o el panel
    A quién afecta
    A quien edita y al build de la web
    Antes
    Solo el registro del servidor
    Ahora
    Sentry y Discord

  • Publicar desde el CMS

    Qué puede fallar
    El token de GitHub caduca
    A quién afecta
    Publicar guarda pero no llega a la web
    Antes
    Solo el registro del servidor
    Ahora
    Sentry y Discord

Las páginas en sí no hace falta vigilarlas: son HTML generado al compilar, y si el build falla, el despliegue se para y avisa. La base de datos y el almacenamiento de imágenes se observan a través del CMS.

Lo que salió

Lo que nadie estaba viendo

  1. El formulario no avisaba de nada

    Es lo único de la web que trae clientes. Si el correo no salía, la persona veía un error y quizá escribía por otro lado. Si no lo hacía, el mensaje se perdía.

  2. Cada despliegue rompía los formularios a medio rellenar

    La clave que firma el formulario cambiaba en cada build, y publicar en el CMS despliega. Quien escribía mientras tanto recibía un rechazo al enviar. Ahora la clave es fija, y si aun así se rechaza un envío, queda el motivo.

  3. El token que despliega desde el CMS caduca

    Cuando caduque, publicar seguirá guardando, pero el cambio no llegará a la web. Antes solo quedaba una línea en el registro del servidor; ahora llega como error.

  4. La primera prueba real guardó una IP

    Sentry deduce la IP de quien navega en los errores de JavaScript aunque el código no la mande. Se vio en la prueba, y el mismo día quedó corregido en el código y en la organización.

  5. La política de seguridad no informa de lo que bloquea

    Va dentro de la página, y ahí los navegadores ignoran la dirección de informes. Si un script dejaba de coincidir con su firma, se bloqueaba en silencio. Ahora una copia de la política avisa a Sentry de cada bloqueo.

Cómo está montado

Un informador en cada capa

  • Navegador

    Informador propio

    Unas 80 líneas en lugar del SDK de Sentry, que pesaría más que todo el JavaScript de la web. Recoge los errores del código de la web, descarta los de extensiones y manda como mucho cinco por visita.

  • Formulario

    PHP en el alojamiento

    Avisa si el correo no sale, si se rechaza un envío y por qué, y si PHP se cae. Si Sentry tarda más de dos segundos en responder, el formulario sigue su camino.

  • CMS

    SDK oficial en el servidor

    Todo lo que el CMS registra como error llega a Sentry, con la versión desplegada. El build sube los mapas del código para que la pila se lea con los nombres originales.

  • Política de seguridad

    Cabecera en Apache

    Al compilar, la política de la página se copia a una cabecera que solo informa. Si el navegador bloquea un script o un recurso, Sentry recibe qué, dónde y por qué regla.

  • Explicaciones

    Claude en GitHub Actions

    Cada tres horas, Claude lee las incidencias nuevas y el código de la web, y escribe en Discord qué ha pasado, la causa probable, dónde está y qué hacer. Solo puede leer archivos: lo que trae un error lo puede haber escrito cualquiera.

  • Despliegue

    GitHub Actions

    Cada despliegue avisa en Discord de cómo ha ido, con el commit y el enlace al registro. Sentry recibe ese commit como versión: cada error queda unido al despliegue que lo trajo.

Antes de darlo por bueno, cada capa mandó un error real a Sentry, provocado a propósito en local: un envío rechazado, un error del navegador y un CMS que no podía conectar con su base de datos. Después, una incidencia nueva llegó a Discord en segundos.

Alertas

Qué llega a Discord y cuándo

Qué avisa en Discord y con qué frecuencia
Qué pasaCuándo avisa
Un fallo nuevo en la web o en el CMSLa primera vez que aparece, y de nuevo si vuelve después de darlo por resuelto
La explicación de ese falloEn las tres horas siguientes, con la causa probable, el archivo y la línea
El navegador bloquea algo por la política de seguridadLa primera vez por cada recurso bloqueado
El correo del formulario no saleCada vez, como mucho una cada cinco minutos
Un envío rechazadoLa primera vez por cada motivo; las siguientes se acumulan en Sentry
La web no responde o el certificado ha caducadoTras tres comprobaciones fallidas seguidas, una por minuto
Un despliegueAl terminar, salga bien o mal

Todo va al mismo canal que los despliegues: un solo sitio para lo que pasa en la web. Un fallo que se repite se agrupa en la misma incidencia y avisa una vez. Lo grave llega además por correo.

Privacidad

Los errores llegan sin datos personales

Formulario
Nunca se manda lo que escribe la persona. Llegan el motivo, el idioma y la versión de PHP. Se comprobó enviando un nombre, un correo y un mensaje de prueba que no aparecieron en ningún evento.
IP
El código no la manda, y la organización de Sentry tiene activado que no se guarde aunque llegue.
CMS
Sin usuario, cookies, cabeceras ni cuerpos de petición. El inicio de sesión lleva la contraseña: se probó y no sale.
Dónde
Los datos se guardan en la región europea de Sentry, en Frankfurt.
Visitas
La web sigue sin cookies ni analítica. A Sentry solo llegan informes de error.

Hablamos

¿Sabes qué está fallando en tu tienda?

En una tienda Shopify también hay cosas que fallan sin que nadie avise: un script del tema que da error en un navegador, una app que deja de responder. Cuéntame cómo está montada la tuya y vemos qué conviene vigilar.

Reservar 20 minEscríbeme