Managed Monitoring Service für Ihre Kunden
Ihre Kunden kaufen GPU-Server, Workstations und DGX-Systeme. Den Betrieb wollen sie nicht selbst überwachen. Mit PeakNode übernehmen Sie das als Systemhaus: Sie sehen jede GPU jedes Kunden, erhalten Alarme in Ihr Ticket-System und haben bei einem Fehler die Daten für die Diagnose bereits vorliegen.
Ein Systemhaus bietet mit PeakNode einen Managed Monitoring Service an, indem es auf den Systemen seiner Kunden den PeakNode-Agenten installiert und die Überwachung im Portal führt. Jeder Server des Kunden ist ein Server-Monitor, jeder Dienst ein Uptime-Monitor, jeder Job ein Heartbeat. Alarme gehen an das Systemhaus, der Kunde erhält auf Wunsch eine eigene Statusseite oder einen Lesezugriff. Tritt ein Fehler auf, zeigt das Portal Verlauf, Hardware-Ereignisse und Prozesse je GPU, sodass der Techniker mit einer Diagnose statt mit einer Vermutung zum Kunden geht.
- Zwei Betriebsmodelle: alle Kunden im Konto des Systemhauses, getrennt nach Projekten, oder je Kunde ein eigenes Konto, in das das Systemhaus als Teammitglied wechselt.
- Der Agent sendet nur Messwerte von innen nach außen. PeakNode ersetzt keinen Fernzugriff und kann nichts auf den Systemen des Kunden ausführen.
- Für Kunden, deren Daten das eigene Netz nicht verlassen dürfen, gibt es die Plattform On-Premise.
| Kunde | Systeme | In PeakNode | Alarm geht an | Der Kunde sieht |
|---|---|---|---|---|
| Ingenieurbüro, 12 Mitarbeitende | 4 KI-Workstations, 1 Inferenz-Server | 5 Server-Monitore, 1 Uptime-Monitor | Ticket-System des Systemhauses per Webhook | Statusseite mit Passwort |
| Maschinenbauer, eigene IT | 1 HGX-Node mit 8 GPUs, 2 PCIe-GPU-Server | 3 Server-Monitore, 3 Uptime-Monitore, 2 Heartbeats | Systemhaus per Microsoft Teams, IT des Kunden per E-Mail | Lesezugriff auf das Portal |
| Forschungsgruppe | 6 DGX Spark | 6 Server-Monitore | Systemhaus per E-Mail | Statusseite unter eigener Domain |
| Summe | 14 Systeme | 14 Server-Monitore, 4 Uptime-Monitore, 2 Heartbeats |
Was Sie als Systemhaus damit leisten
Ein Managed Monitoring Service besteht aus drei Dingen: früh wissen, dass etwas nicht stimmt, schnell wissen, was es ist, und dem Kunden zeigen, was Sie für ihn tun.
Alle Kunden auf einen Blick
Das Dashboard zeigt, was jetzt Aufmerksamkeit braucht: Server offline, GPU-Treiber antwortet nicht, Zertifikat läuft ab, Heartbeat ausgeblieben. Projekte gliedern die Monitore nach Kunde, jede Liste lässt sich nach Projekt filtern.
Alarme dort, wo Ihr Service arbeitet
Je Monitor legen Sie fest, wohin Alarme gehen: Webhook an Ihr Ticket-System, Microsoft Teams, Slack oder E-Mail. Mehrere Kanäle gleichzeitig sind möglich, zum Beispiel Sie und die IT des Kunden. Die Entwarnung kommt automatisch.
Diagnose statt Vermutung
Bei einem Fehler sehen Sie Verlauf und Ereignisse je GPU: Xid-Meldungen aus dem Kernel-Log mit Schweregrad, ECC-Fehler, Row Remapping, PCIe-Link, Drosselgrund, fehlende Karte, Prozesse mit Speicherbedarf. Das zeigt, ob Hardware, Treiber, Kühlung oder ein Job die Ursache ist.
Statusseite je Kunde
Jeder Kunde erhält eine eigene Statusseite mit der Verfügbarkeit der letzten 90 Tage und den Vorfällen der letzten 30 Tage, auf Wunsch unter eigener Domain, mit Logo und Passwortschutz. Das ist der sichtbare Nachweis Ihrer Leistung.
Zugriff mit Rechten
Über Teams erhalten Ihre Techniker und die Ansprechpartner des Kunden Zugriff: nur lesen, oder anlegen, ändern und löschen je Bereich. Ein Mitglied kann mehreren Teams angehören und zwischen den Kunden wechseln.
Berichte und Schnittstellen
E-Mail-Berichte je Monitor, Export der Messwerte als CSV oder JSON und eine REST-API für Ihre eigenen Auswertungen, zum Beispiel einen monatlichen Bericht über Auslastung, Uptime und Energie je Kunde.
Vom Alarm zur Ursache: Was das Portal im Fehlerfall zeigt
Die häufigsten Meldungen eines Kunden und die Daten, die Ihr Techniker dazu im Portal findet, bevor er sich auf das System schaltet oder hinfährt.
| Der Kunde meldet | Das zeigt PeakNode | Das schließen Sie daraus |
|---|---|---|
| „Das Training ist abgebrochen." | Hardware-Ereignisse der GPU mit Zeitpunkt: Xid-Code aus dem Kernel-Log, ECC-Fehler, Row Remapping. Dazu der Verlauf von Speicher und Auslastung bis zum Abbruch. | Xid 79 oder 48: Hardware oder Stromversorgung, Service einplanen. Speicher lief voll: Job-Konfiguration, kein Defekt. |
| „Der Server ist langsam." | Drosselgrund je GPU (Hitze, Power Cap), Temperatur- und Taktverlauf, PCIe-Link unter Maximum, CPU, RAM und Festplatte des Systems. | Thermische Drosselung: Kühlung und Luftführung prüfen. Reduzierter PCIe-Link unter Last: Riser, Slot oder Karte. |
| „Eine GPU fehlt." | Ereignis „weniger GPUs als erwartet" mit Zeitpunkt, erwartete und gemeldete Anzahl, zugehörige Xid-Meldung. | Karte vom Bus gefallen: Neustart und Sitz der Karte prüfen, bei Wiederholung Austausch. |
| „Der Dienst antwortet nicht." | Uptime-Monitor mit Statuscode, Antwortzeit und Response-Body der fehlgeschlagenen Prüfung, dazu der Zustand des Servers im selben Zeitraum. | Server online, Dienst nicht: Anwendung oder Modell nicht geladen. Server offline: Netz, Strom oder System. |
| „Der Server meldet sich nicht mehr." | Offline seit, letzte Meldung des Agenten, letzter Zustand von CPU, RAM, Festplatte und GPUs vor dem Ausfall. | Festplatte war voll oder Last am Anschlag: Ursache auf dem System. Abbruch ohne Vorzeichen: Strom oder Netzwerk. |
| „Was kostet uns der Betrieb?" | GPU-Energie in kWh für heute, den Monat und seit Einrichtung, mit hinterlegtem Strompreis in Euro. Dazu GPUs im Leerlauf mit Dauer. | Grundlage für Ihre Beratung: Auslastung erhöhen, Systeme zusammenlegen oder erweitern. |
Hardware-Ereignisse liest der Agent aus nvidia-smi und dem Kernel-Log. Für das Kernel-Log muss der Cronjob des Agenten als root laufen. ECC, Row Remapping und Drosselgründe liefern Datacenter-GPUs, Consumer-Karten melden diese Felder nicht, das Portal zeigt dann „-". Einzelheiten stehen unter GPU-Server-Monitoring.
Drei Wege, PeakNode für Kunden zu betreiben
Welches Modell passt, hängt davon ab, wem die Daten gehören sollen und wie viele Kunden Sie betreuen.
| Modell | So funktioniert es | Geeignet, wenn |
|---|---|---|
| Ein Konto des Systemhauses | Sie legen alle Systeme in Ihrem Konto an, je Kunde ein Projekt. Der Kunde erhält eine Statusseite oder wird als Teammitglied mit Leserecht eingeladen. | Sie den Service vollständig führen und der Kunde nur das Ergebnis sehen soll |
| Ein Konto je Kunde | Der Kunde hat sein eigenes Konto und lädt Sie als Teammitglied ein. Sie wechseln im Portal zwischen den Kunden. Daten und Tarif gehören dem Kunden. | der Kunde Eigentümer seiner Monitoring-Daten bleiben will oder den Dienstleister wechseln können soll |
| On-Premise | Die Plattform läuft auf einem Server bei Ihnen oder beim Kunden, ohne Telemetrie und ohne Grenzen bei Server-Monitoren, Nutzern und Vorhaltezeit. Interne Adressen werden direkt geprüft. | Daten das Netz nicht verlassen dürfen oder Sie viele Kunden unter eigenem Erscheinungsbild betreuen |
Wer gegenüber dem Kunden Vertragspartner ist und wer die Daten verantwortet, regeln Sie in Ihrem Servicevertrag. Fragen zu Verträgen und zur Auftragsverarbeitung beantworten wir über das Kontaktformular.
So nehmen Sie einen Kunden auf
Vom ersten System bis zur Statusseite in etwa einer Stunde. Auf dem System des Kunden brauchen Sie nur eine Zeile im Terminal.
Projekt und Kanäle anlegen
Ein Projekt mit dem Namen des Kunden anlegen. Benachrichtigungskanäle einrichten: Webhook an Ihr Ticket-System, dazu Microsoft Teams, Slack oder E-Mail.
Systeme anbinden
Je Server einen Server-Monitor im Projekt anlegen und den Install-Befehl auf dem System ausführen. Als root, damit das Kernel-Log lesbar ist. Dienste als Uptime-Monitor, Jobs als Heartbeat ergänzen.
curl -fsSL "https://peaknode.de/server-monitor-code// ?os=linux" -o peaknode.sh chmod 700 peaknode.sh && (crontab -l; echo "* * * * * /bin/bash $PWD/peaknode.sh") | crontab -
Alarme und Statusseite
Schwellwerte je System setzen (Temperatur, Speicher, Festplatte, Leerlauf), erwartete GPU-Anzahl und Strompreis hinterlegen. Statusseite für den Kunden veröffentlichen oder Lesezugriff vergeben.
Häufige Fragen von Systemhäusern
Tarife
Ein Server-Monitor entspricht einem System Ihres Kunden, unabhängig von der Zahl seiner GPUs. Uptime-Monitore, Heartbeats, Statusseiten und Benachrichtigungskanäle sind in allen Tarifen enthalten. Für größere Kundenbestände: On-Premise.
- Server-Monitore (Knoten)3
- Uptime-Monitore5
- Heartbeats5
- Statusseiten1
- Eigene Domains für Statusseiten0
- Teammitglieder0
- Vorhaltezeit der Messwerte14 Tage
- API-Zugangnein
- Server-Monitore (Knoten)10
- Uptime-Monitore50
- Heartbeats50
- Statusseiten5
- Eigene Domains für Statusseiten1
- Teammitglieder5
- Vorhaltezeit der Messwerte365 Tage
- API-Zugangja
- Server-Monitore (Knoten)50
- Uptime-Monitore250
- Heartbeats250
- Statusseiten25
- Eigene Domains für Statusseiten5
- Teammitgliederunbegrenzt
- Vorhaltezeit der Messwerte365 Tage
- API-Zugangja
Alle Details, Zahlungsintervalle und der On-Premise-Betrieb stehen unter Tarife.
PeakNode für Ihren Anwendungsfall
Den ersten Kunden in einer Stunde im Portal
Konto anlegen, Projekt für den Kunden erstellen, Systeme mit einer Zeile anbinden.
Jetzt starten