El control de versiones de la biblioteca de rastreo de Datadog Node.js sigue control de versiones semántico. Cuando se publica una nueva versión principal, se convierte en la línea de publicación principal, donde aterrizan todas las nuevas funciones, correcciones de errores y parches de seguridad. Aquí hay un esquema de lo que constituye cada tipo de cambio de control de versiones semántico:
Principal
Secundaria
Parche
Cambios incompatibles con versiones anteriores
Añadir cualquier cosa que sea compatible con versiones anteriores (no las interrumpe)
Correcciones de seguridad
Cambios en la API incompatibles con versiones anteriores
Incorporaciones a la API
Corrección de errores
Cambios de funcionalidad incompatibles con versiones anteriores
Funciones adicionales
Dejar de dar soporte técnico a, por ejemplo, versiones de Node.js, bibliotecas con soporte técnico u otras funciones
Añadir soporte técnico probado para, por ejemplo, versiones de Node.js, bibliotecas con soporte técnico u otras funciones
Cuando una versión tiene cambios que podrían estar en múltiples categorías de control de versiones semántico, se elige la más alta. Las Notas de lanzamiento se publican con cada versión de GitHub.
El modo de mantenimiento es un periodo durante el cual una versión recibe solo correcciones de seguridad y de errores siempre que sea posible, pero no nuevas funciones, salvo en casos concretos. Las versiones principales de dd-trace entran en el modo de mantenimiento cuando se lanza la siguiente versión principal de dd-trace. El periodo de mantenimiento dura un año después de la fecha de lanzamiento de la versión posterior.
Por ejemplo, si la versión 5.0.0 de dd-trace se lanza el 4 de mayo de 2023, la línea de versiones 4.x.x tendrá soporte técnico en el modo de mantenimiento hasta el 4 de mayo de 2024. Durante este periodo de modo de mantenimiento, se aplicarán parches de seguridad y errores siempre que sea posible.
Cuando el proyecto Node.js deja de dar soporte técnico a una línea de versión principal LTS (cuando pasa a EOL), se le deja de dar soporte técnico en la siguiente versión principal de dd-trace.
La última línea de versión principal que da soporte técnico de la biblioteca de dd-trace brinda soporte técnico a esa versión EOL de Node.js durante por lo menos otro año en el modo de mantenimiento.
Algunos problemas no pueden resolverse en dd-trace y deben solucionarse en Node.js. Cuando esto ocurre y la versión de Node.js en cuestión es EOL, no es posible resolver el problema sin pasar a otra versión que no sea EOL.
En Datadog no se realizan nuevas versiones de dd-trace para ofrecer soporte técnico para las líneas de versiones principales de Node.js que no son LTS (versiones impares).
Para obtener el mejor nivel de soporte técnico, ejecuta siempre la última versión LTS de Node.js, y la última versión principal de dd-trace. Sea cual sea la línea de lanzamiento de Node.js que utilices, utiliza también la última versión de Node.js en esa línea de lanzamiento, para asegurarte de que tenga las últimas correcciones de seguridad.
Los siguientes sistemas operativos tienen soporte técnico oficial de dd-trace. Es probable que cualquier sistema operativo que no aparezca en la lista siga funcionando, pero con algunas funciones ausentes, por ejemplo ASM, perfilado y métricas de tiempo de ejecución. Hablando en general, se brinda soporte técnico a los sistemas operativos que se mantienen activamente en el momento del lanzamiento inicial de una versión principal.
APM proporciona Instrumentación predefinida para muchos marcos de trabajo populares y bibliotecas mediante un sistema de extensiones. Para solicitar soporte técnico para un módulo que no está en la lista, contacta con nuestro impresionante equipo de soporte técnico.
Para obtener más información sobre cómo intercambiar y configurar las extensiones, restaura la documentación de la API.
Algunos marcos de Node.js modernos y complejos, como Next.js y Nest.js, proporcionan su propio punto de entrada a una aplicación. Por ejemplo, en lugar de ejecutar node app.js, puede que necesites ejecutar next start. En estos casos, el punto de entrada es un archivo que viene en el paquete de marco, no un archivo local de la aplicación (app.js).
Cargar el rastreador de Datadog al principio del código de la aplicación no es efectivo porque el marco podría haber cargado ya módulos que deberían instrumentarse.
Para cargar el rastreador antes que el marco, utiliza uno de los siguientes métodos:
Antepón a todos los comandos que ejecutes una variable entorno:
NODE_OPTIONS='--require dd-trace/init' npm start
O bien, modifica el archivo `package.json` si sueles iniciar una aplicación con scripts de ejecución npm o yarn:
```plain
// comando existente
"start": "next start",
// comando sugerido
"start": "node --require dd-trace/initialize ./node_modules/next start",
"start": "NODE_OPTIONS='--require dd-trace/initialize' ./node_modules/next start",
Nota: Los ejemplos anteriores utilizan Next.js, pero el mismo enfoque se aplica a otros marcos con puntos de entrada personalizados, como Nest.js. Adapta los comandos a tu marco y configuración específicos. Cualquiera de los comandos debería funcionar, pero el uso de NODE_OPTIONS también se aplica a cualquier proceso secundario de Node.js.
fibers es incompatible con async_hooks, un [módulo] de Node.js60 utilizado por dd-trace-js para rastrear contextos asíncronos asegurando así un rastreo preciso. Las interacciones entre fibers y async_hooks pueden dar lugar a bloqueos imprevisibles y comportamientos indefinidos. Así, el uso de dd-trace-js con aplicaciones que invocan fibers directa o indirectamente a través de marcos como Meteor puede derivar en inestabilidad (bloqueos) o rastreo incorrecto.
