← Todos los casos
Diagnosticar

Salimos de New Relic: migración de las vistas de APM a SigNoz, con paridad probada

6/6vistas de APM recreadas con paridad probada

Lo que perdió el equipo

New Relic se apagó por costo, y con él se fueron las pantallas que el equipo de desarrollo usaba para encontrar cuellos de botella: endpoints y operaciones de base de datos ordenados por tiempo total consumido, tiempo medio de respuesta y throughput.

SigNoz ya estaba en producción y recibía los traces, pero su interfaz nativa solo ordenaba por volumen. Para el equipo, era un paso atrás. Los cuellos de botella más caros muchas veces son endpoints con poco tráfico y mucho tiempo consumido, y esos desaparecen en un ranking por volumen.

Probar antes de construir

Antes de crear un solo panel, pasé por una fase de análisis solo de lectura: inventario del entorno, configuración del colector de OpenTelemetry, instrumentación y schema de la base de traces, en total 12 verificaciones.

Con consultas manuales, comparé los números con las pantallas antiguas de New Relic. El top 5 de endpoints salió idéntico y en el mismo orden, con un 27,19% del tiempo en SigNoz contra un 26,24% en New Relic en el primero. Confirmé que no había muestreo en ningún punto del pipeline, así que los números eran exactos. Y ningún span de entrada estaba sin ruta, lo que era mejor que New Relic, que agrupaba parte del tráfico en una etiqueta genérica. También medí la retención real de los traces, que definió la ventana máxima honesta para los paneles.

La fuente que parecía obvia

El análisis cambió el diseño. El camino natural habría sido usar las métricas de APM ya listas, pero estaban rotas (lo cuento más abajo), así que los paneles pasaron a consultar los traces directamente.

En la vista de base de datos, el agente de instrumentación nombraba las consultas solo por el nombre de la base: más de un millón de llamadas y el 53% del tiempo de base caían en una única etiqueta, sin la tabla. Extraje la tabla del texto de la consulta, y la vista pasó a coincidir con la de New Relic. Lo que no se podía identificar quedó en un panel propio, declarado, en lugar de escondido.

Entregar panel por panel

Construí y publiqué por la API un dashboard con nueve paneles que cubren las seis vistas pedidas, versionado como JSON. Cada panel se validó de punta a punta con la API de consultas antes de publicarlo. El rollback era simplemente borrar el dashboard, sin efectos colaterales: no se cambió ninguna aplicación, colector ni retención.

Lo que nadie había pedido

Las métricas de APM estaban colapsadas. El procesador que genera las métricas de latencia y tasa por operación tiene un límite de 2.048 operaciones por servicio, y los spans internos del ORM, con unos 900 nombres distintos, lo reventaban. Resultado: el 100% de las series había perdido la dimensión de endpoint. Medí que, filtrando esos spans, quedaba un 44% de holgura dentro del límite actual, y abrí la corrección con validación en staging antes de producción.

También encontré defectos de instrumentación que distorsionaban los números, y los neutralicé con filtros en los paneles antes de pasárselos al equipo de desarrollo. Cuatro servicios tenían spans de entrada duplicados, y la página nativa mostraba el doble del throughput real. Una biblioteca de acceso a la base generaba un span paralelo al del driver, contando el tiempo de base dos veces. Y la espera por una conexión del pool aparecía en lo alto del "tiempo de base" sin ser una consulta. Por último, un punto ciego: la caché no tenía ninguna instrumentación, y New Relic mostraba miles de llamadas por minuto a ella.

Qué cambió

Las seis vistas de APM volvieron a existir, en producción, con paridad comprobada y sin el costo de la herramienta apagada. El dashboard enseguida mostró el argumento del pedido: endpoints con muy poco tráfico consumiendo buena parte del tiempo de la aplicación. Y el equipo ganó números más confiables que los que tenía antes.

Lo que me llevo

En una migración de observabilidad, el primer entregable es la prueba de paridad, y no el dashboard. Si los números nuevos no coinciden con los antiguos, el equipo deja de confiar en la herramienta, y un panel bonito con números equivocados es peor que ninguno. Medir antes de construir cambió el propio diseño: la fuente que parecía obvia llevaba días rota.