ポリシーのスナップショット、アクセス制御のアクティブ化、および長期的な可観測性 (5-A / 5-B / 5-C)

ユーザーの皆様、この章では 3 つの 高度な**機能を紹介します。戦略実行前の **データ スナップショット、市場開始前の スタートアップ アクセス制御、長期取引中の **調整とログ**です。基本的な Live アプリケーションをまだ正常に実行していない場合は、まず 模擬取引プラットフォーム: 構成と操作 をお読みください。

この章はどのような問題を扱っていますか? すべてのステップでデータを繰り返し取得する分単位の戦略は時間がかかり、市場データが欠落する傾向があります。適切な設定やデータを持たずに市場が開く前に注文を行うと、重大なリスクが伴います。これらのチェックを構成可能にし、簡単に確認できるようにログに記録しました。

内部コード名のマッピング (メンテナ/スモークドキュメントによって使用)

qteasy ライブの進化において、5-A / 5-B / 5-C は、それぞれポリシー スナップショット、アクティベーション アクセス コントロール、長期観測可能性の 3 つの機能を指します。 Smoke のドキュメントと管理者のメモではコード名が使用されます。ユーザーは、右側の「ユーザー指定の名前」を覚えておくだけで済みます。以下の表は、コード名と一般的な使用法の対応を示しています。この章の残りの部分を読むと、「5-B」を「アクティベーション アクセス コントロール」として理解できます。

各列の意味: コード**は内部ステージ番号です。 **ユーザー割り当て名 は、ドキュメントで推奨されている名前です。 **一文**は、ライブ パイプラインにおけるこの機能の位置を示しています。

使用方法: 本文中に 5-A などのコードがある場合は、この表を参照してください。 模擬取引プラットフォーム: 構成と操作 §4「ポリシー スナップショット」「アクセス制御の開始」行の構成キー名を参照してください。

コードネーム

ユーザー名

要するに

5-A

戦略のスナップショット

データは戦略の実行前にプリフェッチされ、このステップではデータを再利用して冗長 I/O を削減します。

5-B

アクセス制御を有効にする

開く/実行する前に、準備状況を確認してください。失敗した場合は、アラームまたはブロックがトリガーされる必要があります。

5-C

長期観測可能

証券口座との注文マッピング、リスクログローテーション、輸送中の注文の調整と診断

5-A: 戦略のスナップショット

次のように考えることができます。各「試験」の前に、机の上に試験用紙と資料を準備します。実際に質問に答えるときに、印刷室に急いで行く必要はもうありません。

  • live_trade_split_strategy_prepare=True の場合、qteasy は、各 run_strategy スケジュール時間の 前 に prepare_strategy_snapshot タスクを挿入します (リード タイムは live_trade_prepare_lead_seconds によって制御されます。0 は同時にキューに入れることを意味しますが、順序により準備が最初であることが保証されます)。

  • prepare_strategy_snapshot 関数は、run_strategy の前に行われた重労働を完了します。つまり、1 日未満の頻度データの更新、データ バッファーの準備、ライブ価格の更新、およびプロセス データの挿入です。完了後、メモリ内に「スナップショット有効」マーカー (取引日 + ステップ番号 + 時間) が残ります。

  • その後、run_strategy がスナップショットがまだ live_trade_strategy_snapshot_max_age_seconds 内にあり、ステップ番号が一致していることが判明した場合、上記のフェッチは繰り返されません。それ以外の場合は、snapshot_missing / snapshot_stale が記録され、このステップの戦略は **スキップ**されます (信号の計算に期限切れのデータを使用することを避けるため)。

  • スプリットが有効な場合、prepare_strategy_snapshot と run_strategy はメインスレッドで (非同期のライブ価格設定タスクから分離されて) 同期的に実行され、複数のスレッドが同時に Operator にアクセスするのを防ぎます。

実際の動作との違い: スナップショットはメモリ内にあるため、プロセスの再起動後に再度準備する必要があります。これらはディスク上の永続的なキャッシュではありません。

5-B: アクセス制御の開始(run_startup_gate)

これは、出発前の安全性チェック、つまり戦略の準備ができているかどうか、必要なデータ テーブルが利用可能かどうか、そして (オプションで) ローカル元帳が証券会社側と一致しているかどうかのチェックと考えることができます。

  • live_trade_startup_gate_mode:

    • off — アクセス制御をオフにする

    • warn — 障害はログに記録/トレースされるだけですが、ただしトランザクションは引き続き許可されます (最初は段階的にロールアウトすることをお勧めします)。

    • block — 失敗した場合は拒否します。次に、run_strategy がキューに入れられます (skip_reason=gate_failed)。

  • Trader は、毎日のスケジュールを生成した後、アクセス制御を呼び出します (非取引日はすぐにスキップされます)。

  • 階層化を確認します (障害コードはトレース ``failures`) に書き込まれます:

    • L1: Operator の準備はできていますか?アカウントは存在しますか?

    • L2: メイン履歴テーブルがデータ ソース内にあるかどうか (asset_type などによって日次頻度テーブルにマッピングされる)

    • L3 (オプション): ブローカーが空ではないリモート キャッシュ/ポジションを返した場合、それをローカルのものと比較します。リモート API が実装されていない場合は、厳密な比較を実行しないでください。

手動排煙グリッド道路の完全なリストについては、シミュレートされたライブ取引手動煙生成ソリューション (live_grid_multi) を参照してください。

5-C: 台帳、ログ、およびリカバリの可観測性

5-A/5-B を超えると、長距離のトラブルシューティングと監査**が容易になります (**自動注文変更/補償を除く。実際の QMT リモート クエリは新しいバージョンです)。

  • 注文 ↔ ブローカー ID マッピング: 承認が成功すると、broker_order_id / broker_name will be written back; if the order is rejected, rejected が書き戻され、ブローカー フィールドは空になります。

  • ログ ローテーション拡張機能: rotate_trade_logs は、取引 CSV に加えて、期限切れの *.risk.log をクリーンアップします (ルールについては、製品リストとトラブルシューティング を参照)。

  • 調整および診断トレース:

    • pre_open および post_close コマンドは、reconcile チェックポイント (checkpoint_passed、checkpoint_warn など) を出力します。

    • デバッグタスク ``diagnose_pending_orders`: ローカルとリモートの未決注文の読み取り専用の比較。

初心者のための結論: 2 つのタイプの「注文拒否」

ライブ注文プロセスでは、RiskManager レビューデスク (リスク管理) または ブローカー処理 (カウンター) のいずれかで「拒否」が発生する可能性があり、証拠はまったく異なる場所にあります。これについては、3-risk-and-order-lifecycle ドキュメントでプロセスの観点からすでに説明されています。以下の表は、迅速なトラブルシューティングのために order table と broker_order_id の比較を示しています。

列の意味: パス**は注​​文の拒否/成功のタイプを示します。 **ローカル順序テーブル は、新しい行が追加されたかどうかを示します。 broker_order_id はライトバックが必要かどうかを示します。 監査 は、最初に開くことが推奨されるファイルまたはテーブルを示します。

使用方法: CLI には、危険な拒否理由と新しい注文がないことが表示されます → 最初の行;注文リストに「拒否」と表示され、ブローカー番号が空 → 2 行目;ブローカー番号が存在する → 3 行目で、取引ステータスを確認します。

例: risk_log には「<リスク拒否>」が含まれています。 さらに、「注文」セクションに対応する新規注文がない場合、その注文はリスク管理によって拒否されます。証券会社の接続情報を確認しないでください。

パス

ローカル注文フォーム

broker_order_id

監査

リスク管理による注文拒否

保管庫には置かれていません

—

*.risk.log + ``<RISK REJECTED> ``

柜台受理拒单

rejected という行があります

ヌル

オーダーフォーム+トレース

申請が成功しました

submitted など

返信する

オーダーフォーム+トレース

Diagnostic_pending_orders 出力フィールド (概要)

  • local_pending_count — ローカル保留カウント

  • ``remote_pending_count` — 奇数のリモート保留リクエスト (シミュレーターは通常は空です)

  • local_pending_without_broker_order_id — ローカル注文が送信されましたが、ブローカー ID がありません

  • local_pending_missing_remote — 証券口座はローカルに存在しますが、リモートには存在しません。

  • remote_pending_not_in_local — リモート エンドではマッピングされていますが、ローカル エンドではマッピングされていません。

CLI とデバッグ (運用とメンテナンス)

Trader シェル (--ui cli) 一般的に使用されるコマンド (ヘルプは英語です):

  • gate / startup-gate — ゲート制御の起動プロセスを手動で実行します。

  • reconcile / snapshot-reconcile — 調整 JSON

  • run --task diagnose_pending_orders — 未決注文を診断します (DEBUG が必要)

  • artifacts / ls-artifacts — 4 結合アーティファクト パス

  • rotatelogs / rotate-logs — 手動ログローテーション

  • broker status|connect|disconnect — 仲介セッション (シミュレーターがフラグ)

  • sync / pull-state — 予約済み、実際のリモート同期はまだ実装されていません。

次の取引日の推奨事項

  • 5-A: トレース内の strategy_run_skipped エントリが多すぎますか?ライブ価格の頻度は戦略ステップの頻度より低くありませんか?

  • 5-B: 最初に warn を使用して gate_warn / gate_failed を確認します。次に、block を試す前に、CLI gate を使用して確認します。

  • 5-C: reconcile と diagnose_pending_orders でマーケットをクローズします。必要に応じて、rotatelogs --days N を使用してリスクのクリーンアップを確認します。

関連資料