Eine Web-UI pro Server
Jeder Server zeigt nur seine eigenen Läufe. Um die Fehlschläge der letzten Nacht auf fünf Servern zu prüfen, müssen Sie fünf Web-UIs öffnen.
Dagu Cloud
Die Control Plane für Ihre Dagu-Server
Verbinden Sie jeden selbst gehosteten Dagu-Server mit Dagu Cloud. Sie sehen Zustand und Läufe in einer Konsole, alarmieren Ihr Team dort, wo es arbeitet, und können Läufe wiederholen, stoppen und freigeben, ohne sich an jedem Server einzeln anzumelden. Über einen einzigen MCP-Endpunkt lassen Sie ChatGPT oder Claude die Server bedienen. Workflows laufen weiterhin nur auf Ihren Servern, die die Verbindung selbst nach außen aufbauen; eingehend wird nichts geöffnet.
Kostenlos für einen Server. Team und Pro decken jeden lizenzierten Server ab und ergänzen Aktionen für Läufe, MCP und Ihr Team. Monitoring erfordert Dagu v2.19.1 oder neuer (v2.19.2 im kostenlosen Plan); Aktionen für Läufe und MCP erfordern v2.22 oder neuer.
Ihre Server
- prod-eu-1dagu 2.19.0
- prod-us-2dagu 2.19.0
- batch-01dagu 2.19.0
Workflows laufen hier
HTTPS, nur ausgehend, alle 60 Sekunden
console.dagu.shFührt nie Workflows aus
OverviewServersRunsAlertsNotifications
Alerts per E-Mail, Chat, PagerDuty oder Webhook, wenn etwas ausfällt, und erneut, wenn es sich erholt
Viele Server, keine zentrale Steuerung
Jeder Dagu-Server ist für sich vollständig, mit eigenem Scheduler, eigener Laufhistorie und eigener Web-UI. Bei mehreren Servern heißt das auch: mehrere Stellen, die Sie prüfen müssen, und mehrere Stellen, an denen Sie sich anmelden müssen, wenn ein Lauf Ihr Eingreifen braucht.
Keine Liste aller Fehlschläge
Nichts sammelt die Fehlschläge aller Server an einem Ort, also sieht niemand das Gesamtbild.
Probleme fallen spät auf
Ein gestoppter Scheduler oder ein Server, der verstummt ist, löst keinen Fehler aus. Geplante Workflows laufen einfach nicht mehr, bis es jemand bemerkt.
Alerting, Server für Server eingerichtet
E-Mails bei Fehlschlägen brauchen Mail- und Benachrichtigungseinstellungen auf jedem Server, die Sie von Hand synchron halten müssen.
Jeder Eingriff erfordert eine neue Anmeldung
Um einen fehlgeschlagenen Lauf zu wiederholen oder einen wartenden Schritt freizugeben, müssen Sie den richtigen Server finden, seine Web-UI öffnen und sich dort anmelden.
Kein sicherer Zugang für KI
Damit ChatGPT oder Claude mit einem Server hinter einer Firewall arbeiten kann, müssen Sie einen Port öffnen oder einen API-Schlüssel herausgeben.
Eine Konsole für alle Server
Der Bereich Monitoring der Dagu-Konsole umfasst die Seiten Overview, Servers, Runs, Alerts, Notifications und Insights sowie eine Seite pro Server, pro Workflow und pro Alert. Alle Mitglieder des Workspaces können sie ansehen.
Overview: was jetzt Aufmerksamkeit braucht
Meldende Server, Fehlschläge heute (UTC), aktive Läufe und die Erfolgsquote der letzten 7 UTC-Tage. Needs attention listet, was auf eine Person wartet, offene Alerts und die heutigen Fehlschläge, jeweils mit der passenden Aktion direkt in der Zeile.
- Not reporting
- Not checking in
- Offline
- Scheduler stopped
- Failing workflows
- Events lost
- Monitoring off
Servers: jeder Server und sein Status
Jeder verbundene Server mit Status, Dagu-Version, letztem Bericht, Fehlschlägen heute (UTC), Erfolgsquote über 7 UTC-Tage und offenen Alerts.
- Reporting
- In den letzten 5 Minuten ist ein Bericht eingegangen.
- Not reporting
- Der Server hat schon gemeldet, aber nicht in den letzten 5 Minuten.
- Not checking in
- Seit mehr als 26 Stunden kein Lizenz-Check-in.
- Offline
- Seit mehr als 72 Stunden kein Lizenz-Check-in.
- Monitoring off
- Monitoring wurde auf dem Server ausgeschaltet, oder die Dagu-Konsole hat keinen Bericht von ihm.
- Scheduler stopped
- Der letzte Bericht zählt keinen laufenden Scheduler, daher starten geplante Workflows nicht.
- Events lost
- Der Server war länger getrennt, als sein Event-Store Ereignisse aufbewahrt, daher konnten einige abgeschlossene Läufe nicht gesendet werden.
Jeder Server: Zustand und jüngste Historie
Eine Seite pro Server. Overview zeigt seinen Zustand (Dagu-Version, Betriebssystem und Architektur, Prozessstart, letzter Bericht, letzter Check-in), die Dienste aus dem letzten Bericht, offene Alerts und die letzten Fehlschläge. Runs listet seine Läufe. Workflows zeigt die abgeschlossenen Läufe jedes Workflows pro UTC-Tag über 14 Tage, mit Läufen, Fehlschlägen, Erfolgsquote sowie durchschnittlicher und längster Dauer.
Läufe über alle Server hinweg
Aktive Läufe stehen oben, danach abgeschlossene, die neuesten zuerst. Jeder Lauf hat einen Permalink zu seinen Versuchen.
Filtern Sie nach Server, Workflow, Status (fehlgeschlagen, erfolgreich, läuft, wartend oder eingereiht) und Zeitraum: die letzte Stunde, 24 Stunden, 7 Tage, 14 Tage oder, bei Team und Pro, 30 Tage.
Insights: Trends über 7, 30 oder 90 Tage
Läufe, Fehlschläge und Erfolgsquote im Vergleich zum vorherigen Zeitraum, Läufe pro Tag und jeder Workflow mit seiner p95-Dauer und deren Veränderung. Heutige Läufe zählen, sobald sie abgeschlossen sind.
Jeder Workflow: Schlägt er fehl oder wird er langsamer?
Eine Seite pro Workflow mit seinem offenen Alert, Läufen pro Tag, Erfolgsquote sowie p50- und p95-Dauer über 7, 30 oder 90 Tage, dazu seine letzten Läufe und die Schritte, an denen er fehlschlug. Owner können ihn hier stummschalten.
Eingreifen in der Konsole oder über Ihre KI
Dagu Cloud erreicht jeden Server über eine Verbindung, die der Server selbst aufbaut. So können Mitglieder und MCP-Clients in Läufe eingreifen, ohne eingehenden Port, VPN oder API-Schlüssel.
Läufe in der Konsole steuern
Das Log eines fehlgeschlagenen Schritts lesen, einen Lauf wiederholen oder stoppen und einen Schritt, der auf eine Person wartet, freigeben oder ablehnen: direkt in der Overview, im Lauf oder in seinem Alert.
Ein MCP-Endpunkt für alle Server
Verbinden Sie ChatGPT, Claude oder einen anderen MCP-Client ein einziges Mal. Er liest Läufe und Logs, startet und wiederholt Workflows und bearbeitet DAGs auf allen Servern des Workspace, soweit die Rolle des jeweiligen Mitglieds es zulässt.
Jeder Server setzt die Grenzen
Der Administrator jedes Servers schaltet den Fernzugriff ein und legt die höchste zulässige Rolle fest. Jeder Aufruf wird nur für genau diese Anfrage signiert und in Dagu Cloud sowie im eigenen Audit-Log des Servers protokolliert.
Bei Team und Pro oder in der Testphase. Erfordert Dagu v2.22 oder neuer.
So funktioniert der FernzugriffEin Alert pro Problem, nicht eine E-Mail pro fehlgeschlagenem Lauf
Ein Alert gehört zu einem Workflow oder einem Server. Er wird einmal geöffnet, zählt, was folgt, und löst sich von selbst, sobald das Problem vorbei ist.
Ein Workflow schlägt fehl
Ein fehlgeschlagener Lauf öffnet den Alert des Workflows. Weitere Fehlschläge erhöhen seinen Zähler ohne neue Nachricht, und der nächste erfolgreiche Lauf löst ihn auf.
Ein Server meldet nicht mehr
10 Minuten ohne Bericht, bei kostenlosem Monitoring 25, öffnen den Alert des Servers, sodass ein ausgefallener Host oder ein gestoppter Prozess auffällt. Sein nächster Bericht löst ihn auf.
Ein Lauf dauert viel zu lange
Team und ProEin Lauf, der nach dem Doppelten der üblichen Dauer seines Workflows und mindestens 10 weiteren Minuten noch läuft, öffnet einen Alert, bevor sich jemand über einen verspäteten Bericht wundert. Er löst sich, wenn der Lauf endet.
- Jeder Alert hat eine Seite mit dem, was fehlschlug, auf welchem Server, und einer Zeitleiste: wann er geöffnet wurde, jede E-Mail und jeder Post und wer ihn bestätigt hat.
- Jedes Mitglied des Workspace bestätigt einen Alert auf seiner Seite, ein Empfänger direkt aus der E-Mail, ohne sich anzumelden. Ein PagerDuty-Incident wird mitbestätigt.
- Bei Team und Pro werden unbestätigte Alerts stündlich, alle 4 Stunden oder täglich erneut gepostet, bis zu 6-mal. Pausieren Sie sie für eine Stunde, einen Tag oder bis 9:00 Uhr in Ihrer Zeitzone.
- Alerts, die zusammen geöffnet oder gelöst werden, kommen in einer E-Mail. Ein Kanal erhält höchstens 20 Posts auf einmal und eine Zusammenfassung der übrigen.
- Abgebrochene und abgelehnte Läufe zählen in den Summen als Fehlschläge, öffnen oder lösen aber keinen Alert.
- Zeiten in E-Mails und Posts folgen der Zeitzone Ihres Workspace. Ein lauter Workflow lässt sich stummschalten: Seine Alerts werden weiter erfasst, aber niemand wird benachrichtigt.
Workflow-Alerts erfordern die Stufe Health and run status. E-Mails kommen von no-reply@dagu.sh.
Alerts dort, wo Ihr Team ohnehin hinschaut
Alert-E-Mails gehen an Owner und Admins sowie an die Mitglieder und bestätigten externen Adressen, die Sie hinzufügen, jeweils mit Abmeldung per Klick. Bei Team und Pro gehen Alerts zusätzlich an bis zu 10 Ziele: Slack, Microsoft Teams, Google Chat, Discord, PagerDuty und signierte Webhooks.
- Slack
- Microsoft Teams
- Google Chat
- Discord
- PagerDuty
- Webhook
Beim Hinzufügen eines Ziels wird ein Test gesendet, und jedes Ziel führt ein Protokoll jedes Posts und seiner Antwort. Ein fehlgeschlagener Post wird mit Backoff bis zu einen Tag lang wiederholt, und ein Ziel, das Alerts dreimal in Folge ablehnt, wird angehalten und meldet das.
Eine wöchentliche Zusammenfassung für Owner
Team und ProJeden Montag um 8:00 Uhr in der Zeitzone des Workspace erhält jeder Owner eine E-Mail, die die Vorwoche zusammenfasst. Ein Link beendet sie.
- Abgeschlossene Läufe und Erfolgsquote im Vergleich zur Vorwoche
- Geöffnete und gelöste Alerts und wie schnell sie bestätigt und behoben wurden
- Die Workflows mit den meisten Fehlschlägen und die, die langsamer wurden
- Server, die verstummten, und Ziele, die keine Alerts mehr annahmen
Ausführung und Daten bleiben auf Ihren Servern
Ihre Server schicken Berichte an die Dagu-Konsole. Die Dagu-Konsole verbindet sich nie mit ihnen und führt nie Workflows aus.
Nur ausgehendes HTTPS
Berichte sind HTTPS-Anfragen vom Server an console.dagu.sh. Es wird kein eingehender Port geöffnet, und nichts baut eine Verbindung zum Server auf.
Workflows warten nie darauf
Ist die Dagu-Konsole nicht erreichbar, laufen Workflows wie gewohnt. Der Server versucht es erneut und sendet die verpassten Läufe, sobald die Konsole wieder erreichbar ist.
Aus, bis Sie es einschalten
Monitoring ist standardmäßig aus und wird pro Server von dessen Administrator gewählt. Das Verbinden oder Aktualisieren eines Servers sendet nichts außer seinem Lizenz-Check-in.
Drei Stufen
Health only sendet, was auf dem Server läuft. Health and run status ergänzt den Status seiner Läufe und ist für Workflow-Alerts nötig. Eine dritte Stufe sendet zusätzlich die Fehlermeldungen fehlgeschlagener Schritte, damit Alerts zeigen, warum ein Lauf fehlschlug.
Was Ihren Server verlässt
Dagu-Version, Betriebssystem und Architektur sowie Startzeit des Serverprozesses
- Health only
- Gesendet
- Health and run status
- Gesendet
Anzahl laufender Scheduler und registrierter Coordinator
- Health only
- Gesendet
- Health and run status
- Gesendet
Jeder abgeschlossene Top-Level-Lauf: DAG-Name, Lauf-ID, Versuchs-ID, Status, Auslöser sowie Zeitpunkte von Einreihung, Start und Ende
- Health only
- Nicht gesendet
- Health and run status
- Gesendet
Namen der fehlgeschlagenen Schritte eines Laufs, bis zu 50
- Health only
- Nicht gesendet
- Health and run status
- Gesendet
Eingereihte, laufende oder wartende Läufe, bis zu 200 pro Bericht
- Health only
- Nicht gesendet
- Health and run status
- Gesendet
Logs, Ausgaben, Parameter, Umgebung, Schrittbefehle, DAG YAML und Secret-Werte
- Health only
- Nie gesendet
- Health and run status
- Nie gesendet
Jeder Bericht enthält außerdem Lizenz-ID, Server-ID und Heartbeat-Secret des Servers, wie sein Lizenz-Check-in. DAG- und Schrittnamen werden nur mit dem Laufstatus gesendet; wählen Sie Health only, wenn Sie diese Namen für sensibel halten. Fehlermeldungen fehlgeschlagener Schritte werden nur auf einer dritten Stufe gesendet, Health, run status, and error messages: das Ende jeder Meldung, mit maskierten deklarierten Secrets.
Einrichtung in drei Schritten
Erfordert Dagu v2.19.1 oder neuer (v2.19.2 oder neuer für kostenloses Monitoring), und der Server muss https://console.dagu.sh über HTTPS erreichen.
- 01
Server mit der Dagu-Konsole verbinden
Öffnen Sie in Dagu Plan & features und wählen Sie Connect to Dagu Console, führen Sie dagu license activate aus oder starten Sie den Server mit einem Server-Key. Server mit Offline-Lizenzen senden keine Berichte.
- 02
Festlegen, was gemeldet wird
Wählen Sie Turn on im Bereich Monitoring von Plan & features und dann Health and run status oder Health only. Die Auswahl gilt sofort, ohne Neustart.
Für Server, die als Code verwaltet werden, setzen Sie die Stufe in der Konfigurationsdatei oder setzen DAGU_CLOUD_REPORT=runs:
cloud: report: runs # off, health, or runs - 03
In der Dagu-Konsole ansehen
Der Server meldet alle 60 Sekunden und innerhalb von etwa 5 Sekunden, wenn ein Lauf fehlschlägt oder sich die aktiven Läufe ändern. Er erscheint unter Monitoring in der Dagu-Konsole.
Pläne, Aufbewahrung und Limits
Was jeder Plan abdeckt, wie lange Dagu Cloud die Berichte der Server aufbewahrt und wie viel es pro Tag speichert.
Pläne
Kostenlos für einen Server pro Workspace, mit niedrigeren Limits: ein Bericht alle 5 Minuten, 100 gespeicherte Läufe pro Tag, 7 Tage Laufhistorie und Alert-E-Mails an Owner und Admins. Team und Pro decken jeden lizenzierten Server ab, mit 30 Tagen Laufhistorie, Zielen in Chat, PagerDuty und Webhooks, Erinnerungen, Alerts für zu lange Läufe und der wöchentlichen Zusammenfassung.
Pläne vergleichenAufbewahrung
- Abgeschlossene Läufe
- 30 Tage
- Tagessummen pro Workflow
- 13 Monate
- Aufgelöste Alerts
- 90 Tage nach der Auflösung
- Offene Alerts
- Bis zur Auflösung
Kostenloses Monitoring zeigt die abgeschlossenen Läufe der letzten 7 Tage, eine Testversion die der letzten 14. Ein Server, der 30 Tage lang keinen Bericht sendet, wird samt Tagessummen und Alerts aus dem Monitoring entfernt.
Tägliches Lauflimit
Jeder Workspace speichert bis zu 500 abgeschlossene Läufe pro UTC-Tag, mit kostenlosem Monitoring 100. Läufe über dem Limit zählen weiterhin zu den Tagessummen, öffnen weiterhin Alerts und lösen sie auf, werden aber nicht in die Laufliste aufgenommen. Die Speicherung wird um 00:00 UTC fortgesetzt.
Sie brauchen mehr? Kontaktieren Sie unsAlle Dagu-Server von einem Ort aus steuern
Lesen Sie die Einrichtungsanleitung, oder öffnen Sie die Dagu-Konsole und verbinden Sie Ihren ersten Server. Kostenlos für einen Server; für Team oder Pro starten Sie eine Testphase.