L'enregistrement des paramètres sur la page Tracing échoue avec une erreur DNS liée au point de terminaison OTLP précédent, même en désactivant entièrement le tracing

Les paramètres de traçage ne peuvent pas être enregistrés ou désactivés une fois que le point de terminaison OTLP configuré devient inaccessible. L’action d’enregistrement revalide l’ancien point de terminaison au lieu du nouveau, bloquant tous les changements, y compris la désactivation du traçage.

Environnement : n8n Cloud, Paramètres → Traçage

Étapes de reproduction :

  1. Activez le traçage OpenTelemetry avec un point de terminaison OTLP valide (dans notre cas, une URL de fonction sans serveur Scaleway).
  2. Ce point de terminaison devient par la suite définitivement inaccessible (la ressource de support a été supprimée ; le DNS ne se résout plus pour ce nom d’hôte).
  3. Tentez de mettre à jour le champ du point de terminaison OTLP avec une nouvelle URL valide et accessible, puis cliquez sur Enregistrer les paramètres.
    → Échoue : Impossible d'enregistrer les paramètres — getaddrinfo ENOTFOUND <ancien nom d'hôte> — notez que cela fait référence à l’ancien nom d’hôte en cours de remplacement, non au nouveau en cours d’enregistrement.
  4. Comme alternative (essayé de contourner), au lieu de changer le point de terminaison, définissez Statut sur Désactivé (désactivation complète du traçage) et cliquez sur Enregistrer les paramètres.
    → Échoue avec exactement la même erreur, même ancien nom d’hôte.

Comportement attendu : L’enregistrement de nouveaux paramètres de traçage, en particulier la désactivation complète du traçage ou la modification du point de terminaison, ne doit pas dépendre de l’accessibilité du point de terminaison en cours de remplacement.

Comportement actuel : Tout enregistrement de paramètres sur cette page semble revalider la connectivité au point de terminaison précédemment enregistré avant de persister tout changement, y compris la désactivation de la fonctionnalité. Une fois ce point de terminaison définitivement mort, les paramètres de traçage deviennent effectivement bloqués : il n’existe aucun moyen de les modifier ou les désactiver via l’interface utilisateur.

Impact : Incapacité totale à mettre à jour ou désactiver la configuration de traçage OpenTelemetry une fois que le collecteur configuré devient inaccessible.

Le problème est essentiellement une question de la façon dont n8n enregistre ses paramètres de traçage OpenTelemetry.

La fonctionnalité de traçage envoie des informations de surveillance de n8n vers un autre serveur appelé point de terminaison OTLP. Dans ce cas, le point de terminaison OTLP d’origine a été supprimé, son domaine ne peut donc plus être trouvé. C’est pourquoi n8n retourne l’erreur getaddrinfo ENOTFOUND.

La partie étrange est que n8n semble vérifier le ancien point de terminaison avant d’enregistrer les nouveaux paramètres.

Par exemple, si l’ancien point de terminaison était :

old-server.com

et que je le change en :

new-server.com

n8n essaie toujours de contacter old-server.com avant d’enregistrer la modification. Puisque ce serveur n’existe plus, l’opération d’enregistrement échoue.

Même si je désactive complètement le traçage, n8n vérifie toujours l’ancien point de terminaison et produit la même erreur.

Donc le problème n’est pas simplement que le point de terminaison de traçage n’est pas disponible. Le vrai problème est que le point de terminaison non disponible empêche la configuration du traçage d’être modifiée ou désactivée.

En termes simples, n8n est bloqué en essayant de vérifier une ancienne adresse qui n’existe plus, même quand j’essaie de remplacer ou de supprimer cette adresse.

Le comportement attendu est que n8n devrait permettre à l’utilisateur de modifier ou de désactiver le traçage sans que l’ancien point de terminaison soit toujours accessible.

Bonjour @Mark_Schuddeboom

Cela se produit parce que n8n tente d’arrêter ou d’effacer l’exportateur OpenTelemetry actif pendant que le système est en cours d’enregistrement. Cela provoque une erreur DNS non gérée sur le point de terminaison mort avant que la nouvelle configuration ne prenne effet.

Il existe plusieurs façons de résoudre ce problème.

Une option consiste à utiliser des variables d’environnement pour ce faire. Pour arrêter ou remplacer le suivi, modifiez-le dans votre configuration d’environnement n8n et non dans l’interface utilisateur.

N8N_OTEL_TRACING_ENABLED=false

Mappage temporaire du host/DNS local : Ajoutez une entrée temporaire à votre serveur DNS ou à votre fichier /etc/hosts local. Cette entrée doit rediriger l’ancien domaine vers une adresse IP locale fictive (comme 127.0.0.1). Une fois que n8n a résolu l’ancien point de terminaison, vous pourrez enregistrer ou désactiver le suivi dans l’interface utilisateur.

Mise à jour de la base de données (auto-hébergée/cloud) : Pour corriger cela, accédez à la table des paramètres de votre base de données n8n, trouvez les valeurs de configuration du suivi et modifiez-les. Ensuite, redémarrez l’instance.

J’espère que cela vous aide.

Merci pour les réponses,
Bien qu’elles n’aient pas aidé (@Lopez c’est hébergé dans le cloud donc pas d’accès aux variables d’environnement ou à la base de données, le routage DNS temporaire n’était pas disponible car c’est un endpoint Scaleway donc je n’y ai pas accès)
Mais c’est résolu tout seul ! Probablement qu’un timeout sans bonne réponse a effacé le bug, ça vaut quand même la peine de noter que c’est un obstacle.