Documentación

Seguimiento de errores

Capture las excepciones que lanza su aplicación, agrupadas en issues, en todos los planes incluido el gratuito. Habla el protocolo de Sentry, así que conserva el SDK que ya tiene y cambia una línea de configuración.

Puesta en marcha

Cree un proyecto en el panel y copie su DSN. Después apunte su SDK existente hacia él:

Sentry.init({
  dsn: "https://<key>@vitrinaengine.com/ingest/<project>",
});

Esa es toda la integración. Funciona cualquier SDK de Sentry — JavaScript, Python, Ruby, Go, PHP, .NET — porque es su protocolo de red y no algo parecido.

La clave de un DSN no es un secreto. Un SDK de navegador la envía en el bundle de la página, así que identifica un proyecto y no autoriza nada más. No construya nada que dé por hecho que es privada.

Cómo los errores se convierten en issues

Los eventos que son el mismo problema se agrupan en una issue. La agrupación usa el tipo de excepción, el mensaje y la forma de la pila — nunca los números de línea, porque añadir un import al principio de un archivo dividiría una issue en dos y haría que un fallo antiguo pareciera nuevo.

Una issue que usted resolvió y que vuelve a ocurrir se reabre como regresión y le avisa, en lugar de añadir en silencio una ocurrencia más a una issue cerrada.

Source maps

Suba las maps de una versión y una pila de navegador minificada se vuelve legible. Súbalas desde su build con la API — véase la referencia de la API.

Las maps se emparejan primero por debug_id y después por versión más nombre de archivo. Se aplican al leer una issue, no cuando llega el evento, lo que tiene una consecuencia útil: una map subida después de los errores se les aplica igualmente. Ese suele ser el orden en que ocurren las cosas.

Errores adjuntos a un incidente

Cuando la monitorización abre un incidente, recoge los errores que su aplicación lanzó mientras se confirmaba esa caída y adjunta un resumen al propio incidente.

Merece la pena saber por qué eso es más útil que buscarlos después: la ventana deja de existir en cuanto existe el incidente, y los eventos están sujetos a una retención que expira mucho antes que él. El resumen se captura, por tanto, en el momento en que es posible, y se conserva después junto al incidente.

En una cuenta de agencia el resumen se limita al espacio de trabajo, de modo que el incidente de un cliente no arrastre las trazas de otro dentro de un correo.

Registros de tus servidores y de tu red

A partir de Business, un proyecto también acepta los registros que tus máquinas ya escriben: syslog de Linux y de equipos Cisco y Juniper, el Registro de eventos de Windows y el registro unificado de macOS. Apunta un remitente que ya utilices al endpoint de registros de tu proyecto, que está en la página del proyecto junto al DSN. No hay nada que instalar en las máquinas.

Solo se almacenan los errores. Las severidades de syslog por debajo de err, los niveles de Windows por debajo de Error y todo lo que el registro de macOS llamaDefault o inferior se descartan antes de contarse o cobrarse — así un host sano no te cuesta nada, y las advertencias por las que nadie recibiría un aviso no llenan tu lista de incidencias.

Los registros se agrupan como las excepciones: por el programa que los emitió y por el mensaje, no por el host. Un despliegue defectuoso en veinte servidores web es una incidencia vista veinte veces, no veinte incidencias. Cuando un equipo nombra sus propios mensajes agrupamos por ese nombre, de modo que una interfaz caída es una incidencia, sea cual sea el puerto.

Como una línea de registro se repite mucho más que una excepción, conservamos un ejemplo de cada incidencia por hora y contamos el resto. El número de apariciones y el gráfico son exactos; lo que no obtienes es una copia aparte de la centésima línea idéntica.

Cuotas

Cada plan tiene una asignación mensual de eventos — 5.000 en Free, 50.000 en Starter, 250.000 en Pro, 1.000.000 en Business. La ingesta además está limitada por proyecto, que es el caso que ocurre de verdad: una excepción dentro de un bucle de reintentos puede consumir un mes de cuota en minutos.

Los eventos individuales se conservan según la retención de errores de su plan — siete días en Free, treinta en Starter, sesenta en Pro, noventa en Business. Las issues construidas a partir de ellos sobreviven a los eventos: sus recuentos y su primera y última aparición permanecen tanto tiempo como la retención de historial de su plan.

Lo que no hacemos

Sin repetición de sesión, sin trazas de rendimiento, sin profiling. Esto es seguimiento de excepciones que resulta estar junto a su monitorización de disponibilidad, para que «el sitio está en pie y lanzando quinientos errores por minuto» sea una sola pantalla y no dos productos.