Bonjour à tous,
J’exécute plusieurs instances n8n sur Google Cloud Run en utilisant une seule clé de licence.
Quelle est la meilleure façon de suivre l’utilisation par déploiement/tenant (exécutions, workflows actifs, utilisation de l’API, etc.) ?
Salut @rgrzesk
Je pense que la meilleure façon est d’utiliser les insights :
Mais si tu veux plusieurs instances de données dans un seul cadre, je te recommande ceci :
Je l’ai utilisé, et ça fonctionne tout le temps.
Tu peux aussi simplement appeler l’API N8N :
GET /api/v1/executions?status=success&limit=250
Si tu ne suis pas sur le cloud n8n, l’option de métriques Ud est la meilleure.
Cela t’aide-t-il, @rgrzesk ?
Pour le suivi sur plusieurs instances Cloud Run dans un seul endroit, l’approche d’interrogation d’API ne pourra pas bien évoluer - chaque instance a son propre point de terminaison API et il n’y a pas de vue unifiée. Un motif plus propre est d’ajouter un workflow « logger d’exécution » dédié à chaque instance : il s’exécute selon un calendrier, appelle GET /api/v1/executions avec une fenêtre de temps, ajoute une balise instance_id, et publie les résultats dans une table Postgres partagée ou une feuille Google. Vous disposez alors d’un seul endroit centralisé pour interroger l’utilisation sur toutes les instances. Vous pouvez inclure le nom du service Cloud Run comme identifiant d’instance via une variable d’environnement injectée au moment du déploiement.
Celui-ci semble vraiment sympa, mais le problème est que je n’ai pas accès à chaque instance et je n’en aurai pas. Je peux l’orchestrer, mais je ne peux pas être un utilisateur.
Je devrais créer un tel flux de travail prédéfini lors du déploiement, mais j’imagine que ce n’est pas possible de le faire facilement. Le seul moyen est d’utiliser d’une manière ou d’une autre des données publiquement disponibles. Est-il possible d’utiliser le point de terminaison /metric ? Aurai-je assez de données que je pourrais utiliser ?
Si vous n’avez pas accès à l’API ou aux utilisateurs pour chaque instance, je traiterais /metrics comme un signal d’infrastructure partiel, et non comme un modèle d’utilisation complet.
Cela peut aider à répondre à des questions comme « cette instance fonctionne-t-elle, à quel point est-elle occupée, les exécutions échouent-elles plus que d’habitude », mais cela ne vous donnera généralement pas une attribution métier claire comme l’utilisation des locataires, le nombre de workflows actifs par client, ou les appels d’API facturables, sauf si vous avez conçu le déploiement autour de ces labels dès le début.
Pour votre cas, puisque vous pouvez orchestrer le déploiement, je vous suggérerais de déplacer la limite du suivi dans le modèle de déploiement :
-
donnez à chaque service Cloud Run un label
deployment_id/tenant_idstable -
activez l’export des métriques et des logs au moment du déploiement, pas après que le client commence à l’utiliser
-
assurez-vous que les logs Cloud Run incluent le même label de déploiement
-
si possible, pré-installez un petit workflow de logging interne lors du provisionnement
-
si l’accès aux workflows n’est pas possible, collectez au moins la santé de l’instance, les totaux d’exécution, les échecs, la latence et les signaux de redémarrage/erreur de façon centralisée
L’important est que l’ID doit exister en dehors de n8n aussi. Si chaque instance émet des métriques mais qu’elles arrivent sans un label de déploiement stable, vous finirez quand même avec une pile globale de nombres qu’il est difficile de réconcilier.
Donc j’utiliserais /metrics pour la surveillance opérationnelle, mais ne compterais pas dessus seul pour la création de rapports de locataires/clients. Pour la création de rapports d’utilisation, je voudrais soit un workflow de logging prédéfini, un accès à l’API, soit des labels au niveau du déploiement que votre collecteur ajoute avant que les données ne se retrouvent dans le magasin central.
Merci, c’est logique.
Qu’en est-il d’utiliser la DB comme source de vérité pour l’historique/l’utilisation des licences ? Serait-ce judicieux, est-ce qu’elle conserve les données dont j’ai besoin ?
Vérifier par execution_entity et compter tous ceux qui ne sont pas marqués comme manual ?
Salut @rgrzesk
il y a une autre approche pour ta configuration : OpenTelemetry tracing. Comme tu contrôles le déploiement, définis ces variables d’environnement lors du provisioning :
N8N_OTEL_TRACE_ENABLED=true
N8N_OTEL_TRACE_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=https://your-central-collector:4318
Chaque exécution émet un span workflow.execute avec le mode d’exécution, le statut, l’ID du flux de travail et l’n8n.instance.id unique de l’instance. Pointe toutes les instances vers un seul collecteur (Jaeger, Grafana Tempo, etc.) et tu obtiens un suivi par instance, par exécution avec filtrage du mode. Aucun accès à la DB nécessaire, aucun risque de pruning, protocole standard, et c’est configuré entièrement au moment du déploiement ce qui correspond parfaitement à tes contraintes.
Pour la route DB en secours : oui, execution_entity avec mode != 'manual' fonctionne, mais sache que le pruning supprime ces enregistrements en fonction de EXECUTIONS_DATA_MAX_AGE. Agrège dans ton propre stockage selon un calendrier plus court que la fenêtre de pruning.
Fais-moi savoir si ça t’aide 
Bien vu !
OL est une bonne solution pour les nouvelles instances. Serait-on capable de récupérer également les données historiques ?
OTel ne capture que depuis le moment où il est activé, pas de traces rétroactives.
Pour les données historiques sur les instances existantes, deux options puisque vous avez accès à la base de données :
-
Table
execution_entity: interrogezmode != 'manual'pour les comptes de production. Seulement aussi loin que le nettoyage le permet. -
Tables Insights : n8n stocke les données d’insights compactées séparément de execution_entity, conservées jusqu’à 365 jours par défaut (
N8N_INSIGHTS_MAX_AGE_DAYS). Cela survit au nettoyage des exécutions. Vérifiez les tablesinsight_*dans votre schéma Postgres pour les comptes historiques agrégés.
Pour tout ce qui est plus ancien que ce qui se trouve dans la base de données, c’est perdu.
Salut !
J’ai pris une pause assez longue sur le sujet, mais je reviens 
C’est sympa que depuis la version 2.27.0 je puisse aussi configurer OpenTelemetry dans l’interface.
Cependant, j’ai deux questions :
- Puis-je masquer ces options ? Parce que ça révèle la clé API du système OpenTelemetry.
- À quel execution.mode dois-je regarder dans OTL ? Je veux dire - lesquels d’entre eux sont facturables ? Y compris les !manual ?
ÉDIT - pour la question 2. - Je viens de remarquer qu’il y a déjà un flag N8N_OTEL_TRACES_PRODUCTION_ONLY
Il n’existe pas de bascule intégrée pour masquer le champ de clé API OTel dans Paramètres — c’est une lacune connue, suivie comme demande de fonctionnalité ici : OpenTelemetry visible UI . En attendant que cela soit implémenté, la solution de contournement consiste à restreindre qui peut accéder aux Paramètres via RBAC/rôles de projet, ou à définir les variables d’environnement OTel directement (N8N_OTEL_*) au lieu de l’interface utilisateur afin que la clé ne s’affiche jamais là.
Sur execution.mode : seules les exécutions déclenchées en production sont comptabilisées dans votre quota facturable (webhook, horaire, sondage avec données). Les exécutions « manuelles » ne sont jamais comptabilisées, pas plus que les appels de sous-flux de travail, les exécutions de flux d’erreur ou les sondages vides. Filtrez donc votre requête OTel/insights sur mode != ‘manual’ comme houda_ben l’a suggéré, et vous regardez déjà le bon ensemble facturable.
Qu’est-ce que le mode « intégré » ? Est-ce qu’il compte aussi ?
Comment les sous-workflows sont-ils visibles alors s’ils ne comptent pas - comme manuels ?
« integrated » est le mode défini lorsqu’un workflow s’exécute en tant que sous-workflow appelé via le nœud Execute Workflow, et il ne porte pas la distinction manual/production du parent sur son propre enregistrement d’exécution. Pour la facturation, les appels de sous-workflow ne sont comptabilisés au quota du parent que si l’exécution du parent elle-même a été déclenchée en production : un parent en production déclenche des exécutions d’enfants intégrés facturables, les exécutions d’enfants intégrés d’un parent manuel restent non facturables. Lors du rapprochement des comptages dans OTel/Insights, filtrez donc sur le mode du parent, et non sur le champ de mode propre du sous-workflow.
Shameless plug pour LumaTrack, nous pouvons faire cela assez facilement avec notre nœud communautaire vérifié, OTel, MCP, API, etc.
ok, donc si je te comprends bien, si nous avons une exécution de production qui déclenche 5 sous-workflows différents et que ces 5 sous-workflows s’exécutent (par ex. les conditions sont remplies), nous payons une seule fois pour l’exécution de production principale ?
@rgrzesk Oui, c’est correct. La facturation dépend du mode d’exécution du flux de travail parent, et non de celui de chaque sous-flux de travail individuellement. Donc si le flux de travail principal est déclenché en mode production (webhook/planning/sondage) et qu’il appelle 5 sous-flux de travail via Execute Workflow, ces exécutions enfants s’exécutent en mode « intégré » et ne sont pas facturées séparément, vous êtes facturisé uniquement pour l’une exécution parent en production. Cela ne s’applique que si les sous-flux de travail sont invoqués en tant qu’enfants de cette même exécution ; si vous déclenchez l’un d’eux indépendamment via son propre déclencheur de production, cette exécution est facturée séparément.