Requisitos de compatibilidad de Node.js
Versiones
Control de versiones
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.
Mantenimiento
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.
Si tienes alguna pregunta o duda sobre nuestro soporte técnico para una versión concreta de dd-trace-js
, ponte en contacto con el servicio de soporte técnico para hablar de ello.
Soporte técnico de versiones de Node.js
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.
Para más información sobre la versión de Node.js, consulta la documentación oficial de Node.js.
Soporte técnico de sistemas operativos
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.
Versión de dd-trace | Sistema operativo | Arquitecturas | Versiones mínimas |
---|
3.x | Linux (glibc) | arm, arm64, x64 | CentOS 7, Debian 9, RHEL 7, Ubuntu 14.04 |
| Linux (musl) | arm, arm64, x64 | Alpine 3.13 |
| macOS | arm64, x64 | Catalina (10.15) |
| Windows | ia32, x64 | Windows 8.1, Windows Server 2012 |
2.x | Linux (glibc) | arm, arm64, ia32, x64 | CentOS 7, Debian 9, RHEL 7, Ubuntu 14.04 |
| Linux (musl) | arm, arm64, ia32, x64 | Alpine 3.10 |
| macOS | arm64, x64 | Yosemite (10.10) |
| Windows | ia32, x64 | Windows 8.1, Windows Server 2012 |
Integraciones con soporte técnico
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.
Compatibilidad con marcos web
Módulo | Versiones | Tipo de soporte técnico | Notas |
---|
connect | >=2 | Totalmente compatible | |
express | >=4 | Totalmente compatible | Compatible con Sails, Loopback y más |
fastify | >=1 | Totalmente compatible | |
graphql | >=0.10 | Totalmente compatible | Compatible con Apollo Server y express-graphql |
graphql-yoga | >=3.6.0 | Totalmente compatible | Compatible con el ejecutor graphql-yoga v3 |
gRPC | >=1.13 | Totalmente compatible | |
hapi | >=2 | Totalmente compatible | Admite versiones [@hapi/hapi] >=17.9 |
koa | >=2 | Totalmente compatible | |
microgateway-core | >=2.1 | Totalmente compatible | Biblioteca de núcleo para Apigee Edge. La compatibilidad con la CLI edgemicro requiere la aplicación de parches estáticos mediante @Datadog/cli. |
moleculer | >=0.14 | Totalmente compatible | |
next | >=9.5 | Totalmente compatible | Consulta la nota sobre el uso de Complex framework.
El rastreador admite las siguientes funciones de Next.js:- Standalone (
output: 'standalone' ) - App Router
- Middleware: no rastreado, utiliza las versiones del rastreador
4.18.0 y 3.39.0 o superiores para obtener la mejor experiencia.
|
paperplane | >=2.3 | Totalmente compatible | No se admite en modo sin servidor |
restify | >=3 | Totalmente compatible | |
Uso de marco complejo
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.
Compatibilidad con módulos nativos
Módulo | Tipo de soporte técnico | Notas |
---|
dns | Totalmente compatible | |
http | Totalmente compatible | |
https | Totalmente compatible | |
http2 | Compatibilidad parcial | Actualmente solo se admiten clientes HTTP2 y no servidores. |
net | Totalmente compatible | |
Compatibilidad con almacenes de datos
Módulo | Versiones | Tipo de soporte técnico | Notas |
---|
cassandra-driver | >=3 | Totalmente compatible | |
couchbase | ^2.4.2 | Totalmente compatible | |
elasticsearch | >=10 | Totalmente compatible | Compatible con las versiones de @elastic/elasticsearch >=5 |
ioredis | >=2 | Totalmente compatible | |
knex | >=0.8 | Totalmente compatible | Esta integración es solo para la propagación de contexto |
mariadb | >=3 | Totalmente compatible | |
memcached | >=2.2 | Totalmente compatible | |
mongodb-core | >=2 | Totalmente compatible | Compatible con Mongoose |
mysql | >=2 | Totalmente compatible | |
mysql2 | >=1 | Totalmente compatible | |
oracledb | >=5 | Totalmente compatible | |
pg | >=4 | Totalmente compatible | Admite pg-native cuando se utiliza con pg |
redis | >=0.12 | Totalmente compatible | |
sharedb | >=1 | Totalmente compatible | |
tedious | >=1 | Totalmente compatible | Controlador de SQL Server para mssql y sequelize |
Compatibilidad con Worker
Módulo | Versiones | Tipo de soporte técnico | Notas |
---|
@google-cloud/pubsub | >=1.2 | Totalmente compatible | |
amqp10 | >=3 | Totalmente compatible | Compatible con brokers AMQP 1.0 (como ActiveMQ o Apache Qpid) |
amqplib | >=0.5 | Totalmente compatible | Compatible con brokers AMQP 0.9 (como RabbitMQ o Apache Qpid) |
generic-pool | >=2 | Totalmente compatible | |
kafkajs | >=1.4 | Totalmente compatible | |
rhea | >=1 | Totalmente compatible | |
Compatibilidad con SDK
Módulo | Versiones | Tipo de soporte técnico | Notas |
---|
aws-sdk | >=2.1.35 | Totalmente compatible | CloudWatch, DynamoDB, Kinesis, Redshift, S3, SNS, SQS y solicitudes genéricas. |
openai | 3.x | Totalmente compatible | |
Compatibilidad con biblioteca Promise
Módulo | Versiones | Tipo de soporte ténico |
---|
bluebird | >=2 | Totalmente compatible |
promise | >=7 | Totalmente compatible |
promise-js | >=0.0.3 | Totalmente compatible |
q | >=1 | Totalmente compatible |
when | >=3 | Totalmente compatible |
Compatibilidad con registradores
Módulo | Versiones | Tipo de soporte técnico |
---|
bunyan | >=1 | Totalmente compatible |
paperplane | >=2.3.2 | Totalmente compatible |
pino | >=2 | Totalmente compatible |
winston | >=1 | Totalmente compatible |
Bibliotecas sin soporte técnico
Fibers
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.
Para más información o para debatir deja un comentario en este tema de github o ponte en contacto con el servicio de soporte técnico para seguir hablando.
Leer más
Additional helpful documentation, links, and articles: