Habr analiza la autoinstrumentación en APM: dónde se pierden los 4 segundos de una petición

Una petición tarda 4 segundos. En un monolito, el desarrollador activaría el profiler y encontraría el método pesado en una tarde. En un sistema donde la petición pasa por un API Gateway, varios microservicios, una cola de mensajes, una base de datos y una API externa, el profiler de una sola máquina muestra apenas una parte del cuadro. Habr ha publicado un análisis de cómo el APM responde a la pregunta «a dónde se fue el tiempo» mediante el rastreo distribuido y la instrumentación automática.

Trace y span: de qué se compone el cuadro

En el distributed tracing, cada petición se representa como un trace, es decir, su ruta completa por todos los componentes. El trace se divide en span: cada llamada individual en el frontend, el backend o el bus recibe su propio intervalo de tiempo. Un span tiene un identificador, una referencia a su padre, una hora de inicio y una duración. A partir de estas relaciones se construye el árbol de llamadas.

Para que los span de distintos servicios acaben en el mismo árbol, el contexto debe viajar junto con la petición. Hoy suele hacerse con la cabecera traceparent del estándar W3C Trace Context. Contiene el identificador del trace (16 bytes), el identificador del span actual (8 bytes) y flags, por ejemplo el indicador de muestreo. El servicio recibe la cabecera, crea un span hijo y pasa el contexto al siguiente.

Cómo funciona la autoinstrumentación

La variante manual consiste en que el desarrollador envuelve las llamadas con código de trazado en cada servicio. En equipos con decenas de servicios, esto se convierte rápido en deuda técnica. La autoinstrumentación elimina ese trabajo: un agente se conecta al runtime y añade por sí mismo las mediciones alrededor de las bibliotecas conocidas.

Los mecanismos dependen de la plataforma:

• Java: el agente, mediante -javaagent y java.lang.instrument, modifica el bytecode al cargar las clases, a menudo con ASM o Byte Buddy.
• .NET: se usa la Profiling API del entorno CLR.
• Python y Node.js: se sustituyen funciones en las bibliotecas populares (monkey-patching, hooks de carga de módulos).
• Go y otros lenguajes compilados: suele recurrirse a eBPF o a wrappers manuales, porque el runtime es menos maleable.

El agente conoce los puntos habituales: servidores y clientes HTTP, drivers de bases de datos, clientes de colas. No necesita entender la lógica de negocio para medir una petición entrante, una consulta SQL o la publicación de un mensaje. De estas mediciones nacen los span, que van al colector y de ahí al almacenamiento del APM.

Dónde está el límite de este enfoque

La autoinstrumentación solo ve lo que se ha descrito de antemano. Si el tiempo se va en un algoritmo propio dentro de un método, en un bloqueo sobre un recurso compartido o en un pool de hilos, los hooks estándar mostrarán un único span largo sin explicación. Aquí ayudan los span adicionales alrededor de los tramos críticos y el profiling de hilos.

Otro asunto es la sobrecarga. El agente añade trabajo en cada llamada, por lo que el trazado casi siempre se combina con muestreo. El head-based decide el destino del trace al inicio de la petición y es barato. El tail-based decide cuando la petición ha terminado, así que conserva las peticiones lentas y con errores, pero exige buffering en el colector.

Práctica: por dónde empezar

Si el sistema tiene más de tres o cuatro servicios y los incidentes se analizan a mano con logs, conviene empezar con un conjunto mínimo de pasos:

• Activar la autoinstrumentación en una sola ruta crítica, por ejemplo el proceso de compra, y no en toda la infraestructura a la vez.
• Comprobar que traceparent se propaga de extremo a extremo por el gateway, las colas y los manejadores asíncronos: es donde los trace se cortan con más frecuencia.
• Añadir span manualmente en los tramos donde el agente automático muestra una «caja negra».
• Configurar el muestreo para que las peticiones lentas (por ejemplo, por encima de p95) se conserven siempre.
• Cruzar el resultado con métricas y logs mediante un trace ID común, para que el salto entre señales lleve segundos.

Este enfoque convierte el «el sistema va lento» en datos concretos: 3,1 segundos se fueron en la API externa, 0,6 en la consulta a la base de datos y el resto en la cola. La optimización empieza por ahí, y no por suposiciones.