Lista de productos y solución de problemas

Este capítulo es un «manual de primeros auxilios» para simular operaciones reales: dónde está el registro, qué archivo verificar primero y el orden en el que solucionar problemas comunes.

Estimado usuario, Live dejará varios tipos de «salidas» fijas en su disco. Trátelos como cuatro carpetas dedicadas y, cuando surjan problemas, siga estas carpetas para encontrar el resultado correcto; Esto es mucho más eficiente que buscar ciegamente entre cantidades masivas de resultados.

0. 适用场景

• Ya está ejecutando en modo en vivo y está experimentando problemas como fallas en el envío, rechazo de pedidos, estados anormales o inconsistencias en los pedidos en tránsito.

• Desea localizar el problema en un orden fijo para reducir los reinicios repetidos.

• Debe verificar la ruta del registro, la estrategia de rotación y si se reescribe broker_order_id.

1. 核心概念：四键产物

Qteasy proporciona a cada cuenta Live cuatro nombres de claves fijas para la ruta (la ruta sigue siendo válida incluso si el archivo no existe). En el diseño de observabilidad del subsistema Live, estos cuatro tipos de artefactos corresponden a «cómo se ejecuta el sistema, detalles de la transacción, recuperación de anomalías y auditoría de control de riesgos», respectivamente. Al solucionar problemas, primero determine a qué categoría pertenece el problema y luego abra el archivo correspondiente, en lugar de buscar en todo el registro.

El significado de cada columna: Nombre de clave: La clave dict devuelta por list_live_trade_artifacts / CLI artifacts; Qué es: El tipo de archivo; Cuándo abrirlo: El escenario desencadenante típico.

Cómo utilizar: Presione :doc:3-risk-and-order-lifecycle para determinar el tipo de rechazo de orden → marque risk_log para control de riesgos, marque trade_log para transacciones; marque sys_log para inicio/control de acceso/rastreo.

Nombre clave	¿Qué es?	¿Cuándo se debe encender?
sys_log	Registro de operación del sistema	Programación de tareas, activación de control de acceso, seguimiento, informes de errores generales
trade_log	Detalles de la transacción CSV	Detalles de transacciones, tarifas y cambios de posiciones.
break_point	Reanudar archivo desde el punto de interrupción (el nombre de la clave es break_point)	¿Cómo restaurar el estado Trader después de una salida anormal?
risk_log	Auditoría de rechazo de órdenes de control de riesgos (*.risk.log)	**Priorizar cuando se sospeche de rechazo del control de riesgo

Ejemplos (API y 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'])

También puede obtener la misma ruta de cuatro teclas escribiendo artifacts (alias ls-artifacts) en el Trader Shell.

Reglas de ruta (breves):

• Se admiten rutas relativas relativas al directorio raíz de Qteasy; También se admiten rutas absolutas relativas al directorio de inicio ~/....

• Las rutas sys_log_file_path y trade_log_file_path se pueden modificar en tiempo de ejecución usando qt.configure(...) y entrarán en vigor de inmediato.

2. 日志轮换

El registro en vivo a largo plazo acumula registros CSV y de riesgo. Qteasy limpia los archivos caducados en trade_log_keep_days (3 días predeterminados).

• API: qt.rotate_trade_logs(days=None)

• **CLI: rotatelogs (alias rotate-logs), opcional --days N

Alcance de la limpieza (dentro del directorio de registro de transacciones actual):

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

• *.risk.log

Cada vez que un nuevo proceso de Python importa qteasy, girará automáticamente una vez; También puede ejecutar manualmente el comando anterior durante la operación y el mantenimiento.

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

Por favor, hágase las siguientes preguntas en orden, evitando saltarse pasos:

Paso 1: ¿Se muestra algún motivo de rechazo en inglés en la interfaz?

• Sí, y sigue la ruta de control de riesgos (Paso 3), similar a Order rejected by risk rule [...].

• Si encuentra errores como Order submission failed, continúe con la ruta de envío/conexión (Paso 4).

• No hay mensaje de error obvio pero sí comportamiento incorrecto → Paso 6

Paso 2: abre artifacts y confirma que se pueden escribir en las cuatro rutas y que el archivo está creciendo.

Paso 3: Rechazo del control de riesgos

• Marque risk_log andrule_id`

• No debería aparecer ninguna línea de pedido nueva (a diferencia de los rechazos contrarios)

Paso 4 — Servicio de mostrador / Conexión

• El broker status: is_connected indica si es verdadero (en el simulador, esto significa que la capa del adaptador puede manejar la solicitud).

• Tabla de pedidos: ¿Contiene pedidos con entradas rejected y un número de corredor vacío (pedido rechazado en el mostrador)?

Paso 5: Documentos de tránsito inconsistentes

• En modo DEPURACIÓN: run --task diagnose_pending_orders

• O use Shell: reconcile para ver el JSON.

Paso 6: ¿La configuración es la que esperaba?

• liveconfig --detail comprueba la instantánea.

**Paso 7: compare trade_log con la secuencia de estado del pedido y utilice el estado final en el registro como estándar.

4. 高频故障剧本

Cada sección sigue la misma secuencia: Fenómeno → Qué comprobar primero → Causas comunes → Siguiente paso.

A. Orden rechazada por control de riesgos.

• Problema: Rechazo de CLI debido a un error en inglés; el resultado del envío está vacío {}

• Primera verificación: risk_log que contiene ` Tabla de pedidos no nueva línea

• Razones comunes: Exceder el límite de transacción única, no estar en la lista blanca, fuera del horario comercial, etc.

• Próximos pasos: Ajuste las reglas o los parámetros del pedido y vuelva a realizar la prueba en el mismo escenario; consulte :doc:3-risk-and-order-lifecycle para obtener más detalles.

B. Envío fallido (no debido al control de riesgos)

• Problema: No hay registro de envío válido o error de verificación local.

• Primera verificación: estado del corredor, adecuación del efectivo/posición y pila de errores sys_log.

• Causas comunes: No conectado, campo no válido, recursos insuficientes

• Siguiente paso: Vuelva a intentarlo después de reparar la conexión o el campo.

C. Contragestión de pedidos rechazados

• Impacto: La tabla de pedidos tiene filas donde status=rejected y broker_order_id están vacías.

• Primera verificación: rastreo y el reason devuelto por el departamento de procesamiento.

• Razón común: Las reglas de la casa de bolsa simulada no aceptan esta orden (sin relación con el control de riesgos).

• Siguiente paso: Consulte la lista de rechazos en el documento :doc:6-trader-snapshot-gate y no la confunda con control de riesgos.

D. Cumplimiento parcial a largo plazo

• Fenómeno: Los pedidos se cumplen sistemáticamente sólo parcialmente.

• Primera comprobación: Volumen de operaciones acumulado frente al número de órdenes.

• Razones comunes: Las devoluciones requeridas aún no se han realizado en su totalidad; o las condiciones del mercado están provocando transacciones lentas en lotes.

• Siguiente paso: Determine si los comentarios de la transacción deben usarse para actualizar el estado a filled.

E. El estado poscomercialización es incierto.

• Problema: No está claro cómo manejar las órdenes pendientes después del cierre del mercado.

• Primera comprobación: post_close rastros relacionados, reconcile JSON.

• Siguiente paso: Verificar la orden de cancelación y el estado final.

F. broker_order_id / Excepción de orden en tránsito

Cuando el estado de la orden local, el número de orden de corretaje o la lista de órdenes en tránsito no coinciden, los fenómenos son variados, pero todos pueden clasificarse en las siguientes tablas. Esta tabla está en la categoría viva 5-C observable, consistente con los campos de diagnóstico de :doc:6-trader-snapshot-gate; Las columnas remotas del simulador suelen estar vacías, lo cual es normal.

El significado de cada columna: Fenómeno es la contradicción que observas; Primera verificación es la fuente principal de evidencia; Siguiente paso es una acción sugerida (principalmente un diagnóstico de solo lectura, no modificado automáticamente).

Cómo utilizar: Haga coincidir la línea «fenómeno» → Ejecute «Verificar primero» → Si aún no está claro, ejecute --task diagnose_pending_orders en DEBUG.

Fenómeno	comprobar primero	Siguiente paso
El control de riesgos rechaza pedidos	risk_log no contiene líneas de pedido nuevas.	Reglas de ajuste
Contra rechazo	Orden rechazada, corredor vacío.	trace / reason
Enviado pero sin ID de corredor	ACK de aceptación y reescritura	:doc:4-broker-adapter-and-integration
Inconsistencia entre tránsito local y remoto	DEBUG: run --task diagnose_pending_orders	Diagnósticos de sólo lectura; El extremo remoto del simulador suele estar vacío.

Ayudantes de CLI: reconcile, gate.

G. Inconsistencia entre la interfaz y los registros

• Problema: Las indicaciones de la CLI y las comprobaciones de registros posteriores parecen contradictorias.

• Primera verificación: Alinee todos los registros del mismo ID de pedido en secuencia de tiempo.

• Siguiente paso: Realice un análisis post mortem basado en el estado final del registro.

5. 运维建议

• Verifique periódicamente el uso del directorio del registro de transacciones; si es necesario, utilice rotatelogs --days N.

• Guarde el resultado de liveconfig --detail en los días de ejecución críticos como una captura de pantalla o texto.

• Carrera de larga distancia o referencia previa al lanzamiento: doc:7-manual-smoke-live-grid-roadmap

6. 快速检查清单

• Cuenta correcta

• La configuración entra en vigor (liveconfig)

• ¿El sistema de control de riesgos rechaza la solicitud (risk_log)?

• ¿Puede la firma de corretaje manejar esto (estatus de corredor)?

• ¿Se debe volver a escribir broker_order_id tras un procesamiento exitoso?

• Las rutas de cuatro claves son legibles (artifacts)

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

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

Significado: Regla de control de riesgos local MAX_ORDER_QTY rechazada: la cantidad superó el límite. Marque ⟦CÓDIGO0⟧; No fue una firma de corretaje la que rechazó la orden.

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

Significado: Igual que arriba, líneas de registro de control de riesgos estructuradas, lo que facilita su búsqueda.

Order submission failed.

Significado: El proceso de envío falló (no es un contrarechazo después de la aprobación del control de riesgos). Verifique la conexión y sys_log.

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

Significado: El comando sync aún no ha logrado la sincronización remota real. Este es un mensaje esperado y no un error de tiempo de ejecución.

8. 相关跳转

• Inicio y Configuración: :doc:2-configuration-and-run

• Ciclo de vida: :doc:3-risk-and-order-lifecycle

• Instantánea/Control de acceso/Rechazo de pedido: :doc:6-trader-snapshot-gate

• Humo manual: :doc:7-manual-smoke-live-grid-roadmap

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

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

• Tutorial práctico: tutorials/8-live-trade-risk-and-broker-walkthrough.md