Salut les gars
Je mets à l’échelle une plateforme n8n multi-tenant et je commence à réaliser que les journaux basiques ne suffisent plus.
Load Balancer
↓
Multiples workers n8n
↓
PostgreSQL + Redis + APIs externes
À mesure que le nombre de tenants et de workflows augmente, j’ai du mal à répondre à des questions comme :
• Quel tenant génère la plus grande charge ?
• Pourquoi un workflow spécifique a-t-il échoué ?
• Où sont les goulots d’étranglement du système ?
• Quelles APIs externes causent de la latence ?
• Comment détecter les problèmes avant que les clients ne les remarquent ?
J’envisage d’ajouter :
• Journalisation centralisée
• Collecte de métriques
• Traçage distribué
• Tableaux de bord par tenant
• Alertes et détection d’anomalies
tenant_id
workflow_id
execution_time
error_rate
queue_depth
API_latency
Décrivez le problème/l’erreur/la question
Quelle pile d’observabilité utilisez-vous ? Quelles métriques se sont avérées les plus utiles ?
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
(Sélectionnez les nœuds de votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Bonjour @Selena_Gloria Une fois que vous commencez à évoluer vers plusieurs locataires et workflows, il devient beaucoup plus difficile de comprendre ce qui se passe en regardant uniquement les logs.
Une configuration de production courante comprend :
Logs centralisés
Collecte de métriques
Alertes
Traçage (si nécessaire)
Les métriques que je trouve les plus utiles sont :
•tenant_id
•workflow_id
•Temps d’exécution
•Taux d’erreur
•Profondeur de la queue
•Temps de réponse des API externes
Etiqueter les logs et les métriques avec tenant_id rend beaucoup plus facile le dépannage des problèmes pour un client spécifique sans affecter les autres.
Je vous recommande également de configurer des alertes pour des choses comme les taux d’erreur élevés, l’accumulation croissante de backlogs dans la queue, les défaillances des workers, les APIs lentes et les pics de trafic inattendus. De cette façon, vous pouvez détecter les problèmes avant que les utilisateurs ne commencent à les signaler.
Une erreur à éviter est de s’appuyer uniquement sur les logs applicatifs ou de surveiller uniquement votre infrastructure. Avoir une visibilité sur votre infrastructure et vos workflows vous donne une bien meilleure compréhension de ce qui se passe.
Globalement, une combinaison de logs centralisés, de métriques, de dashboards et d’alertes rend beaucoup plus facile le maintien de la santé de la plateforme à mesure qu’elle se développe.
Excellents points ! Je suis particulièrement d’accord que le balisage avec tenant_id et workflow_id facilite beaucoup le dépannage. Merci de partager !
J’ajouterais une métrique qui n’est pas vraiment infra : un reçu d’action par exécution.
Le locataire, le workflow, le taux d’erreur et la latence vous indiquent où se situe le problème. Le reçu indique au client ce qui s’est passé : exécution attendue, identifiant/compte utilisé, enregistrements affectés, API externe appelée, ID d’objet/message final et état de pause ou de nouvelle tentative.