VPS fuer Trading-Bots: Was wirklich wichtig ist

Was ein Trading-Bot von einem VPS benötigt

Ein VPS für Trading-Bots wird an vier Kriterien gemessen: Startet der Prozess nach einem Absturz wieder, stimmt die Systemzeit, sind die API-Schlüssel (application programming interface) ausreichend vor Diebstahl geschützt, und erfahren Sie, wenn der Prozess beendet wurde? Die reine Geschwindigkeit steht bei einem Bot für Privatanwender weit unten auf dieser Liste. Der langsamste Teil Ihres Orderpfads ist in der Regel Ihr Broker und die Entfernung zu ihm, nicht der Host, auf dem Ihr Python-Prozess läuft.

Dies ist eine Anleitung zur technischen Umsetzung. Die Inhalte stellen keine Finanzberatung dar, und es wird keine Strategie behandelt.

Uptime ist eine Frage der Neustartdisziplin, nicht nur eine Zahl auf einer Verkaufsseite

Die zugesicherten Uptime-Werte unterscheiden sich. AWS gibt für eine einzelne EC2-Instanz mindestens 99.5 Prozent und für qualifizierte Deployments über mehrere Availability Zones hinweg 99.99 Prozent an. Diese Zusagen beziehen sich auf die Verfügbarkeit der Infrastruktur, nicht auf den Zustand Ihres Bots. Ein Bot kann durch eine nicht behandelte Exception, eine WebSocket-Verbindung, die nie wieder hergestellt wird, oder den OOM (out of memory) Killer ausfallen, während der Server die ganze Zeit verfügbar bleibt. Die nützliche Frage lautet daher: Was geschieht in den zehn Sekunden, nachdem Ihr Prozess beendet wurde?

Führen Sie den Bot als systemd-Dienst aus, und überlassen Sie dem Init-System den Neustart. Eine Unit-Datei erledigt das.

[Unit]
Description=Trading bot
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=bot
WorkingDirectory=/opt/tradingbot
EnvironmentFile=/etc/tradingbot/api.env
ExecStart=/opt/tradingbot/venv/bin/python -m tradingbot
Restart=always
RestartSec=10
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/lib/tradingbot

[Install]
WantedBy=multi-user.target

StartLimitIntervalSec=0 ist die Zeile, die häufig übersehen wird. Die Standardwerte von systemd erlauben 5 Starts innerhalb von 10 Sekunden, einschließlich des initialen Starts und manueller Starts; die Manager-Konfiguration kann diese Standardwerte überschreiben. Wird das Limit erreicht, beendet systemd automatische Neustartversuche. Die Unit kann jedoch nach Ablauf des Intervalls manuell oder durch einen Timer oder Socket gestartet werden. Der Wert 0 deaktiviert die Ratenbegrenzung. Ein Bot, der in einer Absturzschleife läuft, versucht dann weiter zu starten, statt still auszufallen. RestartSec=10 verhindert, dass diese Schleife die Exchange mit Reconnects überlastet.

Prüfen Sie die Datei, bevor Sie ihr vertrauen, und starten Sie den Dienst anschließend:

sudo systemd-analyze verify /etc/systemd/system/tradingbot.service
sudo systemctl daemon-reload
sudo systemctl enable --now tradingbot
systemctl status tradingbot

enable ist die Hälfte der Konfiguration, die einen Reboot übersteht. Kernel-Updates machen Reboots erforderlich. Um festzustellen, ob der Bot unbemerkt beendet wurde, lassen Sie sich von systemd den Neustartzähler anzeigen:

systemctl show tradingbot -p NRestarts
journalctl -u tradingbot --since "24 hours ago" | tail -50

NRestarts=0 zählt keine automatischen Neustartjobs seit dem letzten Zurücksetzen des Zählers. Der Wert belegt daher keine fehlerfreie oder absturzfreie Woche. Manuelle Neustarts und systemctl reset-failed setzen den Zähler zurück. Ein hängender Bot kann weiterhin den Wert 0 anzeigen. NRestarts=812 zählt 812 Neustartjobs, nicht erfolgreiche Reconnects zur Exchange oder Trades, und macht keine Aussage darüber, wann diese stattgefunden haben. Prüfen Sie das Journal auf Zeitpunkt und Ursache. Dazu gehören auch Fehler, die auftreten, bevor der Bot eine Verbindung herstellt. Der vollständige Aufbau einer Unit-Datei einschließlich Timern für geplante Aufgaben wie einen täglichen Bericht wird unter ein Programm als systemd-Dienst ausführen beschrieben.

Uhr auf UTC setzen und die Synchronisierung nachweisen

Exchange-APIs verwenden Zeitstempel, um signierte Anfragen zu validieren. Binance Spot verwendet standardmäßig ein Empfangsfenster von 5 Sekunden und lehnt Zeitstempel ab, die mindestens 1 Sekunde vor der Serverzeit liegen. Eine abweichende Systemuhr erzeugt Fehler, die wie Authentifizierungsfehler aussehen. Deshalb tauschen viele Benutzer stundenlang Schlüssel aus, bevor sie die Uhrzeit prüfen. Bei APIs nach dem Muster von Binance ist die Meldung eindeutig: Timestamp for this request was 1000ms ahead of the server's time.

Setzen Sie den Server auf UTC. Lokale Zeitzonen führen bei der Anzeige zu Sprüngen durch die Sommerzeit. Unix-Zeitstempel, die APIs verwenden, ändern sich beim Wechsel der Anzeigezeitzone nicht.

sudo timedatectl set-timezone UTC
timedatectl

Ubuntu verwendet ab Version 25.10 standardmäßig chrony. Ältere Installationen können systemd-timesyncd verwenden, einen SNTP-Client (Simple Network Time Protocol). systemd-timesyncd stellt die Uhr, kann jedoch nicht mehrere Server gleichzeitig abfragen, um eine falsche Zeitquelle zu erkennen. Verwenden Sie stattdessen chrony:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
chronyc tracking
chronyc sources -v

Die in chronyc tracking auszulesende Zeile lautet System time, zum Beispiel System time : 0.000031415 seconds fast of NTP time. Ein kleiner Wert zeigt eine kleine verbleibende Korrektur an der NTP-Uhr von chrony. Prüfen Sie vor einer Bewertung der Genauigkeit auch die Synchronisierung, Root delay und Root dispersion. Wenn dort Leap status : Not synchronised steht, ist chrony nicht synchronisiert, auch wenn Server geantwortet haben. Messwerte können als zu ungenau verworfen werden. Warten Sie eine Minute und prüfen Sie anschließend erneut, bevor Sie Firewall-Regeln ändern.

API-Schlüssel nicht an Stellen ablegen, die Sie kopieren

Ein offengelegter Exchange-Schlüssel ist gefährlicher als ein offengelegter SSH-Schlüssel, weil die Berechtigung für Auszahlungen ihn sofort in Geld verwandelt. Zwei Gewohnheiten decken den größten Teil des Risikos ab.

Erteilen Sie einem Bot-Schlüssel erstens niemals eine Auszahlungsberechtigung. Wenn der Exchange dies unterstützt, beschränken Sie den Schlüssel außerdem auf die IP-Adresse Ihres Servers. Dies ist die einzelne Maßnahme, durch die ein gestohlener Schlüssel nahezu nutzlos wird.

Halten Sie das Geheimnis zweitens aus dem Codeverzeichnis heraus. Alles innerhalb von /opt/tradingbot landet früher oder später in einem git-Repository oder einem Backup-Archiv. Legen Sie es in einer Datei ab, die root gehört und von systemd eingelesen wird:

sudo install -d -m 750 -o root -g bot /etc/tradingbot
sudo install -m 640 -o root -g bot /dev/null /etc/tradingbot/api.env
sudo nano /etc/tradingbot/api.env

Die Datei enthält einfache KEY=value-Zeilen ohne Anführungszeichen und ohne export. Der Modus 640 gewährt dem Eigentümer root Lese- und Schreibzugriff sowie Mitgliedern der Gruppe bot Lesezugriff. Andere Benutzer erhalten keine Berechtigungen. Prüfen Sie dies mit sudo -u bot cat /etc/tradingbot/api.env und anschließend mit einem unprivilegierten Benutzer außerhalb der Gruppe bot. Der Zugriff muss mit Permission denied fehlschlagen.

Der Bot selbst sollte weder als root noch als Ihr Anmeldebenutzer ausgeführt werden. Erstellen Sie vor dem Starten des Dienstes oder dem Anlegen von Dateien, die der Gruppe bot gehören, ein Systemkonto mit einer nologin-Shell und /var/lib/tradingbot als Home-Verzeichnis:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/tradingbot --create-home bot

Die Begründung für jedes dieser Flags und die tatsächliche Reichweite von ProtectSystem=strict finden Sie unter Dienste als unprivilegierter Benutzer ausführen. Die übrigen grundlegenden Maßnahmen für den Server, SSH-Schlüssel und eine Firewall, gehören in die ersten zehn Minuten auf einem neuen VPS.

Erkennen Sie den Ausfall, bevor Ihr Broker ihn erkennt

systemctl status zeigt an, dass der Prozess läuft. Das bedeutet nicht, dass der Bot arbeitet. Ein Prozess, der in einer Wiederholungsschleife gegen einen nicht erreichbaren WebSocket festhängt, besteht die Prozessprüfungen aus der vorherigen Unit.

Verwenden Sie stattdessen einen Heartbeat. Uptime Kuma unterstützt Push-Monitore: Der Bot muss eine URL nach einem festen Zeitplan aufrufen. Bleiben die Aufrufe aus, wird ein Alarm ausgelöst. Platzieren Sie den Aufruf am Ende Ihrer Hauptschleife, nach dem Teil, der belegt, dass der Bot aktiv ist, beispielsweise nach einem erfolgreichen Abruf von Marktdaten.

curl -fsS "http://monitor.example.com:3001/api/push/YOUR_TOKEN?status=up&msg=loop_ok"

Setzen Sie das Monitorintervall auf ungefähr das Doppelte Ihrer Schleifenlaufzeit. Dadurch lösen normale Schwankungen keinen Alarm aus. Betreiben Sie den Monitor auf einem anderen Server als den Bot. Wenn der Monitor zusammen mit dem überwachten Dienst ausfällt, meldet er nichts. Die Einrichtung wird unter Self-Hosting der Statusüberwachung mit Uptime Kuma beschrieben.

Fügen Sie außerdem einen Festplattenalarm hinzu. Ein Bot, der ausführliche Logs schreibt, füllt das Root-Dateisystem innerhalb weniger Wochen. Bei einer vollen Festplatte schlägt der Datenbankschreibvorgang fehl, nicht der Netzwerkaufruf. Dadurch wirken die Symptome ungewöhnlich. journalctl --vacuum-time=14d und eine SystemMaxUse=-Zeile in /etc/systemd/journald.conf begrenzen die Größe des Journals.

Der ehrliche Teil: Die Latenz hängt größtenteils nicht von Ihrem Host ab

Hier endet der technische Teil des Marktes für Trading-VPS-Produkte. Marketingseiten nennen Werte im Submillisekundenbereich und erwecken den Eindruck, der Host stehe zwischen Ihnen und einer Ausführung. Für fast jeden Bot im Retail-Bereich ist das nicht der Fall.

Ihre Order läuft vom Bot über das öffentliche Internet zum Endpunkt der Börse oder des Brokers. Dieser Weg wird hauptsächlich durch die physische Entfernung und das Peering zwischen Ihrem Provider und dem Provider der Gegenstelle bestimmt. Anschließend fügen die Systeme des Brokers ihre Warteschlange, ihre Risikoprüfungen und ihre Rate Limits hinzu.

Messen Sie, statt zu raten. curl gibt die Verbindungs- und First-Byte-Zeiten für einen echten Endpunkt aus:

curl -s -o /dev/null -w 'dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://api.kraken.com/0/public/Time
mtr -rwzc 100 api.kraken.com

Führen Sie diesen Befehl auf einem möglichen Server aus, bevor Sie sich festlegen. Wenn connect 0.180 Sekunden beträgt, umfasst dieser Wert die DNS-Auflösung und den TCP-Verbindungsaufbau. Er zeigt jedoch nicht, auf welchem Kontinent Sie sich befinden. Wenn connect 0.004 Sekunden und ttfb 0.140 Sekunden beträgt, umfasst die Differenz den TLS-Aufbau, die Übertragung der Anfrage, Netzwerkverzögerungen und die Verarbeitung auf dem Server. Ein Hostwechsel kann einige dieser Komponenten beeinflussen. Vergleichen Sie daher Messungen von möglichen Standorten.

Wann spielt der Host also eine Rolle? Wenn Sie per Colocation oder Cross-Connect direkt mit dem Handelsplatz verbunden sind und um die Position in der Warteschlange konkurrieren. Das ist ein anderes Geschäft mit einem anderen Budget. Eine Rolle spielt er auch, wenn Ihr eigener Code der Engpass ist: Ein Bot, der bei jedem Tick Indikatoren über die vollständige Historie neu berechnet, kann pro Schleife 200 Millisekunden CPU-Zeit verbrauchen. Das ist echte Latenz, die Sie kostenlos kontrollieren können. Profilieren Sie die Schleife, bevor Sie nach einem schnelleren Server suchen.

Wichtig bei der Auswahl des Hosts sind die geografische Lage, ein stabiles Netzwerk und ausreichend Arbeitsspeicher, damit der OOM-Killer nie eingreifen muss. Fügen Sie Arbeitsspeicher hinzu, wenn Sie Tick-Historien in einer lokalen Datenbank speichern.

Eine kurze Checkliste vor dem Live-Betrieb

1. systemctl is-enabled tradingbot gibt enabled aus, und der Dienst übersteht sudo reboot.
2. chronyc tracking meldet eine Synchronisierung, eine Abweichung der Systemzeit von unter einigen Millisekunden sowie Root-Delay und Root-Dispersion innerhalb Ihres Zeitbudgets.
3. Der API-Key verfügt über eine Handelsberechtigung, aber keine Auszahlungsberechtigung. Falls die Börse eine IP-Allowlist anbietet, ist sie konfiguriert.
4. Wenn Sie den Prozess mit sudo systemctl kill -s SIGKILL tradingbot beenden, wird er nach der Verzögerung von RestartSec und der Startzeit wieder gestartet.
5. Der Heartbeat-Monitor sendet Ihnen nach dem konfigurierten Intervall einen Alert und führt Wiederholungsversuche durch, wenn Sie den Bot absichtlich anhalten.
6. Die Logs sind begrenzt, und das Root-Dateisystem verfügt in df -h über ausreichend freien Speicherplatz.

Führen Sie das gesamte System eine Woche lang in der Sandbox der Börse oder im Paper-Modus aus, bevor Sie echtes Kapital einsetzen. Jeder Punkt oben schlägt innerhalb dieser Woche mindestens einmal fehl. Genau das ist der Zweck dieser Woche.

FAQ

Benötigt ein Trading-Bot einen Server mit niedriger Latenz oder einen Bare-Metal-Server?

Nur wenn Sie am selben Handelsplatz mit anderen automatisierten Teilnehmern um Ausführungsgeschwindigkeit konkurrieren. In diesem Fall ist normalerweise Colocation statt eines allgemeinen VPS erforderlich. Bei einem Bot für Privatanwender wird die Round-Trip-Zeit hauptsächlich durch die geografische Entfernung und die Verarbeitung beim Broker bestimmt. Wählen Sie daher einen Server in der Nähe des API-Endpunkts und messen Sie mit curl und mtr, bevor Sie für eine schnellere Lösung bezahlen.

Wie viel RAM und CPU benötigt ein Trading-Bot?

Die meisten Bots mit einer einzelnen Strategie sind netzwerkgebunden und zwischen den Ereignissen im Leerlauf. Der Speicher wird zum begrenzenden Faktor, wenn Sie Tick-Historien im Prozess halten oder eine lokale Datenbank betreiben. Überwachen Sie daher free -h und das Journal auf OOM-Kill-Meldungen, statt den Bedarf zu schätzen.

Warum lehnt meine Exchange-API Anfragen mit einem Zeitstempelfehler ab?

Der Zeitstempel der Anfrage liegt außerhalb des vom Exchange akzeptierten Zeitfensters. Sowohl die Zeitabweichung der Systemuhr als auch Verzögerungen bei der Anfrage sind relevant. Installieren Sie chrony. Prüfen Sie, ob chronyc tracking einen kleinen Offset von System time und einen synchronisierten Schaltsekundenstatus anzeigt. Prüfen Sie außerdem Root-Delay und Dispersion. Die Einstellung des Systems auf UTC sorgt für einheitlich angezeigte Zeiten, korrigiert aber keine Zeitabweichung. Das Ersetzen des API-Schlüssels behebt kein Problem mit der Systemuhr.

Wie verhindere ich, dass mein Bot über Nacht unbemerkt beendet wird?

Führen Sie ihn mit systemd und Restart=always sowie StartLimitIntervalSec=0 aus. Dadurch werden Abstürze weiterhin versucht, statt das Start-Rate-Limit zu erreichen. Ergänzen Sie anschließend einen Heartbeat, den der Bot am Ende jedes erfolgreichen Durchlaufs sendet. Der Neustart behandelt den Prozess. Der Heartbeat erkennt den Fall, dass der Prozess noch läuft, aber feststeckt.

Kann ich den Bot und meine Überwachung auf demselben VPS ausführen?

Das ist möglich. An dem Tag, an dem es darauf ankommt, liefert Ihnen die Überwachung jedoch falsche Sicherheit, weil ein Ausfall, der den Bot beendet, auch die Überwachung beendet. Betreiben Sie das Alerting auf einem separaten Rechner, möglichst bei einem anderen Provider oder in einer anderen Region. Verwenden Sie den Server des Bots ausschließlich für den Bot und seine Logs.