5-C)

Lieber Benutzer, dieses Kapitel stellt drei erweiterte Funktionen vor: Daten-Snapshots vor der Strategieausführung, Zugriffskontrolle beim Marktstart vor der Marktöffnung sowie Abgleich und Protokollierung bei Langzeitläufen. Falls Sie die Basis-Live-Anwendung noch nicht erfolgreich ausgeführt haben, lesen Sie bitte zuerst Simulierte Handelsplattform: Konfiguration und Betrieb.

Welches Problem behandelt dieses Kapitel? Strategien auf Minutenebene, die in jedem Schritt Daten abrufen, sind langsam und anfällig für Datenlücken. Die Platzierung von Aufträgen vor Marktöffnung ohne korrekte Konfiguration oder Daten birgt erhebliche Risiken. Wir haben diese Prüfungen konfigurierbar gemacht und zur einfachen Überprüfung protokolliert.

Interne Code-Namenszuordnung (wird von Wartungsteams/Smoke-Dokumenten verwendet)

In der Weiterentwicklung von qteasy live bezeichnen 5-A / 5-B / 5-C drei Funktionen: Richtlinien-Snapshots, Aktivierungszugriffskontrolle und Langzeitbeobachtung. In der Smoke-Dokumentation und den Wartungshinweisen werden Codenamen verwendet; als Benutzer müssen Sie sich nur den rechts angegebenen „benutzerorientierten Namen“ merken. Die folgende Tabelle zeigt die Entsprechung zwischen den Codenamen und ihrer üblichen Verwendung – im weiteren Verlauf dieses Kapitels können Sie „5-B“ als „Aktivierungszugriffskontrolle“ verstehen.

Bedeutung der einzelnen Spalten: Code ist die interne Stufennummer; Benutzerdefinierter Name ist der in der Dokumentation empfohlene Name; Ein Satz gibt die Position dieser Funktion in der Live-Pipeline an.

Anwendung: Wenn Sie im Haupttext Codes wie 5-A sehen, beziehen Sie sich auf diese Tabelle; den Namen des Konfigurationsschlüssels finden Sie in Simulierte Handelsplattform: Konfiguration und Betrieb §4 „Policy Snapshot“ Zeile „Start Access Control“.

Codename	Benutzername	Zusamenfassend
5-A	Strategieübersicht	Die Daten werden vor Ausführung der Strategie vorab abgerufen, und dieser Schritt nutzt die Daten wieder, um redundante E/A-Operationen zu reduzieren.
5-B	Zugriffskontrolle aktivieren	Vor dem Öffnen/Starten den Bereitschaftsstatus prüfen; falls dieser fehlschlägt, sollte ein Alarm ausgelöst oder eine Sperre vorgenommen werden.
11/5-C	Langfristig beobachtbar	Auftragszuordnung zum Brokerkonto, Rotation des Risikologs, Abgleich und Diagnose von Aufträgen in Bearbeitung

5-A: Strategieüberblick

Man kann es sich folgendermaßen vorstellen: Vor jeder „Prüfung“ bereiten Sie die Prüfungsunterlagen und Materialien auf Ihrem Schreibtisch vor; wenn Sie dann tatsächlich die Fragen beantworten, müssen Sie nicht mehr zum Drucker eilen.

Wenn live_trade_split_strategy_prepare=True, fügt qteasy vor jedem geplanten run_strategy-Zeitpunkt eine prepare_strategy_snapshot-Aufgabe ein (die Vorlaufzeit wird durch live_trade_prepare_lead_seconds gesteuert; 0 bedeutet, dass die Aufgaben gleichzeitig in die Warteschlange gestellt werden, aber die Reihenfolge garantiert dennoch, dass die Vorbereitung zuerst erfolgt).
Die Funktion prepare_strategy_snapshot erledigt die aufwendigen Arbeiten, die vor run_strategy durchgeführt wurden: Aktualisierung der Daten mit Untertagesfrequenz, Vorbereitung der Datenpuffer, Aktualisierung der Live-Preise und Einspeisung der Prozessdaten; nach Abschluss hinterlässt sie eine Markierung „Snapshot gültig“ im Speicher (Handelstag + Schrittnummer + Zeit).
Wenn anschließend run_strategy feststellt, dass der Snapshot noch innerhalb von live_trade_strategy_snapshot_max_age_seconds liegt und die Schrittnummer konsistent ist, wird das obige Abrufen nicht wiederholt; andernfalls wird snapshot_missing / snapshot_stale protokolliert und die Strategie dieses Schritts wird übersprungen (um die Verwendung abgelaufener Daten zur Berechnung von Signalen zu vermeiden).
Wenn Split aktiviert ist, werden prepare_strategy_snapshot und run_strategy synchron im Hauptthread ausgeführt (getrennt von asynchronen Live-Preisberechnungsaufgaben), wodurch vermieden wird, dass mehrere Threads gleichzeitig auf den Operator zugreifen.

Abweichungen vom tatsächlichen Verhalten: Snapshots befinden sich im Arbeitsspeicher und müssen nach einem Neustart des Prozesses erneut erstellt werden; sie sind keine permanenten Caches auf der Festplatte.

5-B: Starten Sie die Zugriffskontrolle (run_startup_gate)

Man kann es sich so vorstellen: eine Sicherheitsprüfung vor dem Start – ob die Strategie bereit ist, ob die notwendigen Datentabellen verfügbar sind und (optional) ob das lokale Hauptbuch mit dem des Brokers übereinstimmt.

live_trade_startup_gate_mode:
- aus — Zugangskontrolle deaktivieren
- warn — Fehler werden nur protokolliert/nachverfolgt, Transaktionen sind aber weiterhin erlaubt (empfohlen für eine schrittweise Einführung).
- block wird abgelehnt, wenn es fehlschlägt. run_strategy wird dann in die Warteschlange gestellt (skip_reason=gate_failed).
Der Händler wird die Zugriffskontrolle nach der Generierung des Tagesplans aufrufen (Handelsfreie Tage werden schnell übersprungen).
Überprüfen Sie die Schichtung (Fehlercodes werden in die Ablaufverfolgung „Fehler“ geschrieben):
- L1: Ist der Operator bereit? Existiert das Konto?
- L2: Gibt an, ob die Haupthistorietabelle in der Datenquelle enthalten ist (zugeordnet zur Tabelle mit täglicher Häufigkeit durch asset_type usw.)
- L3 (Optional): Falls der Broker einen nicht leeren Remote-Cashbestand/eine Remote-Position zurückgibt, vergleichen Sie diesen/diese mit dem/der lokalen Bestand; führen Sie keinen harten Vergleich durch, wenn die Remote-API nicht implementiert ist.

Eine vollständige Liste der manuellen Smoke-Live-Grid-Straßen finden Sie unter Lösung zur manuellen Erzeugung von simuliertem Rauch im Live-Handel (live_grid_multi).

5-C: Überwachung von Hauptbuch, Protokollen und Wiederherstellung

Ab Version 5-A/5-B ermöglicht es die Fehlerbehebung und -prüfung aus der Ferne (ausgenommen automatische Auftragsänderung/-kompensation; die eigentliche QMT-Fernabfrage erfolgt in einer späteren Version):

Auftrag ↔ Broker-ID-Zuordnung: Bei erfolgreicher Annahme wird broker_order_id / broker_name zurückgeschrieben; wird der Auftrag abgelehnt, wird rejected zurückgeschrieben und das Broker-Feld bleibt leer.
Erweiterung für die Protokollrotation: rotate_trade_logs löscht zusätzlich zur Handels-CSV-Datei auch abgelaufene *.risk.log-Dateien (siehe Produktliste und Fehlerbehebung für die Regeln).
Abgleich und Diagnoseverfolgung:
- Die Befehle pre_open und post_close geben den reconcile-Checkpoint aus (z. B. checkpoint_passed, checkpoint_warn).
- DEBUG-Task ``diagnose_pending_orders`: Lesegeschützter Vergleich lokaler und entfernter ausstehender Aufträge.

Fazit für Anfänger: Zwei Arten von „Auftragsablehnungen“

Im Live-Auftragsprozess kann eine Ablehnung entweder beim RiskManager-Prüfschalter (Risikomanagement) oder bei der Broker-Bearbeitung (Annahme) erfolgen, wobei die entsprechenden Nachweise an völlig unterschiedlichen Stellen gespeichert sind. Die Dokumentation „3-Risiko-und-Auftragslebenszyklus“ hat dies bereits aus Prozesssicht erläutert; die folgende Tabelle bietet einen Vergleich zwischen der Auftragstabelle und der broker_order_id zur schnellen Fehlerbehebung.

Spaltenbedeutungen: Pfad gibt den Typ der Auftragsablehnung/des Auftragserfolgs an; Lokale Auftragstabelle gibt an, ob eine neue Zeile hinzugefügt wurde; broker_order_id gibt an, ob ein Write-Back erforderlich ist; Audit gibt die Datei oder Tabelle an, die zuerst geöffnet werden sollte.

Anwendung: Die CLI zeigt einen riskanten Ablehnungsgrund und keine neuen Aufträge an → erste Zeile; die Auftragsliste zeigt „abgelehnt“ an und die Brokernummer ist leer → zweite Zeile; die Brokernummer ist vorhanden → dritte Zeile, dann den Transaktionsstatus prüfen.

Beispiel: risk_log enthält ``<RISK REJECTED> Sollten im Bereich „Aufträge“ keine entsprechenden neuen Aufträge vorhanden sein, wird der Auftrag vom Risikomanagement abgelehnt. Überprüfen Sie nicht die Verbindungsinformationen Ihres Brokers.

Weg	Lokales Bestellformular	Broker-Auftrags-ID	Prüfung
Auftragsablehnung aufgrund von Risikokontrollmaßnahmen	Nicht eingelagert	—	*.risk.log + ``<RISK REJECTED> ``
Abwicklung von abgelehnten Bestellungen am Schalter	Da ist eine Zeile: „abgelehnt“.	leer	Bestellformular + Sendungsverfolgung
Bewerbung erfolgreich	eingereicht usw.	Bitte antworten Sie	Bestellformular + Sendungsverfolgung

Ausgabefelder für diagnose_pending_orders (kurz)

local_pending_count — Lokale Anzahl der ausstehenden Vorgänge
``remote_pending_count` — Ungerade Anzahl ausstehender Remote-Anfragen (Simulator ist normalerweise leer)
local_pending_without_broker_order_id — Lokale Aufträge wurden übermittelt, aber ohne Broker-ID
local_pending_missing_remote — Ein Brokerkonto existiert lokal, aber nicht remote.
remote_pending_not_in_local — Auf der Remote-Seite zugeordnet, aber nicht auf der lokalen Seite.

CLI und DEBUG (Betrieb und Wartung)

Trader Shell (–ui cli) häufig verwendete Befehle (Hilfe in Englisch):

gate / startup-gate — Den Startvorgang der Torsteuerung manuell ausführen.
reconcile / snapshot-reconcile — Abgleich-JSON
run –task diagnose_pending_orders — Ausstehende Bestellungen diagnostizieren (erfordert DEBUG)
artifacts / ls-artifacts — Vier-Bindungs-Artefaktpfade
rotatelogs / rotate-logs — Manuelle Logrotation
broker status|connect|disconnect — Brokerage-Sitzung (Simulator ist das Flag)
sync / pull-state — Reserviert, die eigentliche Remote-Synchronisierung ist noch nicht implementiert.

Empfehlungen für den nächsten Handelstag

5-A: Gibt es zu viele strategy_run_skipped-Einträge im Trace? Ist die Live-Preisfrequenz nicht niedriger als die Strategieschrittfrequenz?
5-B: Verwenden Sie zuerst warn, um gate_warn / gate_failed zu überprüfen; verwenden Sie dann CLI gate, um dies zu überprüfen, bevor Sie block versuchen.
5-C: Schließen des Marktes mit reconcile und diagnose_pending_orders; falls erforderlich, rotatelogs –days N, um die Risikobereinigung zu überprüfen.