Sentry o New Relic: el coste cambia entre errores, datos y usuarios

Sentry suele encajar mejor cuando el diagnóstico empieza por una excepción y termina en el código que hay que corregir. New Relic resulta más útil cuando también hay que relacionar el síntoma con registros e infraestructura. Una evaluación práctica de ambas plataformas encontró más profundidad para depurar errores en Sentry y más contexto operativo en New Relic.

La elección económica depende de qué crece en la aplicación y en el equipo. Sentry contabiliza categorías como errores y spans; en el modelo Data + User de New Relic intervienen los datos ingeridos y el tipo de acceso asignado. Una incidencia puede elevar ambos consumos, pero no necesariamente en la misma proporción. Los escenarios siguientes usan cargas hipotéticas para identificar el contador que cambia, sin presentar sus cifras como mediciones de clientes.

Qué diagnóstico necesita el equipo

Sentry agrupa fallos de aplicación y ofrece trazas, contexto de la incidencia y vínculos con el código y las versiones desplegadas. Ese recorrido favorece a quien necesita identificar qué excepción se produjo, en qué parte de la ejecución apareció y qué cambió antes del fallo. Sus spans también permiten localizar operaciones lentas dentro de una traza: el producto no se limita a contar excepciones.

New Relic reúne señales de rendimiento de aplicaciones, registros e infraestructura. Para un equipo de DevOps o SRE, esa amplitud permite investigar si una lentitud coincide con lo que ocurre en otros servicios o en los componentes que sostienen la aplicación. La comparación exige delimitar la instrumentación: recoger solo errores de código en una plataforma y añadir registros de toda la infraestructura en la otra produce facturas para coberturas distintas.

Qué unidad entra en cada factura

En Sentry, errores y spans ocupan cuotas distintas. Un span describe una operación dentro de una traza; una petición puede generar varios, por lo que el número de peticiones no permite deducir por sí solo el consumo de trazado. En la actualización de los planes Developer heredados, Sentry sustituyó la cuota de transacciones por una cuota de spans, mantuvo las de errores y replays, y conservó el plan gratuito. Una cifra histórica de transacciones no se puede trasladar directamente a la nueva unidad.

La documentación de facturación de New Relic incluye 100 GB mensuales de datos ingeridos sin cargo. El contador refleja, en general, lo almacenado después de las reglas de recorte y transformación, no todos los bytes enviados. En Data + User, los accesos Basic no tienen un cargo directo por usuario; Core y Full Platform son tipos facturables. Basic permite consultas y paneles, pero no abre las vistas específicas de APM o infraestructura disponibles para Full Platform. La alternativa Data + Core Compute está en vista previa pública y calcula el uso de capacidad en lugar de cobrar el acceso por usuario.

Por eso, una estimación necesita errores y spans aceptados por Sentry, gigabytes que New Relic almacenará y personas que requieren cada tipo de acceso. También debe mantener constantes las funciones recogidas en los dos meses que se comparan. Si durante una incidencia se activa más registro o se amplía el trazado, el aumento procede tanto del problema como de ese cambio en la instrumentación.

Aplicación pequeña: la incidencia multiplica los errores

Supongamos una aplicación web que envía 40 000 errores aceptados a Sentry y almacena 15 GB mensuales en New Relic. La opera una persona con acceso completo. Durante una incidencia hipotética, los errores suben a 160 000 y los datos almacenados a 35 GB; el número de usuarios permanece igual. Son supuestos de cálculo, no cuotas publicadas ni resultados de una prueba entre plataformas.

Si el contrato de Sentry incluyera una reserva hipotética de 50 000 errores, el mes ordinario quedaría dentro de ella y el incidente la superaría en 110 000. Las condiciones de Pay-As-You-Go de Sentry permiten seguir ingiriendo una categoría después de agotar su cuota y facturan ese uso al final del ciclo; la modalidad no está disponible en Developer. El importe del ejemplo depende de la tarifa adicional y de que la organización tenga habilitado ese gasto.

Los 35 GB hipotéticos de New Relic siguen dentro de su tramo mensual incluido. Si la cantidad almacenada y el acceso son los indicados, el salto de errores no genera por sí mismo un exceso de ingestión. La comparación identifica una exposición distinta al incidente; no presupone que ambas plataformas hayan conservado el mismo detalle de cada fallo.

Más personas: el acceso cambia aunque la carga sea estable

Consideremos ahora otra carga hipotética: 20 000 errores y dos millones de spans aceptados por Sentry, junto con 80 GB almacenados en New Relic cada mes. El equipo pasa de una a seis personas que necesitan investigar la aplicación, sin modificar la telemetría. En un plan de pago de Sentry cuya reserva cubra esos eventos, la ampliación del equipo no añade un cargo por asiento: la política de miembros de Sentry indica que sus planes de pago y patrocinados no cobran miembros adicionales.

En New Relic, el resultado depende del acceso concedido a las cinco personas nuevas. Si todas necesitan Full Platform en Data + User, se incorporan cinco usuarios de un tipo facturable; si les bastan las funciones Basic, esos asientos no tienen cargo directo. Los 80 GB del supuesto permanecen dentro del tramo gratuito de ingestión. Para calcular el incremento de acceso hay que aplicar a los cinco usuarios la tarifa de la edición o del contrato correspondiente, teniendo en cuenta los derechos ya incluidos en él.

El momento de asignar permisos también importa: New Relic cuenta para cada mes el tipo facturable más alto que tuvo cada usuario durante ese mes, incluso si después se reduce su acceso. Así, conceder Full Platform brevemente para atender una incidencia puede afectar al cómputo mensual. Reducir los datos enviados no elimina ese componente de la factura mientras se mantengan los usuarios facturables.

Muchos registros y trazas: dos contadores pueden subir a la vez

En un tercer supuesto, una plataforma registra normalmente 10 000 errores y cuatro millones de spans aceptados por Sentry, además de 80 GB almacenados en New Relic. Una incidencia eleva los spans a doce millones y el volumen almacenado a 280 GB, mientras los errores y usuarios siguen estables. Si el resto de condiciones no cambia, New Relic contabilizaría 180 GB por encima de su tramo mensual incluido; el coste dependería de la tarifa aplicable a esos gigabytes.

En Sentry, la estabilidad de los errores no mantiene estable el consumo de trazado. Con una reserva hipotética de cinco millones de spans, el mes de la incidencia dejaría siete millones fuera de ella. Para convertirlos en dinero hacen falta la tarifa y las condiciones de uso adicional de la organización. Si parte de la telemetría se descarta o se muestrea antes de ser aceptada, también cambia el contador efectivo.

No existe una equivalencia fija entre doce millones de spans y 280 GB: los spans son operaciones contabilizadas, mientras que los gigabytes dependen del tamaño y la mezcla de los datos almacenados. En este escenario, la decisión económica exige valorar por separado el exceso de trazado de Sentry y el exceso de ingestión de New Relic, junto con el diagnóstico que cada equipo necesita conservar durante una incidencia.

Lee también:

• Kit o Substack: el 10% cambia la elección cuando llegan los suscriptores
• Calcular la inversión inicial: el capital de trabajo cambia la cifra
• Cloudera lleva la IA hasta los datos que no pueden ir a la nube