Les Vercel Daemons peuvent désormais envoyer leurs traces directement à Vercel Tracing

L'annonce

Le 13 novembre 2026, Vercel a annoncé dans son journal des modifications que les Vercel Daemons peuvent désormais envoyer des traces OpenTelemetry à Vercel Tracing. Selon Vercel, cela permet à vous et à vos agents d'inspecter les opérations des processus d'arrière-plan à côté des autres traces de votre projet. L'article est signé de Gal Schlezinger, ingénieur logiciel de l'équipe infrastructure de Vercel. Il est indiqué comme une lecture d'une minute. Il est court, mais les détails sont concrets.

Comment cela fonctionne

L'annonce décrit trois étapes. Premièrement, Vercel fournit à chaque daemon un socket Unix qui reçoit des traces au format OTLP/HTTP, et il inscrit le chemin de ce socket dans la variable d'environnement VERCEL_OTEL_SOCKET_PATH. Deuxièmement, on met à jour @vercel/otel vers la version 2.3.0 ou une version plus récente. Avec cette version, les daemons Node.js qui utilisent la configuration par défaut exportent leurs traces automatiquement : le SDK détecte le socket et envoie à Vercel les spans que le processus enregistre. Troisièmement, on initialise OpenTelemetry avant le démarrage du processus. L'exemple officiel tient en deux lignes dans worker.ts. Il importe registerOTel et l'appelle avec un serviceName égal à 'my-daemon'. Le nom du service est au choix du développeur.

Comment lire les données

Les spans sont accessibles par la CLI de Vercel. La commande de l'annonce est vercel traces search, avec --project pour désigner le projet, --service pour le service et --json pour obtenir du JSON. Vercel explique qu'on peut chercher par nom de service au sein d'un projet et recevoir du JSON pour ses agents. La légende de l'exemple précise qu'il cherche les spans de daemon de la dernière heure. L'article se termine par un lien vers la documentation du traçage des daemons. Pour tout ce qui dépasse ces lignes, la documentation fait référence.

Pourquoi c'est utile

Cette section est notre lecture, pas le texte de l'annonce. Un processus d'arrière-plan n'a pas de requête de page comme point d'entrée évident. Quand il se comporte mal, le développeur n'a souvent que des journaux à lire. Une trace découpe une opération en spans chronométrés, ce qui montre quelle étape a pris le temps. L'intérêt pratique de ce changement est que les spans des daemons apparaissent au même endroit que les autres traces du projet. Il n'y a pas de chaîne de collecte distincte à monter, et on n'a pas à choisir où envoyer les données, puisque la plateforme donne le chemin par une variable d'environnement et que le SDK le trouve. Recevoir sur un socket Unix signifie aussi que les données circulent à l'intérieur de la machine, donc un daemon n'a pas besoin d'une adresse de collecteur externe. L'article n'aborde pas ce point, nous le présentons seulement comme une remarque générale.

Un second point est que la fonction est adaptée aux agents. L'article dit que la CLI peut renvoyer du JSON pour les agents. Demander à un agent de code ou d'exploitation d'interroger les spans de daemon de la dernière heure est donc un usage que Vercel envisage lui-même. Cela rejoint une tendance plus large : les plateformes ouvrent leurs données d'observabilité aux outils automatisés.

Limites à garder en tête

L'annonce dit seulement que les daemons Node.js avec la configuration par défaut exportent leurs traces automatiquement, et elle demande @vercel/otel 2.3.0 ou plus récent. Elle ne dit rien des autres environnements d'exécution, des configurations personnalisées, de l'échantillonnage, de la conservation ni des tarifs, et nous ne ferons pas de supposition. Consultez la documentation si vous avez besoin de ces réponses. L'article ne précise pas non plus si la fonction est ouverte à toutes les formules, ni si le daemon lui-même impose une version minimale. Vérifiez les deux avant de vous y fier. L'exemple insiste sur le fait qu'OpenTelemetry doit démarrer avant le processus. Il est logique que ce qui s'exécute plus tôt puisse ne pas être enregistré, mais l'article n'en énonce pas la conséquence.

En résumé

C'est une mise à jour modeste et pratique. Pour un daemon Node.js en configuration par défaut avec socket Unix fourni par la plateforme, mettez @vercel/otel à 2.3.0 ou plus, appelez registerOTel avant le démarrage du processus, et les spans du daemon apparaissent dans Vercel Tracing, où vercel traces search peut les renvoyer en JSON. Pour les équipes qui exécutent déjà des tâches d'arrière-plan sur Vercel Daemons, le coût du changement est faible, et la fonction mérite un essai.