製品リストとトラブルシューティング

この章は、ライブ取引をシミュレートするための「応急処置マニュアル」です。ログの場所、最初に確認するファイル、および一般的な問題のトラブルシューティングの順序について説明します。

ユーザーの皆様、Live はディスク上に数種類の固定「出力」を残します。これらを 4 つの専用フォルダーとして扱い、問題が発生した場合は、これらのフォルダーに従って正しい出力を見つけます。これは、大量の出力を盲目的に検索するよりもはるかに効率的です。

0. 适用场景

すでにライブモードで実行されており、送信の失敗、注文の拒否、異常なステータス、輸送中の注文の不一致などの問題が発生しています。
再起動の繰り返しを減らすために、固定順序で問題を特定したいと考えています。
ログパス、ローテーション戦略、および broker_order_id が書き戻されるかどうかを確認する必要があります。

1. 核心概念：四键产物

Qteasy は、各 Live アカウントにパスの 4 つの固定キー名を提供します (ファイルが存在しない場合でもパスは有効です)。 Live サブシステムの可観測性設計では、これら 4 種類のアーティファクトはそれぞれ「システムの実行方法、トランザクションの詳細、異常回復、リスク管理監査」に対応します。トラブルシューティングを行うときは、ログ全体を検索するのではなく、まず問題がどのカテゴリに属しているかを判断してから、対応するファイルを開いてください。

各列の意味: キー名: list_live_trade_artifacts / CLI artifacts によって返される辞書キー。 概要: ファイルの種類。 いつ開くか: 典型的なトリガーシナリオ。

使用方法: :doc:3-risk-and-order-lifecycle を押して注文拒否タイプを決定します → リスク管理については risk_log を確認し、トランザクションについては trade_log を確認してください。起動/アクセス制御/トレースについては、sys_log を確認してください。

キー名	それは何ですか？	いつオンにすればよいですか?
`sys_log`	システム動作ログ	タスクのスケジューリング、アクセス制御のアクティブ化、トレース、一般的なエラーのレポート
`trade_log`	取引詳細CSV	取引、手数料、ポジションの変更の詳細
`break_point`	ファイルをブレークポイントから再開します (キー名は `break_point`)	異常終了後に Trader ステータスを復元するにはどうすればよいですか?
`risk_log`	リスク管理命令拒否監査 (*.risk.log)	リスク管理拒否が疑われる場合を優先する

例 (API および 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'])

Trader シェルで artifacts (エイリアス ls-artifacts) と入力して、同じ 4 キーパスを取得することもできます。

パスのルール (概要):

相対パスは、Qteasy ルートディレクトリを基準にしてサポートされます。 ~/... ホームディレクトリを基準とした絶対パスもサポートされます。
パス sys_log_file_path と trade_log_file_path は、qt.configure(...) を使用して実行時に変更でき、すぐに有効になります。

2. 日志轮换

長期的なライブログにより、CSV ログとリスクログが蓄積されます。 Qteasy は期限切れのファイルを trade_log_keep_days (デフォルトは 3 日) までにクリーンアップします。

API: qt.rotate_trade_logs(days=None)
**CLI: rotatelogs (エイリアス rotate-logs)、オプションの --days N

クリーンアップ範囲 (現在のトランザクションログディレクトリ内):

trade_log_*.csv / trade_summary_*.csv / value_curve_*.csv
*.risk.log

新しい Python プロセスが qteasy をインポートするたびに、自動的に 1 回ローテーションされます。運用保守時に上記コマンドを手動で実行することもできます。

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

ステップを飛ばさないように、次の質問を順番に自分自身に問いかけてください。

ステップ 1 — インターフェイスに英語の拒否理由が表示されますか?

はい。これは、Order rejected by risk rule [...] と同様に、リスク制御パス (ステップ 3) に従います。
Order submission failed などのエラーが発生した場合は、送信/接続パス (ステップ 4) に進みます。
明らかなエラーメッセージはありませんが、動作が正しくありません → ステップ 6

ステップ 2 — artifacts を開き、4 つのパスが書き込み可能であり、ファイルが増加していることを確認します。

ステップ 3 — リスク管理の拒否

risk_log<リスク拒否> andrule_id` を確認してください
新しい注文明細行は表示されません (カウンター拒否とは異なります)

ステップ 4 — カウンターサービス / 接続

broker status: is_connected は、それが true かどうかを示します (シミュレーターでは、アダプター層がリクエストを処理できることを意味します)。
注文テーブル: rejected エントリと空のブローカー番号 (カウンターで拒否された注文) を持つ注文が含まれていますか?

ステップ 5 — 一貫性のない交通書類

デバッグモード: run --task diagnose_pending_orders
または、シェル: reconcile を使用して JSON を表示します。

ステップ 6 — 構成は期待どおりですか?

liveconfig --detail はスナップショットをチェックします。

ステップ 7 — trade_log と注文ステータスのシーケンスを比較し、ログ内の最終ステータス**を標準として使用します。

4. 高频故障剧本

各セクションは同じ順序に従います: **現象 → 最初に確認する内容 → 一般的な原因 → 次のステップ **。

A. リスク管理により注文が拒否されました。

問題: 英語エラーによる CLI の拒否。送信結果は空です {}
最初のチェック: risk_log に `<リスクが拒否されました> 注文テーブル ** 改行はありません**
一般的な理由: 1 回の取引制限を超えている、ホワイトリストに載っていない、取引時間外など。
次のステップ: ルールまたは順序パラメーターを調整し、同じシナリオで再テストします。詳細については、:doc:3-risk-and-order-lifecycle を参照してください。

B. 提出失敗（リスク管理のためではない）

問題: 有効な送信レコードがないか、ローカル検証エラーがあります。
最初のチェック: ブローカーのステータス、キャッシュ/ポジションの適切性、および sys_log エラースタック。
一般的な原因: 未接続、無効なフィールド、不十分なリソース
次のステップ: 接続またはフィールドを修復した後、再試行してください。

C. 拒否された注文に対するカウンターの処理

影響: 注文テーブルに、status=rejected と broker_order_id が空の行があります。
最初のチェック: トレースと、処理部門から返された reason。
一般的な理由: 模擬証券会社のルールでは、この注文は受け付けられません (リスク管理とは無関係です)。
次のステップ: :doc:6-trader-snapshot-gate 文書の拒否リストを参照し、リスク管理と混同しないでください。

D. 長期的な部分充填

現象: 注文は一貫して部分的にのみ処理されます。
最初の確認: 累積取引高と注文数。
一般的な理由: 必要な収益がまだ完全には実現されていません。または、市場の状況によりバッチのトランザクションが遅くなっている場合があります。
次のステップ: トランザクションフィードバックを使用してステータスを filled に更新するかどうかを決定します。

E. 市販後の状況は不確実です。

問題: 市場終了後に未決注文をどのように処理するかが不明瞭です。
最初のチェック: post_close 関連トレース、reconcile JSON。
次のステップ: キャンセル注文と最終ステータスを確認します。

F. Broker_order_id / 輸送中の注文の例外

現地注文ステータス、仲介注文番号、輸送中の注文リストが一致しない場合、現象はさまざまですが、すべて次の表に分類できます。このテーブルはライブ 5-C 観測可能 カテゴリにあり、:doc:6-trader-snapshot-gate の診断フィールドと一致します。シミュレータ上のリモート列は空であることがよくありますが、これは正常です。

各列の意味: 現象は、観察した矛盾です。 First Check は主要な証拠情報源です。 次のステップ は推奨されるアクションです (主に読み取り専用の診断であり、自動的には変更されません)。

使用方法: 「現象」行を照合 → 「最初に確認」を実行 → それでも不明な場合は DEBUG で --task diagnose_pending_orders を実行します。

現象	まず確認してください	次のステップ
リスク管理により注文が拒否される	`risk_log` には新しい注文明細は含まれません。	ルールの調整
カウンター拒否	注文が拒否され、ブローカーが空です。	trace / reason
送信されましたが、ブローカー ID がありません	承認ACKとライトバック	:doc:`4-broker-adapter-and-integration`
ローカルトランジットとリモートトランジット間の不一致	DEBUG: `run --task diagnose_pending_orders`	読み取り専用の診断。シミュレータのリモートエンドは空であることがよくあります。

CLI ヘルパー: reconcile、gate。

G. インターフェースとログの不一致

問題: CLI プロンプトとその後のログチェックが矛盾しているように見えます。
最初のチェック: 同じ注文 ID のすべてのレコードを 時系列で整列させます。
次のステップ: ログの最終状態に基づいて事後分析を実施します。

5. 运维建议

トランザクションログディレクトリの使用状況を定期的に確認してください。必要に応じて、rotatelogs --days N を使用します。
重要なランタイム日に liveconfig --detail の出力をスクリーンショットまたはテキストとして保存します。
長距離ランニングまたはプレリリースのリファレンス: doc:7-manual-smoke-live-grid-roadmap

6. 快速检查清单

正しいアカウント
設定が有効になります (liveconfig)
リスク管理システムは申請 (risk_log) を拒否しますか?
証券会社はこれ（ブローカーステータス）を扱うことができますか？
処理が成功したら、broker_order_id を書き戻す必要がありますか?
4 つのキーのパスが読み取り可能 (artifacts)

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

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

意味: ローカルリスク管理ルール MAX_ORDER_QTY が拒否されました – 数量が制限を超えました。 risk_log を確認してください。証券会社が注文を拒否したわけではありません。

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

意味: 上記と同様、構造化されたリスク管理ログ行で、検索が容易です。

Order submission failed.

意味: 提出プロセスは失敗しました (リスク管理承認後の反対拒否ではありません)。接続とsys_logを確認してください。

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

意味: sync コマンドはまだ実際のリモート同期を実現していません。これは予期されるメッセージであり、実行時のエラーではありません。

8. 相关跳转

起動と設定: :doc:2-configuration-and-run
ライフサイクル: :doc:3-risk-and-order-lifecycle
スナップショット/アクセス制御/注文拒否: :doc:6-trader-snapshot-gate
手動喫煙: :doc:7-manual-smoke-live-grid-roadmap
CLI リファレンス: :doc:8-cli-trader-capability-matrix
Broker: :doc:4-broker-adapter-and-integration
実践的なチュートリアル: tutorials/8-live-trade-risk-and-broker-walkthrough.md