BookinglyTech News
Infraestructura

Epure permite apuntar el SDK oficial de Sentry a un ingest autoalojado solo cambiando el DSN

El proyecto levanta un servidor de ingesta compatible con el SDK oficial de Sentry en dos contenedores: la app y Postgres 16. No hace falta fork ni tocar el init, solo el DSN.

2 min de lecturaDev.to0 vistas

Levantar un servidor de errores compatible con Sentry sin renunciar al SDK oficial es lo que propone Epure. La idea es sencilla: el codigo de la aplicacion no cambia, la libreria tampoco, y en Sentry.init solo se sustituye el DSN por el del host propio. A cambio de esa comodidad, el alcance es mucho mas estrecho de lo que sugiere la palabra "Sentry".

El montaje son dos contenedores: la aplicacion y postgres:16-alpine. Nada de Redis ni de una flota de workers aparte. Se clona el repositorio publico y se arranca con docker compose desde la raiz, como describe la documentacion de instalacion autoalojada. Si el puerto 8080 esta ocupado, hay que ajustar EPURE_PORT y EPURE_PUBLIC_URL a la vez en el .env y recrear el contenedor de la app; desincronizarlos es una de las causas tipicas de que la ingesta falle en silencio.

La comprobacion de vida es un GET /health que devuelve {"status":"ok"}. Despues, desde el panel de la aplicacion se crea una clave y se copia el DSN, con la forma http://{public_key}@localhost:8080/{project_id}. Ese es el unico valor que se toca en el cliente.

Que se envia y que no

La guia de inicio rapido fija @sentry/browser o @sentry/node en la version 7.120.0 y deja a cero tracesSampleRate, profilesSampleRate, replaysSessionSampleRate y replaysOnErrorSampleRate. No es un detalle menor: si esos valores quedan por defecto, el SDK manda transacciones, replays y perfiles que este host descarta, y el trabajo se pierde por el camino. El SDK 8.x suele funcionar, pero conviene poner enableTracing en false y mantener las tasas a cero.

La prueba de fuego es una excepcion real. Tanto el envio desde el SDK como los POST directos a /api/{project_id}/store/ o a /api/{project_id}/envelope/ devuelven un 202 con un identificador. Ese 202 significa que la autenticacion y el esquema han pasado, no que la incidencia ya este en la lista: la aceptacion va por delante del worker. Si la bandeja aparece vacia, hay que refrescar de nuevo y revisar el filtro de entorno, que debe coincidir con el de Sentry.init.

El propio proyecto pide honestidad con el alcance. Es una via solo para excepciones: no hay APM, ni session replay, ni profiling, ni producto de logs, ni SDKs moviles, y los source maps de JS/TS quedan para otro paso. Nada de poner "100% compatible con Sentry" en un README.

Queda por ver si el proyecto mantiene el ritmo de los SDK y no se ancla en la 7.x. Mientras tanto, para quien quiera dejar de pagar por volumen de errores en un entorno interno, cambiar una linea del init es una propuesta bastante barata de probar.