OpenTelemetry
OpenTelemetry est un projet open source qui facilite l’instrumentation pour la collecte de données de télémétrie standardisée. Cela signifie que vous pouvez facilement intégrer vos données avec AppSignal ou un autre fournisseur de votre choix. Vous n’êtes pas enfermé dans les services d’un seul fournisseur. Comme OpenTelemetry est un projet open source, tout le monde peut collaborer sur les mêmes intégrations de base afin de fournir une instrumentation au bénéfice de tous. OpenTelemetry prend actuellement en charge plusieurs langages de programmation populaires, dont Node.js. OpenTelemetry se compose de plusieurs éléments : le traçage, les métriques et les logs. Ces éléments sont encore en cours de développement dans la plupart des langages de programmation, le traçage étant l’élément le plus stable dans de nombreux langages. Nous prenons en charge le composant de traçage d’OpenTelemetry dans notre intégration Node.js afin de fournir un meilleur reporting d’erreurs et des mesures de performance. En savoir plus sur OpenTelemetry via le site officiel du projet.Bibliothèques prises en charge
Notre intégration prend en charge les bibliothèques et frameworks suivants :- Node.js Core
- Apollo Gateway
- BullMQ
- Elasticsearch
- Express
- Fastify
- GraphQL (comme Apollo Server ou Yoga)
- Knex.js
- Koa.js
- MongoDB
- Mongoose
- MySQL (paquets mysql et mysql2)
- NestJS
- Next.js
- PostgreSQL
- Prisma
- Redis (paquets redis et ioredis)
- Remix
- Restify
Environnements pris en charge
🔧 La prise en charge de Node.js est définie sur notre page de politique de
maintenance.
- Applications Electron : nous ne recommandons pas l’utilisation de @appsignal/nodejs dans les applications Electron. Comme nous avons conçu l’agent pour s’exécuter sur un serveur, il n’est actuellement pas utile dans cet environnement. Cela entraînera également une complexité possiblement indésirable autour de la compilation croisée de l’extension native.
- Processus de courte durée : les processus de courte durée, tels que les outils CLI, conviennent mal à l’agent, qui doit pouvoir rester en cours d’exécution pendant un certain temps (au moins 60 secondes).
- Fonctions serverless : les fonctions serverless sont conçues pour être des processus de courte durée, elles sont donc également peu adaptées à l’agent.
- Applications générées statiquement : certains environnements (par exemple Gatsby.js, Svelte) offrent un certain accès aux API Node.js, mais compilent finalement leur code en une application côté client, et ne conviennent donc pas à la bibliothèque Node.js.