Une interface web par serveur
Chaque serveur n’affiche que ses propres exécutions. Vérifier les échecs de la nuit dernière sur cinq serveurs oblige à ouvrir cinq interfaces web.
Dagu Cloud
Le plan de contrôle de vos serveurs Dagu
Connectez chaque serveur Dagu auto-hébergé à Dagu Cloud. Suivez l’état et les exécutions de tous vos serveurs dans une seule console, alertez votre équipe là où elle travaille, relancez, arrêtez et approuvez des exécutions sans vous connecter à chaque serveur, et laissez ChatGPT ou Claude les piloter via un seul endpoint MCP. Les workflows continuent de s’exécuter uniquement sur vos serveurs, qui ouvrent eux-mêmes la connexion vers l’extérieur ; rien n’est ouvert en entrée.
Gratuit pour un serveur. Team et Pro couvrent chaque serveur sous licence et ajoutent les actions sur les exécutions, MCP et votre équipe. La supervision nécessite Dagu v2.19.1 ou ultérieur (v2.19.2 avec l’offre gratuite) ; les actions sur les exécutions et MCP nécessitent v2.22 ou ultérieur.
Vos serveurs
- prod-eu-1dagu 2.19.0
- prod-us-2dagu 2.19.0
- batch-01dagu 2.19.0
Les workflows s’exécutent ici
HTTPS, sortant uniquement, toutes les 60 secondes
console.dagu.shN’exécute jamais de workflows
Vue d’ensembleServeursExécutionsAlertesNotifications
Alertes par e-mail, chat, PagerDuty ou webhook quand quelque chose casse, puis quand tout revient
Beaucoup de serveurs, aucun endroit d’où les piloter
Chaque serveur Dagu est complet à lui seul, avec son propre planificateur, son historique d’exécutions et son interface web. Avec plusieurs serveurs, cela fait aussi plusieurs endroits à vérifier, et plusieurs endroits où se connecter quand une exécution demande une intervention.
Aucune liste de tous les échecs
Rien ne rassemble les échecs de tous les serveurs en un seul endroit, donc personne ne voit le tableau complet.
Les problèmes apparaissent tard
Un planificateur arrêté ou un serveur devenu silencieux ne déclenche aucune erreur. Les workflows planifiés cessent simplement de s’exécuter jusqu’à ce que quelqu’un s’en aperçoive.
Des alertes configurées serveur par serveur
Les e-mails d’échec nécessitent des réglages de messagerie et de notification sur chaque serveur, à garder alignés à la main.
Chaque intervention, une connexion de plus
Relancer une exécution en échec ou approuver une étape en attente oblige à trouver le bon serveur, à ouvrir son interface web et à s’y connecter.
Aucun accès sûr pour l’IA
Laisser ChatGPT ou Claude travailler sur un serveur derrière un pare-feu oblige à ouvrir un port ou à distribuer une clé API.
Une console pour tous vos serveurs
La section Supervision de la console Dagu comporte les pages Vue d’ensemble, Serveurs, Exécutions, Alertes, Notifications et Analyses, ainsi qu’une page par serveur, par workflow et par alerte. Tous les membres de l’espace de travail peuvent les consulter.
Vue d’ensemble : ce qui est à traiter maintenant
Serveurs qui envoient des rapports, échecs aujourd’hui (UTC), exécutions en cours et taux de réussite sur les 7 derniers jours UTC. À traiter liste ce qui attend une personne, les alertes ouvertes et les échecs du jour, chacun avec son action directement dans la ligne.
- Rapports interrompus
- Ne se signale pas
- Hors ligne
- Planificateur arrêté
- Workflows en échec
- Événements perdus
- Surveillance désactivée
Serveurs : chaque serveur et son statut
Chaque serveur connecté avec son statut, sa version de Dagu, son dernier rapport, ses échecs aujourd’hui (UTC), son taux de réussite sur 7 jours UTC et ses alertes ouvertes.
- Rapports reçus
- Un rapport est arrivé au cours des 5 dernières minutes.
- Rapports interrompus
- Le serveur a déjà envoyé des rapports, mais aucun au cours des 5 dernières minutes.
- Ne se signale pas
- Aucune vérification de licence depuis plus de 26 heures.
- Hors ligne
- Aucune vérification de licence depuis plus de 72 heures.
- Surveillance désactivée
- La surveillance a été désactivée sur le serveur, ou la console Dagu ne détient aucun rapport de ce serveur.
- Planificateur arrêté
- Le dernier rapport ne compte aucun planificateur en marche : les workflows planifiés ne démarrent pas.
- Événements perdus
- Le serveur est resté coupé plus longtemps que son stockage d’événements ne conserve les événements, si bien que certaines exécutions terminées n’ont pas pu être envoyées.
Chaque serveur : état de santé et historique récent
Une page par serveur. Vue d’ensemble affiche son état de santé (version de Dagu, OS et architecture, démarrage du processus, dernier rapport, dernier contact), les services du dernier rapport, les alertes ouvertes et ses derniers échecs. Exécutions liste ses exécutions. Workflows affiche les exécutions terminées de chaque workflow par jour UTC sur 14 jours, avec le nombre d’exécutions, les échecs, le taux de réussite, ainsi que la durée moyenne et la plus longue.
Les exécutions de tous les serveurs
Les exécutions en cours d’abord, puis les exécutions terminées, des plus récentes aux plus anciennes. Chaque exécution a un permalien vers ses tentatives.
Filtrez par serveur, workflow, statut (en échec, réussie, en cours, en attente ou en file) et période : la dernière heure, 24 heures, 7 jours, 14 jours ou, avec Team et Pro, 30 jours.
Analyses : tendances sur 7, 30 ou 90 jours
Exécutions, échecs et taux de réussite comparés à la période précédente, exécutions par jour, et chaque workflow avec sa durée p95 et son évolution. Les exécutions du jour sont comptées à mesure qu’elles se terminent.
Chaque workflow : échoue-t-il, ou ralentit-il ?
Une page par workflow avec son alerte ouverte, ses exécutions par jour, son taux de réussite et ses durées p50 et p95 sur 7, 30 ou 90 jours, ainsi que ses exécutions récentes et les étapes où il a échoué. Les propriétaires peuvent le mettre en sourdine ici.
Agissez depuis la console, ou depuis votre IA
Dagu Cloud joint chaque serveur par une connexion que le serveur ouvre lui-même : membres et clients MCP peuvent agir sur les exécutions sans port entrant, VPN ni clé API.
Agir sur les exécutions dans la console
Lisez le log d’une étape en échec, relancez ou arrêtez une exécution, approuvez ou rejetez une étape qui attend une personne, directement depuis la Vue d’ensemble, l’exécution ou son alerte.
Un seul endpoint MCP pour tous les serveurs
Connectez une seule fois ChatGPT, Claude ou un autre client MCP. Il lit les exécutions et les logs, lance et relance des workflows et modifie des DAG sur les serveurs de l’espace de travail, dans la limite du rôle de chaque membre.
Chaque serveur fixe les limites
L’administrateur de chaque serveur active l’accès à distance et fixe le rôle le plus élevé autorisé sur ce serveur. Chaque appel est signé pour cette seule requête et enregistré dans Dagu Cloud ainsi que dans le journal d’audit du serveur.
Avec Team et Pro, ou pendant un essai. Nécessite Dagu v2.22 ou ultérieur.
Fonctionnement de l’accès à distanceUne alerte par problème, pas un e-mail par exécution échouée
Une alerte concerne un workflow ou un serveur. Elle s’ouvre une fois, compte ce qui suit et se résout d’elle-même quand le problème prend fin.
Un workflow échoue
Une exécution en échec ouvre l’alerte du workflow. Les échecs suivants s’ajoutent à son compteur sans nouveau message, et la prochaine exécution réussie la résout.
Un serveur cesse d’envoyer des rapports
10 minutes sans rapport, ou 25 avec la surveillance gratuite, ouvrent l’alerte du serveur : un hôte tombé ou un processus arrêté ne passe pas inaperçu. Son rapport suivant la résout.
Une exécution dure bien trop longtemps
Team et ProUne exécution toujours en cours après deux fois la durée habituelle de son workflow, et au moins 10 minutes de plus, ouvre une alerte avant que quelqu’un ne s’étonne d’un rapport en retard. Elle se résout quand l’exécution se termine.
- Chaque alerte a sa page : ce qui a échoué, sur quel serveur, et une chronologie de son ouverture, de chaque e-mail et message, et de qui l’a prise en charge.
- Tout membre de l’espace de travail prend une alerte en charge depuis sa page, et un destinataire directement depuis l’e-mail, sans se connecter. L’incident PagerDuty est pris en charge avec elle.
- Avec Team et Pro, les alertes que personne n’a prises en charge sont publiées à nouveau toutes les heures, toutes les 4 heures ou chaque jour, jusqu’à 6 fois. Mettez les rappels en pause pour une heure, un jour ou jusqu’à 9:00 dans votre fuseau horaire.
- Les alertes qui s’ouvrent ou se résolvent ensemble arrivent dans un seul e-mail. Un canal reçoit au plus 20 messages à la fois, et un résumé du reste.
- Les exécutions annulées et rejetées comptent comme des échecs dans les totaux, mais n’ouvrent ni ne résolvent d’alerte.
- Les heures des e-mails et des messages suivent le fuseau horaire de votre espace de travail. Un workflow bruyant peut être mis en sourdine : ses alertes sont toujours enregistrées, mais personne n’est prévenu.
Les alertes de workflow nécessitent le niveau Health and run status. Les e-mails proviennent de no-reply@dagu.sh.
Les alertes là où votre équipe regarde déjà
Les e-mails d’alerte vont aux propriétaires et administrateurs, ainsi qu’aux membres et adresses externes vérifiées que vous ajoutez, chacun avec un désabonnement en un clic. Avec Team et Pro, les alertes vont aussi vers jusqu’à 10 destinations : Slack, Microsoft Teams, Google Chat, Discord, PagerDuty et webhooks signés.
- Slack
- Microsoft Teams
- Google Chat
- Discord
- PagerDuty
- Webhook
Ajouter une destination envoie un test, et chacune garde un journal de chaque message et de sa réponse. Un message en échec est retenté avec backoff pendant un jour au plus, et une destination qui refuse les alertes trois fois de suite s’arrête et le signale.
Un résumé hebdomadaire pour les propriétaires
Team et ProChaque lundi à 8:00 dans le fuseau horaire de l’espace de travail, chaque propriétaire reçoit un e-mail qui résume la semaine passée. Un lien suffit pour l’arrêter.
- Les exécutions terminées et le taux de réussite, comparés à la semaine précédente
- Les alertes ouvertes et résolues, et la rapidité de leur prise en charge et de leur résolution
- Les workflows qui ont le plus échoué, et ceux qui ont ralenti
- Les serveurs devenus silencieux, et les destinations qui ne reçoivent plus d’alertes
L’exécution et les données restent sur vos serveurs
Vos serveurs envoient des rapports à la console Dagu. La console Dagu ne s’y connecte jamais et n’exécute jamais de workflows.
HTTPS sortant uniquement
Les rapports sont des requêtes HTTPS du serveur vers console.dagu.sh. Aucun port entrant n’est ouvert, et rien ne se connecte au serveur.
Les workflows ne l’attendent jamais
Si la console Dagu est injoignable, les workflows s’exécutent normalement. Le serveur réessaie et envoie les exécutions manquées dès que la console est de nouveau disponible.
Désactivé tant que vous ne l’activez pas
La supervision est désactivée par défaut et choisie pour chaque serveur par son administrateur. Connecter ou mettre à niveau un serveur n’envoie rien de plus que sa vérification de licence.
Trois niveaux
Health only envoie ce qui tourne sur le serveur. Health and run status ajoute le statut de ses exécutions et est nécessaire pour les alertes de workflow. Un troisième niveau envoie aussi les messages d’erreur des étapes en échec, pour que les alertes montrent pourquoi une exécution a échoué.
Ce qui quitte votre serveur
Version de Dagu, OS et architecture, et heure de démarrage du processus serveur
- Health only
- Envoyé
- Health and run status
- Envoyé
Nombre de planificateurs en marche et de coordinateurs enregistrés
- Health only
- Envoyé
- Health and run status
- Envoyé
Chaque exécution de premier niveau terminée : nom du DAG, ID d’exécution, ID de tentative, statut, déclencheur, et heures de mise en file, de démarrage et de fin
- Health only
- Non envoyé
- Health and run status
- Envoyé
Noms des étapes en échec d’une exécution, jusqu’à 50
- Health only
- Non envoyé
- Health and run status
- Envoyé
Exécutions en file, en cours ou en attente, jusqu’à 200 par rapport
- Health only
- Non envoyé
- Health and run status
- Envoyé
Logs, sorties, paramètres, environnement, commandes des étapes, DAG YAML et valeurs des secrets
- Health only
- Jamais envoyé
- Health and run status
- Jamais envoyé
Chaque rapport transmet aussi l’ID de licence, l’ID de serveur et le secret de heartbeat du serveur, comme sa vérification de licence. Les noms de DAG et d’étapes ne sont envoyés qu’avec le statut des exécutions ; choisissez Health only si vous les jugez sensibles. Les messages d’erreur des étapes en échec ne sont envoyés qu’à un troisième niveau, Health, run status, and error messages : la fin de chaque erreur, avec les secrets déclarés masqués.
Configuration en trois étapes
Nécessite Dagu v2.19.1 ou ultérieur (v2.19.2 ou ultérieur pour la supervision gratuite), et le serveur doit pouvoir joindre https://console.dagu.sh en HTTPS.
- 01
Connecter le serveur à la console Dagu
Dans Dagu, ouvrez Plan & features et sélectionnez Connect to Dagu Console, exécutez dagu license activate, ou démarrez le serveur avec une clé de serveur. Les serveurs sous licence hors ligne n’envoient pas de rapports.
- 02
Choisir ce qui est envoyé
Sélectionnez Turn on dans la section Monitoring de Plan & features, puis choisissez Health and run status ou Health only. Le choix s’applique immédiatement, sans redémarrage.
Pour les serveurs gérés sous forme de code, définissez le niveau dans le fichier de configuration, ou définissez DAGU_CLOUD_REPORT=runs :
cloud: report: runs # off, health, or runs - 03
Le voir dans la console Dagu
Le serveur envoie un rapport toutes les 60 secondes, et sous 5 secondes environ quand une exécution échoue ou que les exécutions en cours changent. Il apparaît sous Supervision dans la console Dagu.
Plans, conservation et limites
Ce que couvre chaque plan, combien de temps Dagu Cloud conserve ce que les serveurs envoient, et combien il stocke par jour.
Plans
Gratuit pour un serveur par espace de travail, avec des limites plus basses : un rapport toutes les 5 minutes, 100 exécutions stockées par jour, 7 jours d’historique et des e-mails d’alerte aux propriétaires et administrateurs. Team et Pro couvrent chaque serveur sous licence, avec 30 jours d’historique, des destinations chat, PagerDuty et webhook, des rappels, les alertes d’exécutions trop longues et le résumé hebdomadaire.
Comparer les plansConservation
- Exécutions terminées
- 30 jours
- Totaux quotidiens par workflow
- 13 mois
- Alertes résolues
- 90 jours après leur résolution
- Alertes ouvertes
- Jusqu’à leur résolution
La surveillance gratuite affiche les exécutions terminées des 7 derniers jours, et un essai celles des 14 derniers. Un serveur qui n’envoie aucun rapport pendant 30 jours est retiré de la surveillance, avec ses totaux quotidiens et ses alertes.
Limite quotidienne d’exécutions
Chaque espace de travail stocke jusqu’à 500 exécutions terminées par jour UTC, ou 100 avec la supervision gratuite. Les exécutions au-delà de la limite comptent toujours dans les totaux quotidiens et ouvrent et résolvent toujours des alertes, mais elles ne sont pas ajoutées à la liste des exécutions. Le stockage reprend à 00:00 UTC.
Besoin de plus ? Contactez-nousPilotez tous vos serveurs Dagu depuis un seul endroit
Lisez le guide de configuration, ou ouvrez la console Dagu et connectez votre premier serveur. Gratuit pour un serveur ; démarrez un essai de Team ou Pro.