Les traces Node.js se brisent à chaque await. L'agent ARMS d'Alibaba les recoud

Un utilisateur signale que « l'assistant IA a mis une éternité à répondre cette fois-ci ». L'API d'entrée affiche un temps de réponse élevé. La base de données ne montre aucun SQL lent. Le taux de succès Redis est normal. Les journaux sont propres. Cette check-list suffisait autrefois à clore le dossier. Dans un service Node.js orchestrant des agents IA, l'explication peut se cacher n'importe où : dans un appel d'outil LangChain, dans un pic du temps jusqu'au premier jeton (TTFT) du modèle, ou dans un blocage de 200 millisecondes sur la boucle d'événements.

C'est ce scénario qui explique l'existence de l'agent ARMS Node.js d'Alibaba Cloud, et il cible un problème pour lequel les outils APM n'ont pas été conçus. Les services Node.js ne se contentent plus de recevoir des requêtes, d'interroger des bases de données et de renvoyer du JSON. Ils agissent comme backends pour frontend (BFF), passerelles API, hubs de communication en temps réel, consommateurs de files d'attente et couches d'orchestration d'agents IA. Une seule requête peut traverser HTTP, des bases de données, des caches, des RPC, des files de messages, des ressources d'exécution et des LLM. Ce qui manquait n'a jamais été les données de monitoring. C'est le contexte.

Le problème de convergence des traces

Lorsque Node.js se situe entre l'utilisateur et chaque dépendance en aval, un point d'entrée lent est interprété comme un problème Node.js, même lorsque la cause racine se trouve dans la base de données, le cache, un RPC en aval ou une invocation de modèle. La conception même du runtime rend la corrélation plus difficile. Node.js est construit autour des Promises, d'async/await, des minuteurs, des callbacks et de la boucle d'événements, et chacun d'eux est un endroit où un ID de trace peut se perdre. Une fois l'ID perdu à travers une frontière asynchrone, la trace se brise en morceaux, ne laissant que des spans isolés et des journaux éparpillés.

Pourquoi la santé d'exécution se reflète dans la latence des API

Une API lente ne signifie pas toujours un SQL lent. Cela peut être une boucle d'événements bloquée par un travail synchrone pendant 200 millisecondes, un tas V8 qui ne cesse de grimper jusqu'à ce que le garbage collection provoque des à-coups, une utilisation anormale du CPU, ou un processus qui épuise ses ressources. Les journaux d'API classiques ne permettent pas de savoir si le runtime lui-même est sain. L'agent collecte les métriques d'exécution via son MeterManager et les transmet compressées avec gzip et protobuf, afin que vous puissiez demander à la fois quelle trace est lente et pourquoi tout le service est lent. Le nombre de threads rapporté est une estimation basée sur les cœurs CPU et la taille du pool de threads libuv, destinée à l'observation des tendances, pas à des valeurs exactes.

Les appels IA sont une nouvelle cible d'observabilité

Node.js devient la couche côté serveur des applications IA. Les équipes construisent des services clients intelligents, des assistants de codage, des agents d'analyse de données et des outils de productivité internes sur le SDK OpenAI, LangChain.js, LangGraph, le SDK Vercel AI et le SDK Anthropic Claude. Une requête est désormais HTTP plus une base de données plus des invocations de modèle, de l'orchestration, du streaming, des appels d'outils, des embeddings et des recherches RAG.

L'instrumentation IA intégrée de l'agent couvre ces frameworks et enrichit les traces avec la sémantique GenAI : invocations de modèle, utilisation de tokens, réponses en streaming, appels d'outils et détails d'erreur. Le bénéfice est que personne n'a besoin de recouper les journaux de la plateforme de modèles, les journaux métier et les journaux de traces pour répondre à une seule question sur une seule requête utilisateur.

Un seul package npm, trois voies d'intégration

Le package est @loongsuite/cms_node_sdk, où « cms » est une convention de nommage héritée ; côté produit, il fait office d'agent ARMS Node.js. Il est construit sur le modèle de données OpenTelemetry de base et câblé de bout en bout à ARMS. Les projets CommonJS le préchargent, les projets ESM utilisent un hook de chargement, et les projets qui souhaitent un contrôle explicite démarrent le SDK dans le code :

# CommonJS: preload before the app starts
export ARMS_APP_NAME=your-app
export ARMS_REGION_ID=cn-hangzhou
export ARMS_LICENSE_KEY=your-license-key
node -r @loongsuite/cms_node_sdk/register app.js

# ESM: loader injection
node, experimental-loader=@loongsuite/cms_node_sdk/import-hooks app.mjs

const { NodeSDK } = require('@loongsuite/cms_node_sdk');
const sdk = new NodeSDK({
  serviceName: 'your-app',
  licenseKey: 'your-license-key',
  regionId: 'cn-hangzhou',
  workspace: 'your-workspace',
});
sdk.start();

La voie ESM utilise import-in-the-middle pour l'interception des modules, et la documentation conseille de vérifier la séquence de chargement des modules dans un environnement de test si votre projet combine plusieurs loaders. La voie programmatique doit s'exécuter avant l'importation de tout module métier, sinon les modules HTTP, base de données et cache ne seront pas instrumentés. L'agent injecte également le contexte de trace dans les loggers tels que Console, Pino, Winston et Bunyan, afin que les journaux et les traces soient interrogés ensemble.

Le contexte s'appuie sur AsyncLocalStorage par défaut, avec repli sur AsyncHooks uniquement sur les runtimes plus anciens, afin que les spans survivent aux Promises, aux callbacks et aux minuteurs. La propagation W3C Trace Context et Baggage permet à un service Node.js de rejoindre des services Java, Go ou Python dans une seule topologie au lieu de rester isolé. L'instrumentation intégrée couvre les chemins que le travail Node.js côté serveur touche réellement :

Le compromis : des briques de base contre un produit fini

La façon la plus claire de lire cet agent est d'y voir une décision produit à propos d'OpenTelemetry. La norme open source fournit les briques de base, mais quelqu'un doit quand même choisir un exportateur, configurer l'échantillonnage, sélectionner les plugins, normaliser les attributs de ressources, corréler les journaux et résoudre l'observabilité IA. L'agent ARMS répond à ces questions à l'avance et rend les réponses modifiables depuis une console : il récupère la configuration distante environ 60 secondes après le démarrage, puis toutes les 60 secondes, sans redémarrage nécessaire. Pendant les pics de trafic, vous pouvez baisser le taux d'échantillonnage, désactiver un plugin qui entre en conflit avec une version de bibliothèque métier, ou augmenter l'échantillonnage pour une session de débogage puis revenir en arrière.

Les APM traditionnels couvrent les API et les bases de données mais négligent souvent les appels IA ; les outils d'observabilité IA suivent les prompts, les tokens et les traces de modèles mais ne disposent ni de métriques d'exécution ni des fonctions APM essentielles. Cet agent est la tentative d'Alibaba d'avoir les deux dans un seul package. Sa conception est délibérément peu intrusive : export par lots, transport compressé, échantillonnage, interrupteurs de plugins, protection contre les exceptions afin que les défaillances d'instrumentation n'affectent pas le flux métier, et un arrêt propre qui vide les données mises en mémoire tampon sur SIGINT et SIGTERM. Les exigences sont modestes : Node.js 16.x ou supérieur, 18 ou 20 LTS pour la production, et une LicenseKey ARMS et un ID de région.

L'argument est que l'observabilité Node.js devrait être aussi simple que d'installer un package npm. Pour les équipes déjà présentes dans l'écosystème d'observabilité d'Alibaba Cloud, c'est un agent prêt à l'emploi plutôt qu'un ensemble de composants à assembler. La question, que le cadrage même du fournisseur laisse ouverte, est de savoir si les équipes qui exploitent OpenTelemetry auto-géré considèrent un agent lié à ARMS comme une mise à niveau ou comme un verrouillage.