Produktliste und Fehlerbehebung

Dieses Kapitel ist eine Art „Erste-Hilfe-Handbuch“ für die Simulation des Live-Handels: Es erklärt, wo sich das Protokoll befindet, welche Datei zuerst überprüft werden sollte und in welcher Reihenfolge häufig auftretende Probleme behoben werden sollten.

Lieber Benutzer, Live hinterlässt verschiedene Arten von festen Ausgabedateien auf Ihrer Festplatte. Behandeln Sie diese wie vier separate Ordner. Wenn Probleme auftreten, suchen Sie in diesen Ordnern nach der richtigen Ausgabedatei. Dies ist wesentlich effizienter als die ziellose Suche in großen Mengen an Ausgabedateien.

0. 适用场景

  • Sie befinden sich bereits im Live-Modus und erleben Probleme wie Übermittlungsfehler, Auftragsablehnung, abnormalen Status oder Inkonsistenzen bei Bestellungen während des Transports.

  • Sie möchten das Problem in einer festen Reihenfolge lokalisieren, um wiederholte Neustarts zu vermeiden.

  • Sie müssen den Log-Pfad, die Rotationsstrategie und die Frage, ob broker_order_id zurückgeschrieben wird, überprüfen.

1. 核心概念：四键产物

Qteasy stellt jedem Live-Konto vier feste Schlüsselnamen für den Pfad zur Verfügung (der Pfad bleibt auch dann gültig, wenn die Datei nicht existiert). Im Observability-Design des Live-Subsystems entsprechen diese vier Artefakttypen jeweils dem Systembetrieb, Transaktionsdetails, der Anomalie-Wiederherstellung und dem Risikokontroll-Audit. Ermitteln Sie bei der Fehlersuche bitte zuerst die Kategorie des Problems und öffnen Sie dann die entsprechende Datei, anstatt das gesamte Protokoll zu durchsuchen.

Bedeutung der einzelnen Spalten: Schlüsselname: Der von list_live_trade_artifacts / CLI artifacts zurückgegebene Dictionary-Schlüssel; Was es ist: Der Dateityp; Wann es geöffnet werden soll: Das typische Auslöseszenario.

Anwendung: Drücken Sie :doc:3-risk-and-order-lifecycle, um den Ablehnungstyp der Order zu ermitteln → prüfen Sie risk_log für die Risikokontrolle, prüfen Sie trade_log für Transaktionen; prüfen Sie sys_log für Start-/Zugriffskontrolle/Trace.

Schlüsselname

Was ist das?

Wann sollte es eingeschaltet werden?

sys_log

Systembetriebsprotokoll

Aufgabenplanung, Aktivierung der Zugriffskontrolle, Protokollierung, allgemeine Fehlerberichterstattung

trade_log

Transaktionsdetails (CSV)

Einzelheiten zu Transaktionen, Gebühren und Positionsänderungen

break_point

Die Datei wird ab dem Haltepunkt fortgesetzt (Schlüsselname: break_point).

Wie kann der Trader-Status nach einem abnormalen Ausstieg wiederhergestellt werden?

risk_log

Prüfung der Ablehnung von Risikokontrollaufträgen (*.risk.log)

Priorisierung bei Verdacht auf Ablehnung der Risikokontrolle

Beispiele (API und CLI):

import qteasy as qt
arts = qt.list_live_trade_artifacts(account_id=1, data_source=qt.QT_DATA_SOURCE)
print(arts['sys_log'], arts['trade_log'], arts['break_point'], arts['risk_log'])
# 若 CLI 提示 risk 拒单，可单独打开：
print(arts['risk_log'])

Denselben Pfad aus vier Tasten erhalten Sie auch, indem Sie in der Trader Shell artifacts (Alias ls-artifacts) eingeben.

Pfadregeln (Kurzfassung):

  • Es werden relative Pfade relativ zum Qteasy-Stammverzeichnis unterstützt; absolute Pfade werden auch relativ zum ~/...-Home-Verzeichnis unterstützt.

  • Die Pfade sys_log_file_path und trade_log_file_path können zur Laufzeit mit qt.configure(...) geändert werden und werden sofort wirksam.

2. 日志轮换

Die Langzeit-Live-Protokollierung sammelt CSV- und Risikoprotokolle. Qteasy bereinigt abgelaufene Dateien nach trade_log_keep_days (Standardwert: 3 Tage).

  • API: qt.rotate_trade_logs(days=None)

  • **CLI: rotatelogs (Alias rotate-logs), optional --days N

Bereinigungsbereich (innerhalb des aktuellen Transaktionsprotokollverzeichnisses):

  • trade_log_*.csv / trade_summary_*.csv / value_curve_*.csv

  • *.risk.log

Bei jedem Import von qteasy durch einen neuen Python-Prozess wird dies automatisch einmal wiederholt; Sie können den obigen Befehl auch während des Betriebs und der Wartung manuell ausführen.

3. 建议排错顺序（决策树）

Bitte beantworten Sie die folgenden Fragen der Reihe nach und vermeiden Sie es, Schritte auszulassen:

Schritt 1 – Wird auf der Benutzeroberfläche ein englischer Ablehnungsgrund angezeigt?

  • Ja, und es folgt dem Risikokontrollpfad (Schritt 3), ähnlich wie bei „Auftrag aufgrund von Risikoregel abgelehnt […]“.

  • Falls Fehler wie „Auftragsübermittlung fehlgeschlagen“ auftreten, fahren Sie mit dem Übermittlungs-/Verbindungspfad fort (Schritt 4).

  • Keine offensichtliche Fehlermeldung, aber fehlerhaftes Verhalten → Schritt 6

Schritt 2 – Öffnen Sie artifacts und vergewissern Sie sich, dass die vier Pfade beschreibbar sind und die Datei wächst.

Schritt 3 – Ablehnung der Risikokontrolle

  • Überprüfen Sie risk_log undrule_id`

  • Es sollte keine neue Auftragszeile erscheinen (anders als bei Gegenablehnungen).

Schritt 4 – Bedienung am Schalter / Verbindung

  • Der Wert broker status: is_connected gibt an, ob die Verbindung hergestellt wurde (im Simulator bedeutet dies, dass die Adapterschicht die Anfrage bearbeiten kann).

  • Auftragstabelle: Enthält sie Aufträge mit Einträgen „abgelehnt“ und einer leeren Brokernummer (Auftrag am Schalter abgelehnt)?

Schritt 5 – Uneinheitliche Reisedokumente

  • Im DEBUG-Modus: run --task diagnose_pending_orders

  • Oder verwenden Sie Shell: reconcile, um das JSON anzuzeigen.

Schritt 6 – Entspricht die Konfiguration meinen Erwartungen?

  • liveconfig --detail prüft den Snapshot.

**Schritt 7 — Vergleichen Sie das Handelsprotokoll mit der Auftragsstatussequenz und verwenden Sie den endgültigen Status im Protokoll als Standard.

4. 高频故障剧本

Jeder Abschnitt folgt der gleichen Abfolge: Phänomen → Was zuerst zu überprüfen ist → Häufige Ursachen → Nächster Schritt.

A. Auftrag von der Risikokontrolle abgelehnt.

  • Problem: CLI-Ablehnung aufgrund eines englischen Fehlers; das Ergebnis der Übermittlung ist leer {}

  • Erste Prüfung: risk_log enthält ` Bestelltabelle nein neue Zeile

  • Häufige Gründe: Überschreitung des Limits für Einzeltransaktionen, Nichtbeachtung der Whitelist, Handel außerhalb der Handelszeiten usw.

  • Nächste Schritte: Passen Sie die Regeln oder Auftragsparameter an und testen Sie erneut im selben Szenario; Einzelheiten finden Sie unter :doc:3-risk-and-order-lifecycle.

B. Einreichung fehlgeschlagen (nicht aufgrund von Risikokontrolle)

  • Problem: Kein gültiger Übermittlungsdatensatz oder lokaler Verifizierungsfehler.

  • Erste Prüfung: Brokerstatus, Angemessenheit der Liquidität/Positionen und Fehlerprotokoll (sys_log).

  • Häufige Ursachen: Keine Verbindung, ungültiges Feld, unzureichende Ressourcen

  • Nächster Schritt: Versuchen Sie es erneut, nachdem Sie die Verbindung oder das Feld repariert haben.

C. Bearbeitung abgelehnter Bestellungen

  • Auswirkung: Die Auftragstabelle enthält Zeilen, in denen status=rejected steht und broker_order_id leer ist.

  • Erste Prüfung: Trace und der von der Verarbeitungsabteilung zurückgegebene Grund.

  • Häufiger Grund: Die Regeln des simulierten Brokerhauses lassen diesen Auftrag nicht zu (unabhängig von der Risikokontrolle).

  • Nächster Schritt: Beachten Sie die Ablehnungsliste im Dokument :doc:6-trader-snapshot-gate und verwechseln Sie diese nicht mit der Risikokontrolle.

D. Langfristig teilweise gefüllt

  • Phänomen: Bestellungen werden regelmäßig nur teilweise ausgeführt.

  • Erste Prüfung: Kumuliertes Handelsvolumen im Vergleich zur Anzahl der Aufträge.

  • Häufige Gründe: Die erforderlichen Renditen wurden noch nicht vollständig realisiert; oder die Marktbedingungen führen zu langsamen Transaktionen in Chargen.

  • Nächster Schritt: Ermitteln Sie, ob das Transaktionsfeedback verwendet werden soll, um den Status auf erledigt zu aktualisieren.

E. Der Status nach der Markteinführung ist ungewiss.

  • Problem: Es ist unklar, wie mit ausstehenden Aufträgen nach Börsenschluss umzugehen ist.

  • Erste Prüfung: post_close-bezogene Traces, reconcile-JSON.

  • Nächster Schritt: Überprüfen Sie die Stornierungsbestellung und den endgültigen Status.

F. broker_order_id / Ausnahme bei in Bearbeitung befindlicher Bestellung

Wenn der lokale Auftragsstatus, die Brokerauftragsnummer oder die Liste der in Bearbeitung befindlichen Aufträge nicht übereinstimmen, sind die Phänomene vielfältig, lassen sich aber alle in die folgenden Tabellen einordnen. Diese Tabelle gehört zur Kategorie der Live-Beobachtbarkeit gemäß 5-C, was mit den Diagnosefeldern von :doc:6-trader-snapshot-gate übereinstimmt; die Remote-Spalten im Simulator sind häufig leer, was normal ist.

Bedeutung der einzelnen Spalten: Phänomen ist der von Ihnen beobachtete Widerspruch; Erste Prüfung ist die primäre Beweisquelle; Nächster Schritt ist eine empfohlene Vorgehensweise (in erster Linie eine schreibgeschützte Diagnose, die nicht automatisch modifiziert wird).

Anwendung: Die Zeile „phenomenon“ abgleichen → „Check First“ ausführen → Falls immer noch Unklarheiten bestehen, --task diagnose_pending_orders im DEBUG-Modus ausführen.

Phänomen

Zuerst prüfen

Nächster Schritt

Die Risikokontrolle lehnt Bestellungen ab

risk_log enthält keine neuen Auftragszeilen.

Anpassungsregeln

Gegenablehnung

Auftrag abgelehnt, Broker leer.

Spur / Grund

Eingereicht, aber keine Broker-ID

Annahmebestätigung (ACK) und Rückschreiben

:doc:4-broker-adapter-and-integration

Inkonsistenz zwischen lokalem und entferntem Verkehr

DEBUG: run --task diagnose_pending_orders

Nur lesbare Diagnosedaten; der entfernte Simulator ist oft leer.

CLI-Hilfsfunktionen: reconcile, gate.

G. Inkonsistenz zwischen der Benutzeroberfläche und den Protokollen

  • Problem: Die CLI-Eingabeaufforderungen und die nachfolgenden Protokollprüfungen scheinen widersprüchlich zu sein.

  • Erste Prüfung: Alle Datensätze mit derselben Auftrags-ID in zeitlicher Reihenfolge ausrichten.

  • Nächster Schritt: Führen Sie eine Nachuntersuchung auf Basis des endgültigen Zustands des Holzes durch.

5. 运维建议

  • Überprüfen Sie regelmäßig die Nutzung des Transaktionsprotokollverzeichnisses; verwenden Sie gegebenenfalls rotatelogs --days N.

  • Speichern Sie die Ausgabe von liveconfig --detail an kritischen Laufzeittagen als Screenshot oder Text.

  • Langstreckenlauf oder Vorabversionsreferenz: doc:7-manual-smoke-live-grid-roadmap

6. 快速检查清单

  • Konto korrekt

  • Die Konfiguration wird wirksam (liveconfig)

  • Wird der Antrag vom Risikokontrollsystem abgelehnt (risk_log)?

  • Kann das Brokerhaus dies handhaben (Brokerstatus)?

  • Soll broker_order_id nach erfolgreicher Verarbeitung zurückgeschrieben werden?

  • Vier-Schlüssel-Pfade sind lesbar (artifacts).

7. 常用英文提示与中文含义

Order rejected by risk rule [MAX_ORDER_QTY]: order quantity exceeds limit

Bedeutung: Die lokale Risikokontrollregel MAX_ORDER_QTY wurde abgelehnt – die Bestellmenge hat das Limit überschritten. Prüfen Sie das Risikoprotokoll; die Ablehnung des Auftrags erfolgte nicht durch ein Brokerhaus.

<RISK REJECTED> rule_id='MAX_ORDER_QTY' reason='...' symbol='000001.SZ' ...

Bedeutung: Wie oben, strukturierte Risikokontroll-Logzeilen, die die Suche erleichtern.

Order submission failed.

Bedeutung: Der Einreichungsprozess ist fehlgeschlagen (keine Gegenablehnung nach Genehmigung durch die Risikokontrolle). Überprüfen Sie die Verbindung und das sys_log.

[NOT_IMPLEMENTED] sync_from_broker is reserved for QMT broker integration (S2.1-b).

Bedeutung: Der Befehl sync hat die Remote-Synchronisierung noch nicht erfolgreich abgeschlossen. Dies ist eine erwartete Meldung und kein Laufzeitfehler.

8. 相关跳转

  • Start und Konfiguration: :doc:2-configuration-and-run

  • Lebenszyklus: :doc:3-Risiko-und-Auftrags-Lebenszyklus

  • Snapshot/Zugriffskontrolle/Auftragsablehnung: :doc:6-trader-snapshot-gate

  • Manuelles Rauchen: :doc:7-manual-smoke-live-grid-roadmap

  • CLI-Referenz: :doc:8-cli-trader-capability-matrix

  • Broker: :doc:4-Broker-Adapter-und-Integration

  • Praktisches Tutorial: tutorials/8-live-trade-risk-and-broker-walkthrough.md